Language Tags in HTTP

この頁では、HTTPやHTMLで「言語」を表現する時に使用する言語タグや、その指定方法などについて解説します。

• 言語タグとは
  • はじめに
  • Accept-Language
  • Content-Language
• 言語タグの使用例
  • パターン1：リソースを構成する自然言語が単一の場合
  • パターン2：リソースを構成する自然言語が複数の場合
  • パターン3：リソースが一度に複数返され、それぞれの自然言語が異なる場合
  • パターン4：一つのリソース中に、別の自然言語が組み込まれて使用されている場合
• ISO 639に基づく主要タグの値
• ISO 3166に基づくサブタグの値
• 言語タグの利用によるセキュリティリスクについて
• 参照文献

言語タグとは

はじめに

言語タグとは、データ内の「言語（自然言語）」に関する情報を表現するために、HTTPヘッダやHTMLの中で使用します。 RFC 2616のsection 3.10に記述されています。

言語タグは、他の人間との情報のコミュニケーションのため、人間によって話され、書かれ、あるいは別の方法で伝えられる自然言語を識別する。 コンピュータ言語は完全に除外される。 HTTP では、Accept-Language や Content-Language 各フィールドにおいて言語タグを使用する。

HTTP 言語タグの構文や登録は、RFC 1766 で定義されたものと同じである。 要約すると、言語タグは、第一の言語タグと空の可能性のあるサブタグのいくつかから成る。

 language-tag  = primary-tag *( "-" subtag )
 primary-tag   = 1*8ALPHA
 subtag        = 1*8ALPHA

ホワイトスペースはタグの中では認められず、すべてのタグで大文字・小文字を区別しない。 言語タグの名前空間は IANA によって管理されている。 例えば、言語タグには以下のような物がは含まれる。

 en, en-US, en-cockney, i-cherokee, x-pig-latin

第一タグの二文字は、ISO-639 の言語短縮形であり、サブタグの最初の二文字は、ISO-3166 カントリーコードである。 (上記の後ろ三つのタグは登録されていないタグである; しかし、全て将来に登録されるかもしれないタグの例である。)

（※） 上記文中のRFC 1766は、その後別のRFCによって置き換えられています。 最新の情報については、RFC INDEXで追跡してください。 （追跡方法は、RFCについてでご確認ください）

HTTPでは、Accept-LanguageやContent-Languageといった、言語に関するHTTPヘッダにおいて、メッセージボディで使用されている自然言語を示すために使用します。 通信シーケンスに関しては、以下の図をご覧ください。

Accept-LanguageやContent-Languageに含まれる言語タグには、ISO 639やISO 3166といった自然言語を表すための定型的な略語が使われます。

Accept-Language

Accept-Language リクエストヘッダフィールドは、Accept に似ているが、リクエストへのレスポンスとして望む自然言語のセットを限定する。 言語タグは、section 3.10 にて定義されている。

 Accept-Language = "Accept-Language" ":"
                   1#( language-range [ ";" "q" "=" qvalue ] )
 language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

それぞれの languege-range では、そのレンジで指定する言語に対するユーザの優先度を示す品質値をつける事ができる。 品質値の既定は、"q=1" である。例を見よ。

 Accept-Language: da, en-gb;q=0.8, en;q=0.7

これは、"私はデンマーク語を望むが、イギリス英語か、他の英語でも受け入れる。" という事を意味する。 もし languege-range が、タグに一致する時、あるいはタグの接頭辞に等しくてそれに続く文字が "-" である時には、言語タグに一致する。 Accept-Language フィールドに特別なレンジである "*" がある場合は、その Accept-Language フィールド内に無いあらゆるタグに一致する。

ユーザが使用したい自然言語を示すために使用されます。 複数の言語を指定するすることができ、その場合の優先度は品質値で指定します。

（※） 言語タグの利用によるセキュリティリスクについてもご確認ください。

Content-Language

Content-Language エンティティヘッダフィールドは、それと共に送られるエンティティの読者の自然言語を表す。 ただし、エンティティボディで使われている言語のすべてとは一致しないかもしれない事に注意せよ。

 Content-Language  = "Content-Language" ":" 1#language-tag

言語タグは、section 3.10 にて定義されている。 Content-Language の主な目的は、ユーザ自身が望む言語に応じて、エンティティを識別したり区別したりできるようにするためである。そのため、もしボディの内容がデンマーク語を理解できる人のみを対象にしているのならば、それに合ったフィールドは次のようになる。

 Content-Language: da

