tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allistair Crossley" <>
Subject RE: ++ Best practive ?? ++ (JSP-->Servlet-->Database) character encoding.
Date Wed, 01 Sep 2004 08:50:11 GMT
We had to look at several areas:

1. JSP pageEncoding

<%@ page contentType="text/html; charset=UTF-8" %>

This ensures that the JSPs will display pretty much everything. Actually, our SQL Server database
runs Latin1_General_CI_AS (which does include euro). 
2. Database Connection URL


We discovered that we _had_ to talk to the database using an encoding it understood. It turned
out that Cp1252 was actually Latin1_General_CI_AS, so we make sure the character encoding
is set on our database driver.

3. Request Character Encoding

Taken from

Submitting information via a HTML form. Most browsers don't appear to send back a charset
in the request that corresponds to the encoding that was used to format the page. In this
case, the request character encoding defaults to ISO-8859-1 meaning that there's potentially
a mismatch between form data being sent (in UTF-8) and information retrieved from the request
(in ISO-8859-1) using the getParameter() method on the HttpServletRequest class. To fix this,
all you need to do is explicitly set the character encoding of the request before accessing


This is what the filter code I sent you does for all requests.

I hope this clears up your issue!

Alles gut, ich wuensche Dir Glueck!


> -----Original Message-----
> From: Ben Bookey []
> Sent: 01 September 2004 09:37
> To: Allistair Crossley
> Cc: Tomcat User List
> Subject: How to pre-determine the browser request character encoding
> type
> Hi Alistair,
> I hope you find time to do your work.... more questions :)
> Why should the IE client which is definitely reading/parsing as
> ISO-8859-15(i can see this in the IE menu bar), then post to 
> the server
> converting the Euro to a questionmark . its rather stupid of 
> IE isn't it,
> its definitely reading as ISO-8859-15 then posts anyway as 
> ISO-8859-1 ?
> Could you explain in simple english, how the filter ensures 
> that the request
> is in utf8 encoded.

> -----Original Message-----
> From: Ben Bookey []
> Sent: 01 September 2004 09:37
> To: Tomcat User List
> Cc: Allistair Crossley
> Subject: ++ Best practive ?? ++ (JSP-->Servlet-->Database) character
> encoding.
> Dear list,
> We have a web-based jsp-servlet application performing 
> updates, deletes and
> inserts into an oracle database running with Tomcat 5. We 
> want to support
> both
> american, and european customer client locales, so we want to 
> use either
> ISO-8859-15 or utf-8. But we are having problems saving the 
> Euro symbol when
> using ISO-8859-15 encoding.
> I had previously assumed that because java works with unicode 
> as default,
> that all data entered in a HTML form would be saved therefore 
> as UTF-8 into
> the database. (i.e. as soon as a value is assigned to  the a 
> java dataobject
> e.g. string or int). I am beginning to think this not to be 
> case, and that
> all data is saved in the database based on the original 
> encoding as posted
> by the browser. Please can someone explain what is really 
> going on?? Do i
> need to have some code which, checks the browser encoding in the HTTP
> header, and then convert/parse accordingly to a chosen 
> standard. This will
> then avoid the situation that our database could end up 
> containing records
> in different character encoding systems, which I suspect is 
> what is now
> happening.
> In addition, how does TC deal with framsets containing many 
> html pages. Are
> they all treated individually (in theory allowing many 
> character encodings
> to be used in each HTML frame), or as one unit.
> I LOOK very much forward to any reply on this matter.
> Sincerely,
> Ben Bookey
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

QAS Ltd.
Developers of QuickAddress Software
<a href=""></a>
Registered in England: No 2582055
Registered in Australia: No 082 851 474

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message