ちゃんとした定義見たいのはないみたいです。 必要とする仕様が適当に定義しています。 説明読めばわかりますが、 ASCII 文字以外の送信は意図していない みたいです。というかむしろ、(仕様策定の時点で無茶苦茶で) あえて無視せざるを得なかったのかもしれません。 でっかなバイナリ・データや非 ASCII 文字のデータを送るのには 相応しくないので、 [[multipart/form-data媒体型]]が推奨されています。 *BNF でっちあげ。 =body = field *(separator field) / obs-body =separator = "&" / obs-separator =field = name "=" value =name = 1*uchar / obs-name =value = 1*uchar / obs-value =uchar = ALPHA / DIGIT / "-" / "_" / "." / "," / ":" / joint / escaped / obs-uchar =joint = "+" =escaped = "%" escaped-code / "%0D%0A" =escaped-code = "0" ( "0" / .. / "9" / "B" / "C" / "E" / "F" ) / ( "1" / .. / "7" ) HEXDIGIT / obs-escaped-code =obs-escaped-code = 2HEXDIGIT =obs-separator = ";" ;; 下の注記を参照 =obs-body = *(separator field) [ separator ] =obs-name = *uchar =obs-value = *uchar =obs-uchar = "'" / "(" / ")" / ";" / "$" / "@" / "*" / "!" *区切文字 区切文字は "&" です。 一方、 HTML4 は、 CGI などの URI で x-www-form-urlencoded 同様の形式の query-part を使うときに、 "&" でなくて ";" を使うのが望ましい、としています。 もちろんこれは URI での話であって、 x-www-form-urlencoded の話は無いのですが、元々は同じ物ですし、 ";" に対応した CGI script では、両者(の復号処理)を一緒くたにして いるものが少なくありません。 ですから、復号側は必要に応じて ";" も区切り文字として扱うようにし、 符号化側は ";" を必ず URI escape して "%3B" とするのが 望ましいと考えられます。 また、幾つかの CGI script で区切り文字に使われている "$" も、同様に URI escape しておくのが望ましいでしょう。 *8ビットのオクテットの扱い 8ビットのオクテットを含むときは、 [[multipart/form-data媒体型]] を使うべきでしょう。 解釈の時。 XForm (WD) は、疑問を呈しつつも [[UTF-8]] にすべし、 といってます。 CGI script などの実装では、ビット組合せから自動判別するか、 特定の[[符号化文字集合]]に決め打ちしているのが多いようです。 (というか他に選択肢は無いな・・エラーで処理中止くらいしか。) IETF HTML 2.x (RFC 2070), HTML4 は accept-charset 属性により、 form 要素から送られるデータの charset を指定できるようにしています。但しこれを指定していない HTML 文書が多く、対応していない実装(UA)も少なくありません。 この既定値は "unknown" とされています。その場合、 HTML4 は文書の charset が指定されているとみなすように 言っています。 ですからこれだけの手がかりがあれば、余程運が悪く無い限り、 なんとか解読できるのではないでしょうか。 とはいえ、 charset 指定の可能な [[multipart/form-data媒体型]] を使うのが望ましいことにはかわりありません。 *W3C HTML 4.01 の説明 17.13.4 曰く: **application/x-www-form-urlencoded This is the default content type. Forms submitted with this content type must be encoded as follows: =Control names and values are escaped. Space characters are replaced by `+', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by `%HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as "CR LF" pairs (i.e., `%0D%0A'). =The control names/values are listed in the order they appear in the document. The name is separated from the value by `=' and name/value pairs are separated from each other by `&'. **和訳 これは ([[form要素]]からの送信時の) 既定の内容型です。 この内容型で送信する form は、次のように符号化しないといけません。 =制御 control 名と値を escape する。間隔文字は「+」で置き換えて、予約文字は [RFC1738] の2.2節で説明されているように escape する。つまり、非字母数字文字を「%HH」 (百分率記号と文字の ASCII 符号を表す2桁の16進数字) で置き換える。改行は「CR LF」組 (つまり「%0D%0A」) で表現する。 =制御名・値を文書に現れる順で列挙する。名前と値は「=」で区切って、名前・値組は互いに「&」で区切る。 *IETF HTML 2.0 (RFC 1866) の説明 W3C HTML 4.01 の説明とほぼ同じです。 2. には更に次のように 書かれています。 (もしかすると HTML4 でも他の部分に書いてあるのかも しれません。) 値無し (null) の領域は、省略しても構いません。 特に、未選択のラジオ・ボタンやチェック箱は 符号化データに出現させるべきではありません。 但し、 value 属性のある隠し領域は出現させるべきです。 *W3C XForm での説明 W3C HTML4 と大体同じです。但し、 XForm はまだ WD です。 *charset パラメーター 『WAP 日本仕様ガイドライン (日本語を用いたコンテンツ作成環境) ― WAP June 2000 Conformance Release 対応版 ―』, 2000 年10 月25 日 1.0 版, モバイル・インターネット・アクセス・フォーラム 第1技術部会 SPEC 作業班 という仕様書では、 [[charsetパラメーター]] が使えることになっています。 但し値はこいつの仕様上実質的に [[Shift_JIS]] のみとり得ます。 日本仕様じゃない元仕様にもあるのかとか、新版があればそれにも あるのかとかは、調べてません。 - [1] によると、古い [[Lynx]] は [CODE[charset]] パラメーターを付けてしまうようです。 [[perl]] の古い [[CGI]] 用 library である [[cgi-lib.pl]] はこれに対応していません。 - [2] なお、この実在しない [CODE[charset]] パラメーターを使った場合でも、 [[MIME]] の [CODE[charset]] パラメーターと同じ解釈にはなりませんから注意が必要です。