8 言語情報とテキスト方向

目次

  1. 文書の言語指定: lang属性
    1. 言語コード
    2. 言語コードの継承
    3. 言語コードの解釈
  2. テキストと表の方向性指定: dir属性
    1. 双方向アルゴリズムの概説
    2. テキスト方向情報の継承
    3. 埋込みテキストの方向設定
    4. 双方向アルゴリズムの上書き: BDO要素
    5. 方向性及び結合制御の文字参照
    6. 双方向性へのスタイルシートの効果

ここでは、HTMLの国際化に関連する、2つの重要事項を解説する。 文書の言語指定 (lang属性)とテキスト方向指定 ( dir属性)である。

8.1 文書の言語指定: lang属性

属性定義
lang = language-code [CI]
この属性は、当該要素の属性値及び内容テキストの基本言語を指定する。デフォルト値は「不明」である。

lang属性で指定する言語情報は、ユーザエージェントがレンダリングを制御する様々な局面で利用され得る。 著者が提供する言語情報が大いに助けとなる局面には、次のようなものが含まれる。

lang属性は、当該要素内容の言語と、属性値の言語を指定する。 属性値の指定が適切かどうかは、当該属性のシンタクス及びセマンティクス、並びに属性に含まれる働きに依存する。

lang属性の目的は、ユーザエージェントに対して、所定の言語における一般的文化慣習に基づいた、より有意なレンダリングを行えるようにさせようというものである。 これは、ある言語においてあまり使われない文字は無意味な状態でレンダリングすべきだということを意味するものではない。 ユーザエージェントは、lang属性によって指定される値に関わらず、すべての文字をレンダリングするよう、最善を尽くさねばならない。

例えば、ギリシア文字が英文テキストの中に現れたとしよう。

<P><Q lang="en">Her super-powers were the result of
&gamma;-radiation,</Q> he explained.</P>

この場合ユーザエージェントは、 (1) 引用符の取扱いなどを含め、英文を適切にレンダリングしようと試みるべきであり、かつ (2) 英語には出現しない文字であるけれどもγのレンダリングに最善を尽くさねばならない。

関連情報について、表示できない文字の項を参照されたい。

8.1.1 言語コード

lang属性の値は、会話、筆記、その他情報交換のために人々が用いる自然言語を識別する言語コードである。コンピュータ言語は、言語コードからは明示的に除外されている。

[RFC1766]が、HTMLで使用しなければならない言語コードを定義し、説明している。

簡単に言うと、言語コードは主コードと副コード群とから成り、副コードは空であっても構わない。

        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]の国コードであると理解される。

8.1.2 言語コードの継承

ある要素は、次の優先順に従って言語コード情報を継承する。

次に例示する文書の主言語はフランス語("fr")である。1つの段落がスペイン語("es")であると宣言されており、その後はフランス語に戻る。 次の段落には日本語("ja")の句が埋め込まれており、日本語の句が終わると再びフランス語に戻っている。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<HTML lang="fr">
<HEAD>
<TITLE>Un document multilingue</TITLE>
</HEAD>
<BODY>
…フランス語であると解釈されたい…
<P lang="es">…スペイン語であると解釈されたい…
<P>…フランス語であると解釈されたい…
<P>…フランス語テキストが…<EM lang="ja">日本語
         の挿入で中断され、</EM>…またフランス語になる…
</BODY>
</HTML>
注意。 表のコマは、lang属性の値を、親要素からではなくスパン中の最初のコマから継承してよい。 詳しくは、表の配置の継承の項を参照されたい。

8.1.3 言語コードの解釈

HTMLの文脈では、ユーザエージェントは言語コードを単一のトークンとしてではなくトークンの階層として解釈すべきである。 ユーザエージェントが言語情報によってレンダリングを調整する際、つまりスタイルシート言語コードとlang属性値を比較する際、常に正確な合致を試みねばならないが、主コードの合致でも十分であることをも考慮する必要がある。 従って、HTML要素の lang属性値が "en-US" に設定されている場合、ユーザエージェントは "en-US" に合致するスタイル情報をまず優先し、より一般的な値である "en" を次に用いるようにする必要がある。

