Copyright © 2017-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
この文書は、Web で使用される文字列について、言語および方向を識別するためのベストプラクティスを説明します。
この節では、この文書の公開時点における位置付けについて説明します。現在のW3C 公開文書の一覧およびこの技術報告書の最新版は、 W3C標準および草案の 索引で確認できます。
この文書に対するコメントを歓迎します。ただし、コメントを追跡しやすくするため、コメントごとに個別の課題を作成し、 URLを使用してコメント対象の節を示してください。
この文書は、国際化 ワーキンググループによって、 勧告 トラックを使用した初回公開作業草案として公開されました。
初回公開作業草案としての公開は、 W3Cおよびその会員による承認を意味するものではありません。
これは草案文書であり、いつでも他の文書によって更新、置換、または廃止される可能性があります。 この文書を進行中の作業以外のものとして引用することは不適切です。
この文書は、 W3C 特許 方針の下で運営されるグループによって作成されました。 W3Cは、このグループの成果物に関連して行われた 特許開示の公開一覧 を管理しています。このページには、 特許を開示するための手順も含まれています。本人が 必須クレーム を含むと考える特許について実際の知識を有する者は、 W3C特許方針の第6節に従って情報を開示しなければなりません。
この文書には、 2025年8月18日付W3Cプロセス文書が適用されます。
この文書は、JSON、WebIDL、およびその他の非マークアップデータ言語に基づく形式に関連する一連の仕様レビューで、 国際化ワーキンググループが行った観察の結果として策定されました。XMLなどのマークアップ形式とは異なり、 これらのデータ言語は通常、拡張可能な属性を提供しておらず、言語または書字方向のメタデータを 組み込むことを前提として設計されていません。
この文書の概念は、形式化されたデータ構造の一部として文字列が使用される場合だけでなく、 JavaScriptスクリプトや保存された文字列の一覧から単に生成される場合を含め、 ウェブ上で文字列が使用されるあらゆる場面に適用できます。
ウェブ上の自然言語 情報は、言語および書字方向のメタデータの存在に依存し、その恩恵を受けます。Unicodeのサポートとともに、 テキスト範囲のブロック方向および 自然 言語を含めて指定するための仕組みは、ウェブ向けの新しい形式や技術を開発する際の 主要な国際化上の考慮事項の1つです。
HTMLやXMLなどのマークアップ形式、およびCSSやXSLなどの関連するスタイル言語は、 十分に成熟しており、組み込み機能を通じて世界中の言語の交換と表示をサポートしています。 文字列および文字列ベースのデータ形式にも、世界中の言語と文化を完全かつ一貫して サポートするために、同様の仕組みが必要です。
この文書では、[RFC2119]の 大文字イタリック体のキーワードは通常の意味を持ちます。また、次の表記規則も使用します。
定義は、このように異なる背景色と 装飾で表示されます。
ベストプラクティスは、このように異なる背景色と 装飾で表示されます。
この節では、この文書の内容を理解するために必要な主要用語の簡潔な定義を示します。 ここに記載されている用語の大部分は、[I18N-GLOSSARY]から引用したものであり、 利便性のためにここで再掲しています。
双方向テキストまたは右から左に書かれるテキストに詳しくない場合は、 基本的な説明がこちらにあります。 これにより、Unicode双方向 アルゴリズムの仕組み、およびそれとブロック方向 との相互作用について基本的に理解でき、この文書を読むうえで役立ちます。追加資料は、 国際化ワーキンググループの仕様開発者向け ベストプラクティスにあります。
メタデータとは、データに 関するデータです。つまり、追加の文脈、意味、または表示情報を提供するために データ構造に含められる情報です。この文書では、メタデータの役割は書字方向および言語に関する 情報を表現することです。[I18N-GLOSSARY]
生成者とは、後で保存、処理、 または交換するために自然言語の文字列データを作成するあらゆるプロセスです。[I18N-GLOSSARY]
利用者とは、表示または処理のために 自然言語の文字列を受け取るあらゆるプロセスです。[I18N-GLOSSARY]
シリアル化に関する取り決めとは、文字列メタデータの シリアル化について生成者と利用者が共有する理解です。これには、その解釈、シリアル化、読み取り、 送信、削除などの方法が含まれます。[I18N-GLOSSARY]
Unicode双方向アルゴリズム [UAX9]は、 UBAとも呼ばれ、段落方向という概念を 定義しています。これは「段落」の初期基底方向であり、左から右または 右から左のいずれかに解決されます。「段落」という用語は、UBA内部で固有の意味を持ちます。 この文書の文脈では、ウェブ上の文字列やその他のデータは一般に文書形式内の 「テキストの段落」ではないため、この用語は誤解を招く可能性があります。この文書では通常、 次の2つのより具体的な用語を使用します。
ブロック方向。テキストブロックの 初期基底方向であり、左から右または右から左のいずれかに解決されます。 ブロックとは、文書内の段落やデータファイル内の文字列など、テキスト全体を1つの単位として 扱うものを指します。「ブロック」という名称は、インライン方向との対比として選ばれています。 Unicodeでは、この値を段落 方向と呼びます。[I18N-GLOSSARY]
文字列の書字方向。特定の文字列全体の 書字方向であり、文字列内部の方向性を持つランの表示順序を示します。さまざまなデータ構造内で 送信される文字列は、段落などのブロックに挿入されることがよくあります。この場合、文字列の 双方向分離の一部として、 文字列の書字方向が必要です。
この文書では、文字列全体の文字列の書字方向を 識別すること、およびさまざまな文脈で文字列を表示する際にその書字方向を送信し適用する方法を 扱います。文字列内部のテキストランの書字方向または表示を決定する方法については扱いません。
双方向 アルゴリズムは、主に文字のプロパティに基づいて隣接する文字を配置することに重点を置いています。 ブロック方向は、（a）強い方向型を持つLTR文字およびRTL文字のランが表示される 視覚的な順序と方向、ならびに（b）句読点などの弱い方向性または中立的な文字が存在する場合に、 それらの項目を他のコンテンツに対してどこに配置するかを決定します。
文字列メタデータを処理する代替手段を、文脈から切り離して検討することはできません。 文字列の処理とデータ形式について議論するための枠組みを確立する必要があります。
文字列は、コンテンツ作成者がプレーンテキストエディター、テキストメッセージ、または編集ツールに 文字列を入力する場合、スクリプトがウェブページからテキストを抽出する場合、別のアプリケーションや リポジトリから既存の文字列集合を取得する場合など、さまざまな方法で作成できます。この文書で 検討するデータ形式では、多くの文字列がバックエンドのデータリポジトリやさまざまな種類の データベースから取得されます。文字列のソースは、データの文字列の書字方向および言語に関する情報を含む インターフェイス、API、またはメタデータを提供する場合があります。また、書字方向または言語が 提供または指定されていない場合に適した既定値を提供するものもあります。この文書では、 文字列の生成者とは、人間か仕組みかを問わず、保存または送信するために 文字列を作成または提供するソースを指します。
文字列を作成するときは、（a）文字列に関連付ける適切な言語および文字列の書字方向を検出または取得し、 （b）必要に応じて、言語および文字列の書字方向を保存および伝達できる形で 文字列を設定するための手順を実行する必要があります。
たとえば、HTMLフォームから抽出された文字列の場合、文字列の書字方向は、フォームフィールドの算出値から
検出できます。この値は、html要素などの先行する要素から継承される場合や、
input要素自体のマークアップまたはスタイルによって
設定される場合があります。利用者は、キーボード
ショートカットキーを使用してフォームフィールドの書字方向を変更することもできます。
dirname属性は、その値をフォーム送信時に自動的に
伝達する方法を提供します。
同様に、HTMLフォーム内の言語情報は通常、htmlタグのlang属性、またはツリー内でlang属性を持つ祖先要素から継承されます。
文字列の生成者が、別の生成者によって保存された場所から文字列を受け取っており、 その文字列の書字方向および言語がすでに確立されている場合、 生成者は、言語と文字列の書字方向がすでに設定されていることを理解し、その情報を利用者向けに 変換または符号化する方法を理解する必要があります。
利用者とは、処理のために文字列を受け取り、場合によっては利用者に 提示される文脈にその文字列を配置するアプリケーションまたはプロセスです。表示目的では、 その文脈において文字列のブロック方向および言語が 正しく適用されるようにしなければなりません。処理目的では、少なくとも言語と書字方向を保持し、 言語固有の操作を行うために言語および書字方向のデータを使用する必要がある場合があります。
文字列を適切に表示するには、追加のマークアップを適用する、制御コードを追加する、または 表示プロパティを設定することによって、文字列の 書字方向および言語をレンダリング文書またはプロセスに提供する必要があります。 これにより、この表示文脈で文字列を正しく表示するために適用すべき文字列の書字方向または言語がレンダリングソフトウェアに 示されます。言語と書字方向の両方について、それが適用されるテキスト範囲の境界を明確に しなければなりません。テキストの書字方向については、双方向アルゴリズムの波及効果を避けるため、 埋め込まれた文字列を周囲のテキストから分離する必要もあります。[UAX9]
ある文書形式の利用者が、別の文書形式の生成者になる場合があることに 注意してください。
あらゆる生成者と利用者の間には、 文書形式に何が含まれ、各フィールドまたは属性内のデータが何を意味するかについての 取り決めが必要です。文字列の生成者が、その文字列の文字列の書字方向または言語に関する 情報を収集して伝達するために特別な手順を実行する場合、利用者が生成者によるその情報の 符号化方法を理解することを前提として行わなければなりません。
生成者が何の処置も行わない場合でも、利用者は適切な文字列の書字方向および言語を決定するために従う規則を 決めなければなりません。それが何らかの既定値を提供するだけの場合でも同様です。
一部のシステムまたは文書形式では、文字列の生成者および利用者に必要な動作が完全に 規定されています。それ以外では、そのような取り決めは用意されておらず、必要な言語または 書字方向の情報をどのように符号化、送信し、後で復号するかについて、利用者自身が取り決めを 定める必要があります。JSONのような低水準仕様は、既定では文字列メタデータ構造を提供しないため、 それらに基づく文書形式は独自に「取り決め」を提供する必要があります。
ウェブでは、ほとんどのデータを符号化するために文字列および文字列シーケンスを使用します。
異なるデータ型（数値、時刻値、またはbase64などのバイナリデータのシリアル化）を
除外しても、文字列データ型を使用すると定義されているものの、自然
言語データ値として使用することを意図していない値が存在します。たとえば、CSSの予約済み
キーワードやWebIDL文書内の各種定義名など、仕様によって定義される構文コンテンツは、
それぞれの文書形式またはプロトコルのローカライズ可能なテキストの
一部ではありません。
多くの仕様では、利用者が所定の名前空間または文書形式内で利用者提供値を指定することも 許可しています。たとえば、Wi-FiネットワークのSSIDは利用者が定義します。CSSスタイルシートの クラス名も同様です。多くの仕様は、これらの名前に幅広いUnicode文字を使用することを許可しており、 また許可することが推奨されています。多くの利用者は、値を扱いやすくするため、いずれかの 自然言語の単語として認識できる値を選びます。しかし、これらの文字列が自然言語の単語で 構成されていても、この種類の文字列はローカライズ可能な テキストとは見なされず、言語または文字列の書字方向に関連する追加メタデータを 付加する必要はありません。通常、それらはコンピューターが値を照合できるようにする単なる識別子です。
場合によって有用な判定方法として、識別子を
tK0001.37Bのような任意の文字列に置き換えても引き続き許可され、
機能し、「通常」と見なされるのであれば、それはローカライズ可能な
テキストではありません。
たとえば、以下の基本例では、JSON文書内のすべてのキー
（id、title、authors、language、
publisherなど）は構文コンテンツです。ISBN、言語タグ、公開日などの
データ値も構文コンテンツです。実際の書名、著者名、出版社名だけが自然言語データ値であり、
したがってローカライズ可能な
テキストです。
この節では、ウェブ上のデータ形式において言語および文字列の書字方向を識別するための、 国際化（I18N）ワーキンググループによる一連のベストプラクティスを示します。場合によっては、 I18N WGの推奨事項に追加の標準化が必要であったり、完全な採用を妨げる障壁が存在したりするなど、 既存の標準に課題があります。
主な問題は、データ値の生成者と利用者の間で共通のシリアル化に関する取り決めを確立し、各データフィールドの 言語および文字列の書字方向を どのように符号化、検出、解釈するかを双方が理解できるようにすることです。自然言語文字列フィールドの 言語と文字列の書字方向の 両方を提供するためにメタデータを使用することで、必要な情報が確実に存在し、最小限の処理で 提供および抽出でき、生成者または利用者がデータを走査または変更する必要がなくなります。
国際化ワーキンググループがすべての仕様で求める、最も基本的なベストプラクティスは次のとおりです。
自然言語テキストを含むあらゆる文字列フィールドについて、その特定の文字列の 言語および文字列の書字方向を 判定できるようにしなければなりません（MUST）。この判定には、文字列レベルまたは文書レベルのメタデータを 使用することが推奨され（SHOULD）、ヒューリスティックに依存しないことが 推奨されます（SHOULD NOT）。
この節では、文字列値のシリアル化に関する4つの手法について説明します。仕様は、 文書形式およびプロトコルにおける言語と書字方向のメタデータを管理するための完全な解決策を 形成するように、これらを組み合わせて使用することを意図しています。
非言語フィールド （すなわち、人間の言語ではないデータを含む文字列）に対して言語または書字方向のメタデータを 割り当てたり要求したりしないでください。これにはアプリケーション内部の データ値も含まれることに注意してください。[INTERNATIONAL-SPECS]
構文コンテンツ項目または 利用者提供値では、 人間に意味を伝える単語のようなトークンが値として使用されることがよくあります （たとえばデバッグを容易にするため）。ただし、利用者に表示する際には、これらの値を一貫して ローカライズ可能な表示文字列で囲む必要があります。
利用者が非言語データに
言語タグを割り当てる必要がある場合は、言語タグzxx（非言語）を使用することが
推奨されます（SHOULD）。利用者がそのようなデータに
文字列の書字方向を割り当てる必要がある場合は、
値autoを使用することが推奨されます（SHOULD）。
仕様は、構文コンテンツを、 利用者提供値を含め、 ローカライズ可能なテキストと 慎重に区別することが推奨されます（SHOULD）。
個々のローカライズ可能なテキスト値の 言語および文字列の書字方向を示すために、 フィールドベースのメタデータまたは文字列データ型を使用してください。
単一の言語で現れるローカライズ可能なテキスト
フィールドでは、値を表すためにデータ構造を使用します。推奨される表現は、3つのフィールドを
持つオブジェクトです。valueフィールドには実際の文字列が含まれます。
langフィールドには、[BCP47]に準拠する妥当な言語タグが含まれます。
dirフィールドには、文字列の文字列の書字方向（ltr、
rtl、autoのいずれか）が含まれます。
言語または文字列の書字方向を決定するために ヒューリスティックを使用すると、特定の場合には必ず失敗するため、そのような文字列について 正しい結果を指定する方法が必要です。メタデータを割り当てること （リソース全体の既定値として、または文字列固有のラベルとして）は意図的な行為であり、 ヒューリスティックを適用して結果を推測する必要をなくします。
ブロック方向を 示すためにメタデータを使用することが推奨されます。これは、 最初の強い文字などの方法を使用して利用者が書字方向を推定したり、 データ自体の変更を必要とする方法（RLM/LRMマーカーの挿入や 双方向制御文字など）を使用したりする必要がなくなるためです。
[WebIDL]で定義されたデータ構造では、それぞれの
ローカライズ可能なテキスト
（自然言語テキスト）フィールドを
として
定義してください。
Localizable
これにより、言語と書字方向の両方のメタデータが組み合わされ、一貫して採用された場合には、 異なる形式間の交換が容易になります。異なる仕様および文書形式間で一貫性を保つことで、 文字列データを容易に交換できます。フィールド属性に同じ名称を付け、同じセマンティクスを 採用することにより、異なる仕様が他のデータソースからリソースへ値を追加したり、 リソースから値を抽出したりすることが容易になります。
リソースに多数の自然言語文字列が含まれる場合（特にそれらの文字列がすべて同じ言語の場合）、 上述したローカライズ済み文字列表現を使用すると非効率になることがあります。これらの文字列を 符号化する複雑さを軽減するため、仕様は言語および文字列の 書字方向について、リソースレベルの既定値を確立できます。言語は書字方向を含意しないため、 これらは別々の値です。任意の文字列値について、上記の 表現を使用して言語または書字方向のいずれかを上書きできるようにする必要があります。
リソース全体の既定値とは、 リソースまたは文書レベルで指定され、そのリソースに含まれるラベルなしの値に適用できる値です。
仕様は、所定のリソース内のすべての文字列について、既定の言語および 既定の文字列の 書字方向を提供する仕組みを定義してもかまいません（MAY）。ただし、リソース全体の既定値だけで十分であると 仮定してはなりません（MUST NOT）。リソース全体の設定が 利用できる場合でも、文字列固有のメタデータを使用してその既定値を上書きできなければなりません。
仕様で独自の文書レベルの既定値を定義する場合は、次の2つの任意フィールドを提供してください。
リソース全体の既定言語フィールドはlanguageという名前にし
（SHOULD）、[BCP47]に準拠する妥当な
言語タグを含むものとして規定することが推奨されます（SHOULD）。
実装には、[BCP47]言語タグが整形式であるかどうかだけを
検査する必要があると規定することが推奨されます（SHOULD）。
既定値の例外は常に発生し得るため、利用者が文字列ごとに既定値を上書きできる必要があります。
書字方向がメタデータを使用して外部から設定されている場合、最初の強い文字に基づく
ヒューリスティックは文字列に適用されません。
U+200F RIGHT-TO-LEFT MARKのような強い方向性を持つ文字が
文字列の先頭に付加されている場合でも、リソース全体の既定メタデータによって文字列の表示が
上書きされ、波及効果が発生することが
あります。そのため、文字列の書字方向がリソース全体の既定値と一致しない
文字列について、既定値を上書きする文字列レベルのメタデータをコンテンツから提供できる必要があります。
[JSON-LD]の@contextの仕組みを
使用できる仕様では、文書レベルの既定値を提供するために@languageおよび
@directionフィールドを使用してください。
文書内で単一フィールドの複数の言語版を保存するには、言語マップを
使用してください。[WebIDL]で定義されたデータ構造では、
フィールドの定義にLanguageMapを使用してください。
世界は単一言語ではありません。文書に単一の言語しか含められない場合、コンテンツを ローカライズするために、言語ごとに文書の複数版を提供する必要があります。また、 コンテンツを要求するときに言語ネゴシエーションが必要になる場合もあります。
この問題に対処する1つの方法は、文書内の各ローカライズ可能なテキスト フィールドに複数言語の値を許可することです。
言語の選択は、言語タグの文字列値を利用者の優先ロケールと完全一致させるだけではありません。 通常のオブジェクト表現によるローカライズ可能なテキスト フィールドでは、値に関連付けられた言語タグを確認するためにオブジェクトを逆シリアル化する 必要があります。所定のファイルに多数の値がある場合、これは非効率になることがあります。 この場合のベストプラクティスは、言語マップを使用してローカライズ可能なテキスト値を 整理することです。このようなマップは選択目的で言語タグを公開しますが、特定の文字列値について 言語と書字方向の両方を上書きする必要がある場合があるため、マップの値側では引き続き オブジェクト表現を使用します。
他の情報がない場合、既定の書字方向および既定の言語は不明であると 規定してください。
明示的なメタデータが利用できる場合は、ヒューリスティックを適用する必要性よりも優先されます。 ヒューリスティックな方法だけでは必要な書字方向を確実に推定できず、メタデータが明示的に提供されて いる場合には、それが正式な情報として意図されていると考えられるため、これは論理的です。
利用者がデータにフォールバック戦略を適用すべき時点を判断できるようにするため、 言語および書字方向が不明であることを利用者が認識できることが不可欠です （言語検出や書字方向に対する最初の強い文字のヒューリスティックなどが含まれます）。 特に、既定の書字方向をLTRに設定すべきではありません。これは、RTL用字系で書かれた文字列に より適した最初の強い文字の検出を使用する必要性を上書きしてしまうためです。
メタデータが利用できない場合、文字列の利用者は、できればUnicode標準の最初の強い文字の 検出アルゴリズムに基づくヒューリスティックを使用して、文字列の基底方向を検出すべきです。
最初の強い文字のアルゴリズムは、文字列内の最初の強い方向性を持つ文字を 探し（特定の先頭部分文字列を読み飛ばします）、それが文字列全体の文字列の書字方向を表すと仮定します。ただし、 最初の強い方向性を持つ文字が、文字列全体の実際または意図された文字列の書字方向と常に一致するとは限らないため、 必要に応じて、この問題に対処するメタデータを提供できるようにすべきです。
最初の強い文字のヒューリスティックに依存する場合、特定の基底方向を 強制する必要があるときは、コンテンツ開発者が文字列の先頭でRLM/LRMを使用できるようにしてください。 ただし、既存の文字列にこれらの文字のいずれかを付加しないでください。
多くの場合、RLM/LRM書式制御文字を利用できることに依存しないでください。
文字列データがウェブフォームやその他の単純な環境で利用者またはコンテンツ開発者によって提供される場合、 利用者はこれらの書式制御文字を入力できない可能性があります。実際、ほとんどの利用者は、 そのような文字が存在することや、その使用方法を知らない可能性があります。ウェブフォームは、 入力のブロック方向を設定すれば（設定すべきです）、 即時確認のためにこれらを使用する必要をなくすことができます。
仕様は、書字方向のメタデータが利用できず、他の方法でも提供できない場合を除き、 文字列の書字方向を利用可能な言語メタデータから推定できるようにしないことが推奨されます （SHOULD NOT）。
すべてのリソースが利用可能なメタデータの仕組みを使用するわけではありません。言語タグの用字系サブタグ （または[BCP47]および[LDML]に 基づく「可能性の高い」用字系サブタグ）は、他のデータが利用できない場合にブロック方向または文字列の書字方向を推定するために使用できる場合があります。 言語情報の使用は「最後の手段」であり、仕様は、ブロック方向を示す主要な方法として これを使用しないことが推奨されます（SHOULD NOT）。 メタデータを提供するよう努めてください。
自然言語テキスト値を含む文書形式またはプロトコルの仕様では、各自然言語コンテンツ値の ブロック方向を保存するための データフィールドまたは属性を定義する必要があります。相互運用性を確保するため、 これらの定義はウェブ全体で一貫している必要があります。これは、ある文書形式の利用者が、受け取った値の ブロック方向を、自身が生成するフィールドに対応付けたり、 コンテンツを表示する際に各文字列の文字列の書字方向を制御したりする 必要があるためです。この節では、そのような定義を、使用すべき具体的な内容とともに 提供する方法について説明します。
コンテンツの書字方向を定義する一般的なユースケースは2つあります。（i）データ構造のフィールドとして 文字列の書字方向を保存および送信するための 書字方向メタデータフィールドを定義する場合と、 （ii）所定の自然言語コンテンツにブロック方向を関連付けるための書字方向属性を定義する場合です。
書字方向メタデータフィールド。書字方向メタデータフィールド （略して書字方向フィールド）とは、所定の自然言語文字列フィールドまたは データ値に文字列の書字方向を関連付けるために使用される データ構造内のフィールドです。
書字方向属性。書字方向属性とは、通常は マークアップ言語内の属性として表され、関連付けられた自然言語文字列コンテンツの文字列の書字方向を提供するフィールドまたは値です。
データ構造またはプロトコルで書字方向メタデータフィールドを定義する場合は、
フィールド名directionを使用してください。
データ値にはdirectionという名前が推奨されます。
dirという名前も許容可能な代替です。
マークアップ言語などの属性には、dirという名前が
推奨されます。属性名としてdirectionを使用することは、
長く、このユースケースでは比較的一般的でないため、推奨されません。[HTML]と[XML10]の両方に、
組み込みのdir属性があることに注意してください。
dir属性には文書内の適用範囲を持たせ、
双方向分離を提供するように定義すべきです。
書字方向メタデータフィールドまたは書字方向属性の値には、
ltr、rtl、
autoを含め、これらの値だけに限定するよう定義してください。
値ltrは、CSS書字モード
[CSS-WRITING-MODES-4]で示されるものと
まったく同じ意味で、左から右への書字方向を示します。
値rtlは、CSS書字モード
[CSS-WRITING-MODES-4]で示されるものと
まったく同じ意味で、右から左への書字方向を示します。
値autoは、利用者エージェントが[HTML]で定義されるautoのアルゴリズムを使用して、
ブロック方向（「段落方向」）を
決定することを示します。このヒューリスティックは、双方向アルゴリズム
[UAX9]の段落レベル決定と同様の方法で、
強い方向性を持つ最初の文字を探します。
autoが複数のフィールドまたは文書全体に適用される場合、
方向はフィールドごとに個別に導出すべきであることを意味します
（自動的に決定できない場合は、文字列固有のメタデータによって上書きします）。
これは、ほとんどの文字列の文字列の書字方向を
最初の強い文字のヒューリスティックで確実に判定できる場合に、書字方向の混在する文字列群に
ラベルを付けるために役立ちます。可能な限り、個々の文字列の実際の文字列の書字方向（ltrまたはrtl）を、
autoの代わりに保存または交換すべきです。
値が本当に不明な場合は、書字方向フィールドを省略する方が適切です。
文書形式またはプロトコルの仕様には、通常、例が含まれます。例には必然的に 自然言語テキストフィールドが含まれます。
仕様で例を作成するときは、自然言語テキストを 含むフィールドについて、この文書に記載されているシリアル化とベストプラクティスを常に 使用してください。形式またはプロトコルがリソース全体の既定値をサポートする場合は、 例でその既定値を設定してください。形式またはプロトコルが文書レベルの既定値を サポートしない場合、または既定値を示すことが不便な場合は、例で単一言語のローカライズ可能なテキストフィールドまたは 言語マップを使用してください。
この文書で説明する各種の言語および書字方向のメタデータ機構を提供する仕様の実装者を含む、 コンテンツの生成者には、 ここに記載されているベストプラクティスをどのように実装するかについて一定の裁量があります。 たとえば、文書形式がリソース全体の既定値と単一言語のローカライズ可能なテキストフィールドの 両方を提供する場合、利用者はどちらを優先すべきでしょうか。
文書形式またはプロトコルによって言語のリソース全体の既定値が 提供される場合、その値は常に文書の内容に最も適した言語に設定することが推奨されます （SHOULD）。多くの場合、これは生成する利用者のロケールです。
文書形式またはプロトコルによって書字方向のリソース全体の既定値が 提供される場合、その値は常に文書の内容と最も強く関連する書字方向に設定することが 推奨されます（SHOULD）。通常、この書字方向は、提供されている場合、 文書レベルの言語の既定値と一致します。
たとえば、文書のリソース全体の言語がen-US
（英語、米国）の場合、左から右がその言語に関連付けられた書字方向であるため、
文書のリソース全体の書字方向はおそらくLTRに
すべきです。
生成者は、リソース全体の既定値が提供されており、 文字列固有の値がその既定値と一致する場合、文字列固有の言語または書字方向のメタデータを 含めないことが推奨されます（SHOULD NOT）。
生成者は、所定の文字列の値が リソース全体の既定値より具体的である場合、 または完全に異なる場合、文字列固有の言語メタデータを含めることが推奨されます （SHOULD）。
たとえば、リソース全体の既定値が
fr（フランス語）であり、文字列に関連付けられた言語が
fr-FR（フランス語、フランス）である場合、
生成者は、より具体的な
fr-FRタグを使用して文字列固有のメタデータを
生成すべきです。同様に、言語がde（ドイツ語）のように完全に異なる場合も、生成者は文字列固有の
メタデータを生成すべきです。
言語タグは、 より多くのサブタグを含む場合に、より具体的です。
生成者は、提供されているリソース全体の既定値と反対の文字列の書字方向を持つコンテンツについては、 文字列自体が明確であっても、文字列固有の書字方向メタデータを含めることが推奨されます （SHOULD）。
多くの文字列は、文字列全体の文字列の書字方向と一致する強い方向性を持つ文字だけで 構成されています。この書字方向がリソース全体の既定値と一致せず （かつ既定値が存在する）場合、文字列の書字方向を含める必要があります。 これにより、利用者が書字方向を決定するために 文字列の内容を調べる必要がなくなり、フィルタリングや選択などのプロセスがコンテンツの 書字方向を誤認することも防げます。
言語および文字列の 書字方向のメタデータを収集、シリアル化、送信する目的は、利用者がそれを使用して 文字列データを正しく表示および処理できるようにすることです。
利用者は、関連付けられた文字列値を処理または表示するときに、 文書形式またはプロトコルによって提供される言語メタデータを使用することが推奨されます （SHOULD）。
文字列を文書に表示または挿入する場合、利用者はその文字列を周囲の テキストから書字方向上分離することが推奨されます（SHOULD）。
利用者は、文字列を文書に挿入するとき、その文字列に書字方向メタデータを 適用することが推奨されます（SHOULD）。この文字列の 書字方向が文字列に関連付けられたメタデータによって提供されている場合、 利用者はそれを使用することが推奨されます（SHOULD）。 そのようなメタデータが利用できない場合は、最初の強い文字のヒューリスティックを使用して 書字方向を割り当てることが推奨されます（SHOULD）。
挿入される文字列値を双方向分離で囲んでも問題が生じることはなく、そうすることで波及効果を防ぎ、 最良の結果を得られます。
利用者は、文字列を文書に挿入するとき、その文字列に言語メタデータを 適用することが推奨されます（SHOULD）。関連する文書属性または APIを使用して、利用可能な言語メタデータを文字列に適用してください。
表示（フォント選択など）またはテキスト処理（ハイフネーションなど）で最良の結果を得るため、
挿入されるテキストの言語を文書またはテキストを処理するAPIで設定すべきです。
[HTML]では、lang属性を設定することで
行います。[XML]では、
xml:lang属性を設定することで行います。
利用者は、相互運用性の確保に役立てるため、言語タグを正規化しても かまいません（MAY）。
たとえば、多くの実装では、[CLDR]の言語タグの 変換にある正規化を使用します。この正規化では、廃止されたサブタグの置換や バリアントのアルファベット順での並べ替えなどが行われます。
生成者でもある利用者は、言語および書字方向のメタデータを 後続の利用者に渡すよう注意することが推奨されます（SHOULD）。
これを使用する文書形式では、[JSON-LD]に、文字列の集合（リソース全体を含む）へ
言語メタデータを割り当てるために役立つデータ構造が含まれています
（ただし段落方向のメタデータは含まれません）。特に、JSONのブロックまたは個々の
オブジェクト内に関連付けることができる、コンテキストを適用範囲とする @language 値の形式で、
「文字列の国際化」と呼ばれるものを定義しています。基底方向の定義はないため、
現在の @context の仕組みだけでは、
この文書で提起されるすべての問題に対処できません。
i18n名前空間を利用できない場合、
またはその使用が適切でない場合、仕様は、自然言語値に対する[JSON-LD]のプレーン文字列リテラルに、
文字列固有の言語情報を提供することを要求するのが推奨されます
（SHOULD）。
[RDF-PLAIN-LITERAL]など、 言語メタデータを文字列値の一部としてシリアル化できるデータ型はすでに存在します。
レガシー形式上の理由により書字方向を指定できない文字列について、 仕様は、各文字列の文字列の 書字方向が最初の強い文字のヒューリスティックに依存すると規定することが推奨されます （SHOULD）。
ローカライズ可能なテキスト
ではない文字列値および文字列フィールドについて、仕様は、そのフィールドが
本質的に非言語であると規定し、各文字列値に言語タグzxx（「言語コンテンツなし」）を関連付けることを推奨するのが
望ましいです（SHOULD）。
ローカライズ可能なテキストを
含むことが分かっているものの、基礎となる形式から言語メタデータを取得できない文字列値および
文字列フィールドについて、仕様は、コンテンツの言語が不明であると規定し、各文字列に
言語タグund（「未確定」）を関連付けることを
推奨するのが望ましいです（SHOULD）。仕様は、適切な場合に
最後の手段として、ヒューリスティックの使用または他のフィールド値からの言語の推定を
許可してもかまいません（MAY）。
多くのプロトコルまたは形式では、自然言語テキストとして意図されてはいないものの、 人間が判読できるトークンとしての値を使用します。これにより、デバッグなどで人が その値を利用できます。これらには、人間が値を表示して操作することが想定される 一般的なプロトコル要素が含まれる場合があります。
一般的な例として、ドメイン名と電子メールアドレスがあります。この種の値空間でUnicodeを 使用できる機会が増えると、これらの値の表示はシステムや環境によって異なる場合があります。 たとえば、言語によって異なる可能性のあるフォント選択は、既定のロケールが異なる システム間で変わる場合があります。
一部の仕様は、既存のプロトコルまたは形式によって定義された文字列値を扱います。 多くの場合、これらの文字列には言語または書字方向のメタデータが関連付けられていないか、 そのようなメタデータが提供されません。たとえば、多くのHTTPヘッダーは、その内容が 自然言語テキストであることを想定していても、その内容がローカライズ可能なテキストでは ないものとして定義しています。これらの文字列値の利用者または 生成者として 動作する仕様には、言語または書字方向のメタデータを判別する方法も、 そのようなメタデータを付加する仕組みもありません。
仕様は、言語の識別にUnicodeの「言語タグ」文字
（コードポイントU+E0000からU+E007F）を使用しないことが
推奨されます（SHOULD NOT）。
[Unicode]では、言語タグを伝えるためにタグ文字を 使用することは強く非推奨であり、文字U+E0001 LANGUAGE TAGの使用も強く非推奨であるとしています。
仕様は、対になった双方向制御文字の生成または使用を 要求してはなりません（MUST NOT）。
言い換えると、実装に対して、通過するデータの変更を要求しないでください。 Unicode双方向制御文字は、生成者またはデータソースがテキストを正しく表示するために使用した、 特定の文字列コンテンツ内に存在する場合があります。つまり、それらはすでにデータの一部である場合が あります。実装は、検出した制御文字を変更すべきではありませんが、独自に追加の制御文字を 生成することを要求されるべきでもありません。
同じ値について複数の言語でLocalizable
文字列を提供できる場合、仕様は言語インデックス付けの使用を推奨することが望ましいです
（SHOULD）。
生成者は、 同じコンテンツ項目またはデータレコードについて、複数の言語値を提供する必要がある場合があります （ローカライズに関する考慮事項を参照）。 これを利用する方法の1つが、利用者による 言語 ネゴシエーションです。
ウェブ上の双方向テキストと 言語メタデータのユースケースの記事をお読みください。この記事では、波及効果やロケールに基づく レンダリングなどの問題を明確に示した、詳細なユースケースを説明しています。この節では、 その文書の重要なポイントと、言語および書字方向のメタデータが必要となる理由を要約します。
ローカライズ可能な テキストを処理および表示する際、コンテンツの言語に関する情報はさまざまな理由で重要です。 言語情報が存在しない場合、外観や機能が低下して利用者を苛立たせたり、コンテンツを理解不能にしたり、 重要な機能を使用不能にしたりする可能性があります。影響を受ける処理には、次のものがあります。
同様に、書字方向のメタデータもウェブにとって重要です。文字列に右から左（RTL）へ進む用字系の テキストが含まれる場合、その文字列が最終利用者に届いたとき、正しく表示できなければなりません。 そのためには、文字列全体にどの文字列の書字方向を 適用する必要があるかを確立しなければなりません。適切な文字列の 書字方向は、文字列を見るだけでは必ずしも推定できません。推定できる場合でも、 文字列の生成者と利用者が同じヒューリスティックを使用して書字方向を解釈する必要があります。
ウェブページの本文や電子書籍の内容などの静的コンテンツには、多くの場合、文書形式または コンテンツメタデータの一部として言語または書字方向の情報が提供されています。ウェブ上にある データ形式は、一般にこのメタデータを提供しません。Microformats、WebIDL、JSONなどの 基盤仕様では、自然言語テキストを追加メタデータなしで文字列オブジェクトに保存する傾向が ありました。
そのため、アプリケーション作成者およびデータ形式の設計者は、自ら進んでメタデータを提供する 責任を負うことになります。標準化された形式がその結果生じる問題に対処しない場合、 データ自体は完全な状態で到着しても、その処理または表示を完全には復元できないことがあります。
分散型のウェブでは、あらゆる利用者が、別のプロセスまたは システムにとっての生成者にもなり得ます。 したがって、ある利用者は、1つの文書形式（および1つのシリアル化に関する取り決め）から、別の文書形式を使用する 別の利用者へ、言語および書字方向のメタデータを渡す必要がある場合があります。 シリアル化に関する取り決めにおいて言語および書字方向のメタデータの表現に一貫性がないことは、 相互運用性を脅かし、一貫した実装の障壁となります。
顧客の電子書籍ライブラリを表示するウェブページを構築しているとします。電子書籍は データカタログ内に存在し、通常のデータ値で構成されています。単一のエントリーに対する JSONファイルは、次のようになります。
{
"id": "978-111887164-5",
"title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
"authors": [ "Jon Duckett" ],
"language": "ar",
"pubDate": "2008-01-01",
"publisher": "مكتبة",
"coverImage": "https://example.com/images/html_and_css_cover.jpg",
// etc.
},上記の各項目は、どこかのデータベース内のデータフィールドです。書籍がどの言語で書かれているかに 関する情報（"language": "ar"）もあります。
適切に国際化されたカタログには、上記に加えて追加のメタデータが含まれます。つまり、 titleフィールドやauthorsフィールドなど、ローカライズ可能なテキストを 含む各フィールドについて、言語および文字列の書字方向の情報をメタデータとして 保存すべきです。（東アジア言語の情報を並べ替えるための発音メタデータなど、他の値が 存在する場合もあります。）これらのメタデータ値は、データの利用者が処理に影響を与え、 項目をさまざまな方法で表示できるようにするために使用されます。JSONデータ構造には、 これらの値を保存または交換する場所がないため、国際化されたアプリケーションの構築が より困難になります。
回避策の1つとして、HTMLとUnicode双方向制御文字を組み合わせて値を符号化し、 データ値を次のいずれかのようにすることが考えられます。
// following examples are NOT recommended
// contains HTML markup
"title": "<span lang='ar' dir='rtl'>HTML و CSS: تصميم و إنشاء مواقع الويب</span>",
// contains LRM as first character
"authors": [ "\u200eJon Duckett" ],しかし、JSONはデータ交換形式です。コンテンツが最終的にHTMLの文脈でtitleフィールドとして 表示されるとは限りません。上記のJSONは、たとえばネイティブコントロールを使用してタイトルを 表示するローカルデータストアを構築するために使用される可能性があり、そのコントロールはHTMLを 文字列の内容として扱います。データの生成者および利用者は、追加データを提供または削除したり、 メタデータとして公開したりするために、データの内容を調べることを想定していない可能性があります。 多くのJSONライブラリは、シリアル化するコンテンツの構造について何も知りません。生成者は、 データベースなどのローカルデータストアからJSONファイルを直接生成しようとします。 利用者は、各文字列の内容を追加で検討することなく、使用する値を保存または取得しようとします。 さらに、生成者または利用者には、フィールド長の制限など、追加の制御文字またはマークアップの 挿入によって影響を受ける別の考慮事項が存在する場合があります。これらの考慮事項はすべて、 必要なメタデータをシリアル化、逆シリアル化、管理、交換するための独自の手段を実装者が 作成するという特別な負担を課し、その過程で相互運用性が犠牲になります。
（補足として、上記の例に示すマークアップは、タイトルだけでなく、挿入されたマークアップ自体も ブラウザーで正しく表示するために実際に必要であることに注意してください。）
[Unicode]およびUTF-8などの文字エンコーディングは、 ウェブとその形式の重要な要素です。これらにより、インターネット全体であらゆる言語のテキストを 一貫して符号化し、交換できます。ただし、Unicodeは完全な交換を保証しますが、それだけでは 自然言語テキストの 完全な表示と処理を保証しません。
Unicodeのいくつかの機能が、言語および書字方向のメタデータを提供する解決策の一部として
提案されることがあります。具体的には、書字方向のメタデータを処理するためにUnicode双方向
制御文字が提案されます。また、UnicodeのU+E0000
ブロックには、当初言語タグとして使用することを意図した「タグ」文字があります
（ただし、この使用方法は現在非推奨です）。
交換形式のデータに文字を追加することが適切でない理由は、さまざまです。次のようなものがあります。
最後の考慮事項は、特に強調する必要があります。文書形式は、多くの場合、 複数層のコードを使用して構築およびシリアル化されます。汎用JSONライブラリなどのライブラリには、 渡されたデータを忠実に保存および取得することが期待されます。上位レベルの実装も通常、 渡された値を忠実にシリアル化および逆シリアル化することを重視します。データ自体を変更する あらゆる処理は、望ましくない変動を生じさせます。たとえば、文書から返された文字列が、 文書の生成に使用したデータカタログ内の文字列と同一であるかを確認するアプリケーションの 単体テストを考えてください。双方向制御文字、HTMLマークアップ、またはUnicode言語タグが 挿入、削除、変更されている場合、本来は同一であると期待される文字列であっても、 等しいと比較されない可能性があります。
双方向テキストのユースケースを考慮すると、利用者は追加の作業や準備を 行わずに文字列を対象の場所へ単純に挿入することはできないと分かります。まず、挿入する文字列に 適した文字列の書字方向を確立し、次に文字列の周囲へ 双方向分離を適用する必要があります。
これには、文字列の周囲にマークアップまたはUnicode書式制御文字が存在する必要があります。 文字列の実際の書字方向が、挿入先のコンテンツの書字方向と反対である場合、 マークアップまたは制御コードで文字列を密接に囲む必要があります。前の節で確認した 波及問題を避けるため、互いに隣接して挿入される文字列は、すべて個別に囲む必要があります。
[HTML]は、
dir属性を使用する場合、またはbdi要素を使用する場合に、任意のインライン要素へ基底方向の制御と
分離を提供します。文字列をプレーンテキスト環境へ挿入する場合は、Unicodeの分離用書式文字を
使用する必要があります。（残念ながら、Unicode標準がプレーンテキストまたは非マークアップ
アプリケーションの既定として推奨している分離用文字のサポートは、まだ普遍的ではありません。）
重要なのは、マークアップまたは制御文字によって提供される書字方向の情報が、 文字列の文字列の書字方向を反映するようにすることです。
双方向テキスト値に関する根本的な問題は、文字列の利用者が、その文字列を最終的に 利用者へ表示するときに、どの文字列の書字方向を使用すべきかをどのように知るかです。 書字方向を識別または推定するためのこれらの手法の一部は、特定のアプリケーションで有用であり、 [HTML]などの さまざまな仕様で使用されています。ここでの問題は、どの手法を一般的に採用し、文書形式における ベストプラクティスとして使用するよう規定するのが適切かということです。
この手法を単独で使用することは推奨されませんが、他の手法と組み合わせたフォールバックとして 使用することは推奨されます。
生成者は何も行う必要がありません。
文字列はそのまま保存されます。
利用者は、文字列内で強いUnicode方向特性を持つ最初の文字を探し、それに一致するように 文字列の書字方向を設定しなければなりません。 その後、文字列が必要に応じて表示されるように適切な処置を行います。ただし、次の理由により、 見た目ほど単純ではありません。
最初の強い文字の検出は、必要な文字列の 書字方向がまだ分かっていない場合にのみ必要です。文字列固有またはリソース全体の宣言に よるメタデータで文字列の書字方向が示されている場合、最初の強い文字のヒューリスティックを 呼び出すべきではありません。たとえば、最初の強い文字のヒューリスティックは、 「HTML و CSS: تصميم و إنشاء مواقع الويب」のような 文字列に対して誤った結果を生成します。これはメタデータを使用して修正できます。 メタデータの使用は情報に基づく意図を示すため、その後に結果を誤らせるヒューリスティックを 適用する必要も、適用する理由もありません。
ただし、メタデータを適用する仕組みがない場合、またはその仕組みが存在しても
コンテンツ開発者が使用しなかった場合、最初の強い文字のヒューリスティックは、
すべてではないものの、多くの場合に基底方向を
確立するために役立ちます。強い方向性を持つ書式文字を適用すると、先ほど引用した例のような
プレーンテキスト文字列で正しい結果を生成できますが、それらを常に適用できるとは限りません
（4.3
RLM/LRMマーカーを挿入して最初の強い文字
を補強するを
参照してください）。
信頼できる場合は、文字列を変更することなく、また帯域外メタデータをサポートするために 必要となる取り決めや構造を使用することなく、書字方向に関する情報を取得できます。
この手法の主な問題は、次の場合に誤った結果を生成することです。
spanなどのマークアップで始まる文字列。
最初の強い文字は常にLTRになるためです。文字列全体がRLI/LRI/FSI...PDI書式文字で始まり、終わる場合、 Unicode双方向アルゴリズムに従って最初の強い文字を検出することはできません。 これは、アルゴリズムが双方向分離されたテキストを検出から除外することを要求するためです。
文字列内に強い方向性を持つ文字が見つからない場合、書字方向はおそらくLTRと仮定し、 利用者はそれに基づいて動作すべきです。ただし、これはまだ十分に検証されていません。
文字列に利用者によってマークアップとして解析されるマークアップが含まれる場合、 追加の問題があります。最初の強い方向性を持つ文字を検索するとき、 文字列の先頭にあるそのようなマークアップも読み飛ばす必要があります。
文字列内の解析可能なマークアップに、その文字列の意図された書字方向に関する情報
（たとえば、HTMLで値がrtlであるdir属性）が含まれている場合、
最初の強い文字のヒューリスティックに依存するのではなく、その情報を使用すべきです。
これには2つの問題があります。（a）文字列の利用者がマークアップのセマンティクスを理解していると
仮定します。たとえば、すべての関係者がHTMLマークアップだけを使用するという取り決めがある場合は
問題ない可能性がありますが、任意のXML語彙を扱う場合などには問題になります。
（b）利用者は、文字列の先頭部分だけにマークアップがあり、マークアップが文字列全体ではなく
インラインのテキスト範囲に適用される状況を認識して処理できなければなりません。
次の段落にあるリンク切れの例がどこにあるのか、または以前どこにあったのかが 明確ではありません。
ただし、山括弧で囲まれた内容が実際のマークアップではなく、マークアップの例として 意図されている場合、そのマークアップを読み飛ばしてはなりません。RTLの文脈で マークアップのソースコードを表示しようとすると、非常に分かりにくい結果になります。 しかし、文字列の利用者が例と解析可能な文字列の違いを常にどのように判断するかは明確ではありません。
最初の強い文字の検出はUnicode双方向アルゴリズム（UBA） [UAX9]で概説されていますが、 文字列の書字方向を推定するために言及されている唯一の上位レベルプロトコルではありません。 たとえば、X（旧Twitter）とFacebookは現在、テキストの基底方向を推測するために 異なる既定のヒューリスティックを使用しています。どちらも単純な最初の強い文字の検出だけを 使用しておらず、一方はまったく異なる方法を使用しています。
この手法は推奨されます。
ここでいう「メタデータ」とは、データ形式内の特定の文字列または文字列集合に関連付けられた フィールドベースの情報、あるいは文字列データ型に組み込まれた情報を意味します （4.7 新しい双方向テキスト用データ型を作成するも参照してください）。
例：
{
"title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
"direction": "rtl",
"language": "ar",
},適切なフィールドを使用して、リソース内のすべての文字列に対する既定の書字方向を示す メタデータを設定することもできます。
生成者は文字列の文字列の書字方向を確認し、 文字列を保存または送信するときに、その文字列に付随するメタデータフィールドへ追加します。
メタデータを使用する手法には、いくつかあります。
autoを使用します。一度に文字列集合を保存または送信する場合、リソース全体に対するフィールドを用意して、 リソース内のすべての文字列が継承できる、全体的な既定の文字列の書字方向を設定すると 役立ちます。全体的なフィールドに加えて、文字列の文字列の書字方向が既定値と異なる場合には、 文字列固有のメタデータフィールドを関連付けられる必要があることに注意してください。 個々の文字列に設定された文字列の書字方向は、常に既定値を上書きしなければ なりません。
利用者は、文字列とともに送信されたメタデータの読み取り方法を理解し、 メタデータがない場合は最初の強い文字のヒューリスティックを適用する必要があります。
言語と書字方向の両方のメタデータを組み合わせ、一貫して採用された場合に異なる形式間の交換を 容易にするため、JSONベースの文書形式における個々の値には、Localizable dictionary構造を使用することが 推奨されます。
メタデータを文字列とは別のデータ値として渡すことで、文字列の実際の内容に影響を与えずに、 意図された文字列の書字方向を伝達する、単純で効果的かつ 効率的な方法を提供できます。
すべての文字列に書字方向がラベル付けされている場合、または全体設定と文字列固有の 例外を適用することで、すべての文字列の書字方向を確認できる場合は、 個々の文字列の文字列の書字方向を決定するために内容を調べ、 ヒューリスティックを実行する必要がなくなります。
帯域外情報を文字列に関連付け、文字列とともに保持する必要があります。定義済みの枠組みに 含まれていない一部の文字列データ集合では、これが問題になる場合があります。
特に、JSON-LDでは、言語の場合と同じ方法で書字方向を個々の文字列に関連付けることが できません。
この手法は、すべての状況で実行可能なわけではありません。
生成者は文字列の文字列の書字方向を確認し、 文字列の先頭にマーカー文字（U+200F RIGHT-TO-LEFT MARK（RLM） またはU+200E LEFT-TO-RIGHT MARK（LRM））を追加します。 このマーカーは機能的なものではありません。つまり、利用者が使用できる基底方向を 文字列へ自動的に適用するものではなく、単なるマーカーです。
次のような手法が考えられます。
利用者は、最初の強い文字のヒューリスティックを適用して文字列の文字列の 書字方向を検出します。RLM文字とLRM文字は方向的に強い型を持つため、 適切な基底方向が検出されるはずです。
4.1 最初の強い文字のプロパティによる検出で説明したように、 書字方向の情報がメタデータを通じて提供される場合、この手法は関係ありません。
生成者がマーカーを確実に適用できる限り、基底方向を示す信頼できる方法を提供します。
理論上、正しいRLM/LRMが文字列の先頭に付加されていれば、マークアップで始まる文字列でも 最初の強い文字を見つけやすくなるはずです。
生成者が人間である場合、理論上は、文字列を作成するときにこれらの文字のいずれかを 適用して書字方向を示すことができます。
特にモバイルデバイスでは、RLM/LRM文字を入力できないこと、または入力が不便であることが 大きな問題です。モバイルデバイスのキーボードには通常、RLM/LRM文字用のキーがありません。 さらに重要なこととして、これらの文字は不可視であり、Unicode双方向テキストは複雑であるため、 利用者が文字を効果的に使用する方法を理解することは困難です。実際、多くの利用者は、 これらの文字が何であり、何をするものなのかを知りません。
さらに、利用者がRTLページ内のHTMLフォームなどに情報を入力する場合、または
ショートカットキーを使用してフォームフィールドの書字方向を設定する場合、
RLM/LRMを追加しなくても文字列は正しく表示されます。しかし、その文脈の外で使用すると、
必要なブロック
方向に関する情報が関連付けられていない限り、文字列は誤って表示されます。
同様に、html要素にdir=rtlが設定されたウェブページから抽出された文字列は、
HTML内では通常、文字列の先頭にRLM/LRM文字を持たず、必要ともしません。
生成者が使用する手順に、文字列の元の文脈から書字方向の情報を調べる処理 （たとえばHTMLフォームフィールドの算出された書字方向を検査すること）を含め、 その後、必要に応じて文字列の先頭へRLM/LRMマークを自動挿入することは可能かもしれません。 この手法の問題は、文字列の値と同一性が変化することです。特に、一部の生成者だけが マーカーを追加する場合、文字列長やポインター位置を扱う際にも問題が生じる可能性があります。
利用者によってマークアップとして解析されるマークアップ内に書字方向の情報
（たとえばHTMLのdir=rtl）が含まれている場合、
文字列の生成者は、RLM/LRM文字を適切に設定するか設定しないかを判断するために、
そのマークアップを理解する必要があります。生成者が常にそのような文字列の先頭へ
RLM/LRMを追加する場合、利用者はそのことを理解していることが期待されます。
代わりに生成者がマークアップの理解に依存する場合、利用者はそのマークアップを
理解することが期待されます。
文字列の生成者は、文字列の先頭にRLMまたはLRMを自動的に適用するのではなく、 必要かどうかを検査すべきです。たとえば、テキスト内にすでにRLMが存在する場合、 さらに追加する必要はありません。最初の強い文字のヒューリスティックによって 文脈が正しく伝えられる場合も、追加文字は必要ありません。ただし、この種の補足的な 書字方向情報が必要かどうかを検査できるのは、生成者が文字列の元の文脈へアクセスでき、 かつアクセスできることを認識している場合だけです。多くの文書形式は、元の文脈から離れた 場所に保存されたデータから生成されます。たとえば、上記の元の例にある書籍カタログは、双方向テキストを入力する 利用者から切り離されています。
この手法は推奨されません。
生成者は文字列の文字列の書字方向を確認し、 文字列の先頭へ書字方向の書式文字（U+2066 LEFT-TO-RIGHT ISOLATE（LRI）、U+2067 RIGHT-TO-LEFT ISOLATE（RLI）、 U+2068 FIRST STRONG ISOLATE（FSI）、U+202A LEFT-TO-RIGHT EMBEDDING（LRE）、またはU+202B RIGHT-TO-LEFT EMBEDDING（RLE）のいずれか）を追加し、末尾へU+2069 POP DIRECTIONAL ISOLATE（PDI）またはU+202C POP DIRECTIONAL FORMATTING（PDF）を追加します。
次のような手法が考えられます。
理論上、利用者は文字列を表示される場所へ挿入するだけで、書式コードによる書字方向の管理に 依存できます。しかし、実際はそれほど単純ではありません（以下を参照してください）。
対になった書式文字には2つの種類があります。元の制御文字群は、Unicode双方向アルゴリズムに 双方向の「埋め込み」の追加レベルを加える機能を提供します。より最近、Unicodeは補完的な 「分離」制御文字群を追加しました。分離制御文字は、文字列を囲むために使用されます。 文字列の内部は独自の双方向シーケンスとして扱われ、文字列は周囲のテキストに関連する 波及効果から保護されます。外側の文字列は、囲まれた文字列全体を、双方向の並べ替えで 無視される1つの単位として扱います。この問題についてはこちらで説明しています。
| コードポイント | 略称 | 説明 | コードポイント | 略称 | 説明 |
| U+200A | LRE | 左から右への埋め込み | U+2066 | LRI | 左から右への分離 |
| U+200B | RLE | 右から左への埋め込み | U+2067 | RLI | 右から左への分離 |
| U+2068 | FSI | 最初の強い文字による分離 | |||
| U+200C | 書字方向の書式を終了する（埋め込みを終了する） | U+2069 | PDI | 書字方向の分離を終了する（分離を終了する） |
対になった書式文字を使用する場合、RLEまたはLREではなく、RLI、LRI、FSIで始まる 分離用の文字を使用すべきです。
この手法を使用する実質的な利点はありません。
この手法は、文字列の値を変更しても許容される場合にのみ適切です。文字列長や ポインター位置の変化などの問題に加えて、処理エラーやテキストの切り詰めなどによって、 対になった文字の一方が失われる現実的かつ重大な危険があります。
文字列の生成者と利用者は、書式文字が文字列の一部だけを表しているため、 文字列が対になった書式文字で始まっても、それで終わらない状況を認識して処理する 必要があります。
Unicodeは、有効な埋め込み数に制限を規定しており、埋め込みが時間の経過とともに蓄積して その制限を超える可能性があります。
利用するアプリケーションは、分離用書式文字を認識して適切に処理する必要があります。 現時点では、RLI/LRI/FSIのサポートは広く普及しているとは言えません。
この手法を認識していない利用者が使用する場合、 UBAの最初の強い文字のヒューリスティックを文字列に適用できなくなります。 Unicode双方向アルゴリズムは、RLI/LRI/FSIで始まりPDIで終わる文字列の基底方向を 確認できないためです。これは、アルゴリズムが分離されたシーケンスを読み飛ばし、 中立文字として扱うためです。文字列の利用者は、 そのような場合に最初の強い文字を特定するための特別な手順を実行する必要があります。
この手法は、メタデータを使用できない状況に対する回避策としてのみ推奨されます。
生成者は、 必要に応じて使用中の用字系を指定し、文字列へ言語メタデータを提供します。
次のような手法が考えられます。
利用者は、 各文字列に関連付けられた言語タグから用字系サブタグを抽出し、必要に応じて文字列の 文字列の書字方向を算出します。 RTL用字系に関連付けられた用字系サブタグは、関連する文字列へRTLの書字方向を 割り当てるために使用されます。
言語情報には、[BCP47]言語タグを使用しなければなりません
（MUST）。情報を伝える言語タグの部分は、
第一言語サブタグではなく用字系サブタグです。たとえば、アゼルバイジャン語は
ラテン文字またはキリル文字ではLTRで、アラビア文字ではRTLで書かれる可能性があります。
したがって、サブタグazだけでは、意図されたブロック方向を明確にするには不十分です。
しかし、az-Arab（アラビア文字で書かれたアゼルバイジャン語）のような
言語タグは、通常、ブロック方向をRTLにすべきで
あることを示すものとして信頼できます。
文字列自体を調べたり変更したりする必要がありません。
この手法は、最初の強い文字が文字列に必要な文字列の 書字方向を示さない場合に生じる最初の強い文字の検出の問題、およびマークアップの 解釈に関連する問題を回避します。
文字列のテキストコンテンツに言語を設定するマークアップ
（<cite lang="zh-Hans">など）で始まる文字列は、
ここでは問題にならないことに注意してください。その言語宣言は、文字列の書字方向の設定に関与することを
想定されていないためです。
上述したメタデータの使用が可能である場合は、そちらの方がはるかに優れた手法です。 この用字系関連の手法は、レガシー上の理由によりその手法を利用できない場合だけに使用します。
言語固有ではないものの、正しく利用するために特定のブロック方向と必ず関連付ける
必要がある文字列は多数あります。たとえば、RTLの文脈に挿入されたMACアドレスは、
全体的なLTRの基底方向で表示し、周囲のテキストから分離する必要もあります。
これらの場合を他の場合からどのように区別するかは明確ではありません
（書字方向のメタデータを使用する場合に実行可能な方法で）。
この種類のコンテンツを識別するため、zxx（非言語）のような
特別な言語タグが存在しますが、この種類のデータフィールドでは、通常、言語情報は
適用できないため完全に省略されます。
用字系サブタグの一覧は、将来追加される可能性があります。その場合、既定のRTL方向を示す サブタグを、文字列の利用者が使用する一覧へ追加する必要があります。
用字系サブタグから適切な段落方向を 識別できないまれな状況がありますが、実際には古風なテキストの使用に限られます。 たとえば、第二次世界大戦以前の日本語と中国語のテキストは、LTRではなくRTLで書かれることが よくありました。エジプトのヒエログリフやティフィナグ文字を使用するベルベル諸語などは、 以前はLTRまたはRTLのいずれでも書くことができましたが、学術研究ではLTRを既定とする傾向が あります。
ここで概説する手法は、文字列に関連付ける全体的な文字列の書字方向に関する情報を宣言する場合にのみ 適切です。使用パターンに互換性がないため、文字列内部のテキストの書字方向を示すために 言語データを使用することは推奨しません。
HTMLまたはXMLのマークアップデータだけを交換することを想定したシリアル化に関する取り決めを 使用する場合を除き、この手法は推奨されません。
生成者は、すべての文字列が、その文字列に適した基底方向を示すマークアップで始まり、
終わるようにします。このため、生成者は文字列を調べる必要があります。
文字列が書字方向情報を持つマークアップで囲まれていない場合、生成者は、
dir属性、its:direction属性
[ITS20]、
または所定のXMLアプリケーションに適した他のマークアップを持つ要素で文字列を
囲まなければなりません。文字列がマークアップで囲まれていても、それがHTMLの
h1要素などである場合、生成者は文字列を単純に
spanで囲むのではなく、既存のマークアップへ
書字方向の情報を追加する必要があります。
この例ではHTMLマークアップを使用します。（例を読みやすくするため、文字が保存される順序ではなく、 表示されるべき順序で文字列のテキストコンテンツを示しています。）
利用者は、文字列を表示するとき、そのテキストコンテンツの周囲に基底方向を設定するために マークアップに依存します。（追加のメタデータが提供されない限り、利用者は文字列を 対象の場所へ統合する前にマークアップを削除できないことに注意してください。 生成者が追加したマークアップと、すでに存在していたマークアップを区別できないためです。 ただし、一般に、このような追加マークアップは無害です。）
すでにマークアップを使用しているコンテンツにとっての利点は明確です。 コンテンツには、テキストの表示と処理に必要な完全なマークアップがすでに含まれているか、 元のページの文脈から抽出できます。HTMLおよびXMLプロセッサーは、このマークアップを 処理する方法をすでに理解しており、すぐに検証できます。
HTMLでは、dir属性がコンテンツを周囲のテキストから
双方向に分離し、波及による競合を排除します。これにより、利用者の作業が軽減されます。
マークアップは、文字列内部の書字方向の情報にも使用できます。これは文字列の書字方向だけでは解決できない問題です。
実質的に、実装スタックのすべてのレベルがマークアップの理解に関与する （または損害を与えないようにする）必要があります。
システムが最初から最後までHTMLを使用する場合、適切なマークアップを利用でき、そのセマンティクス
（dir属性、ならびにbdi要素およびbdo要素）が
理解されています。しかし、XMLアプリケーションには双方向テキストをサポートする標準的な
マークアップがありません。このようなマークアップを最初に定義し、その後、生成者と利用者の
両方が理解する必要があります。
この手法の主な欠点は、多くのデータ値が単なる文字列であることです。Unicodeタグや Unicode双方向制御文字の追加と同様に、文字列へマークアップを追加すると、元の文字列の内容が 変化します。コンテンツの長さを変更すると、任意の制限を適用するプロセスや、 山括弧などHTML/XMLで安全でない文字をエスケープしてコンテンツを「無害化」するプロセスで、 問題が生じる可能性があります。
もう1つの問題は、生成者が文字列を調べ、必要に応じてマークアップを追加するために必要な作業と 高度な処理です。
Unicode双方向アルゴリズムでは、許可される埋め込み数に制限があります。利用者は、 文字列をより広い文脈へ埋め込む際に、この制限を超えないようにする必要があります。
マークアップを追加する場合、利用者はXSS攻撃など、マークアップの挿入に伴う通常の問題から 保護する必要もあります。
この手法は[JSON-LD] 1.1に追加されました。
これは、前述した文字列とともにメタデータを送信する考え方に似ています。
ただし、メタデータは（4.2 メタデータのように）
完全に別のフィールドへ保存されるのでも、（4.3 RLM/LRMマーカーを挿入して
最初の強い文字
を補強するのように）文字列自体へ挿入されるのでもなく、
文字列のシリアル化形式の一部として文字列に関連付けられます。
[RDF-PLAIN-LITERAL]など、 言語メタデータを文字列値の一部としてシリアル化できるデータ型はすでに存在します。 ただし、これらは書字方向を考慮していません。この問題には、文書形式が言語と書字方向の 両方のメタデータを含む自然言語文字列をシリアル化するために使用できる新しいデータ型を 定義する（または既存のデータ型を拡張する）ことで対処できる可能性があります。
[JSON-LD] 1.1では、JSON文書が言語および書字方向の
メタデータを文字列値とともに直接シリアル化できるようにするため、i18n名前空間が追加されました。必要とする仕様向けに、
RDFへの逆シリアル化を提供します。
最後の文字列は内部データ値であるため言語情報を含みませんが、この種類の文字列は LTR順で表示されなければならないため、書字方向の情報は含まれていることに 注意してください。
生成者は、必要に応じて 各文字列へ文字列の書字方向を関連付ける必要があります。
各利用者は、この手法を 使用しない文字列、または文字列の書字方向を含まない文字列について、 最初の強い文字のヒューリスティックを使用すべきです。 生成者は、最初の強い文字の手法が誤った結果を生成する場合にのみ文字列の書字方向の情報を追加します。 メタデータを必要とする文字列の数は比較的少ないため、これにより文字列の管理と 送信するデータ量を簡略化できる可能性があります。
利用者は、 文字列にメタデータが関連付けられているかを確認し、関連付けられている場合は、示された 文字列の書字方向を設定します。 それ以外の場合は、最初の強い文字のヒューリスティックを使用して文字列の書字方向を 決定します。
自然言語文字列をサポートする新しいデータ型がJSONへ追加された場合、仕様は文書形式で 使用するデータ型としてその型を容易に規定できます。その形式は標準化されているため、 生成者と利用者は、 符号化された書字方向または言語の情報を推測する必要がなくなります。
現時点では機能しないという事実を別にしても、データ型を追加することの欠点は、 JSONが多数の独自実装を含め、広く実装されている形式であることです。新しいシリアル化形式は、 これらの既存実装を破壊したり、相互運用性の問題を引き起こしたりする可能性が高くなります。 JSONは「バージョン管理される」形式として設計されていません。使用するシリアル化形式は、 既存のJSONプロセッサーに対して透過的である必要があるため、既存の文字列および形式へ 不要なデータを追加したり、データを破損させたりする可能性があります。
この節では、文字列値の言語を判定または伝達するためのさまざまな方法を扱います。
この手法は推奨されます。
生成者は、 文字列の言語を確認し（通常は上流から提供されたメタデータから確認します）、文字列を 保存または送信するときに、その文字列に付随するメタデータフィールドへこの情報を含めます。
一度に文字列集合を保存または送信する場合、リソース全体について、そのリソース内の すべての文字列が継承できる言語を設定するフィールドを用意すると役立ちます。 全体的なフィールドに加えて、文字列の言語が既定値と異なる場合には、 文字列固有のメタデータフィールドを関連付けられる必要があることに注意してください。 個々の文字列に設定された言語は、リソースレベルの値を上書きしなければなりません。
利用者は、 文字列に関連付けられたメタデータの読み取り方法を理解し、自身が生成する表示、処理、 またはデータ構造へ適用する必要があります。これには、個々の値をシリアル化または 交換するときに、リソースレベルの既定言語を適用する必要がある場合も含まれることに 注意してください。
一貫した明確に定義されたデータ構造を使用すると、異なる標準を組み合わせ、 相互に円滑に機能させられる可能性が高くなります。
コンテンツ自体に影響を与えることなく、メタデータを提供できます。
メタデータを利用できない場合は、省略できます。
利用者と生成者は、通常の処理以外でデータの内容を調べる必要がありません。
dictionaryおよびそのデータ値を使用するシリアル化済みファイルには追加フィールドが 含まれるため、読み取りが難しくなる可能性があります。
既存の文書形式では、交換される値への変更となります。
交換されるコンテンツが、所定のマークアップ言語のリテラル値だけで構成され、 それらに限定されることが想定される特別な場合を除き、この手法は推奨されません。
文書がHTMLまたはXMLの断片で構成されることが想定され、厳密にマークアップの文脈で
処理および表示される場合、生成者は、lang属性またはxml:lang属性を
持つ要素で文字列を囲むことにより、マークアップを使用してコンテンツの言語を伝達できます。
この手法とその利点は、実質的にこの節と同じです。
上記を参照してください。
この手法は推奨されません。
生成者は、 文字列に言語をタグ付けするため、Unicodeタグ文字をデータへ挿入します。
利用者は、 Unicodeタグ文字を処理し、それを使用して言語を割り当てます。
Unicodeは、言語タグとして使用できる特殊文字を定義しています。これらの文字は 「既定で無視可能」であり、視覚的に表示されないことが想定されています。 Unicodeタグは、次のように機能することを想定されています。
各タグは文字シーケンスです。シーケンスはタグ識別文字で始まります。現在定義されているものは
U+E0001だけで、[BCP47]言語タグを識別します。
私的な取り決めにより、他の種類のタグも使用できます。タグを構成するUnicodeブロックの
残りの部分は、印字可能なASCII文字に対応します。つまり、U+E0020は
スペース（U+0020に対応）、U+E0041は大文字のA
（U+0041に対応）などです。生成者はタグ識別文字の後に、
各タグ文字を使用して、大文字と小文字、数字、ハイフン文字からなる[BCP47]言語タグを綴ります。
ASCII文字、数字、ハイフンから構成される所定の元の言語タグは、各文字のコードポイントに
0xE0000を加えることでタグへ変換できます。[RFC4647]の言語優先順位リストなどの
追加構造を、コンマやセミコロンなどの他の文字を使用して構築できる可能性がありますが、
Unicodeはこれを定義しておらず、必ずしも許可しているわけでもありません。
タグの適用範囲の終端は、文字列の終端によって示されるか、キャンセルタグ文字
U+E007Fを単独で使用して（すべてのタグを取り消す）、または言語タグ識別文字
U+E0001を前に置いて（言語タグだけを終了するシーケンス
<U+E0001,U+E007F>として）明示的に示すことができます。
したがって、タグは最低でも3文字で構成され、容易に12文字以上になる可能性があります。
さらに、これらの文字は補助文字です。つまり、UTF-8では1文字につき4バイトを使用して
符号化され、UTF-16ではサロゲートペア（2つの16ビットコード単位）として符号化されます。
JavaやJavaScriptなど、内部でUTF-16を使用する言語の文字列型でこれらの文字を
符号化するには、サロゲートペアが必要です。サロゲートを使用すると、文字列が多少
不透明になります。たとえば、U+E0020はUTF-16では
0xDB40.DC20、UTF-8ではバイトシーケンス
0xF3.A0.80.A0として符号化されます。
これらの言語タグ文字は、文書形式の構造を変更することなく、通常のUnicodeテキストの 一部として使用できます。
言語の識別にUnicodeタグ文字を使用することは、Unicodeコンソーシアムによって 強く非推奨とされており、したがって非推奨です。これらのタグ文字は、 プレーンテキストの文脈で言語をタグ付けするために使用することを意図しており、 帯域内でマークアップを使用せずに言語をタグ付けする代替手段として提案されることが よくあります。これらを言語タグとして使用する実装は確認されていません。
これらの文字を未知のUnicode文字として扱うアプリケーションは、豆腐文字 （中空の四角形の代替文字）として表示し、長さの制限などに含める可能性があります。 したがって、アプリケーションまたは交換機構がこれらを完全に認識し、適切に削除または 無視できる場合にのみ有用です。これらの文字は表示されず、テキスト処理にも影響を 与えないことが想定されていますが、実際には切り詰め、改行、ハイフネーション、 スペルチェックなどの通常のテキスト処理を妨げる可能性があります。
設計上、[BCP47]言語タグは、 ASCIIの大文字と小文字を区別しないことを意図しています。Unicodeタグ文字を扱う アプリケーションも、言語を正しく識別するために同様に大文字と小文字を区別しない処理を 適用する必要があります。（Unicodeデータはこれらの文字について大文字と小文字の 変換ペアを規定していないため、タグ文字を使用して符号化された言語タグ値の処理と 照合が複雑になります。）
さらに、[BCP47]に適合するには、 言語タグを妥当なサブタグから構成する必要があります。妥当なサブタグはIANAレジストリに 保管され、新しいサブタグが定期的に追加されるため、この種類のタグ付けを扱う アプリケーションは、常に各サブタグをレジストリの最新版と照合する必要があります。
言語タグ文字では、言語タグを入れ子にできません。たとえば、英語の文中にフランス語の 引用があるなど、文字列に2つの言語が含まれる場合、Unicodeタグ文字で示せるのは、 ある言語が開始する場所だけです。言語を入れ子にして示すには、タグを先頭に付けるだけでなく、 テキスト内部に埋め込む必要があります。
実装されたことはありませんが、Unicodeタグ文字を使用して、他の種類のタグを 文字列または文書へ埋め込むこともできます。これらのタグが、言語タグでタグ付けされた テキスト範囲と重なる可能性があります。
最後に、Unicodeは最近、スコットランドの旗（🏴）などの地域旗を構成するため、 これらの文字を「再利用」しました。この旗は、次のシーケンスで構成されています。
上記は、2017年6月にUnicode 10.0（UTR#51のバージョン5.0）へ追加された 絵文字の新機能です。適切に表示されるかどうかは、システムがこのバージョンに 対応しているかに依存します。
この手法は推奨されません。
生成者は 何も行いません。
利用者は、 テキストの言語を判定するために言語検出アルゴリズムを実行します。通常、これは、 他のデータと組み合わせる場合もある、言語内のn-gram頻度などに基づく統計的な ヒューリスティックです。
この手法に本質的な利点はありません。
ヒューリスティックは、走査するテキストが長く、代表的であるほど正確になります。 短い文字列では、適切に検出できない場合があります。
言語検出は、検出器が存在する言語に限定されます。
別の言語または用字系で書かれた人名やブランド名などが含まれると、 検出結果が乱れる可能性があります。
言語検出は低速になりやすく、多くのメモリーを消費する可能性があります。 単純な利用者は、言語を判定するために必要な複雑さを負担できない可能性があります。
場合によっては、生成者と利用者の間で何らかの言語 ネゴシエーションを行うことにより、生成者が所定のコンテンツ項目または データレコードについてローカライズ済みの値を提供できます。その後、ネゴシエーションされた言語を 使用して返すコンテンツを選択することで、生成者側でローカライズが行われます。 この手法では、利用者が必要とする言語だけを 返せばよいため、遅延に影響するファイルサイズと複雑さを軽減できます。
ただし、これが常に可能とは限らないため、仕様は所定のフィールドについて複数の異なる言語値を 返すことを許可する場合があります。これは、実行時のローカライズをサポートするため、 または生成者が複数の異なる言語値を 持っており、それらを事前に適切に選択できないためである可能性があります。
このような場合、コンテンツ項目のローカライズは、生成者がその項目について複数の 言語表現を返し、利用者が表示する値を 選択することで行われます。この手法は、生成者が言語をネゴシエーション できない場合（生成されたファイルが複数の利用者向けにキャッシュされる場合など）や、 言語数が比較的少ない場合に役立ちます。多数の言語を含めると、文書が過度に大きくなり、 扱いにくくなる可能性があります。
言語
インデックス付けとは、所定のフィールドの異なる言語版を言語タグを使用して整理し、
利用者が
最も適切な値を選択できるようにする方策です。仕様は、LanguageMapなどの
データ構造を使用して、所定のフィールドに複数の言語版を提供できます。所定のフィールドの値は
マップとして定義されます。マップ内のキーは言語
タグです。各言語タグに関連付けられた値は文字列、または理想的にはLanguageEntryオブジェクトです。
言語タグを
マップ内の値に対するキーとして使用すると、所定の要求に適した値を迅速に選択できます。
言語タグに関連付けられた値がLanguageEntryである場合、値内で言語を
再指定または上書きできることに注意してください。値内のLanguageTagは任意であるため、これは必須では
ありません。（付加価値がある場合を除き、含めないでください。）
たとえば、要求された言語が米国英語（en-US）の場合、
この形式を使用すると、最適なtitleオブジェクト{"value": "Learning Web Design"}を照合して抽出しやすくなります。
もう1つの潜在的な利点は、インデックス付けされた言語タグが、実際のデータ値の言語タグとは
別に、その値の対象読者を示せることです。この例として、次の例のように、より具体的な言語値を
より具体性の低い言語タグで囲む、言語範囲
[RFC4647]の使用が考えられます。
この例では、コンテンツは特定の言語タグ（de-DE）で
ラベル付けされていますが、de-CHやde-ATなど、
他のドイツ語変種を話す利用者にも使用でき、適用できます。
あまり一般的ではない例として、実際の翻訳値が欠けているなどの理由により、 システムがインデックス付け用の言語タグとは異なる「誤った」言語で特定の値を提供する場合があります。
この手法の主な問題は、インデックスを生成するために、コンテンツからインデックス付け用の
言語タグを抽出する必要があることです。生成者は、
インデックス付け用の言語タグを何らかの方法で正規化するかどうかについて、利用者との
シリアル化に関する取り決めを必要とする場合もあります。
たとえば、言語タグcel-gaulishは、[BCP47]の既得権付き言語タグの1つです。
[CLDR]の規則に従う実装などでは、
言語ネゴシエーションのために、このタグを現代的な同等物
（この場合はxtg-x-cel-gaulish）へ置き換えることが
推奨されます。
[JSON-LD]は、@context構造の使用に依存する、言語インデックス付けの具体的な実装を定義しています。
この構造は、LanguageEntry値の使用をサポートしておらず
（文字列または文字列の配列だけをサポートします）、[JSON-LD]文書で上述した機能の一部を使用できるようにするには、
変更が必要です。
この節には、上記の本文で説明したさまざまな構造のWebIDL定義が 含まれています。
効果を得るため、仕様作成者は同じ形式とデータ構造を一貫して使用し、大部分のデータ形式に 相互運用性を持たせることが推奨されます（言い換えると、追加の処理を適用することなく、 多くの形式間でデータをコピーできるようにします）。単一言語の ローカライズ可能なテキストフィールドにはLocalizableを、 言語マップにはLanguageMapを採用することを推奨します。
言語と書字方向をWebIDL dictionary形式で定義することで、仕様は所定のString値に対する言語および 書字方向のメタデータを簡潔に組み込むことができます。実装はdictionaryの実装を容易に再利用できます。
WebIDLtypedef DOMString LanguageTag;
LanguageTag typedefDOMString。WebIDLdictionary Localizable {
DOMString value;
LanguageTag lang;
TextDirection dir = "auto";
};
valueメンバーlangメンバー
dirメンバーWebIDLtypedef record<DOMString,LanguageEntry> LanguageMap;
LanguageMap recordLanguageTagで、値がキーに関連付けられた
ローカライズ済み文字列値と上書き用メタデータを含むLanguageEntryであるマップ。WebIDLdictionary LanguageEntry {
DOMString value;
LanguageTag? lang; // Optional property for language tag
TextDirection? dir; // Optional property for text direction
};
valueメンバーlangメンバーLanguageMapのLanguageEntryにあるlangメンバーを上書きまたは補足するLanguageTag。
このフィールドが使用されることはまれです。dir
メンバーTextDirection。WebIDLenum TextDirection {
"auto",
"ltr",
"rtl"
};
テキストの書字方向を示す値は次のとおりで、人間が読めるメンバーの値が既定で 次のようになることを意味します。
autoltrrtl国際化（I18N）ワーキンググループは、この文書に貢献した次の方々に感謝します。 Mati Allouche、 David Baron、 Ivan Herman、 Tobie Langel、 Emil Lundberg、 Sangwhan Moon、 Felix Sasaki、 Najib Tounsi、 ならびにその他多くの方々。
次のページが、この文書の当初の基礎となりました。
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: