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]
