[3] Content-Language: ヘッダーは、
対象となるデータの自然言語を表すものです。
[34] HTTP における Content-Language: ヘッダーは、
表現の想定読者の自然言語(群)を指定するものです。
これは必ずしも表現中で用いられている言語すべてのリストでなくても構いません。 >>26
[42] HEAD メソッドに対する応答の場合は、
GET だったなら返される表現についての情報を表しています。
[35] このヘッダーの主目的は、 利用者が自身の好む言語と表現の言語を比べて識別できるようにするものだ >>26 と説明されています。
[64]
実際にはこのヘッダーが利用されるとしたら、
表示、音声合成、その他の言語情報を使った処理への入力として、
が最も普通の用途と思われます。
[36] このヘッダーが指定されていなければ、すべての言語の読者を対象にしていることを表します。 これは、送信者が特定の自然言語の読者を想定していない場合もあれば、 想定する言語をわかっていない場合もあります。 >>26
[37] 複数の言語を指定して、複数の読者を対象にしていることを示すこともできます。 ただし、表現中に複数の言語が現れるからといって、複数の言語を対象にしているとは限りません。 >>26
[28] MIME でも HTTP >>26 でも、1つ以上の言語タグを ,
で区切って並べたものとされています。
[29] MIME では字句間に CFWS が挿入できます。
[30] HTTP では、リスト (#) とされています >>26。
[7] 言語タグは、 BCP 47 で定義されています。数世代の RFC があり、途中で非互換変更も行われています。どの版が参照されているかは、 MIME や HTTP の仕様書の版によっても異なっています。
[39] Content-Language: は、テキスト系に限らず、
どんな MIME型にも適用できます。 >>26
Content-Type: との依存関係はありません。[58] HTTPヘッダーとして利用できます。 HTTP要求にもHTTP応答にも指定できます。
Accept-Language:
に指定します。[27] HTTP では、1つのHTTPメッセージのヘッダー部中に複数個
Content-Language:
ヘッダーを指定できます (>>30)。
[60] HTTP では、使われることは皆無ではありませんが、それほど多くは見かけません。
[61]
かつて Apache と内容折衝がよく使われていた頃 (平成時代中期頃)
は、ファイル名に言語を表す拡張子を付けておけば自動的に
Content-Language: ヘッダーに設定される
(かつ Accept-Language: を使った処理に適用される)
ようになっているために、たまに送出されていました。
[57] MIMEヘッダーとして利用できます。 インターネットメールを含む、 任意のMIME実体のヘッダーに指定できます。
[55] インターネットメールでは、 使われることは皆無ではありませんが、それほど多くは見かけません。 元々の RFC 822 のヘッダーでも、 MIME の初期からのヘッダーでもないため、 このヘッダーを出力するべきという慣習が生じなかったためと考えられます。
[103]
multipart/alternative では言語違いの選択に使うことができます。
[66]
HTML
では
<meta http-equiv=Content-Language>
として記述できます。
[67] これは不適合で、著者は使ってはならないとされています。 >>65 しかし後方互換性のため Webブラウザーは実装しなければなりません。
[68] 昔から例文などで (意味もよく理解しないままコピペで) よく紹介されていたためもあってか、 しばしば見かけます (がそれほど多いというわけでもありません)。
[69] HTML5 の開発当時、これを使った文書が不適合と判定されるのを快く思わない人がそれなりにいた (程度にはまま使われていた) ために、 不適合であるものの適合性検査器はエラーとしなくていいという玉虫色の決着がなされました >>15。
<meta http-equiv="content-language" content="english">
language 異体属性[2] 異体説明の language 異体属性は、
Content-Language: ヘッダーに相当するものです >>1。
[43] 属性値は、1つ以上の言語タグのリスト (#) です >>1。
DAV:getcontentlanguage 特性 (WebDAV)[45] DAV:getcontentlanguage 特性は、
accept header なしで GET した時に返されるであろう
Content-Language: ヘッダーの値を表します >>44。
[52] Content-Language: ヘッダーを返す WebDAV
に従う資源はすべて
DAV:getcontentlangauge 特性を定義しなければなりません >>44。
[71]
Content-Language
には、
言語タグを複数指定できます。
また、
HTTPヘッダーや meta 要素は複数指定されることがあります。
(>>37, >>28, >>30)
[72]
HTTP では、仕様上、 HTTPヘッダー複数個で指定するのは、
HTTPヘッダー1個に , 区切りで順に並べて指定するのと等価とされています。
[73]
HTML では、複数の meta 要素で指定された場合、
最後のものが採用されます。
>>65
これは実際の Webブラウザーがそう実装していたことによります >>22。
[74]
HTML では、1つの meta 要素に複数指定された場合、
その指定全体が無視されます。
>>65
lang="" や xml:lang=""<meta http-equiv=Content-Language>[79] プロトコルの言語情報は「such as HTTP」 >>65 としかありませんが、 具体的には
Content-Language:Content-Language:about: (about:blank, about:srcdoc を除く。),
ブラウザー拡張,
その他Webブラウザー独自の URL scheme
などでは、
Webブラウザー依存の方法で指定した言語情報 (もしあれば)が該当することになるのでしょう。
iframe srcdoc文書はHTTP応答相当の規定があり、
Content-Language: は含まれない形で定義されています。
つまり無指定と同等です。
(iframe 要素の言語は影響しません。)[83] プロトコルの言語情報が複数の言語の場合、未知の言語 (言語の指定: 空文字列) とみなすことになっています。 >>65
[86] この HTML の規定は、 HTML文書だけでなく、 XML文書にも適用されます。 また、それ以外のファイル形式でもWebブラウザーの閲覧文脈内で表示されるもの (平文文書、媒体文書など) に適用されます。
[87]
例えば、言語情報を内部に記述する方法のない text/plain
のファイルでも、 Content-Language: ヘッダーに
lang="" 属性相当の指定ができます。
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 や引数の言語情報との相互関係は明確な規定がないようですが、
両者は独立したものとするのが仕様策定側の意向と考えられます。
[94]
ただ現実的には encoded-word や引数の言語情報がない場合には
Content-Language: にフォールバックする方がより適切な結果を得られるとも考えられます。
[96]
multipart/*
や
message/*
によってメッセージや実体が入れ子になっているとき、
Content-Language:
の適用関係は定かではありません。
[97]
Link: などでヘッダー内の人間可読な文字列が
Webブラウザーに表示されるときについても、
必ずしも仕様上言語情報の取り扱いが明確ではありません。
[54] 末、 新しい RFC 3282 により再定義されました。
[21] RFC 2130 はこの Content-Language と同様の形式による自然言語の指定を他のプロトコルでも
(必要なら) 使うことが好ましいと述べています。
The specification technique should be a MIME identifier with IANA registered values for languages. If headers are used, the header should be '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
maymight 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
shouldwould properly only include "en".
しかし、ただ単に実体中に複数の言語が示されていることは複数の言語の視聴者を想定していることを意味しません。
例えば、初めての言語入門書, 例えば『A First Lesson in Latin』のような明らかに英語の分かる視聴者に使われることを意図したものを考えましょう。
この場合だと、 Content-Language は en
だけを含めるのが適当でしょう。
Content-Language
mayMAY be applied to any media type -- it is not limited to textual documents.
Content-Language はどの媒体型に適用してもかまいません。
文的文書には制限しません。
[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 著, 版) http://lists.w3.org/Archives/Public/public-html/2008Dec/0032.html
<meta http-equiv=Content-Language> は不適合になりました。
[16] (X)HTML5 Tracking ( 版) http://html5.org/tools/web-apps-tracker?from=4336&to=4337
[17] Web Applications 1.0 r5980 8088 ( ( 版)) http://html5.org/tools/web-apps-tracker?from=5979&to=5980
[40] 文書に含まれる要素の言語の決定には lang
属性が使われますが、文書要素にも明示されていない場合、
Content-Language: ヘッダーがあれば、その値が採用されます。
[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. ( ( 版)) 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) ( ( 版)) http://html5.org/tools/web-apps-tracker?from=8388&to=8389
[24] IRC logs: freenode / #whatwg / 20140115 ( ( 版)) 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著, ) https://github.com/whatwg/fetch/commit/9288c8f85c809a0ac371be6843ad2cf4046ee35b