[36] Accept-Encoding:
ヘッダーは、
受け入れ可能な自然言語を示すものです。
[37] HTTP における Accept-Encoding:
ヘッダーは、
利用者エージェントが応答において好ましいと考える自然言語の集合を示すものです
>>35。
[41] Accept-Language:
ヘッダーのない要求は、
利用者エージェントがどの言語の応答でも受け入れることを示しています >>35。
[38] HTTP では、このヘッダーは、複数指定できます。
[46] WebSocket handshake でも使うことができます。
[10] 電子メールでは複数指定できるかどうか、 RFC 3282 には言及がありません。 複数指定しないほうが安全です。
[39] 欄値は、1つ以上の値のリスト (#
) です >>35。
[40] それぞれの値は、基本言語範囲か、その後に q
引数を指定したものです >>35。
[8] RFC 3282 の ABNF による構文規則によれば、
Accept-Language = "Accept-Language:" [CFWS] language-q *( "," [CFWS] language-q )
language-q = language-range [";" [CFWS] "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] )
Obs-accept-language = "Accept-Language" *WSP ":" [CFWS] obs-language-q *( "," [CFWS] obs-language-q ) [CFWS]
obs-language-q = language-range [ [CFWS] ";" [CFWS] "q" [CFWS] "=" qvalue ]
language-tag := <BCP47 / RFC3066 language-tag (See 言語札)>
[9] 読む側の実装は構文 obs-Accept-Language
を理解出来なければなりません。
出力側の実装は構文 Accept-Language
に沿わなければなりません。
[21] q
に構文上は quoted-string が使えないようにも見えますが、
Apache は対応しているようです。
[22] 構文上は q
以外の引数を指定できないように見えますが、
Apache は他の引数にも対応している (無視する) ようです。
[23] quoted-string に ,
が含まれていても、 Apache
はちゃんと quoted-string として字句解析してるみたいです。しかし quoted-pair
には対応していないようです。
[24] Apache は q
の先頭の小数以外は無視するみたいです。
整数部分が二桁以上あっても最初の一桁だけとみなすようです。
小数点以下は3桁までで、それ以上あっても無視するようです。 1
より大きな値は 1 とみなすようです。
[42] HTTP 起源鯖は、利用可能な表現のいずれの言語も指定された言語範囲に一致しない場合には、
このヘッダーを無視して内容折衝の対象でないものとして扱うこともできますし、
406
応答を送ることもできます >>35。
ただし 406
応答を送ってしまうと、
(翻訳ソフトウェアを使うなど) 利用者が何らかの形で使うことができるかもしれない内容にアクセスできなくなってしまいますから、
推奨しません >>35。
[408] 言語タグの一致については、 RFC 4647 に複数の一致方法が定義されており、 HTTP の実装はそれぞれの要件により好きな方法を使うことができる >>35 とされています。
[407] 受信者によっては、(特に q
値が等しい場合には)
言語範囲の指定の順序を優先順とみなすことがありますが、
そう解釈されるとは限りませんから、一貫性と相互運用性のため、
多くの利用者エージェントはそれぞれに異なる q
値を指定し、大きいものから小さいものへと並べます >>35。
[25] Apache は q 値が同じ言語が複数指定されているとき、
LanguagePriority
の順序に従って解釈します。
[412] 利用者エージェントは何らかの形で利用者の望む言語を利用者が指定できるようにする必要があります。
利用者にそのような方法を提供しない利用者エージェントは、
Accept-Language:
ヘッダーを送信してはなりません。 >>35
[50] 一般的な Webブラウザーは、設定画面に自然言語の指定機能が用意されているのが普通です。 選択肢からいくつかの言語を選んだり、それ以外の言語タグを追加したりできるのが普通です。
[51] 既定では、プラットフォームの言語設定が Webブラウザーにも反映されるようになっているのが一般的です。 プラットフォームの言語設定を変化させた時に自動的に Webブラウザーにも反映されるのかどうかは不明です。 自動的に反映されるべきかもしれませんし、利用者の個別設定があればそれが優先されるべきかもしれません。
[413] 利用者は普通言語範囲の一致の仕組みに詳しくないですから、
利用者エージェントは何らかの配慮をするべきです。
例えば利用者が eb-GB
を選択した時に、
en
も追加することを提案するとよさそうです。 >>35
[52] 一般的な実装では、利用者が非論理的な指定をできてしまい、
特に何の警告も発されないことがあります。例えば、
en-GB, ja, en
のような指定は、
利用者が英語と日本語のどちらを求めているのか、
真意が定かではありません。サーバーは決めかねて、
利用者の意図に沿わない動作をするかもしれません。
利用者が試行錯誤している場合など、深い意図もなくそのような指定をしてしまうこともありますから、
利用者エージェントが問題のありそうな指定を検出して利用者に警告できれば良いのですが、
どのような指定方法だと問題となるかもあまり明確ではありませんし、
利用者がそう頻繁に使いそうな設定項目でもありませんから、
実装を複雑化させるコストに見合わないかもしれません。むしろ設定画面の奥の方に押し込んで、
不注意な利用者がうっかり触ることが内容にした方が良いのかもしれません。
[419] 利用者エージェントは、このヘッダーと DOM (>>417) で同じ言語リストを用いるべきです >>418。
[410] Accept-Language:
ヘッダーは利用者のプライバシーに関わる情報を漏らすものですから、
注意が必要です。
[411] とはいえどの Webブラウザーもこのヘッダーをすべての要求につけて送信するようです。
[416] 実際には言語の情報だけでは個人を特定することはできないでしょうが、 話者が少数の言語の場合や、言語の組み合わせ、あるいは言語とそれ以外の情報の組み合わせによって、 個人を特定したり、複数の要求や複数のサイトにわたった行動の追跡に用いたりすることができるかもしれません。 また、話者が多数の言語であっても、あまりその言語の話者がいない Webサイトを閲覧すると、同様に特定したり追跡したりできるかもしれません。
[16] mod_negotiation - Apache HTTP サーバ ( 版) http://httpd.apache.org/docs/2.2/ja/mod/mod_negotiation.html
[27] Google ウェブマスター向け公式ブログ: 多言語ウェブサイトの作成について ( ( 版)) http://googlewebmastercentral-ja.blogspot.jp/2011/11/blog-post.html
[28] Accept-Language Header for Internet Explorer 7 - IEBlog - Site Home - MSDN Blogs ( ( 版)) http://blogs.msdn.com/b/ie/archive/2006/10/17/accept-language-header-for-internet-explorer-7.aspx
[58] Mosaic-L10N: Changes, , http://takadat.com/i/Mosaic-l10n/changes.html
[17] Request Headers in the HTTP protocol ( ( 版)) http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z12
[1] ブラウザの言語を自動認識 http://www.ybi.co.jp/koike/qa2000/qa2033.htm: 色々なWWWブラウザでの Accept-Language:
欄の実装状況
[1] 元々 HTTP (RFC 1945, RFC 2068, RFC 2616) で定義されていたものですが、 末に RFC 3282 により再定義されました。
[6] 以前から NN の MUA などが
X-Accept-Language:
欄を吐いていたのは有名ですが、
RFC 3282
により電子メイルなどの世界でもこの欄の使用が公式に認められたことになります。
[7] RFC 3282
は現実の実装にあわせてやや解釈を変更するとしています。
具体的には、要求度 (qvalue
)
が指定されていない場合に、左側 (先頭側)
に指定された言語ほど要求度が高いと見なします。
HTTP の実装も、この新しい解釈を採用して差し支えないでしょう。
RFC 3282 には、 HTTP で Accept-Language:
欄を使う場合の定義を更新するとは残念ながら明記されていません。Web 文書で使われる
という曖昧に言及されているのみです。
[12]
>>6 電子メイルでの Accept-Language:
の使用についての議論が ietf-822 の Is Accept-language an email header field?
mid:5.1.0.14.2.20040406163449.0258c008@127.0.0.1
から始まるスレ (2004年4月)
で議論されています。
内容を要約すると、
From:
や Cc:
の宛先が複数ある時に、 Accept-Language:
の適用対象が不明。Accept-Language:
の実装はそれなりにある。 X-Accept-Language:
や Preferred-Language:
というのも使われている。 X-Accept-Language:
が一番多い気がする。 q
引数は滅多に使われない。[5]
NN は昔から電子メイルでも X-Accept-Language;
欄を出力していまして、内容は HTTP
のものと同じなんですが
(ただし q
引数は用いない)、
こっちは未だに応用があるのか謎です。
多言語化の時代ですから、 人間相手の情報としても有用かもしれません。 よくあるアドレス帳に追加みたいな機能を選んだらこの欄から自動的に情報を採って載せてくれるみたいな。
[3] この Accept-Language:
欄ってクライアント側ではかなり昔、遅くても NN2
では実装されていたんですが、鯖では長く上手く使えていませんでした。せいぜい
CGI とかの鯖側スクリプト系の仕組みで利用する程度。
[4] それが、数年前に Apache がファイル名の接尾辞 base の conneg を実装してから一変。 利用者の言語に応じた資源を提供するのが楽になって、 それを利用しているサーバーも激増中。
[13] 1つの言語を指定する例
Accept-Language: ja
日本語を希望することを示します。q
が省略されているので、q=1
とみなされます。
[14] 複数の言語を指定する例
Accept-Language: ja, en
日本語と英語を希望することを示します。
q
が省略されているので、日本語も英語もq=1
とみなします。
RFC 2616までの規定だけでは日本語も英語も同じくらいの希望度であることがわかるだけで、両方がある場合どちらを提供するべきかは明らかではありませんが、 RFC 3282の規定 (>>7) によれば日本語の方をより優先するものと理解するべきとなります。
[15] 優先度付きで複数の言語を指定する例
Accept-Language: en; q=0.1, ja; q=1.0
日本語と英語を希望することを示します。その中でも特に日本語が好ましいことがq
値によって示されています。この場合、記述の順序は意味を持ちませんから、
Accept-Language: ja; q=1.0, en; q=0.1
でも同じ意味です。
[417] このヘッダーに相当する DOM の API として、
navigator.language
と navigator.languages
があります。
[414] Accept-Language:
ヘッダーによって言語を指定すると、
通常は選択された言語が応答の Content-Language:
ヘッダーで示されることになります。
[26] [whatwg] Accept-Language DOM API proposal ( ( 版)) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-June/036355.html
[29] Bug 23517 – Expose the user's preferred languages in a DOM API ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=23517
[30] Locale-Preferences-API/proposal.md at master · marcoscaceres/Locale-Preferences-API ( 版) https://github.com/marcoscaceres/Locale-Preferences-API/blob/master/proposal.md
[44] Set Accept/Accept-Language in Fetch per #43 · whatwg/fetch@d095fdc ( 版) https://github.com/whatwg/fetch/commit/d095fdcf284cd36e9ddee526ad6faa6fda4ecc00
[45] Accept/Accept-Language handling is now done in Fetch · whatwg/xhr@7e8e1d8 ( 版) https://github.com/whatwg/xhr/commit/7e8e1d887c2b16ba4665c849e7034a45ab826ec3
[47] Googlebot による地域認識クロール - Search Console ヘルプ ( 版) https://support.google.com/webmasters/answer/6144055?hl=ja
[48] Clarify requirements around Accept and Accept-Language · whatwg/fetch@69eda57 ( 版) https://github.com/whatwg/fetch/commit/69eda57af99fd5762162f24739da1895bd2130f4
[49] Expand Request.destination · whatwg/fetch@6b9cdaa ( 版) https://github.com/whatwg/fetch/commit/6b9cdaa9be7acd2b8074c74823981ef994d17857
[54] Strengthen requirements on CORS-safelisted request-headers (annevk著, ) https://github.com/whatwg/fetch/commit/9288c8f85c809a0ac371be6843ad2cf4046ee35b