注意。 言語コード階層は、主コードが共通する言語を、その変型で主コードが等しく副コードが異なる1つ以上の言語によって理解できるということを保証するものではない。 言語コード階層は単に、ユーザにとってそうした操作が正しい場合においてユーザが当該の変形を要求することを許容するのみである。

8.2 テキストと表の方向性指定: dir属性

属性定義

dir = LTR | RTL [CI]
この属性は、当該要素内容及び属性値における、方向性について中立なテキスト(すなわち、 [UNICODE]が定義する固有の方向性を持たないテキスト)の、基本方向を指定する。 この値はまた、表の方向性についても指定する。 可能な値は次の通り。
  • LTR: 左から右の、テキストあるいは表。
  • RTL: 右から左の、テキストあるいは表。

文書の言語をlang属性で指定するのに加えて、著者は、文書のテキストや表の構成に関する基本方向(左-右か、右-左か)をも指定する必要があり得よう。 方向性の指定は、dir属性によって行う。

[UNICODE]仕様は、文字に対して方向性を割り当てており、またテキストの適切な方向性を決定するための(複合)アルゴリズムを定義している。 文書中に、表示可能な右-左文字が含まれていない場合、適合ユーザエージェントは、[UNICODE]の双方向アルゴリズムの適用を要求されない。 文書中に右-左文字が含まれていて、かつユーザエージェントがこれを表示する場合、ユーザエージェントは双方向アルゴリズムを用いねばならない。

ユニコード仕様はテキスト方向を扱う特殊文字を規定しているが、HTMLはdir属性(DIR要素と混同しないこと)及びBDO要素という、より高次のマーク付け構成素を提供し、同じ目的を果たす。 そこで、例えばヘブライ語からの引用を行う場合を考えると:

<Q lang="he" dir="rtl">…ヘブライ語の引用…</Q>

上のHTMLマーク付けの方が、これと等価な下のユニコード制御文字の数値参照よりも、直感的に判りやすい。

&#x202B;&#x05F4;…ヘブライ語の引用…&#x05F4;&#x202C;

ユーザエージェントは、テキスト方向の決定にlang属性を用いてはならない

dir属性は、継承され、また上書きされ得る。 詳細はテキスト方向情報の継承の項を参照されたい。

8.2.1 双方向アルゴリズムの概説

次に、双方向性アルゴリズムの望ましい動作を説明する例を示す。この例には、左-右用字系である英語と、右-左用字系であるヘブライ語が含まれる。

次の例文を考えよう。

  english1 HEBREW2 english3 HEBREW4 english5 HEBREW6

上の例文(並びに後述の関連例文すべて)に含まれる文字は、上に示した順序でコンピュータに保存される。ファイル中の最初の文字が「e」であり、2番目の文字が、「n」、最後の文字が「6」である。

ここで、この段落を含む文書の主言語が英語であると仮定する。これはつまり、基本方向が左-右であることを意味する。すると、この行の正しいプレゼンテーションは、次の通りとなる。

english1 2WERBEH english3 4WERBEH english5 6WERBEH
         <------          <------          <------
            ヘ               ヘ               ヘ
------------------------------------------------->
                      英

点線が、文の構造を示している。英語が主であり、ヘブライ語テキストがそこに埋め込まれている。ユーザエージェントが双方向アルゴリズムを適用しているため、正しいプレゼンテーションのために追加的なマーク付けを行う必要はない。

仮に、これとは反対に主言語がヘブライ語であるとすると、基本方向は右-左となる。そこで正しいプレゼンテーションはこうである。

6WERBEH english5 4WERBEH english3 2WERBEH english1
        ------->         ------->         ------->
            英               英               英
