accept-charset 属性 (HTML)

[1] HTML の form 要素の 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 名は間隔で区切らなければならないのだとか、あるいは読点で区切らなければならないのだとかいう風説が流布しています。

例

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

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

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

Perl で Encode や Jcode を使っている場合はこれが一番近いです。

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

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

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

Perl で jcode.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] 仕様書:

HTML 4
- form 要素 accept-charset 属性 IW:HTML4:"interact/forms.html#adef-accept-charset"
- HTML 4 Changes IW:HTML4:"appendix/changes.html#h-A.1.1.12"

メモ

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

[29] ところで、input要素の欄などで入力文字列に送信 charset で表せない文字が含まれていた場合、 HTML4 で >>8 のように書かれている以外にはなんとも指定がありません。 WinIE や Mozilla の実装では、 &#n; と SGML の数値文字参照風に (もちろん UCS の符号位置で) 送ってきます。 (& は & にはしません。) この仕様は 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 に触れていません。

[14] しかしながら、現実の運用 (サーバー側の実装にしろ、 UA にしろ。) は application/x-www-form-urlencoded を任意のオクテット列として取り扱っています。そして多くの (全ての?) accept-charset を実装した UA は、 get や application/x-www-form-urlencoded の場合でも accept-charset を参照しています。サーバー側もそれを期待しています。
[15] こと文字周りに関しては、 HTML の仕様書はほとんど当てになりません。長らく需要に追いついていなかったためです。 HTML2.0 が出る以前から漢字とか実際には平気で使われてたのに、規格は HTML 4 でようやく追いついたくらいですから。余談だけど HTML3.2 では日本語を扱えないから云々の類の話を聞くと嫌になっちゃうね。確かに厳密に SGML宣言まで見ればその通りだけど、一体それに何の意味があるのか。