W3C home > Mailing lists > Public > www-international@w3.org > July to September 2003

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

From: Shigemichi Yazawa <yazawa@globalsight.com>
Date: Mon, 28 Jul 2003 10:41:08 -0600
Message-ID: <5evftmeh97.wl@flatiron.globalsight.com>
To: Jungshik Shin <jshin@i18nl10n.com>
Cc: <www-international@w3.org>

At Fri, 25 Jul 2003 23:39:13 -0400 (EDT),
Jungshik Shin wrote:
>   Have you tried Mozilla 1.4? Mozilla 1.0 is pretty outdated and a lot
> of features have been added since.
> 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.

I entered a Japanese text and got the same result. No content-type
header.  Mozilla 1.4 (for Windows) doesn't put it either.

I setup a JSP here. Feel free to try this out yourself.


The input data in this page is written out in ISO-8859-1. So any
non-ASCII string will be shown as garbage.

I also setup another JSP that adds accept-charset="UTF-8" in FORM
element as Chris suggested.


It seems to work fine even if you change the character encoding in
your browser. This seems to be a effective solution for immediate

Even using this technique, you still have to do this old trick.

  new String(request.getParameter("param").getBytes("ISO8859_1"), "UTF-8");

That's because the character encoding is specified only in the page
source and not in the HTTP request.

It seems that enctype="text/plain" was proposed at some point. If this
scheme is employed and browsers add charset parameter in HTTP request,
the server side API can reliably convert the character encoding. Just
a thought...

Shigemichi Yazawa
Received on Monday, 28 July 2003 12:41:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:40:47 UTC