Hi Dennis,

On Wed, Oct 7, 2009 at 4:46 PM, Dennis Dam <[email protected]> wrote:
> I noticed that the non-ajax forms in the CMS cause the browser to send a
> request without a specified charset in the "Content-Type:" header. I tried
> the following to try to get "charset=utf-8" part on the request:
>
> - configure accept-charset="utf-8" on the <form> element : CHECK
> - configure  enctype="application/x-www-form-urlencoded; charset=UTF-8" :
> CHECK
> - check if <META http-equiv="Content-Type" content="text/html;
> charset=UTF-8"/> is in html <head> section : CHECK
> - check if Content-Type: response header for the html that contains the form
> is set to charset = utf-8 : CHECK
>
> My browser (Firefox) just doesn't want to set the charset to utf-8 in the
> content-type request header! I get the feeling that the browser is not able
> to determine the encoding of the form (or whole page?), and then decides to
> send the form using ISO-8859-1.
> I'm out of ideas, who can help me out ? It must be some basic html thing :)

According to a javadoc document of spring framework, it says, "current
browsers typically do not set a character encoding even if specified
in the HTML page or form." [1]
So, I think we need to assume that the request encoding is one
specific one. Currently we have a good alternative one: UTF-8.
Before UTF-8 is not popular one, I used to determine the encoding
based on the user's language. (e.g., "ko" : KSC5601 or EUC-KR, "en" :
ISO-8859-1, "ja" : Shift_JIS, ...)
However, I think you don't have any problem with the assumption of
UTF-8 today in most cases.

[1] 
http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/web/filter/CharacterEncodingFilter.html

>
> Ofcourse I can fix it with a workaround: implement a filter that converts
> only POST parameters, if the incoming encoding is NULL or anything else than
> utf-8. But I'd rather like to solve the cause of the problem :)

You don't have to implement new filter. As Ard mentioned, you can use
"CharacterEncodingFilter" of Spring Framework. If
request.setCharacterEncoding() has been ever invoked, then
request.getParameter() returns a converted string from the container
encoding to target encoding. The "CharacterEncodingFilter" is doing
this.


Regards,

Woonsan

>
> regards
> Dennis
>
>
> On Wed, Oct 7, 2009 at 2:24 PM, Dennis Dam <[email protected]> wrote:
>
>>
>>
>> On Wed, Oct 7, 2009 at 2:09 PM, Bartosz Oudekerk 
>> <[email protected]>wrote:
>>
>>> Ard Schrijvers wrote:
>>>
>>>> 1. added system property -Dfile.encoding=UTF-8 to catalina.sh
>>>>> 2. added URIEncoding=utf-8 to the 8080 connector in conf/server.xml
>>>>> 3. the container-encoding init parameter for the Cocoon servlet is set
>>>>> to
>>>>> "ISO-8859-1".
>>>>> 4. the form-encoding init parameter for the Cocoon servlet is set to
>>>>> "utf-8"
>>>>>
>>>>
>>>> why is (3) not utf-8??
>>>>
>>>
>>> Because if it's set to UTF-8, then things tend to get doubly encoded.
>>>
>>
>>
>> not exactly.. it depends on the value of "form-encoding", if
>> container-encoding + form-encoding are identical (e.g. both set to utf-8),
>> then Cocoon does not perform encoding conversions.
>>
>> Why is (3) not set to UTF-8?? Because then the form POST encoding is broken
>> :)) With ISO the form GETs are broken .. :)
>>
>>
>>> Regards,
>>> --
>>> Bartosz Oudekerk
>>> .---------------------------------.-----------------------------------.
>>> | Hippo B.V.                      | Hippo USA Inc.                    |
>>> | Oosteinde 11                    | 101 H Street, suite Q Petaluma CA |
>>> | 1017 WT  Amsterdam              | 94952-5100  San Francisco         |
>>> | The Netherlands                 | United States                     |
>>> | Tel  +31 (0)20 5224466          | +1 (707) 773-4646                 |
>>> +---------------------------------+-----------------------------------+
>>> |     [email protected]     |      http://www.onehippo.com      |
>>>
>>> `---------------------------------^-----------------------------------'
>>> ********************************************
>>> Hippocms-dev: Hippo CMS development public mailinglist
>>>
>>> Searchable archives can be found at:
>>> MarkMail: http://hippocms-dev.markmail.org
>>> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html
>>>
>>>
>>
>>
>> --
>> Hippo B.V.  -  Amsterdam
>> Oosteinde 11, 1017 WT, Amsterdam, +31(0)20-5224466
>>
>> Hippo USA Inc.  -  San Francisco
>> 101 H Street, Suite Q, Petaluma CA, 94952-3329, +1 (707) 773-4646
>> -----------------------------------------------------------------
>> http://www.onehippo.com   -  [email protected]
>> -----------------------------------------------------------------
>>
>>
>
>
> --
> Hippo B.V.  -  Amsterdam
> Oosteinde 11, 1017 WT, Amsterdam, +31(0)20-5224466
>
> Hippo USA Inc.  -  San Francisco
> 101 H Street, Suite Q, Petaluma CA, 94952-3329, +1 (707) 773-4646
> -----------------------------------------------------------------
> http://www.onehippo.com   -  [email protected]
> -----------------------------------------------------------------
> ********************************************
> Hippocms-dev: Hippo CMS development public mailinglist
>
> Searchable archives can be found at:
> MarkMail: http://hippocms-dev.markmail.org
> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html
>
>



-- 
[email protected]     www.onehippo.com
EUROPE • AMSTERDAM - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466
NORTH AMERICA • SAN FRANCISCO - Hippo USA Inc. 185 H Street, Suite B
Petaluma CA 94952 +1 (877) 414-4776
********************************************
Hippocms-dev: Hippo CMS development public mailinglist

Searchable archives can be found at:
MarkMail: http://hippocms-dev.markmail.org
Nabble: http://www.nabble.com/Hippo-CMS-f26633.html

Reply via email to