レスポンスのエンティティに使用されている自然言語を示すためのフィールドです。 ここにも、複数の言語タグを指定することができますが、その場合の「リソースに含まれる言語の割合」などを表現することはできません。 言語タグの使用例を参照ください。

言語タグの使用例

言語タグは、HTTPヘッダやHTMLの中で使用されますが、使用場面によって意味合いが少しずつ変わります。 上記文中のRFC 1766を置き換えた、RFC 3066のsection 2.4をご覧下さい。

タグとそれが関連する情報との間の関係は、それが表れる状況を記述する標準によって定義される。 それ故に、この節ではその使用が可能な例のみを与える。

• 単一の情報オブジェクトに関して、それはその完全なオブジェクトの完全な理解のために必要である言語のセットとして解されるであろう。 例: プレーンテキスト文書。
• 情報オブジェクトの集合に関して、それはその集合の各要素の内部で使用される言語のセットとして解されるべきである。 例: 文書記憶装置及びライブラリ。
• その目的が代替を提供する事であるような情報オブジェクトに関して、それに関連するタグのセットは、その内容が複数の言語で提供され、その言語を見つけるために各代替を調査する必要があるという事のヒントとして見なされるべきである。 この場合、複数の言語のタグは、その文書の完全な理解を得るために複数言語を理解できる必要があるという事は意味しない。 例: MIME multipart/alternative 。
• HTML や XML のようなマークアップ言語では、言語情報は、マークアップ構造によって識別される (文書全体それ自身を含む) その文書の各部分に付加する事ができる。 例えば、ノルウェー語の文書内に <span lang="FR">C'est la vie.</span> と書く事ができる。 すると、ノルウェー語を話すユーザは、マークされる部分が何を意味するかを知るために仏-ノルウェーの辞書を引く事ができるだろう。 もしユーザがスピーチ合成インターフェースを通じてその文書を聞いているのであれば、この構造は、そのテキストの span に、ノルウェー語の規則を誤って適用する代わりに、フランス語のテキスト-発音変換規則を適切に適用するように合成器に信号を送るために使用されるであろう。

この4つのパターンについて、具体的にContent-Languageの使用例をご覧ください。

パターン1：リソースを構成する自然言語が単一の場合

まずは、最も単純なパターンです。

 HTTP/1.1 200 OK
 Content-Type: text/plain
 Content-Language: ja
 Content-Length: 10

 こんにちは

この例では、「HTTPレスポンスで返されるtext/plainファイルは日本語で記述されている」と解釈できます。 また、HTTPレスポンスで転送できるデータは文書に限らないため、以下のような利用も考えられます。 RFC 3282のsection 2.1の例をご覧ください。

Liverpool の下町にて録音された声

 Content-type: audio/basic
 Content-Language: en-scouse

Star Trek からの引用

 Content-type: video/mpeg
 Content-Language: i-klingon

このように、音声データや、動画データなどにもContent-Languageを送っておけば、レスポンスを利用するクライアント側で「このデータの言語は○○語です」などと表示するなどして、音声や動画を見ることなく、ユーザに通知することができます。

パターン2：リソースを構成する自然言語が複数の場合

次に、複数ファイルがパッケージングされているパターンなどです。

 HTTP/1.1 200 OK
 Content-Type: application/x-tar
 Content-Encoding: gzip
 Content-Language: ja, en
 (以下略)

この例では、「返されるアーカイブ内には日本語のリソースと英語のリソースがそれぞれ含まれている（が、1つのレスポンスとして返す）」と解釈できます。 また、以下のようなパターンも考えられます。 RFC 3282のsection 2.1の例をご覧ください。

英仏辞典（※）

 Content-type: application/dictionary
 Content-Language: en, fr (This is a dictionary)

（※） ただし、RFC 2616ではContent-Language中でコメント（括弧付の文言）を使用することはできません。

これは、「和英辞典」の場合です。 最初のアーカイブの場合、Content-Languageの意味は「『日本語のリソース』と『英語のリソース』が2つある」というように解釈できますが、この場合は「主に日本人が読むリソースだけれども、『日本語の使用比率』と『英語の使用比率』が同等程度である」というように解釈ができます。

パターン3：リソースが一度に複数返され、それぞれの自然言語が異なる場合

3番目のパターンは、MIMEのマルチパートタイプです。

公式な欧州委員会の (その公用語のいくつかによる) 文書

 Content-type: multipart/alternative
 Content-Language: da, de, el, en, fr, it

