W3C home > Mailing lists > Public > www-international@w3.org > October to December 2001

RE: Servlet question

From: souravm <souravm@infy.com>
Date: Fri, 19 Oct 2001 13:54:31 +0530
Message-ID: <755FA95DB839D211856B0008C7287D930DE6A880@kecmsg02.ad.infosys.com>
To: <www-international@w3.org>
Hi Thierry, Shigemichi,

The problem is setContentType works fine when the string you are
printing out is an Unicode string. When you're printing a string which
is non-Unicode, servelet Engine assumes it to be in Unicode and converts
it to the output bytes based on the encoding specified in content type.
In thia case junk is being shown.

Where as if content type is specified through meta tag what I found even
the non unicode string is displayed properly. I don't know how it works.


-----Original Message-----
From: Thierry Sourbier [mailto:webmaster@i18ngurus.com]
Sent: Friday, October 19, 2001 11:07 AM
To: www-international@w3.org
Subject: Re: Servlet question


For parameter reading, the API 2.3 introduces a new method:
request.setCharacterEncoding(Encoding) that let you specfy the character
encoding used to encode parameters in a request. If your servlet
inplementation does not yet support this API then you'll probably have
to do
the data convertion *by hand* by first converting your params back to a
stream using the system default encoding then decode the byte stream
the proper encoding. (that's roughly 2 extra lines of code).

For the output, any JSP intended to return data in a character encoding
other than the default (ISO-8859-1 Latin) should contain a content-type
directive near the beginning of the file, in the following form:

<%@ page contentType ="text/html; charset=characterSet" %>

Note that you can also do this by setting the content type header
response.setContentType() as Shigemichi hinted. Note that both those
will normally directly generate the proper HTTP header suppressing
the need for the Meta Tag.


www.i18ngurus.com - Open Internationalization Resources Directory
Received on Friday, 19 October 2001 04:25:25 UTC

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