accept-charset

accept-charset 属性 (HTML)

[1] HTMLform 要素の accept-charset 属性は、 フォーム処理エージェントが受け付ける charset を指定します。

代替

[11] この属性自体は非推奨ではありませんが、 Web 上の文字コードUTF-8 とするべきとされているので、 それに従う限り、この属性の出番はありません。

[27] 古いサーバーに対するフォームの提出でやむを得ない場合 (ほとんど無さそうですが。) を除き、この属性を使うべきではありません。

属性値

[7] この属性の値は %Charsets です。 つまり、 charset 名 (%Charset) を任意個、間隔及び/又は読点で分離したものです。 大文字・小文字は区別しません。 SGML 的には CDATA です。 HTML 4 17.3

この値並びは、排他的論理和と解釈しなければなりません HTML 4 17.3。 つまり、鯖は指定された charset のどれか1つを使って符号化することを要求しています。

[2] この属性は省略可能です。省略時の既定値は予約値 UNKNOWN です (DTD 的には #IMPLIED となっています)。 UA は、これをその form を転送するのに使った文字符号化 と解釈しても構いません。 HTML 4 17.3

ところで unknown 値を予約しているのは誰でしょうか。 HTML 4 でしょうか。少なくても IANAREG には予約されているというようなことは書かれていません。

[17] HTML 4 DTD では accept-charset 属性%Charsets 型になっています。そして HTML 4 DTD注釈 (参考), XHTML 1 DTD注釈 (規定), XHTML m12n 抽象モジュール定義に於ける属性型の定義 (規定) では間隔で分離するとしか説明がありません。 (名無しさん)

[23] + XHTML m12n DTDモジュール注釈 (規定)

UA による利用

[4] この属性の値は、フォームの提出の際に文字符号化の決定に使われます。 詳しくはフォームの提出の説明を参照してください。

[5] UA は、利用者に accept-charset 属性値を助言して構いません。 また、 accept-charset に応じて認識できない文字 (特定の charset で表現できない文字のことか?) の入力を制限しても構いません。 HTML 4 17.3

不思議解釈

[3] >>17 の通り、属性値内の charset 名は間隔と読点で分離します。 (実装はゆるく解釈して間隔文字ではなく空白としているかもしれません。)

しかし、世間一般には、 charset 名は間隔で区切らなければならないのだとか、 あるいは読点で区切らなければならないのだとかいう風説が流布しています。

関連

[6] Accept-Charset: 頭欄: 意味的に似ている HTTPAccept-Charset: 欄とは違って、 q 値の指定はできません。 多くの UA は前から順に使えるかどうか調べている模様です。

[12] enctype 属性: accept-charset 属性が特に設けられる以前は、 enctype 属性の値の媒体型charset 引数として受付け charset 名 (1つだけ) を指定することが行われていました。

[9] 提出: フォーム提出処理との関係 (action, method, enctype, accept などとの関係)、 特に指定された charset で表現できない文字の取扱いなどについては、 フォームの提出の説明を参照してください。

[18] 一般的な日本語用フォームの場合:

<form accept-charset="UTF-8 ISO-2022-JP EUC-JP Shift_JIS" (略)>

近代的な日本語対応のフォーム処理エージェントは、 大抵この4種類の charset くらいには対応しているはずです。

PerlEncodeJcode を使っている場合はこれが一番近いです。

[20] やや古めの日本語用フォームの場合:

<form accept-charset="ISO-2022-JP EUC-JP Shift_JIS" (略)>

少々古めの日本語対応のフォーム処理エージェントは、 この3種類の charset には対応しているはずです。

Perljcode.pl を使っている場合はこれが適当です。

[19] Windows 向け日本語用フォームの場合:

<form accept-charset="UTF-8 Windows-31J" (略)>

日本語対応のフォーム処理エージェントで、 標準的なシフトJIS ではなく Windows の独自拡張であるマイクロソフト標準キャラクターセットに対応している場合 (NEC拡張文字IBM拡張漢字などに対応している場合) にこのようにします。

[21] ISO-2022-JP で提出させる例:

<form accept-charset="ISO-2022-JP" (略)>

[24] Adobe: アドビの教育ソリューション:CS3 Web Premium (2007-08-02 21:53:04 +09:00 版) <http://www.adobe.com/jp/education/products/creativesuite/web/?xNavEdu=jpWS>

<form id="globalnav-search" class="ja" name="globalnav-search" method="get" action="/go/gn_search_jp" accept-charset="utf-8">

この文書自体も UTF-8

歴史

HTML4

[16] 仕様書:

メモ

[22] 「POST 時の文字符号化方式」 <http://bakera.jp/hatomaru.aspx/htmlbbs/inthread/3223> (名無しさん 2005-11-30 12:24:10 +00:00)

[29] ところで、input要素の欄などで入力文字列に送信 charset で表せない文字が含まれていた場合、 HTML4>>8 のように書かれている以外にはなんとも指定がありません。 WinIEMozilla の実装では、 &#n;SGML数値文字参照風に (もちろん UCS符号位置で) 送ってきます。 (&&amp; にはしません。) この仕様は W3C/IETF の仕様書に規定されているものではなく、独自のエラー処理と考えられます。

[10] >>29 これ、 Opera とかは ? にするんで、 どうするべきかって w3c-i18n で話題になってましたね。

[13] HTML 4 によれば、 application/x-www-form-urlencoded は ASCII 文字しか使えませんから、 accept-charset の効力も method=get の場合や post でも application/x-www-form-urlencoded の場合には効力がないであろうことが容易に推察できます。実際、 HTML 4 の該当部分では全然 accept-charset に触れていません。

[25] RFC 2070 ではどの input type に適用されるのか不明確です。

[26] Web Applications 1.0 r7647 Embrace the Encodings specification. ( ( 版)) <http://html5.org/tools/web-apps-tracker?from=7646&to=7647>

[8] Update integration with Encoding Standard · whatwg/html@6a31c26 ( 版) <https://github.com/whatwg/html/commit/6a31c26cf12e39dab1a488e75dd56c03d6786d39>

[28] Require utf-8 when specifying character encoding by sideshowbarker · Pull Request #3091 · whatwg/html () <https://github.com/whatwg/html/pull/3091>