tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <ahardy.str...@cyberspaceroad.com>
Subject Re: JSTL & character encoding
Date Mon, 29 Sep 2003 12:04:36 GMT
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!

Thanks for the advice.

Regards
Adam


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
-- 
struts 1.1 + tomcat 4.1.27 + java 1.4.2
Linux 2.4.20 RH9


Mime
View raw message