[3]

Content-Language: ヘッダーは、対象となるデータの自然言語を表すものです。

意味

[34] HTTP における Content-Language: ヘッダーは、表現の想定読者の自然言語(群)を指定するものです。これは必ずしも表現中で用いられている言語すべてのリストでなくても構いません。 >>26

[42] HEAD メソッドに対する応答の場合は、 GET だったなら返される表現についての情報を表しています。

[35] このヘッダーの主目的は、利用者が自身の好むpreferredpreferred言語と表現の言語を比べて識別できるようにするものだ >>26 と説明されています。

[63] それって具体的にどういうことなのでしょう? 知らない言語だったらその応答は捨てるとか? あまりそのような処理方法はイメージできませんが...

[64] 実際にはこのヘッダーが利用されるとしたら、表示、音声合成、その他の言語情報を使った処理への入力として、が最も普通の用途と思われます。言語情報

[36] このヘッダーが指定されていなければ、すべての言語の読者を対象にしていることを表します。これは、送信者が特定の自然言語の読者を想定していない場合もあれば、想定する言語をわかっていない場合もあります。 >>26

[62] それを「すべての言語の読者を対象」と表現するのはちょっとおかしいのでは、という気がしますが、 HTTP の仕様書には一応そのように説明されています。

[37] 複数の言語を指定して、複数の読者を対象にしていることを示すこともできます。ただし、表現中に複数の言語が現れるからといって、複数の言語を対象にしているとは限りません。 >>26

[38] 例えば日本語で書かれた「英会話入門」には日本語と英語が現れますが、想定読者は日本語が分かる人ですから、 Content-Language: ja が適当です。

文脈

[39] Content-Language: は、テキスト系に限らず、どんな MIME型にも適用できます。 >>26

[56] 言い換えると、 Content-Type: との依存関係はありません。

HTTP での利用

[58] HTTPヘッダーとして利用できます。 HTTP要求にもHTTP応答にも指定できます。

[59] あくまで「内容」の言語を表すものです。 HTTP要求に指定したとて、 HTTP応答に関する指定として解釈されるものではありません。 HTTP応答に関する指定をしたいときは、 Accept-Language: に指定します。

[27] HTTP では、1つのHTTPメッセージのヘッダー部中に複数個 Content-Language: ヘッダーを指定できます (>>30)。

[60] HTTP では、使われることは皆無ではありませんが、それほど多くは見かけません。

[61] かつて Apache と内容折衝がよく使われていた頃 (平成時代中期頃) は、ファイル名に言語を表す拡張子を付けておけば自動的に Content-Language: ヘッダーに設定される (かつ Accept-Language: を使った処理に適用される) ようになっているために、たまに送出されていました。内容折衝

MIME での利用

[57] MIMEヘッダーとして利用できます。インターネットメールを含む、任意のMIME実体のヘッダーに指定できます。

[55] インターネットメールでは、使われることは皆無ではありませんが、それほど多くは見かけません。元々の RFC 822 のヘッダーでも、 MIME の初期からのヘッダーでもないため、このヘッダーを出力するべきという慣習が生じなかったためと考えられます。

[103] multipart/alternative では言語違いの選択内容折衝に使うことができます。 multipart/alternative

HTML での利用

[66] HTML では <meta http-equiv=Content-Language> として記述できます。

[67] これは不適合で、著者は使ってはならないとされています。 >>65 しかし後方互換性のため Webブラウザーは実装しなければなりません。

[68] 昔から例文などで (意味もよく理解しないままコピペで) よく紹介されていたためもあってか、しばしば見かけます (がそれほど多いというわけでもありません)。

[69] HTML5 の開発当時、これを使った文書が不適合と判定されるのを快く思わない人がそれなりにいた (程度にはまま使われていた) ために、不適合であるものの適合性検査器はエラーとしなくていいという玉虫色の決着がなされました >>15。

[70] 今ならこの措置ももう不要でしょうね。

[105]

Lightweight HTML renderer, layout manager and print engine, 2024-08-17T08:10:31.000Z, 2004-12-13T19:19:44.193Z

https://web.archive.org/web/20041213191849/http://www.terrainformatica.com/htmlayout.old/index.htm

    <meta http-equiv="content-language" content="english">

異体説明 `language` 異体属性

