この章では、HTMLの国際化に関する2つの重要な内容を扱います。言語情報の扱い方（lang属性）と、書字方向（dir属性）に関する事柄です。
文書に付与した 言語情報は、ユーザエージェントが文書を表示する際に様々な部分で利用されます。lang属性によって予め言語情報を記載しておくと、次のような場合に便利でしょう。
lang属性は、各要素に含まれる内容および属性値が何語で記されているかを示すものです。属性値の方については、その値に許される形式は何かといった元々の定義にも拘束されます。
lang属性の目的は、ユーザエージェントに対して、指定された言語の慣習に従って文書の表示をよりよく整えることを可能にしようというものです。これは、珍しい文字でもちゃんと表示するべきだということを意味するものではありません。ユーザエージェントは、lang属性の指定の有無に関わらず、全ての文字を表示できるよう最大限の努力をする必要があります。
例えば、英語の文の中にギリシャ文字が現れるような場合。
<P><Q lang="en">"Her super-powers were the result of γ-radiation,</Q> he explained.</P>
ユーザエージェントは、(1) 英文の正書法によって文の表示を行うようにし（例えば引用符号の選択）、(2) 「γ ガンマ」は英字には含まれないけれどもまともに表示されるよう最大限の努力をすべきです。
関連情報として、第5章4節「表示できない文字」もご参照下さい。
lang属性の値には言語コードが指定されます。言語コードとは、一般に話されたり書かれたりなど通常のコミュニケーションに用いられている各言語を特定するためのもので、コンピュータ言語はこのコード表から除外されています。
HTMLに使用する言語コードは、[RFC1766]の定めに従わねばなりません。
単純に説明すると、言語コードは「一次コード<primary code>」と「副次コード<subcode>」の組合せで指定されます。副次コードはなくてもかまいません。
language-code = primary-code ( "-" subcode )*
言語コードの見本を示します。
2文字で表す一次コードは、[ISO639]による略語として登録されています。2文字の一次コードには、「fr (フランス語)」「de (ドイツ語)」「it (イタリア語)」「nl (オランダ語)」「el (ギリシア語)」「es (スペイン語)」「pt (ポルトガル語)」「ar (アラビア語)」「he (ヘブライ語)」「ru(ロシア語)」「zh (中国語)」「ja (日本語)」「hi (ヒンドゥー語)」「ur (ウルドゥー語)」そして「sa (サンスクリット語)」があります。
2文字の副次コードは、[ISO3166]による国コードとして扱われます。
HTML文書中の要素は、言語コード情報を、次の優先順位で継承します。
Content-Language: en-cockney
下記の文書は、文書全体はフランス語（「fr」）で記述されています。1つの段落がスペイン語（「es」）に指定され、その段落の次からはまたフランス語に戻ります。が、そこには日本語（「ja」）の引用句が挿入され、引用句の直後からはまたフランス語に戻ります。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <HTML lang="fr"> <HEAD> <TITLE>Un document multilingue</TITLE> </HEAD> <BODY> ...まずはフランス語として解釈されます... <P lang="es">...ここはスペイン語で表示されます... <P>...またフランス語です... <P>...フランス語の文が<EM lang="ja">日本語の挿入で中断され</EM> またフランス語に戻ります... </BODY> </HTML>
HTMLにおいては、言語コードは単独の演算子<token>としてではなく階層化された演算子として扱われねばなりません。ユーザエージェントが言語情報に応じて表示の調整を行う場合、（lang属性値と、スタイルシートにおける言語コードとの協調を含めて、）まずは完全に一致する言語コードの規則を参照しようとするわけですが、完全一致が無理な場合には一次コードのみを手がかりにもしていくべきでしょう。従って、HTML要素のlang属性値として「en-US」の指定があった場合には、まずは「en-US」の表示規則を参照しようとし、次に「en」の規則を参照するようにしましょう。
注。 一次コードとその付随する副次コードの組が規定する言語の全てが正しく理解されるという保証はありません。二次化された文字コードは、読者に対し、一次コードの規則で解釈して構わない場合にその解釈を採用する選択の自由を提供するものです。
属性の定義
文書の言語情報をlang属性で設定する場合、書字方向にせよ表の配列方向にせよ、 基本書字方向（左から右、あるいは右から左）を併せて指定する必要も出てくるでしょう。これはdir属性によって別途指定を行うことになります。
[UNICODE]の定義は、各文字が必要とする書字方向に関する指定も組み込んでおり、また文章を組み立てていく際の文字の並びに関する複合的なアルゴリズムに関しても定めています。もし文書中に、右から左へ書くために表示可能な文字が含まれていない場合、HTML 4.0 準拠ユーザエージェントは、[UNICODE] の双方向書字アルゴリズムに従う必要はありません。文書中に右から左へ書く文字が含まれていて、それを表示しようとする場合は、双方向書字アルゴリズムを利用する必要があります。
Unicodeの場合、符号化方法のレベルで文章の書字方向を指定する特別な符号が定められていますが、HTMLではマークアップによって同じ目的を果たすことが可能です。dir属性（DIR要素と間違わないで下さい）と、BDO要素です。そこで、例えばヘブライ語からの引用をするような場合、Unicodeによる表記よりもより直感的に分かりやすくなっています。
<Q lang="he" dir="rtl">...ヘブライ語の部分...</Q>
マークアップによって上のように書く方が、下記のUnicode表記よりも分かりやすいでしょう。
‫״...ヘブライ語の部分...״‬
ユーザエージェントは、 lang属性によって書字方向を判断してはいけません。
dir属性は、継承もされますし、上書きもされます。詳しくは本章2節2項「書字方向情報の継承」をご参照下さい。
以下は、双方向表記の仕組みによって実現されることが期待される文章表現を説明するものです。左から右に書く英語と右から左に書くヘブライ語を題材としています。
では、次の例文をご覧下さい。
english1 HEBREW2 english3 HEBREW4 english5 HEBREW6
この例文に含まれる各文字は、（そして関連する他の例文の文字も、）コンピュータ中に、上に書いた通りの順番で蓄積されます。最初の文字は「e」で、次が「n」、そして最後が「6」というわけです。
この例文が英語表記を中心としたものだとしましょう。つまり、基本的な書字方向は「左から右」だということです。正しい表記は下記のようになります。
english1 2WERBEH english3 4WERBEH english5 6WERBEH
<------ <------ <------
ヘブライ ヘブライ ヘブライ
------------------------------------------------->
英語
矢印で示した方向が、文の構造を表しています。英語は文全体の主で、ヘブライ語がその中に埋め込まれています。データ自体が左から右の順で記されていますから、ヘブライ語部分へのマークアップを施すことで、正しい表記が実現できます。
一方もし、これがヘブライ語の文中に英語が挟まれているとした場合、基本の書字方向は右から左となります。この場合正しい表記は下記のようになります。
6WERBEH english5 4WERBEH english3 2WERBEH english1
-------> -------> ------->
英語 英語 英語
<-------------------------------------------------
ヘブライ語
この場合、文全体は右から左へ書かれ、英語の部分が逆向きに表示されるということになります。
Unicodeの双方向書字アルゴリズムは、基本書字方向の情報を必要とします。ブロックレベル要素に基本方向の指定を行うには、その要素にdir 属性を指定してやります。dir属性の既定値は「ltr」（左から右へ）です。
ブロックレベル要素に与えられたdir属性の値は、その要素の終わりまで、入れ子になっている要素も含めて、効力を持ちます。内側の要素に別のdir属性が与えられた場合は、継承されてきた「dir」属性値は上書きされます。
文書全体の書字方向を設定したい場合は、HTML要素のdir 属性で設定します。下記のように。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <HTML dir="RTL"> <HEAD> <TITLE>...この表題は右から左に向けて表示されます...</TITLE> </HEAD> ...この文も右から左に向けて表示されます... <P dir="ltr">...ここは左から右に向けて表示されます...</P> <P>...また右から左に向けて表示されます...</P> </HTML>
この一方で、インライン要素はdir属性の値を継承しません。つまり、dir 属性を持たないインライン要素は、入れ子になるような挿入句について、双方向書字アルゴリズムによるコントロールを受け入れられないのです。（各要素は、基本的に、ブロックレベル要素かインライン要素のどちらかに分類されます。INS要素とDEL要素はブロックレベルとしてもインラインレベルとしても機能しますので、置かれた文脈上の注意が必要です。）
[UNICODE] の双方向書字アルゴリズムは、（前述の例文のように）挿入句の部分を制御文字の指定に沿って自動的に方向決定します。けれども、何層もの入れ子になった挿入句をコントロールすることはできず、通常1文中に1つの [方向転換を伴う] 挿入句のみしか扱えません。2層以上の入れ子になった [方向転換を伴う] 挿入句を扱うには、インライン要素でdir 属性を指定する必要があります。
また同じ例文で考えましょう。
english1 HEBREW2 english3 HEBREW4 english5 HEBREW6
英語が主であるとします。この英文の中には「HEBREW2」から「HEBREW4」にかけてのヘブライ語の挿入句があり、そのヘブライ語の挿入句の中には（english3という）英語の挿入句が含まれています。望ましい表示方法は下記のようになります。
english1 4WERBEH english3 2WERBEH english5 6WERBEH
------->
英語
<-----------------------
ヘブライ語
------------------------------------------------->
英語
2層の入れ子になった挿入句の方向転換を実現するには、2層目の転換を明示する補足情報が必要です。ここでは、SPAN要素の使い方を説明します。2層目の挿入句をSPAN要素としてマークアップし、そこにdir属性を記述するのです。
english1 <SPAN dir="RTL">HEBREW2 english3 HEBREW4</SPAN> english5 HEBREW6
マークアップではなく、Unicodeの制御文字によって複層入れ子の挿入句の方向転換を行うこともできます。左から右へ表示させたい範囲は「左から右符号LEFT-TO-RIGHT EMBEDDING（「LRE」記号すなわち十六進の202A）」と「POP DIRECTIONAL FORMATTING（「PDF」記号すなわち十六進の202C）」とで囲み、右から左へ表示させたい範囲は「右から左へ符号 RIGHT-TO-LEFT EMBEDDING（「RTE」記号すなわち十六進の202B）」とPDF記号とで囲みます。
HTMLのマークアップによる書字方向の指定とUnicodeの制御文字による方向指定を併用する際には、著作者もオーサリングツール開発者も、（BDO要素を含む）インライン要素のdir属性指定と[UNICODE] の制御文字の指定とが衝突を起こす危険があることに注意を払ってください。どちらか一方のみを使うようにすべきでしょう。HTMLのマークアップは、文書構造の表現としての完全性に優れ、また簡素なエディタで双方向書字を必要とするHTML文書の著作編集を行う際にも便利ですが、利用するソフトウェアによっては[UNICODE] の制御文字が用いられがちになるでしょう。HTMLのマークアップとUnicodeの制御文字が両方使われる際には、マークアップと制御文字の関係に、非常に細心の注意が必要です。でなければ、意図する表示を指定できません。
<!ELEMENT %inline;)* -- I18N BiDi over-ride -->
<!ATTLIST BDO
%coreattrs; -- style, title --
%LanguageCode; #IMPLIED -- language code --
dir (ltr|rtl) #REQUIRED -- directionality --
>
開始タグ: 必要、終了タグ: 必要。
属性の定義
制御文字による双方向書字アルゴリズムもdir 属性による指定も、主に挿入句における方向転換のために使われます。けれども、制御文字による方向転換が却って意図に反する表示結果を引き起こす場合があります。BDO 要素は、その指定範囲に関して、制御文字による方向転換の機能を 解除するものです。
おなじみの例文で説明しましょう。
english1 HEBREW2 english3 HEBREW4 english5 HEBREW6
今回扱うのは、上記の各文字列が、意図する表示の通りに並んでいる場合についてだという点にご注意下さい。MIME標準（[RFC2045]と [RFC1556]）の場合、そうした見た目通りの順番でデータを流すことを想定しているからです。つまり、右から左へ書かれる文字列は右から左へ書かれる順序通りのビット列として扱われるのです。例えば電子メールでは、改行を含めると、下記のように送られてくることになります。
english1 2WERBEH english3 4WERBEH english5 6WERBEH
この場合、[UNICODE] の双方向書字アルゴリズムと衝突が起きます。せっかく意図通りに正しく右から左へ書いた順番に並んでいる2WERBEH、 4WERBEH、6WERBEHの各語句を再度方向転換して左から右に並べ換えてしまうからです。
これを解消するためには、（改行の意図を保持するため）本文全体をPRE要素としてマークアップし、更に各行をBDO 要素とした上でdir属性をLTRにすることです。
<PRE> <BDO dir="LTR">english1 2WERBEH english3</BDO> <BDO dir="LTR">4WERBEH english5 6WERBEH</BDO> </PRE>
上記のマークアップは、制御記号による方向転換の指令に対し、「左から右のままにしてくれ!」と命令の更新を行い、元々の表示を生かすものです。
english1 2WERBEH english3 4WERBEH english5 6WERBEH
BDO要素は、絶対的な順番指定が必要な状況において用いられるべきものです。（例えば多言語混在の番号付け<<multi-language part numbers>>など。）「BDO」要素にはdir属性が必須です。
Unicodeには双方向書字アルゴリズムを上書きするための制御文字もあります。「上書きして左から右へ符号 LEFT-TO-RIGHT OVERRIDE（十六進の202D）」と「上書きして右から左へ符号 RIGHT-TO-LEFT OVERRIDE（十六進の202E）」です。どちらも上書き区間の末尾に「POP DIRECTIONAL FORMATTING（十六進の202C）」を記して上書き区間を閉じます。
双方向書字と符号化方法との関係 について、[RFC1555] 及び[RFC1556]によると、MIME形式の電子メールで双方向書字文書を扱う場合には「charset」指定に3種類の特別な文字集合を指定する必要があります。書字方向について「見たまま指向」と「暗示指向」と「明示指向」を区別するためです。例えばヘブライ語の符号化方法「ISO-8859-8」は「見たまま指向」を表し、「ISO-8859-8-i」は「暗示指向」、「ISO-8859-8-e」は「明示指向」を表します。
HTML 4.0仕様はUnicodeの双方向書字アルゴリズムを使用するので、HTML 4.0準拠の文書をISO-8859-8系で符号化する場合は、「ISO-8859-8-i」として記す必要があります。明示指向のHTML文書も一般的には作成可能ですが、その場合はISO-8859-8系では表せないので「ISO-8859-8-e」は使ってはいけません。
符号化方法に「ISO-8859-8」が選ばれているということは、その文書が「見たまま指向」で表示されるべきことや、双方向書字アルゴリズムをサポートしていない旧式ユーザエージェントで意図通りの表記を実現するためにマークアップが誤用されているということを意味します。（ここでいうマークアップの誤用とは、例えば右寄せにされたTABLE要素や、改行拒否指定などに関するものです。）こうした文書は、現在のこのHTML 4.0 仕様に準拠するものではありません。このような文書を（旧式ユーザエージェントでの表示を満足させつつ）HTML 4.0 準拠文書に作り替えるには、要所要所にBDOのマークアップを行えばよいのです。 つけ加えると、[RFC1555]及び[RFC1556]の記述とは異なり、 ISO-8859-6 (アラビア語) は「見たまま指向」ではありません。
書字方向を考える際にどちらの方向性をも持ちうる文字（例えば句読点など）の方向性を表現するために、[UNICODE] 規格には、適切な方向性解釈を与えるための定義が含まれています。更にまた、Unicodeには（アラビア語など）連字が必要な場合の書字制御に関する既定も含まれています。このHTML 4.0 仕様では、そうした制御文字に関する文字参照も用意しました。
方向指定や連字の制御に関係する文字参照から抜粋してみましょう。
<!ENTITY zwnj CDATA "‌"--=zero width non-joiner--> <!ENTITY zwj CDATA "‍"--=zero width joiner--> <!ENTITY lrm CDATA "‎"--=left-to-right mark--> <!ENTITY rlm CDATA "‏"--=right-to-left mark-->
zwnjは、連字化が起こりうる文脈で連字化を行わせない指定をするための文字参照です。zwjは、その逆の働きをします。 例えば、「HEH」という名のアラビア文字は、イスラム式暦法 [聖遷暦] を意味する「Hijri」の略語として用いられます。ただし、独立形の「HEH」がアラビア文字綴り<Arabic script>の「5」と紛らわしいので、年号の末尾の「5」と間違ってしまうことを避けるため、語頭形の「HEH」で記されます。この場合隣接する文字の存在によって「HEH」が自動的に連字化されるということがありませんので、文字参照によってzwj符号を添付することで語頭形の「HEH」として表現することになります。
同様に、ペルシャ語の文章で、通常連字化される文字を切り離したい場合があります。この場合はzwnjによって連字化を防ぐことができます。
残り2つの制御文字lrmとrlmは、左右どちらにでも書ける文字をどちらかの方向に強制するものです。例えば、二重引用符がアラビア文字（右から左に書かれる文字）とラテン文字（左から右に書かれる文字）の間に入った場合、引用符をどちらに合わせるかは不定です。（アラビア文の引用符なのかラテン文の引用符なのか。）lrmとrlmは方向の指定を行うためだけに用いられ、表示される文字として文中に現れることもなければ、語や行の区切りの役割も果たしません。より詳しくは[UNICODE]の仕様をご参照下さい。
字形の鏡像化について。 パーレン [括弧] などの一部の例外（[UNICODE]の表4-7を参照のこと）を除いて、一般に、Unicodeの双方向書字機構においては字形の鏡像化は扱われず、通常の文字のままにされます。例えばエジプトのヒエログリフやギリシャの犂耕書式 [牛耕法] 、その他特別なデザイン効果のために字形の鏡像化が必要な場合は、スタイルシートによって扱うようにしてください。[ 訳注。たぶん原文の最後の「styles」は「style sheets」の誤記だと思います。また、犂耕書式を原文はbustrophedonと記していますが、boustrophedonの方が一般的らしいことが両者をWeb上でサーチすると判ります。]
一般に、スタイルシートを用いてある要素の表現型をブロックレベルからインラインレベルにすることも、その逆も、簡単にできます。けれども、双方向表記の仕組みはブロックレベルとインラインレベルの区別に依拠しているので、レベルを変える場合には細心の注意が必要です。
もしスタイルシートの指定によって、dir属性を持たないインライン要素がブロックレベルに変更された場合、最も近親の親ブロック要素からdir属性の値を参照して、書字方向を決定します。
逆にdir属性を持たないブロックレベル要素がインライン要素に変更された場合、dir属性を持たないインライン要素一般が従う双方向表記の原則（値の継承方法）に従って書字方向を決定します。