[36] Accept-Encoding: ヘッダーは、 受け入れ可能な自然言語を示すものです。

[415] このヘッダーは、内容折衝の仕組みの一つです。

仕様書

意味

[37] HTTP における Accept-Encoding: ヘッダーは、 利用者エージェントが応答において好ましいと考える自然言語の集合を示すものです >>35。

[41] Accept-Language: ヘッダーのない要求は、 利用者エージェントがどの言語の応答でも受け入れることを示しています >>35。

[11] RTSP/1.0 (RFC 2326) は、その適用先は内容ではなくプロトコル要素であるとしています。

[59] 利用者の言語も参照。

文脈

[38] HTTP では、このヘッダーは、複数指定できます。

[46] WebSocket handshake でも使うことができます。

[10] 電子メールでは複数指定できるかどうか、 RFC 3282 には言及がありません。 複数指定しないほうが安全です。

構文

HTTP の場合

[39] 欄値は、1つ以上の値のリスト (#) です >>35。

  1. 言語と重み
  2. *
    1. OWS
    2. ,
    3. OWS
    4. 言語と重み

[40] それぞれの値は、基本言語範囲か、その後に q 引数を指定したものです >>35。

  1. 基本言語範囲
  2. ?
    1. ;
    2. |
      1. q
      2. Q
    3. =
    4. 品質値
[18] RFC 2616 では空白 (LWS) をどこに挿入可能か明確に言及されていませんでした。

[19] Apache は字句間どこにでも認めているようです。

822 メッセージの場合

[8] RFC 3282 の ABNF による構文規則によれば、

[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 応答を送ってしまうと、 (翻訳ソフトウェアを使うなど) 利用者が何らかの形で使うことができるかもしれない内容にアクセスできなくなってしまいますから、 推奨encourageしません >>35。

[408] 言語タグの一致については、 RFC 4647 に複数の一致方法が定義されており、 HTTP の実装はそれぞれの要件により好きな方法を使うことができる >>35 とされています。

[409] RFC 2616 では、 RFC 4647 のうち基本濾過に相当するものが定義されていました >>35。

[407] 受信者によっては、(特に q 値が等しい場合には) 言語範囲の指定の順序を優先順とみなすことがありますが、 そう解釈されるとは限りませんから、一貫性と相互運用性のため、 多くの利用者エージェントはそれぞれに異なる q 値を指定し、大きいものから小さいものへと並べます >>35。

[25] Apache は q 値が同じ言語が複数指定されているとき、 LanguagePriority の順序に従って解釈します。

従って RFC 3287 の >>7 の解釈とは異なります。

[56] 言語の折衝, 利用者の言語も参照.

利用者インターフェイス

利用者の言語

プライバシー

利用者の言語

実装

[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

[57] PHP: locale_accept_from_http

歴史

HTTP

[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

[31] RFC 1945 (HTTP/1.0) D.2.4; RFC 2068・2616 (HTTP/1.1) 14.4 Accept-Language

The Accept-Language request-header field is similar to Accept, but restricts the set of natural languages that are preferred as a response to the request. {2616} Language tags are defined in section 3.10.

Accept-Language 要求頭欄は、 Accept と同様ですが、要求に対する応答として優先させる自然言語の集合を制限します。 言語札は 3.10 節で定義しています。

{2068,2616}

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

Each language-range MAY be given an associated quality value which represents an estimate of the user's preference for the languages specified by that range. The quality value defaults to "q=1". For example,

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

各 language-range は、その範囲により指定される言語についての利用者の優先の見積もりを表現する、関連付ける品質値を与えても構いません。 品質値の既定値は q=1 です。 例えば、

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

would mean: "I prefer Danish, but will accept British English and other types of English." A language-range matches a language-tag if it exactly equals the tag, or if it exactly equals a prefix of the tag such that the first tag character following the prefix is "-". The special range "*", if present in the Accept-Language field, matches every tag not matched by any other range present in the Accept-Language field.

は「私はデンマーク語を希望しますが、 イギリス英語及びほかの種類の英語も受け付けます。」 を意味します。 language-range は、 language-tag と正確に等しいか、または tag の接頭辞と正確に等しく、その接頭辞に続く最初の tag の文字が - である とき一致します。 特殊な範囲 * が Accept-Language 欄に示された時は、 Accept-Language 欄に示された他のどの範囲にも一致しない各 tag と一致します。

Note: This use of a prefix matching rule does not imply that language tags are assigned to languages in such a way that it is always true that if a user understands a language with a certain tag, then this user will also understand all languages with tags for which this tag is a prefix. The prefix rule simply allows the use of prefix tags if this is the case.

注意 : 接頭辞一致規則をこのように使用するからといって、 利用者がある tag の言語を理解するとしたらこの利用者がその tag を接頭辞とする tag の全ての言語をも理解するということが常に真であるように言語札が言語に割り当てられることを求めるものではありません。 この接頭辞規則は、単にこれがそうである場合に接頭辞 tag の使用を認めるに過ぎません。

The language quality factor assigned to a language-tag by the Accept-Language field is the quality value of the longest language-range in the field that matches the language-tag. If no language-range in the field matches the tag, the language quality factor assigned is 0. If no Accept-Language header is present in the request, the server SHOULD assume that all languages are equally acceptable. If an Accept-Language header is present, then all languages which are assigned a quality factor greater than 0 are acceptable.

Accept-Language 欄により language-tag に割り当てられる言語品質因子は、 language-tag に一致する欄中の最長の language-range の品質値です。欄中のどの language-range も tag に一致しなければ、割り当てられる言語品質因子は 0 です。陽宮中に Accept-Language 頭が示されていなければ、 鯖は全ての言語が等しく受入れ可能と仮定するべきです。 Accept-Language 頭が示されていれば、 0 より大きな品質因子が割り当てられている全ての言語が受入れ可能です。

It {2068} may {2616} might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic preferences of the user in every request. For a discussion of this issue, see section {2068} 15.7 {2616} 15.1.4.

利用者の完全な言語的好みを要求毎に Accept-Language 頭で送るのは、個人情報に関する利用者の期待と反対かもしれません。 この問題についての議論は、 15.* 節をご覧下さい。

Note: As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice of linguistic preference available to the user. If the choice is not made available, then the Accept-Language header field must not MUST NOT be given in the request.

了解度は個々の利用者に高く依存しているので、 クライアント応用は利用者が利用可能な言語的好みの選択を行うことができるようにすることを推奨します。 選択が利用可能にできない場合、 Accept-Language 頭欄は要求中に与えてはなりません。

Note: When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not familiar with the details of language matching as described above, and should provide appropriate guidance. As an example, users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. A user agent might suggest in such a case to add "en" to get the best matching behavior.

注意 : 利用者に利用可能な言語的好みの選択を行わせる時、 利用者は前述の言語一致の詳細に詳しくないかもしれないことに利用者は注意し、 適切な案内を提供するのがよいでしょう。例えば、 利用者が en-gb を選択していると仮定すると、 イギリス英語が利用可能でないときに任意の種類の英語の文書を供給するでしょう。 利用者エージェントはそのような場合に最善の一致動作が得られるように en を追加することを勧めるといいでしょう。

[32] RFC 2326 (RTSP) 12.3 Accept-Language

See [H14.4]. Note that the language specified applies to the presentation description and any reason phrases, not the media content.

[2] [H14.4] を参照。 なお、言語指定は表現説明及び理由語句に適用されるものであって、媒体内容に適用されるものではありません。

[33] RFC 2068 15.7, RFC 2616 15.1.4 (HTTP/1.1) Privacy Issues Connected to Accept Headers

Accept request-headers can reveal information about the user to all servers which are accessed. The Accept-Language header in particular can reveal information the user would consider to be of a private nature, because the understanding of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option to configure the contents of an Accept-Language header to be sent in every request are strongly encouraged to let the configuration process include a message which makes the user aware of the loss of privacy involved.

Accept 要求頭群は、 利用者についての情報をその接続したサーバーすべてに暴くことができます。 Accept-Language 頭は特に、利用者が私的な性質であると考えているかもしれない情報を晒し得ます。 なぜなら、特定言語の理解はしばしば特定の民族集団の一員であることと強い関連があるからです。 要求毎に送信する Accept-Language 頭の内容を設定する選択肢を提供している利用者エージェントは、 設定過程において利用者が個人情報の流出に気づくようなメッセージを含めることを強く推奨します。

An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language headers by default, and to ask the user whether it should or not to start sending Accept-Language headers to a server if it detects, by looking for any Vary response-header fields generated by the server, that such sending could improve the quality of service.

個人情報の流出を限定するために、利用者エージェントが既定では Accept-Language 頭を送信せずに、 サーバーによって生成される Vary 応答頭欄を見て Accept-Language 頭を送ることでサービスの質を向上できるだろうと判断した場合には利用者に Accept-Language 頭を送信することを開始するかどうかをたずねるという方法もあるでしょう。

Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions of individual users. Note that for many users not behind a proxy, the network address of the host running the user agent will also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents should ought to be conservative in offering accept header configuration options to end users. As an extreme privacy measure, proxies could filter the accept headers in relayed requests. General purpose user agents which provide a high degree of header configurability should SHOULD warn users about the loss of privacy which can be involved.

利用者が緻密に調整した受入れ頭欄群を要求毎に送信すると、特に品質値が含まれている場合には、鯖がこれを比較的信頼でき長生きする利用者識別子として使うことができます。 この利用者識別子で内容提供者はかちっ跡追跡を行ったり、共同内容提供者が個々の利用者のかちっ跡や入力欄提出をサーバー間で一致させたりすることができるでしょう。 串に隠れていない多くの利用者については利用者エージェントが走っているホストのネットワーク番地も長生きする利用者識別子として供給されることに注意してください。 個人情報保護向上のために串を使う環境では、 利用者エージェントは末端利用者に受入れ可能頭設定選択肢を提供することに慎重になるべきです。極度の個人情報保護の観点から、 串は中継する要求の受入れ可能頭群を濾過できるでしょう。 高度な頭設定可能性を提供する一般目的利用者エージェントは、 個人情報の流出があることを利用者に警告するべきです。

[1] ブラウザの言語を自動認識 http://www.ybi.co.jp/koike/qa2000/qa2033.htm: 色々なWWWブラウザでの Accept-Language: 欄の実装状況

電子メール

  • [34] RFC 3282

[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月) で議論されています。

内容を要約すると、

[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: ヘッダーで示されることになります。

メモ

[43] Versioning & Internationalization ( 版) https://developer.foursquare.com/overview/versioning

You can specify the locale by setting the Accept-Language HTTP header in your request. Alternatively, you can add a locale=XXX parameter to your request but HTTP header specification is preferred. We currently support en (default), es, fr, de, it, ja, th, tr, ko, ru, pt, and id.

[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

[53] Fitbit Web API Basics — Fitbit Web API Docs () https://dev.fitbit.com/docs/basics/

API calls reveal and log resource values in one of the unit systems based on the value of the Accept-Language header. If an endpoint respects the Accept-Language header, it is explicitly mentioned in the endpoint details.

Accept-Language Unit System

en_US US

en_GB UK

none of the above or not provided METRIC

[54] Strengthen requirements on CORS-safelisted request-headers (annevk著, ) https://github.com/whatwg/fetch/commit/9288c8f85c809a0ac371be6843ad2cf4046ee35b

[55] SORACOM API 利用ガイド | SORACOM Users () https://dev.soracom.io/jp/docs/api_guide/#errormessage

API 呼び出しリクエストのヘッダーに X-Soracom-Lang: を含めると、その言語コードに対応している場合はエラーメッセージもその言語になります。(未対応の言語に対しては英語にフォールバックします)

現在対応している言語は en(英語), ja(日本語) の 2 つです。