- From: Jungshik Shin <jshin@i18nl10n.com>
- Date: Fri, 25 Jul 2003 16:11:17 -0400 (EDT)
- To: Shigemichi Yazawa <yazawa@globalsight.com>
- cc: <www-international@w3.org>
On Fri, 25 Jul 2003, Shigemichi Yazawa wrote: > At Wed, 23 Jul 2003 08:49:41 +0200, > Michael Jansson wrote: > > > > The web page above suggests that content-type param in HTTP request > header contains character encoding information of escaped characters > (i.e. %HH). But as far as I know, a value of content-type param of a > submitted form is always application/x-www-form-urlencoded without > character encoding information. I confirmed this with Mozilla 1.0 and For a while (before 1.0), Mozilla added 'charset' parameter to Content-Type header with application/x-www-form-urlencoded, but it broke a lot of CGI programs and was removed later. (see http://bugzilla.mozilla.org/show_bug.cgi?id=18643) > My understanding is that the character encoding in POST request is, > unfortunately, as ambiguous as in GET request. If you specify ENCTYPE="multipart/form-data" in FORM, you'll get charset parameter specified in each part of 'multipart/form-data' if necessary. See http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2 None of examples in HTML 4.01 has 'charset' parameter, but it's clear that the following is possible: Content-Type: multipart/form-data; boundary=AaB03x --AaB03x Content-Disposition: form-data; name="submit-name" Content-Type: text/plain; charset=EUC-JP Content-Transfer-Encoding: 8bit Japanese name in EUC-JP --AaB03x Content-Disposition: form-data; name="files"; filename="file1.txt" Content-Type: text/plain; charset=EUC-JP Content-Transfer-Encoding: 8bit ... contents of file1.txt in EUC-JP --AaB03x-- Jungshik
Received on Friday, 25 July 2003 16:11:28 UTC