The new JSF spec does allow for Content-Type lookup, here's a bit of code that I used in my implementation to find the content type out of that header, it might be of some use to you or whoever:
protected static final Pattern PATTERN_CHARSET = Pattern.compile(".*charset\\s*=\\s*([\\w\\-]+)(\\s*|;).*"); /** * Grab the character encoding from the request, if not found, check the * stored value. Finally, set the character encoding on the request * * @param context * @param stored * @throws FacesException */ protected void setCharacterEncoding(FacesContext context) throws FacesException { ExternalContext extCtx = context.getExternalContext(); Object request = extCtx.getRequest(); if (request instanceof ServletRequest) { String contentType = (String) extCtx.getRequestHeaderMap().get("Content-Type"); String charset = null; if (contentType != null) { Matcher match = PATTERN_CHARSET.matcher(contentType); if (match.lookingAt()) { charset = match.group(1); } } if (charset == null) charset = (String) extCtx.getSessionMap().get(CHARACTER_ENCODING_KEY); if (charset != null) { try { ((ServletRequest) request).setCharacterEncoding(charset); } catch (UnsupportedEncodingException uee) { extCtx.log("Error Encoding: " + charset, uee); } } } } Note, this required J2SE 1.4. Cheers, Jacob Hookom -----Original Message----- From: Carl-Eric Menzel [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 2:44 PM To: Larry Young Cc: Struts Users Mailing List Subject: Re[3]: character encoding > Then I'm out of luck. That's the biggest problem with Strut's lack of > support for the accept-charset attribute. *Most of the time* it works > that if you send the response in UTF-8 the next request will come in > as UTF-8 too. That's what I'm doing now - I send out only UTF-8 forms > and assume that I get the same back. It's an ugly hack, but the only > way that seems to work at the moment. > I asked a few weeks ago if there was any way for me to extend the form > tag to support this attribute, or whether there is any good reason why > it is not implemented. So far I haven't received an answer. PS: While searching for a solution I found that the HTTP spec actually provides the browsers with a way to *specify* the encoding they're sending, which would completely solve this issue. It appears that the only browser that supported it *was* Mozilla. They found out that this extended (but conforming to the spec!) Content-Type header made so many broken CGI-scripts puke that they removed this feature again. *sigh* Carl-Eric -- Antwort: Weil es das Lesen des Textes erschwert. | Carl-Eric Menzel Frage : Warum ist das so schlimm? | PGP ID: 808F4A8E Antwort: Antworten oben zu schreiben. | Bitte keine HTML- Frage : Was ist die schlimmste Unsitte in Emails? | Mails schicken. --------------------------------------------------------------------- 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]