[2] 異体説明の language 異体属性は、 Content-Language: ヘッダーに相当するものです >>1。

[43] 属性値は、1つ以上の言語タグのリスト (#) です >>1。

言語タグ
*
1. OWS
2. ,
3. OWS
4. 言語タグ

`DAV:getcontentlanguage` 特性 (WebDAV)

[45] DAV:getcontentlanguage 特性は、 accept header なしで GET した時に返されるであろう Content-Language: ヘッダーの値を表します >>44。

[52] Content-Language: ヘッダーを返す WebDAV に従う資源はすべて DAV:getcontentlangauge 特性を定義しなければなりません >>44。

[47] 値は言語タグです >>44。

言語タグ

[48] ヘッダーの値が OWS を含む場合には、これを除去して特性値として使うべきです >>46。

[49] 保護特性とするべきではありません >>44。

[50]

RFC 2518 時代の鯖は、保護特性としているかもしれません

>>44

。

[51] COPY や MOVE でも値が保持されるべきです >>44。

複数の値

[71] Content-Language には、言語タグを複数指定できます。また、 HTTPヘッダーや meta 要素は複数指定されることがあります。 (>>37, >>28, >>30)

[72] HTTP では、仕様上、 HTTPヘッダー複数個で指定するのは、 HTTPヘッダー1個に , 区切りで順に並べて指定するのと等価とされています。リスト (HTTP)

[73] HTML では、複数の meta 要素で指定された場合、最後のものが採用されます。 >>65 これは実際の Webブラウザーがそう実装していたことによります >>22。

[74] HTML では、1つの meta 要素に複数指定された場合、その指定全体が無視されます。 >>65

[75] HTML では、要素の言語の決定に際して、

[76] 要素の lang="" や xml:lang=""
[77] <meta http-equiv=Content-Language>
[78] プロトコルの言語情報
[85] 未知の言語 (言語の指定: 空文字列)

の優先順位で言語の指定が使われます。 >>65

[79] プロトコルの言語情報は「such as HTTP」 >>65 としかありませんが、具体的には

[80] HTTP の Content-Language:
[81] MIME の Content-Language:
[82] ファイルシステムの言語情報 (もしあれば)
[102] about: (about:blank, about:srcdoc を除く。), ブラウザー拡張, その他Webブラウザー独自の URL scheme などでは、 Webブラウザー依存の方法で指定した言語情報 (もしあれば)

が該当することになるのでしょう。

[91] この辺は仕様書として敢えて明確に規定せずに任意のプロトコルに対応できるようにしていたのでしょうが、当時としてはともかく、現在ならもっと明確な規定が必要な箇所ですね。いずれ改定が望まれます。

[98]

初期about:blankでは言語情報の規定がなく、無指定と同等と思われます。

[99]

iframe srcdoc文書はHTTP応答相当の規定があり、 Content-Language: は含まれない形で定義されています。つまり無指定と同等です。 (iframe 要素の言語は影響しません。)

[101]

data:, ftp: には言語情報を指定する方法がなく、無指定とみなされます。

[83] プロトコルの言語情報が複数の言語の場合、未知の言語 (言語の指定: 空文字列) とみなすことになっています。 >>65

[84]

Content-Language: に指定した複数の言語タグのうち先頭のものや最後のものが選ばれるのではなく、すべて無視されることに注意。

[86] この HTML の規定は、 HTML文書だけでなく、 XML文書にも適用されます。また、それ以外のファイル形式でもWebブラウザーの閲覧文脈内で表示されるもの (平文文書、媒体文書など) に適用されます。

[87] 例えば、言語情報を内部に記述する方法のない text/plain のファイルでも、 Content-Language: ヘッダーに lang="" 属性相当の指定ができます。

[92]

XML の仕様書にも xml:lang="" の規定として >>75 に近いものが定められていましたが、 HTML 関連の規定がないのが >>75 と違っています。現在では HTML の仕様書に従うべきです。

[88] この規定は、事実上 Content-Language: に複数の言語タグを指定しても役に立たないことを意味しています。

[90] 複数の言語タグが指定されたとき、それをどう処理に活用するべきか、 HTTP も MIME も明確にしていない以上、この措置は致し方ないでしょう。例えば言語タグを使ったフォントの選択で、複数の言語タグがあっても解釈が混乱するだけです。思い切ってすべて捨てるのは現実的な選択です。

[89] 著者は Content-Language: ヘッダーを高々1つ指定し、指定する場合はちょうど1つだけ言語タグを指定するのが望ましいでしょう。適合性検査器はそうでなければ警告を出すべきです。

[104] HTML や XML を扱う以外の応用 (HTTPクライアント) も、言語情報を使うものは HTML Standard と整合する処理方法とするべきでしょう。

[93] Content-Language: と encoded-word や引数引数 (MIME)の言語情報との相互関係は明確な規定がないようですが、両者は独立したものとするのが仕様策定側の意向と考えられます。

[95]

ヘッダーは互いに独立というのが RFC 822メッセージの伝統的な考え方です。

[94] ただ現実的には encoded-word や引数引数 (MIME)の言語情報がない場合には Content-Language: にフォールバックする方がより適切な結果を得られるとも考えられます。

[96] multipart/* や message/* によってメッセージや実体が入れ子になっているとき、 Content-Language: の適用関係は定かではありません。

[97] Link: などでヘッダー内の人間可読な文字列が Webブラウザーに表示されるときについても、必ずしも仕様上言語情報の取り扱いが明確ではありません。

[100] フレーム (iframe, frame) の内外関係は言語情報に関係しません。

歴史

[25] 元々 RFC 1766 で定義されていました。

[54] 平成14(2002)年5月2002-05末、新しい RFC 3282 により再定義されました。

[8] HTTP も別途定義しています。

[4] Content-Language = "Content-Language" ":" [CFWS] Language-List
[5] Language-List = Language-Tag [CFWS] *("," [CFWS] Language-Tag [CFWS])
[6] obs-content-language = "Content-Language" *WSP ":" [CFWS] Language-List (RFC 1766 および RFC 3282 より作成)

RFC 1766

[18] RFC 1766 - Tags for the Identification of Languages http://tools.ietf.org/html/rfc1766#section-3

[21] RFC 2130 はこの Content-Language と同様の形式による自然言語の指定を他のプロトコルでも (必要なら) 使うことが好ましいと述べています。

[20]

The specification technique should be a MIME identifier with IANA registered values for languages. If headers are used, the header should be 'Content-Language'.

RFC 2130 - The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996 (2011-09-04 12:12:00 +09:00 版) http://tools.ietf.org/html/rfc2130#page-12

HTTP

RFC 1945 (HTTP/1.0) D.2.5; (HTTP/1.1) RFC 2068 14.13; RFC 2616 14.12 Content-Language

The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity. Note that this ~~{1945,2068} may~~ {2616} might not be equivalent to all the languages used within the entity-body {2068,2616}.

Content-Language 実体頭欄は、囲まれた実体の想定視聴者の自然言語を記述します。これは entity-body 中で使われている全ての言語と等しくないかもしれないことに注意して下さい。

{2068,2616}
Content-Language = "Content-Language" ":" 1#language-tag

Language tags are defined in section 3.10. The primary purpose of Content-Language is to allow a user to identify and differentiate entities according to the user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate field is

言語札は 3.10 節で定義しています。 Content-Language の主たる区的は、利用者が利用者自身の優先言語に従って実態を識別・差別化することを可能とすることにあります。従って、本体内容がデンマーク語が分かる視聴者のみを想定しているのであれば、適切な欄は

Content-Language: da

If no Content-Language is specified, the default is that the content is intended for all language audiences. This ~~may~~ might mean that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language it is intended.

Content-Language が指定されていなければ、既定値はその内容がすべての言語の視聴者を想定しているになります。これは、送信者がそれが何らかの自然言語に特有のものであると考えていないか、送信者がどの言語が想定されているのか知らないことを意味するでしょう。

Multiple languages MAY be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi," presented simultaneously in the original Maori and English versions, would call for

複数の視聴者を想定している内容については、複数の言語を列挙しても構いません。例えば、 Treaty of Waitangi の翻訳で、元のマオリ版と英語版が並行して示されているなら、

Content-Language: mi, en

となるでしょう。

However, just because multiple languages are present within an entity does not mean that it is intended for multiple linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly intended to be used by an English-literate audience. In this case, the Content-Language ~~should~~ would properly only include "en".

しかし、ただ単に実体中に複数の言語が示されていることは複数の言語の視聴者を想定していることを意味しません。例えば、初めての言語入門書, 例えば『A First Lesson in Latin』のような明らかに英語の分かる視聴者に使われることを意図したものを考えましょう。この場合だと、 Content-Language は en だけを含めるのが適当でしょう。

Content-Language ~~may~~ MAY be applied to any media type -- it is not limited to textual documents.

Content-Language はどの媒体型に適用してもかまいません。文的文書には制限しません。

RFC 3282

[19] RFC 3282 - Content Language Headers http://tools.ietf.org/html/rfc3282

[32] MIME 側の定義が独立する形で新しい版が発行されました。

[33] HTTP にも適用することをほのめかすような記述もありましたが不明瞭でした。 HTTP の改訂版である RFC 7231 は、 RFC 3282 を参照していないで独自に定義しています。

`<meta http-equiv=Content-Language>`

[14] よく、 HTML文書に <meta http-equiv="Content-Language" content="ja"> のように言語を指定すれば文字化けしなくなるなどと適当な解説がされていますが、まったく意味がありません。

http-equiv は本来鯖が解釈するものでしたが、そうするように設定されている鯖はほとんどありません。 Webブラウザが解釈することもありますが、保障されているわけではありませんでした。 本当の HTTP 頭欄としての Content-Language: を指定するか、 HTML の要素に lang を指定するのが適切なやり方です。

いずれにしても、文字コードとはまったく関係ありません。文字化けがなくなるなどと解説している文書は信用してはいけません。

[15] <meta http-equiv="Content-Language"> (Ian Hickson 著, 2008-12-02 16:05:28 +09:00 版) http://lists.w3.org/Archives/Public/public-html/2008Dec/0032.html

<meta http-equiv=Content-Language> は不適合になりました。

[16] (X)HTML5 Tracking (2009-10-27 22:21:31 +09:00 版) http://html5.org/tools/web-apps-tracker?from=4336&to=4337

[17] Web Applications 1.0 r5980 8088 ( (2011-04-09 07:20:00 +09:00 版)) http://html5.org/tools/web-apps-tracker?from=5979&to=5980

メモ

[9] 2002-11-16 (土) 19:06 名無しさん: 関連して内容折衝に使われる対応する欄として、 Accept-Language:欄があります。
[10] 2002-11-16 (土) 19:08 名無しさん: 言語情報は転送プロトコル層に使われるこの欄ではなく、より上の層で記述されることもあります。 (例えば HTML の lang属性や XML の xml:lang属性, あるいは Unicode の14面言語タグ, ファイル名の一部など。) どれを使うのが適切かは、その場面によるでしょう。
[11] >>10 言語情報
[12] この欄って使われてるのかなあ? MIME にしろ HTTP にしろ有意義に使われてるのって見たことなくない?
[13] 欄自体は、 MIME ではたまにしか見ないけど、 HTTP では Apache とかで内容折衝に使う関係で、ちゃんと設定されてることも少なくないよね。情報提供側はまあまあいけてるけど、実際に応用側ではどうだろう。。。

[22] Web Applications 1.0 r7283 Change Content-Language pragma to obeying the last pragma, not the first, as this is closer to what Firefox, IE9, and WebKit do. ( (2012-08-28 04:32:00 +09:00 版)) http://html5.org/tools/web-apps-tracker?from=7282&to=7283

[23] Web Applications 1.0 r8389 Mention that the content-language pragma intentionally ignores words after the first (hopefully browsers end up matching this... they vary in their behaviour today) ( (2014-01-10 04:19:00 +09:00 版)) http://html5.org/tools/web-apps-tracker?from=8388&to=8389

[24] IRC logs: freenode / #whatwg / 20140115 ( (2014-01-16 20:18:06 +09:00 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20140115#l-249

[41] 文書中の JavaScript から Content-Language: ヘッダーにはアクセスできないので、 Content-Language: を使うより文書要素の lang 属性に指定する方が好ましいと考える人もいます。

[53] Strengthen requirements on CORS-safelisted request-headers (annevk著, 2018-05-25 18:19:35 +09:00) https://github.com/whatwg/fetch/commit/9288c8f85c809a0ac371be6843ad2cf4046ee35b

仕様書

意味

構文

文脈