文字データを示唆する Content-Type を持つ HTTP 応答の場合、何も指定されていない場合、クライアントはどの文字セットを想定する必要がありますか?
https://stackoverflow.com/questions/2325571
-
22-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
Content-Type ヘッダーに charset パラメーターが指定されていない場合、 RFC2616 セクション 3.7.1 サブタイプ「text」のメディアタイプに対して ISO8859-1 を想定する必要があることを暗示しているようです。
送信者によって明示的なcharsetパラメーターが提供されていない場合、「テキスト」タイプのメディアサブタイプは、HTTPを介して受信したときに「ISO-8859-1」のデフォルトのcharset値を持つように定義されます。
「ISO-8859-1」以外の文字セットのデータまたはそのサブセットには、適切な憲章値をラベル付けする必要があります。
ただし、「application/x-javascript」のような Content-Type 値を持つ Javascript ファイルを提供するアプリケーションを日常的に目にします (つまり、charset パラメータはありません)。これらのスクリプトに非 ASCII UTF-8 文字が含まれている場合でも、ISO8859-1 として解釈されると破損します。
これはクライアントに問題を引き起こすものではないようです。クライアントはバイトを UTF-8 として解釈することをどのようにして知るのでしょうか?他の文字データのサブタイプに対して、UTF-8 をデフォルトにするルールはありますか?これはどこに文書化されていますか?
解決
私がチェックしたすべての主要なブラウザ (IE、FF、Opera) を完全にチェックしました RFC仕様を無視する この部分で。
データによって文字セットを自動検出するアルゴリズムに興味がある場合は、次を参照してください。 モジラ Firefox リンク。
コンテンツ タイプについて少し注意してください。 文字セットを持つのはテキストのみです. 。ブラウザーは text/javascript を処理するのと同じように application/x-javascript を処理すると想定するのが合理的です (IE6 を除くが、それは別の話です)。
インターネットエクスプローラ 前述のように、デフォルトの文字セット (おそらくレジストリに保存されている) が使用されます。
デフォルトでは、Internet Explorerは、サーバーによって返されたHTTPコンテンツタイプで指定された文字セットを使用して、この翻訳を決定します。このパラメーターが指定されていない場合、Internet Explorerは、ドキュメント内のMeta要素によって指定された文字セットを使用します。 ユーザーの好みを使用します メタ要素が指定されていない場合。
ソース: http://msdn.microsoft.com/en-us/library/ms537500%28VS.85%29.aspx
モジラ Firefox ここで示されているように、文字セットの自動検出を試みます。
このペーパーでは、ドキュメントのエンコーディングを決定するための 3 種類の自動検出方法を紹介します。 明示的な文字セット宣言なし.
ソース: http://www.mozilla.org/projects/intl/UniversalCharsetDetection.html
オペラ 文書化されているように、自動検出も使用します。
トランスポート プロトコルでエンコード名が提供されている場合は、それが使用されます。そうでない場合、Opera はそのページで文字セット宣言を調べます。 これが欠落している場合、Opera はエンコーディングを自動検出しようとします。, 、ドメイン名を使用して、スクリプトが CJK スクリプトであるかどうか、そうである場合はどのスクリプトであるかを確認します。Opera は UTF-8 を自動検出することもできます。
他のヒント
としてもapplication/javascriptがcharsetパラメータを有することができ、 RFC 4329 ので説明しました。他の質問には、ブラウザの実装の取り扱いです。申し訳ありませんが、テストされていません。
がない場合には、 charset パラメータで文字エンコーディングを指定できます。 コンテンツ. 。いくつかのコンテンツ タイプで採用されているいくつかのアプローチを次に示します。
HTML - 経由 メタタグ:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
HTML5 変異体：
<meta charset="utf-8">
XML (XHTML、KML) - 経由 XML宣言:
<?xml version="1.0" encoding="UTF-8"?>
文章 - 経由 バイトオーダーマーク. 。たとえば、 UTF-8 ファイルの最初の 3 バイトを 16 進数で表したもの:
EF BB BF
ドキュメントに関連付けられた文字セットとは異なり、非 ASCII 文字は、さまざまな方法を使用して ASCII 文字シーケンス経由でエンコードできることにも注意してください。
HTML - 経由 キャラクターリファレンス:
&#nnnn;
&#xhhhh;
XML - 経由 キャラクターリファレンス:
&
&defined-entity;
JSON - 経由 エスケープ機構:
\u005C
\uD834\uDD1E
さて、HTTP 1.1 プロトコルに関しては、 RFC 2616 は文字セットについて次のように述べています:
「charset」パラメーターは、一部のメディアタイプで使用され、データの文字セット（セクション3.4）を定義します。送信者によって明示的なcharsetパラメーターが提供されていない場合、「テキスト」タイプのメディアサブタイプは、HTTPを介して受信したときに「ISO-8859-1」のデフォルトのcharset値を持つように定義されます。「ISO-8859-1」以外の文字セットのデータまたはそのサブセットには、適切な憲章値をラベル付けする必要があります。互換性の問題については、セクション3.4.1を参照してください。
したがって、上記の私の解釈は次のとおりです できない デフォルトの文字セットを想定します を除外する タイプ「テキスト」のメディアサブタイプの場合。もちろん、私たちは現実の世界に住んでおり、実装者は常にルールに従うとは限りません。で説明されているように、 受け入れられた回答, 、さまざまな Web ブラウザ ベンダーは、明示的に指定されていない場合にドキュメントの文字セットを決定するための独自の戦略を実装しています。他のクライアント (Google Earth など) のベンダーも独自の戦略を実装していると想定できます。
RFC 4329 を定義する "アプリケーション/ javascriptの" メディア「テキスト/ javascriptの」、「アプリケーション/ X-ジャバスクリプト」、および他の類似のタイプの代替品として入力。セクション4.2は、デフォルトの文字は、明示的な「文字セット」パラメータが使用可能でないと全くユニコードBOMは、データの前に存在しない場合、UTF-8であることが確立コードする。
これは、XMLHttpRequestのためのビット特別だとここで説明されています。 http://www.w3.org / TR / XMLHttpRequestを/ の
明白なことを指摘： "アプリケーション/ X-javascriptのは、" "テキスト" のサブタイプではありません。
。