Re: [Stripes-users] Locale / CharacterEncoding Redux

[cleverpig <gre...@gm...>]

Thanks for Tim!
It's my honour with the second resolvent which just was my said in maillist=
:
cleverpig to stripes-users:

A nice and flexible way for resolve charaterEncoding problem

After one Thought's period,I get one reasonable way to resolve
charaterEncoding problem.
It is to configure locale and characterEncoding related with locale.
Like as:
<init-param>
    <param-name>LocalePicker.Locales</param-name>
    <param-value>en_US,zh_CN</param-value>
 </init-param>

<init-param>
    <param-name>charaterEncodingPicker.Encoding </param-name>
    <param-value>UTF-8,GBK</param-value>
 </init-param>

<init-param>
    <param-name>charaterEncodingPicker.Default Encoding</param-name>
    <param-value>UTF-8</param-value>
 </init-param>

As Above,I made LocalePicker.Locales as "en_US" and "zh_CN",added
charaterEncodingPicker. Encoding to declare "en_US" locale's
charaterEncoding "UTF-8" and declare "zh_CN" locale's charaterEncoding
"GBK".There,I had made my locale and charaterEncoding's relation.

DefaultEncoding is a default encoding declaration,it's param value  will be
default encoding for exceptional locale.

Another thing must to be done:modify the stripesRequestWrapper's doFilter
method to apply the relation.
Such as:
public void doFilter(...){
   ...
   request.setLocale(locale);
   String characterEncoding=3DgetCharaterEncodingByLocale(locale);

   log.info("LocalePicker selected locale: ", locale);
   log.info("request's characterEncoding:: ",request.getCharacterEncoding
());
   request.setCharacterEncoding(characterEncoding );
   ...
}

On 5/16/06, Tim Fennell <tf...@tf...> wrote:
>
> Hey All,
> So there have been a number of emails on the list in the past few weeks
> about how to ensure that a response uses the correct character encoding
> etc.  I'm pretty sure there are things Stripes could do to make life easi=
er
> in this area, so this is an email to suggest a couple of options and gath=
er
> some feedback.
>
> 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)
> 2. Ensure that the correct locale is available for other things downstrea=
m
> (done)
> 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 (no=
t
> 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.4spe=
cification 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 encodin=
g.
> What it doesn't do is set the character encoding for the HttpServletReque=
st,
> 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 ca=
ll
> 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 fo=
rm:
> Content-Type: text/html;encoding=3DUTF-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 cou=
ld
> 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 muc=
h
> of this would be helpful?  Would the ideas outlined above at least improv=
e
> things in the majority of cases without getting in the way or making
> anything else more difficult?  Are there alternate solutions that would w=
ork
> better?
>
> -t
>



--=20
cleverpig
Location:Beijing
Phone:010-66415588-1113
MSN:gre...@ho...
QQ:149291732