Re: what should the charset be in the response to the server

On Fri, 25 Jul 2003, Shigemichi Yazawa wrote:

> At Fri, 25 Jul 2003 16:11:17 -0400 (EDT),
> Jungshik Shin wrote:
> >
> >   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)
>
> This is a very good example that shows that any standard must be
> created with i18n in mind. It's very hard to change it after it's out
> to the public.

  Indeed, it is. Our activities here would prevent similar things from
happening again.

> >   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
>
> I tried this, but neither Mozilla 1.0 nor IE 6.0 add content-type
> header in any part. I see something like this.

  Have you tried Mozilla 1.4? Mozilla 1.0 is pretty outdated and a lot
of features have been added since.


>
> -----------------------------75689853717345751981973594324
> Content-Disposition: form-data; name="i18n"
>
> test string
> -----------------------------75689853717345751981973594324--

Have you tried entering some non-ASCII characters? The default (in MIME)
content-type is 'Content-Type: text/plain; charset=US-ASCII' and it can
be omitted. If it still does  not add 'C-T' header with charset
parameter for non-ASCII chars, I'll file a bug
and hopefully fix it.

> If browsers support charset parameter in multipart/form-data, it would
> disambiguate the character encoding, although getting input values
> become a little cumbersome (you can't use the convenient
> getParameter() method).

   Yeah, the server side tools written in Java, Perl, Python, VB etc have
to be updated as well.

   Jungshik

Received on Friday, 25 July 2003 23:39:22 UTC