<-------------------------------------------------
                       ヘ

この場合、文全体は右-左方向でプレゼンテーションされ、埋め込まれた英語部分が双方向アルゴリズムによって適切に逆転される。

8.2.2 テキスト方向情報の継承

ユニコードの双方向アルゴリズムは、テキストの固まりについて基本のテキスト方向を必要とする。ブロックレベル要素の基本テキスト方向を指定するには、その要素の dir属性の設定を行う。 dir属性のデフォルト値は"ltr" (左-右テキスト) である。

あるブロックレベル要素にdir属性が設定された場合、当該要素が閉じられるまでの間にある、すべての子孫ブロックレベル要素に対して効果を持つ。 子孫である要素のdir属性値は、継承された値を上書きする。

文書全体の基本テキスト方向を設定するには、HTML要素にdir属性を設定する。

例を示す。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<HTML dir="RTL">
<HEAD>
<TITLE>…右-左のタイトル…</TITLE>
</HEAD>
…右-左のテキスト…
<P dir="ltr">…左-右のテキスト…</P>
<P>…再び右-左のテキスト…</P>
</HTML>

一方、行内要素は、dir属性を継承しない。 これはつまり、dir属性のない行内要素は双方向アルゴリズムに関して追加的な埋込みレベルを開始しないということを意味している。 (ここでは、要素は、デフォルトのプレゼンテーションによってブロックレベルであるか行内レベルであるかと考えられている。 INS要素とDEL要素は文脈によってブロックレベルでも行内レベルでもあり得るという点に注意されたい。)

8.2.3 埋込みテキストの方向設定

[UNICODE]の双方向アルゴリズムは、前述の例のように、埋込み文字列を、その固有の方向性に応じて自動的に逆転させる。 しかし、一般的には、1レベルの埋込みしか表せない。方向転換の埋込みレベルを追加したい場合、行内要素にdir属性を設定する必要がある。

再度前述のテキストを考えよう。

english1 HEBREW2 english3 HEBREW4 english5 HEBREW6

ここで、この段落を含む文書の主言語が英語であると仮定する。さらに、この英文はHEBREW2からHEBREW4までのヘブライ語の区間を含み、このヘブライ語区間は英語の引用(english3)を含む。すると、このテキストの望ましいプレゼンテーションは、次の通りとなる。

english1 4WERBEH english3 2WERBEH english5 6WERBEH
                 ------->
                    英
         <-----------------------
                    ヘ
------------------------------------------------->
                    英

2回の方向変換を埋込むためには、追加情報を与える必要がある。ここでは2番目の埋込みを明示的に区切ることで追加情報とする。 次の例では、テキストのマーク付けにSPAN要素とそのdir属性を用いる。

english1 <SPAN dir="RTL">HEBREW2 english3 HEBREW4</SPAN> english5 HEBREW6

著者は、複数の方向転換を埋込むために、ユニコードの特殊文字を用いてもよい。左-右の埋込みを行うには、埋込むテキストを LEFT-TO-RIGHT EMBEDDING ("LRE"、十六進202A) 文字とPOP DIRECTIONAL FORMATTING ("PDF"、十六進202C) 文字とで囲む。 右-左の埋込みを行なうには、RIGHT-TO-LEFT EMBEDDING ("RTE"、十六進202B) 文字とPDFとで囲む。

ユニコードの制御文字とHTMLの方向性マーク付けとの併用。 著者、並びに著述ソフトウエアの設計者は、BDO要素を含む行内要素でdir属性が使われた場合、 [UNICODE]の整形用制御文字に関連する衝突が起こり得るという点に注意する必要がある。 どちらか一方を相互排他的に用いねばならない。 マーク付けすることの方が、文書構造の統一性をよりよく保証し、また双方向性HTMLテキストを単純なテキストエディタで編集する際に起こる問題を回避できる。しかし [UNICODE]制御文字の利用に傾きがちなソフトウエアもあろう。 マーク付けと制御文字の両方を用いる場合、マーク付けを適切に入れ子にすることと方向性の埋め込みや上書きを適切にすることについて、多大な注意を払う必要がある。そうしないと、レンダリング結果は不定である。

