[1] HTTP は MIME の charset の仕組みを流用していますが、細かい部分で色々と違いがあります。
そしてなんといっても問題なのが、 MIME 以上に HTTP では charset の規定が無視されています。
[2] MIME との最も重要な差異は、
Content-Type 欄の charset 引数が省略された時の既定値が、
MIME の US-ASCII ではなく
ISO-8859-1 であることです。
ただ、その規定の適用範囲が曖昧で困ります。 (すべての text/* に適用されるのか、 MIME の text/plain の定義と同じものに限るのか。 text/plain と同じ定義なら非 text にも適用するのか。) (そもそもこういう問題が生じるのは、欄の引数ではなく媒体型の引数であるはずの charset の定義をプロトコルが変えてしまったためです。 (そしてその元凶は、 MIME が text/* や charset を特別扱いしているせいです。。。))
HTTP uses the same definition of the term "character set" as that described for MIME:
HTTP は、用語「文字集合」を、 MIME で説明されているのと同じ定義で使用します :
The term "character set" is used in this document to refer to a method used with one or more tables to convert a sequence of octets into a sequence of characters. Note that unconditional conversion in the other direction is not required, in that not all characters may be available in a given character set and a character set may provide more than one sequence of octets to represent a particular character. This definition is intended to allow various kinds of character encodings, from simple single-table mappings such as US-ASCII to complex table switching methods such as those that use
ISO 2022'sISO-2022's {2616} techniques. However, the definition associated with a MIME character set name{1945} mustMUST fully specify the mapping to be performed from octets to characters. In particular, use of external profiling information to determine the exact mapping is not permitted.
用語「文字集合」は、この文書では、オクテットの列を文字の列に変換する一つ以上の表とともに使用する方式を参照するために使います。 逆方向への無条件の変換は必須ではなく、すべての文字が与えられた文字集合で利用可能ではないかもしれず、複数のオクテット列がある一つの特定の文字を示すかもしれないことに注意してください。 この定義は、 US-ASCII のような単純な単一表写像から ISO 2022 の技術を使った複雑な表切り替え方式まで種々の文字符号化を認めることを意図しています。 しかし、 MIME 文字集合名と関連付けられる定義はオクテットから文字への写像を完全に規定していなければなりません。 特に、正確な写像の決定のために必要な外部プロファイル情報の使用は認めていません。
Note: This use of the term "character set" is more commonly referred to as a "character encoding." However, since HTTP and MIME share the same registry, it is important that the terminology also be shared.
注意 : 用語「文字集合」のこの用法は、より一般的には「文字符号化」 と呼ばれます。しかし、 HTTP と MIME は同じ登録簿を共有していますから、 用語も共有することが重要です。
HTTP character sets are identified by case-insensitive tokens. The complete set of tokens
{1945} areis defined by the IANA Character Set registry{1945} [15].{1945} However, because that registry does not define a single, consistent token for each character set, we define here the preferred names for those character sets most likely to be used with HTTP entities. These character sets include those registered by RFC 1521 [5] -- the US-ASCII [17] and ISO-8859 [18] character sets -- and other names specifically recommended for use within MIME charset parameters.]]
HTTP 文字集合は大文字・小文字を区別しない字句で識別します。
字句の完全な集合は IANA 文字集合登録簿で定義します。しかし、この登録簿は各文字集合に単一の一貫した字句を定義してはいませんから、ここでそうした文字集合で HTTP 実体に使用するのに最も好ましい名前を定義します。この文字集合には、 RFC1521 により登録された US-ASCII 文字集合や ISO8859 文字集合や、 MIME charset 引数で使用することが特に推奨される他の名前を含みます。
{1945}
charset = "US-ASCII" | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3" | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6" | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9" | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR" | "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8" | token
Although HTTP allows an arbitrary token to be used as a charset value, any token that has a predefined value within the IANA Character Set registry
{1945} [15] mustMUST represent the character set defined by that registry. Applications{1945} shouldSHOULD limit their use of character sets to those defined by the IANA registry [19]].
HTTP は charset 値として任意の字句を使用することを認めていますが、
IANA 文字集合長禄簿で定義されている値はその登録簿で定義されている文字集合を表現しなければなりません。
応用は、その使用する文字集合を IANA 登録簿で定義されたものに制限するべきです。
{1945} The character set of an entity body should be labelled as the lowest common denominator of the character codes used within that body, with the exception that no label is preferred over the labels US-ASCII or ISO-8859-1.
実体本体の文字集合はその実体で使用している文字符号の最小公倍数で札付けするべきです。
但し札 US-ASCII や札 ISO-8859-1
を他よりも優先します。
{2616} Implementors should be aware of IETF character set requirements [38] [41].
実装者は、 IETF 文字集合要件に注意されたい。
{errata} HTTP uses charset in two contexts: within an Accept-Charset request header (in which the charset value is an unquoted token) and as the value of a parameter in a Content-type header (within a request or response), in which case the parameter value of the charset parameter may be quoted.
HTTP は charset を2つの文脈で使用します。
Accept-Charset 要求頭中で (charset 値は非引用字句。)
および (要求または応答の中の) Content-Type 頭の引数の値としてで、
charset 引数の引数値としての場合は引用しても構いません。
Some HTTP/1.0 software has interpreted a Content-Type header without charset parameter incorrectly to mean "recipient should guess." Senders wishing to defeat this behavior MAY include a charset parameter even when the charset is ISO-8859-1 and SHOULD do so when it is known that it will not confuse the recipient.
HTTP/1.0 ソフトウェアの中には charset
引数なしの Content-Type 頭を誤って
「受信者は推測するべし」を意味すると解釈するものがあります。
この動作を撃破したいと思う送信者は、 charset
が ISO-8859-1 であっても charset
引数を含めても構いませんし、
そうすることによって受信者を混乱させないだろうと分かっているのであれば、
そうするべきです。
Unfortunately, some older HTTP/1.0 clients did not deal properly with an explicit charset parameter. HTTP/1.1 recipients MUST respect the charset label provided by the sender; and those user agents that have a provision to "guess" a charset MUST use the charset from the content-type field if they support that charset, rather than the recipient's preference, when initially displaying a document. See section 3.7.1.
不幸にも、古い HTTP/1.0 クライアントの中には陽に示した charset
引数を適切に処理しないものがありました。 HTTP/1.1
受信者は送信者が提供した charset
札を尊重しなければなりません。そして charset
を「推測」する用意のある利用者エージェントは、
content-type 欄の charset
に対応していれば、最初の文書を表示する時にはその受信者の設定でではなく、
その charset を使わなければなりません。
[3]
WinIE 6.0 は、たとえばある URI 参照 u の頁を表示したときに、その charset が iso-8859-1 で、表示直後にアドレス
欄で Enter を押したら今度は charset が iso-2022-jp になっていたとき、 iso-8859-1 として解釈しようとして化けます。
再読込
ボタンではこの症状は起きません。
(名無しさん 2004-05-03 04:43:16 +00:00)