struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J. Patterson Waltz III" <>
Subject Re: Character encoding problems after 1.1 to 1.2.4 upgrade
Date Wed, 05 Jan 2005 12:30:43 GMT
in article, Josh Cronemeyer at wrote
on 4/01/05 18:02:

> J. Patterson Waltz III wrote:
>> Merci Guillaume,
>> I had actually seen the references to the Filter solution in the comments of
>> Struts bug 16191 in Bugzilla:
>> I will try that out and see if it improves my results.
>> I remain perplexed at what changes between versions 1.1 and 1.2.4 of Struts
>> caused it to become susceptible to this problem. Any ideas on that?
>> Patterson
>> P.S. - I know how to view the headers of replies sent from the server to the
>> browser, but am not sure how to get at those sent from the browser to the
>> server, to make sure that they are indeed UTF-8. Any suggestions?
>> in article, Guillaume Cottenceau at
>> wrote on 4/01/05 16:40:
>>> Most probably the browser is sending data in UTF-8 but doesn't say so with
>>> charset= in the Content-Type header. If you're confident enough that the
>>> browsers will send UTF-8 (which should be the case if they are encoded in
>>> UTF-8 and you use accept-charset in the forms), you can use a filter which
>>> forces the HTTP request to be seen as UTF-8 in input (for example
>>> filters/SetCharacterEncodingFilter which is bundled with tomcat)[1].
> One way woulb be to set up a proxy that your browser uses to connect to the
> web.  I used to use web scarab.
> -josh
I still haven't figured out the solution to my problem, but I have figured
out one *cause* of it.

After using web scarab at Josh's suggestion to eavesdrop on the
conversations between my browser and app server, I've figured out what has
changed between Struts 1.1 and 1.2.4:

Struts 1.1 in spite of the the <%@ page pageEncoding="UTF-8"
contentType="text/html;charset=UTF-8" language="java" %> directive, Struts
was in fact sending back pages encoded in ISO-8859-1, and the resulting form
submissions were URL-encoded (and decoded) in the same format.

Struts 1.2.4 the directive is now being followed, and pages are sent out in
UTF-8 encoding. However, for some reason, the form data is not being decoded
as UTF-8, but still as ISO-8859-1.

This suggests to me that if I were to remove the contentType directive in
Struts 1.2.4, it would fall back to the default ISO-8859-1 encoding, and all
would work as before: except that my web application would then be
constrained to using only characters representable in that encoding.

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

View raw message