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:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]