8.2.4 双方向アルゴリズムの上書き: BDO要素

<!ELEMENT BDO - - (%inline;)*          -- I18N BiDi over-ride -->
<!ATTLIST BDO
  %coreattrs;                          -- id, class, style, title --
  lang        %LanguageCode; #IMPLIED  -- language code --
  dir         (ltr|rtl)      #REQUIRED -- directionality --
  >

開始タグ: 必須、終了タグ: 必須

属性定義

dir = LTR | RTL [CI]
この必須属性は、当該要素の内容テキストについての基本方向を指定する。 この指定方向は、[UNICODE]が定義する、文字の固有方向を上書きする。 可能な値は次の通り。
  • LTR: 左から右のテキスト。
  • RTL: 右から左のテキスト。

別途定義がある属性

双方向アルゴリズム及びdir属性は、一般に、方向変換の埋込みを管理するのに使われる。 しかし、双方向アルゴリズムが不正なプレゼンテーションを引き起こしてしまうような状況もあり得る。 BDO要素は、著者に対し、ある範囲のテキストについて双方向アルゴリズムを無効にする手段を提供する。

再び、これまでと同じテキストで考えよう。

english1 HEBREW2 english3 HEBREW4 english5 HEBREW6

今回は、テキストが既に視覚的順序で並べられていると仮定する。 その理由の1つは、MIME標準 ([RFC2045]及び [RFC1556]) が、視覚的順序を採用しているからである。すなわち、右-左の文字列は、バイト列中に右-左の順で挿入される。 電子メールでは、上記の例文は、line breakを含め、次のように整形されるであろう。

english1 2WERBEH english3
4WERBEH english5 6WERBEH

これは[UNICODE]の双方向アルゴリズムと衝突する。なぜなら、双方向アルゴリズムは、2WERBEH4WERBEH6WERBEHを再逆転させ、ヘブライ語を右-左ではなく左-右方向で表示してしまうからである。

これを解決する方法は、まずline breakを保存するために当該メール本文を PRE要素とし、次に各行を BDO要素とすることである。この 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要素は、例えば多言語混在の部分番号など、並び順の完全な制御が必要な局面で用いるべきである。 この要素には、dir属性が必須である。

著者は、ユニコード特殊文字の LEFT-TO-RIGHT OVERRIDE (十六進202D) 及び RIGHT-TO-LEFT OVERRIDE (十六進202E) を用いて双方向アルゴリズムを上書きしてもよい。 どちらの双方向上書きをも、 POP DIRECTIONAL FORMATTING (十六進202C) が終了させる。

注意BDO要素を含む行内要素で使われるdir属性が、同等機能の[UNICODE]の整形文字と同時に使われると、衝突を起こすということを思い起こされたい。

双方向性と文字符号化方法 [RFC1555]及び[RFC1556]によると、MIMEメールにおける双方向性の取扱いについて、特に視覚的方向性と暗黙的方向性と明示的方向性とを区別するための、charsetパラメータ使用に関する特別な規約が存在する。 ヘブライ語に用いるパラメータ"ISO-8859-8"は、視覚方向符号化を示し、"ISO-8859-8-i"は双方向性を暗示し、"ISO-8859-8-e"は明示的方向性を示す。

HTMLではユニコードの双方向性アルゴリズムを用いるので、ISO 8859-8で符号化する適合文書は、パラメータ"ISO-8859-8-i"でラベルづけしなければならない。 HTMLでは明示的な方向性制御も可能だが、ISO 8859-8では表現できない。従って"ISO-8859-8-e"は用い得ない。