この例は、どちらも複数のデータを1つのレスポンスボディの中に含めて転送しているという点で、アーカイブの例とよく似ています。 違う点は、アーカイブが「『アーカイバ』という外部プログラム」を利用しているのに対して、この例では「『マルチパートタイプ』という転送プロトコルの仕組み」を利用しているという点です。

パターン4：一つのリソース中に、別の自然言語が組み込まれて使用されている場合

最後のパターンは、HTMLやXMLのようなマークアップ言語の場合です。

 HTTP/1.1 200 OK
 Content-Type: text/html
 Content-Language: ja
 (以下ヘッダ略)

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
 <html lang="ja">
 (中略)

 <p>トイレットペーパーは、中国語では<span lang="zh">手紙</span>と書くそうですよ。</p>

 (中略)
 </html>

このパターンのポイントは、Content-Languageヘッダではjaという言語タグを返しているということです。 これにより、「このHTMLは日本語を理解できる人向けに記述されているが、その上で一部だけ日本語以外の言語（この場合は中国語）を使用している」ということを示しています。 和英辞典の例と比べて、「対象言語の使用比率」は日本語が圧倒的に大きいので、この場合は「このレスポンスの構成言語は日本語」とのみ書かれているわけです。

ISO 639に基づく主要タグの値

このサイトでは、primary-tagを主要タグと訳します。 主要タグについて、RFC 3066 の section 2.2をご覧下さい。

主要タグについては以下の規則が適用される:

• 全ての 2 文字サブタグは、ISO 標準 639 "言語名を表すためのコード" [ISO 639] 中に見られる割り当てか、あるいは将来の ISO 639 part 1 の管理機関、あるいはそれを管理する標準化団体による割り当てに従って解釈される。 (注: 改訂は進行中であり、ISO 639-1:2000 として公開されると予想される。)
• 全ての 3 文字のサブタグは、"言語名を表すためのコード -- Part 2:Alpha-3 コード [ISO 639-2]" 中に見られる割り当てか、あるいは将来の ISO 639 part 2 の管理機関、あるいはそれを管理する標準化団体による割り当てに従って解釈される。
• "i" という値は、IANA に定義され登録済のものとして予約されている。
• "x" という値は、私的使用のために予約されている。 "x" というサブタグは、IANA によっては登録されないだろう。
• その他の値は、この標準の改訂版によって以外は割り当てられないであろう。

他の全てのタグが予約されている理由は、新たな ISO 639 の改訂版に向けて制限なくあるべきであるからである; すなわち、"i" や "x" の使用は最小限我々が当面の要求に直面するようなメカニズムをここで拡張できるためのものである。

主要タグとなりうる値には、いくつか種類がありますが、最も一般的なものはISO 639にある2文字コードです。 以下の表は、主要タグとそれが示す言語名の対応について、RFC 3066の参照文献ともなっているISO 639:1988に基づいて、当サイトが作成したものです。 以下で定義した言語名は、当サイトが独自に定義した読み方であり、「正しい読み方」を保証するものではないことをご了承下さい。

また、公的な機関に定義されていない言語名を使用したい場合は、主要タグの先頭にx-をつければ、好きな値を使用することができます。

ISO 3166に基づくサブタグの値

RFC 3066のsection 2.2では、引き続き、主要タグの直後に続く第二サブタグについても記述されています。

第二サブタグについては以下の規則が適用される:

• 全ての 2 文字サブタグは、[ISO 3166] からの ISO 標準 3166 alpha-2 カントリーコード、あるいは将来の ISO 3166 の管理機関、あるいはそれを管理する標準化団体による割り当てに従って解釈され、この言語の異形体に関係付けられる地域を意味する。
• 3 から 8 文字の第二サブタグを持つタグは、この文書の chapter 5 中の規則に従って、IANA によって登録する事ができる。
• 1 文字の第二サブタグを持つタグは、この標準の改訂版以降によるもの以外では割り当てられないであろう。

第三及びそれ以降のサブタグについて、構文上つけ加えられる規則はない。

その全てがこの章によってその解釈を割り当てられるコードにて構築されるようなタグは、その使用の前に IANA にて登録される必要はない。

サブタグ中の情報は、例えば以下のようであるだろう:

