tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Bergsten <>
Subject Re: JSTL & character encoding
Date Mon, 29 Sep 2003 17:20:17 GMT
Adam Hardy wrote:
> Hi Robb,
> good solution. I suppose this is why it is called 'bleeding edge'!
> I see tomcat 5 implements servlet spec 2.4 - that is a relief.
> I checked out the servlet spec 2.4, as you said, there is the following 
> element-list in web.xml specified as 1 or more:
> <locale-encoding-mapping-list>
>   <locale-encoding-mapping>
>     <locale>ja</locale>
>     <encoding>Shift_JIS</encoding>
>   </locale-encoding-mapping>
> </locale-encoding-mapping-list>
> I shall try it out.
> Guess I have to learn to be even more bleeding edge and then I won't 
> spend hours wondering what's up!

Actually, if you use a Servlet 2.3, JSP 2.0 and JSTL 1.1 combo, the
charset you specify with the page directive will be used for the
response, no matter how many times setLocale() is called by the JSTL
actions. No need to mess with the locale/charset mappings.

To make a long story short, the whole i18n area was underspecified in
the older specifications, especially the order of precedence between
setContentType() and setLocale(). In Servlet 2.4, the charset set by
setContentType() is required to win over an implicit charset set by
setLocale() (and it's mappings between locales and charsets), and JSP
2.0 is required to call setContentType() with the value defined by the
page directive before processing the page.

So if you still run into this problem with this in TC 5, it's a bug.


> On 09/29/2003 12:40 PM Nedwick, Robert wrote:
>> I don't really understand why the behavior that is described in the
>> specification is desirable, especially since the JSTL is overriding 
>> explicit
>> page directives that set the response character set, and you don't have a
>> clue that it is doing it unless you're aware of this side effect of the
>> <fmt> tag library. I never got a response to a similar question that I 
>> had
>> posted on one of the tag lib mailing lists, but based on the fact that 
>> its
>> so well documented in the spec, I believe that someone must have had a
>> reason for this behavior. I think that part of the problem is that the 
>> next
>> servlet specification (2.4) provides a standard method of mapping of a
>> Locale to a character encoding via web.xml, and therefore the JSTL could
>> perform the setLocale() method in such a way that your page encoding 
>> was not
>> messed up.
>> Anyway, the solution that I came up with was to use a ServletFilter that
>> intercepted all calls to our presentation tier.  The filter would set the
>> request encoding and the response charset to UTF-8.  It would also pass a
>> custom subclass of HttpServletResponseWrapper named UTF8Response to 
>> the next
>> item in the chain.  UTF8Response basically just any method that could set
>> the response character set to be an empty operation.  It also would 
>> always
>> return UTF-8 for the response character set.
>> By using the custom response class, in conjunction with the 
>> ServletFilter,
>> we managed to get everything to work fine in Tomcat 4.1, Oracle 9iAS 
>> 9.0.3,
>> and Weblogic 6.1 (service pack 5 is required for Weblogic 6.1 due to 
>> bugs in
>> the ServletFilter implementation 6.1).  FYI, Oracle 9iAS still has some
>> other character encoding issues with JSP tags that use BodyContent so the
>> Oracle container still doesn't work 100% even after using the
>> filter/response wrapper.
>> Let me know if you have need any more details than this.
>> Good Luck, Robb

Hans Bergsten                                <>
Gefion Software                       <>
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at                                    <>

View raw message