[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。
language
異体属性[2] 異体説明の language
異体属性は、
Content-Language:
ヘッダーに相当するものです >>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
と同様の形式による自然言語の指定を他のプロトコルでも
(必要なら) 使うことが好ましいと述べています。
[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