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]