パラメータ"ISO-8859-8"は、文書が視覚的方向性に基づいて整形されていて、双方向性を処理しない旧いユーザエージェントで意図した表示になるようにとマーク付けの誤用(例えば TABLEを右揃えで行の折り返しなしにする等)が行なわれている、ということを暗示する。 そうした文書は、現在の仕様には適合しない。 これを現在の仕様に適合させる必要があり、同時に旧いユーザエージェントでも正しい表示を得たいと考える場合、適宜BDOのマーク付けを加えることで、この目的が達成できる。 [RFC1555]及び[RFC1556]の記述とは異なり、ISO-8859-6 (アラビア語) は視覚的順序ではない

8.2.5 方向性及び結合制御の文字参照

句読点などいくつかの文字については方向性に関する両義性が生じ得るため、[UNICODE]仕様はこれを適切に解決するための文字を含んでいる。 また、ユニコードは、例えばアラビア語のアラビア文字等において必要となることがある、結合の制御を行なう文字をも含んでいる。 HTML 4は、これらの文字への文字参照を含む。

次のDTD抜粋は、方向性と結合に関連する実体の例である。

   <!ENTITY zwnj CDATA "&#8204;"--=zero width non-joiner-->
   <!ENTITY zwj  CDATA "&#8205;"--=zero width joiner-->
   <!ENTITY lrm  CDATA "&#8206;"--=left-to-right mark-->
   <!ENTITY rlm  CDATA "&#8207;"--=right-to-left mark-->

zwnj実体は、結合が起こり得る文脈で結合を禁じたい場合に用いる。 zwj実体は、その反対に、結合が起らない文脈で強制的に結合させる。 例えば、アラビア文字の"HEH"はイスラム式暦法【聖遷暦】の名称である"Hijri"の略語として使われるのだが、 独立形の"HEH"はインド数字に基づく5をアラビア文字で綴ったものに形が似ているので、"HEH"が年の末尾の5と混同されることを避けるため、語頭形で用いられる。 しかし、この文脈では"HEH"の結合相手となる文字が存在しないため、zwj文字が結合文脈を提供する。

同様に、ペルシア語のテキストでは、通常は後続の文字と結合される文字について続け字にしたくないような場合が存在する。 この場合、zwnj文字が結合制御に使われる。

他の文字、lrmrlmは、方向性中立な文字に方向性を持たせるために用いる。 例えば、二重引用符がアラビア語(右-左)とラテン文字(左-右)との間にある場合、アラビア語を囲むのか、ラテン文字テキストを囲むのか、二重引用符の向きは明解ではない。 lrm文字とrlm文字は、方向性は持っているが幅はなく、語及び行をbreakすることもない文字である。 詳細は[UNICODE]を参照されたい。

文字グリフの鏡像化 一般に、双方向アルゴリズムは文字グリフを鏡像化させず、そのままにしておく。 例外は、括弧類( [UNICODE]表4-7参照)である。 例えばエジプトのヒエログリフや、ギリシアの犂耕書式、その他特殊なデザイン効果のために鏡像化を望む場合、スタイル制御によって行なう必要がある。

8.2.6 双方向性へのスタイルシートの効果

スタイルシートを用いてある要素の視覚的レンダリングをブロックレベルから行内レベルへ変えること(及びその逆の変換)は、簡単にできる。 しかし、双方向アルゴリズムがブロックレベルと行内レベルの違いに依存するため、この変換には格段の注意を払わねばならない。

dir属性を持たない行内要素がスタイルシートによってブロック要素へと変換された場合、当該ブロックの基本方向を定める、最も近親の祖先ブロック要素からdir属性を継承する。

dir属性を持たないブロック要素要素がスタイルシートによって行内要素へと変換された場合に結果的に得られるプレゼンテーションは、双方向性整形の点で、被変換要素に対して(継承される値に設定された) dir属性を明示的に付加して得られるものと、等価である必要がある。


訳者代表: 内田明 (UCHIDA Akira)
email: uchida@happy.email.ne.jp