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, response & character encoding
Date Mon, 29 Sep 2003 10:20:35 GMT
Hallo Martin,

thanks for the quote. I did read that before but just didn't realise its 
significance.

I could have stayed with the struts bean taglib, but I spent a couple of 
days last month changing over, because JSTL has more flexibility. :(

The quotation from the JSTL spec in my eyes shows a flaw in someone's 
thinking, or a lack of understanding on my part - how can a character 
encoding be associated with a locale?

A locale has a country code and a language code, but no character 
encoding associated with it. I assume that ServletResponse.setLocale() 
uses the default app server encoding. Or is that configurable somewhere, 
like logging.properties?

My last hope is that the words "sets the charset header as appropriate" 
leave some way of stipulating what 'appropriate' actually is.

Do you agree that this is a deficiency in the JSTL specification? If so 
I will gladly go away and take up the issue with the JSTL expert group. 
If not, what would you recommend?

Adam

On 09/29/2003 09:34 AM Martin van Dijken wrote:
> Hey Adam,
> 
> The behaviour you describe seems to be according to specifications. I've inlined section
8.4 of the spec below. This describes that you cannot use tags that establish a Localization
context if you want to prevent setLocale being called. I'm guessing that's not altogether
a big help to you since it seems the taglib becomes a pain in the ass more than a convenience,
but you can't blame me for that;) 
> 
> I'm not 100% certain how well they still work but you might want to give the jakarta
I18N taglib a shot. I don't think they're in active development any more, but they might be
just what you need.
> 
> Grtz,
> 
> Martin
> 
> 8.4:
> 
> Any i18n action that establishes a localization context is responsible for setting the
> response's locale of its page, unless the localization context that was established
> does not have any locale. This is done by calling method
> ServletResponse.setLocale() with the locale of the localization context.
> This assumes that the response is buffered with a big enough buffer size, since
> ServletResponse.setLocale() and ServletResponse.setContentType()
> must be called before ServletResponse.getWriter() in order for the specified
> locale or charset to affect the construction of the writer.
> 
> It also assumes that the JSP container doesn't call getWriter() until it's about to flush
the buffer. An errata
> has been published for the JSP 1.2 specification to clarify this.
> 
> More specifically, the response's setLocale() method is always called by the
> <fmt:setLocale> action (see Section 8.5). In addition, it is called by the following
> actions:
> 	Any <fmt:bundle> (see Section 8.6) and <fmt:setBundle> (see Section 8.7)
action.
> 	Any <fmt:message> action that establishes an i18n localization context
> 	Any formatting action that establishes a formatting locale on its own (see
> 		Section 9.3).
> 
> After an action has called ServletResponse.setLocale(), and sessions are
> enabled, it must determine the character encoding associated with the response
> locale (by calling ServletResponse.getCharacterEncoding()) and store it in
> the scoped variable javax.servlet.jsp.jstl.fmt.request.charset in
> session scope. This attribute may be used by the <fmt:requestEncoding> action (see
> Section 8.10) in a page invoked by a form included in the response to set the request
> charset to the same as the response charset. This makes it possible for the container
> to decode the form parameter values properly, since browsers typically encode form
> field values using the response's charset.
> 
> 
>>-----Original Message-----
>>From: Adam Hardy [mailto:ahardy.struts@cyberspaceroad.com]
>>Sent: zondag 28 september 2003 23:21
>>To: Adam Hardy
>>Cc: Tag Libraries Users List
>>Subject: JSTL & character encoding
>>
>>
>>In  <fmt:message key=".."/> the class 
>>...tag.common.fmt.SetLocaleSupport's method setResponseLocale() is 
>>called after fetching the localizationContext and before getting the 
>>bundle.
>>
>>In setResponseLocale(), the response's locale is set via 
>>response.setLocale(). This method according to the API also:
>>
>>"Sets the locale of the response, setting the headers (including the 
>>Content-Type's charset) as appropriate"
>>
>>thus overwriting what I set with my JSP page contentType= directive.
>>
>>Would this a bug in Sun's implementation, a bug in 
>>MessageTag, or not a 
>>bug at all?
>>
>>I see it as a problem because I cannot control what 
>>ServletResponse.setLocale() does to the http headers. A locale is 
>>ignorant of the character encoding, so it seems strange taht calling 
>>this method should affect the http character encoding header.
>>
>>I see there's an entry in bugzilla already from a couple of weeks ago:
>>
>>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23125
>>
>>
>>
>>
>>
>>On 09/28/2003 05:54 PM Adam Hardy wrote:
>>
>>>I'm trying to set my pages to UTF-8. I am setting my page 
>>
>>directive with:
>>
>>><% page contentType="text/html; charset=UTF-8" %>
>>>
>>>and so long as I don't use the JSTL fmt taglibs, it works. 
>>
>>When I put in 
>>
>>>something like <fmt:message key="general.browserTitle" /> 
>>
>>then UTF-8 is 
>>
>>>overridden and response content type is set to ISO-8859-1.
>>>
>>>On digging around I can't really see obviously in the 
>>
>>source when the 
>>
>>>response.setContentType is called, but I can see that the 
>>
>>sessions are 
>>
>>>getting this attribute set:
>>>
>>>javax.servlet.jsp.jstl.fmt.request.charset==ISO-8859-1
>>>
>>>although it doesn't seem to be the cause, just another 
>>
>>symptom. I have 
>>
>>>tried <fmt:requestEncoding value="UTF-8" /> with no success.
>>>
>>>I am using a filter in tomcat to set the request encoding 
>>
>>anyway, and 
>>
>>>this is always UTF-8.
>>>
>>>I'd appreciate any help on this, I've must have spent about 6 hours 
>>>trying to nail this glitch.
>>>
>>>Thanks
>>>Adam
>>>
>>
>>-- 
>>struts 1.1 + tomcat 4.1.27 + java 1.4.2
>>Linux 2.4.20 RH9
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
> 
> 

-- 
struts 1.1 + tomcat 4.1.27 + java 1.4.2
Linux 2.4.20 RH9


Mime
View raw message