• en-US (この使用法は ISO 639 中に記述される) のような、国の識別
• en-scouse のような、方言あるいは異形の情報
• i-tsolyani のような、i-接頭辞にて登録する事ができる、任意の列挙される言語の変形でないような ISO 639 中に列挙されない言語
• sgn-US-MA (Martha's Vineyard Sign Language, これは米国のマサチューセッツ州で見られる) のような、地域識別

ここでは、4種類の例が列挙されていますが、最も一般的なものは“言語名-国名”というタイプのものです。 この国名は上にある通り、ISO 3166に基づいて決定されています。 以下の表は、国名を表すサブタグとそれが示す国名の対応について、RFC 3066の参照文献ともなっているISO 3166:1988に基づいて、当サイトが作成したものです。 以下で定義した国名は、当サイトが独自に定義した読み方であり、「正しい読み方」を保証するものではないことをご了承下さい。

第二サブタグ以降には、国名だけでなく、地域名を入れる場合もあります。 たとえば、沖縄の言葉で記述された文書のContent-Languageには、ja-okinawaやja-JP-okinawaなどのタグを使って、受信者に通知することができます。

言語タグの利用によるセキュリティリスクについて

Accept-Languageを利用すると、ユーザが利用できる自然言語をサーバに示すことができますが、このヘッダを不用意に利用してしまうことで、セキュリティ上の問題を引き起こす可能性が指摘されています。 RFC 2616のsection 14.4、および15.1.4をご覧ください。

ユーザが、すべてのリクエストに完全な言語優先度を伴った Accept-Language ヘッダを送信する事は、プライバシー保護の立場とは逆のものとなるかもしれない。 この問題の議論について、section 15.1.4 参照。

Accept リクエストヘッダは、アクセスされたすべてのサーバにユーザに関する情報を表す事ができる。 特に Accept-Language ヘッダは、特定の言語を理解するという事がしばしば特定の民族グループの一員である事と強く関連付けられているため、個人的な性質であるとみなすであろう情報を表す。 リクエスト毎に送られる Accept-Language ヘッダの内容を設定するためのオプションを提供するユーザエージェントは、設定のプロセス中にそれがユーザのプライバシーの損失になるという事に気づかせるようなメッセージを含むようにする事が強く推奨される。

プライバシーの損失をより制限するためには、ユーザエージェントが既定では Accept-Language ヘッダを送信しないようにし、サーバによって生成された Vary レスポンスヘッダフィールドを見つけ、その送信によってサービスの品質を向上できるとわかった場合に、サーバに Accept-Language ヘッダを送る事を開始するどうかをユーザに尋ねるようにする。

ユーザによって設定された詳細な Accept ヘッダフィールドがリクエストごとに送られ、特にそれらが品質値を含んでいたら、比較的信頼でき長い間住んでいる{long-lived} ユーザを識別するものとしてサーバによって使われうる。 そのようなユーザを識別するものは、内容供給者がクリックの追跡{click-trail tracking} をできるようにし、共同で作業する内容供給者が個々のユーザのサーバ越しのクリックの追跡{cross-server click-trail} やフォーム提出と一致できるようにする。 プロクシの内側でない多くのユーザにとって、ユーザエージェントが実行されているホストのネットワークアドレスも長く住んでいる{long-lived} ユーザを識別するものとして役に立つという事に注意せよ。 プロクシがプライバシーを高めるために使用されている環境においては、ユーザエージェントはエンドユーザに accept ヘッダコンフィギュレーションオプションを提供する事には保守的であるべきである。 極端なプライバシー手段として、プロクシは中継されたリクエストにおける accept ヘッダをフィルタできる。 高いヘッダ設定機能を供給する一般的な目的のユーザエージェントは、伴う可能性のあるプライバシーの損失に関してユーザに警告すべきである。

たとえば、Accept-Language: jaというヘッダが送信された時、サーバ側では「日本語を使うユーザからのアクセスがあった」ということがわかります。 世界中で日本語が公用語になっているのは日本だけですから、すなわち日本語を使う人間のほとんどは日本人です。 ここで問題とされていることは、「ユーザが日本人である」ということによる差別が発生するかもしれないということです。

基本的にAccept-Languageは送られるべきですが、クライアントがセキュリティ上の観点から、送るべきではないと判断した場合には送らなくてもかまいません。 たとえば、サーバ駆動型ネゴシエーションを利用しようとしなければ、このヘッダは必要ありません。

参照文献

Webリソース

• Hypertext Transfer Protocol -- HTTP/1.1
• Tags for the Identification of Languages
• Content Language Headers

Copyright © 1999-2011 , All Rights Reserved.