Improved locale-based character-encoding handling
-------------------------------------------------
Key: STS-210
URL: http://mc4j.org/jira/browse/STS-210
Project: Stripes
Type: Improvement
Components: ActionBean Dispatching
Reporter: Tim Fennell
Assigned to: Tim Fennell
Fix For: Release 1.4
The way I figure it there are a few parts to this:
1. Ensure that the correct locale is used for number/date parsing and
for error messages (done pre-1.4)
2. Ensure that the correct locale is available for other things
downstream (done pre-1.4)
3. Ensure that the request is parsed using the correct *character
encoding* (not done)
4. Ensure that the response is sent in the correct character encoding
(not done)
5. Ensure that the browser is made aware of the response encoding
Right now Stripes has a LocalePicker component that is responsible for deciding
what locale to use when processing and type converting values in the request,
when formatting values in pages, etc. To make life easier Stripes wrap the
request and ensures that all subsequent calls to request.getLocale() return the
correct locale.
Stripes does *not* call Response.setLocale(). This is probably the first step
in improving things. A little reading shows that the Servlet 2.4 specification
supports a new stanza in the web.xml file to map locales to character
encodings. For example:
<locale-encoding-mapping-list>
<locale-encoding-mapping>
<locale>tr_TR</locale>
<encoding>UTF-8</encoding>
</locale-encoding-mapping>
</locale-encoding-mapping-list>
In this case, when a call is made to HttpServletResponse.setLocale(tr_TR), the
container will ensure that the response writer uses the UTR-8 encoding. What
it doesn't do is set the character encoding for the HttpServletRequest, and
therefore doesn't affect the character translation of text in the request.
Nor, unfortunately does the specification provide programmatic access to this
mapping information. Theoretically one could get the web.xml as a resource and
parse it, but that's a lot of work :p
So here's what I'm thinking. Where you currently specify a list of Locales in
the web.xml for Stripes to use (yes, this is optional), we'd extend the format
a little bit to allow the specification of a character encoding also. E.g.:
<init-param>
<param-name>LocalePicker.Locales</param-name>
<param-value>en_US,tr_TR:UTF-8,ja:Shift_JIS</param-value>
</init-param>
I.e. locale:character_encoding. If the encoding isn't specified then let the
container decide what is appropriate. This would allow Stripes to call
HttpServletResponse.setCharacterEncoding(encoding) after calling
HttpServletResponse.setLocale(locale), and effectively tackle #4 above.
This also would allow Stripes to call
HttpServletRequest.setCharacterEncoding(encoding) *before* anything is read
from the request, ensuring that the the content is parsed in the specified
encoding. But is that always going to be correct? If not, is there any way to
determine programmatically the correct encoding to parse the request with? If
this'd work (at least more often than doing nothing), it's help with #3.
Tackling #5 is a bit trickier since the communication of character encoding is
done through the Content-Type http header, which takes the form:
Content-Type: text/html;encoding=UTF-8
If a content type is not set, then the this header isn't sent even if a
character encoding is set. So the only solution I can think of here that
doesn't require a lot of repetition is to 1) have a new init/config param,
perhaps 'Stripes.DefaultContentType' that would specify the default content
type that would be set on all responses. If not specified it could default to
"text/html". This would solve #5. It should be noted that setContentType can
be called repeatedly, so this can always be overridden by downstream code or
JSPs.
So my question to those of you developing localized applications, how much of
this would be helpful? Would the ideas outlined above at least improve things
in the majority of cases without getting in the way or making anything else
more difficult? Are there alternate solutions that would work better?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://mc4j.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
