Hi,

付 尧 schrieb:
> Hi Felix,
> 
> I can't find a way to make the simple form post work, along with ajax
> too, :( .
> 
> How should I write the form?
> 
> like this?
>   <form id="form" method="post" action="/test/encoding"
> enctype="text/html; charset=utf-8">
>     <input name="name" value="测试" />
>     <input name="message" value="" />
>     <input type="hidden" name="_charset_" value="utf-8" />
>     <input type="submit" value="submit" />
>   </form>
> 
> It won't work.
> 
> And this?
> <form id="form" method="post" action="/test/encoding"
> enctype="application/x-www-form-urlencoded; charset=utf-8">
> won't work.
> 
> And this?
> <form id="form" method="post" action="/test/encoding"
> enctype="multipart/form-data; charset=utf-8">
> won't work either.

The value of the enctype should just be "multipart/form-data" as in:

   <form id="form" method="post" action="/test/encoding"
         enctype="multipart/form-data">

> 
> Ajax Post is like that too.

Depending on how you do the Ajax Post, you might want to set the
Content-Type header with the charset on the request.

> 
> My page's encoding is utf-8, what should I do?

This should work.

If you still can't get it to work, I suggest you post a JIRA with a
sample script/servlet generating the form and expecting the response,
such that we can better reproduce your issue.

Regards
Felix

> 
> -----
> Jack
> 
> 
> 
> 在 2008-11-14,下午5:18, Felix Meschberger 写道:
> 
>> Hi Jack,
>>
>> 付 尧 schrieb:
>>> Hi Felix,
>>>
>>>> The core problem is, that the browsers generally do not send the
>>>> Cotent-Type header with the proper charset parameter. Instead they tend
>>>> to encode the form post using the same encoding as was used for the
>>>> HTML
>>>> on which the form resides.
>>>
>>> Yes, that's the browser's problem.
>>>
>>>> So if you send the form with
>>>>
>>>>  Content-Type: text/hml; charset=UTF-8
>>>
>>> My form really can't be that content type, especially in an ajax
>>> request.
>>
>> So you are not using a normal form post but an AJAX request to send the
>> data ?
>>
>> In this case you might want to consider setting the ContentType header
>> explicitly ?
>>
>>>
>>>> the POST is sent back encoded in UTF-8 and Sling will happily decode as
>>>> UTF-8 as instructed by the _charset_ parameter.
>>>>
>>>> For best (and proven) results:
>>>>
>>>> * Send everything as UTF-8
>>>> * Use encoding="multipart/form-data" for your forms
>>>> * Keep the _charset_ parameter set to UTF-8 (or utf-8)
>>>
>>> Yes, that's what I do. It doesn't work when using  dojo ajax post in
>>> ie(When I use dojo in ie do the ajax post, sling didn't get the
>>> encoding, so it use iso-8859-1 as default).
>>
>> I do not know enough of dojo and how dojo sends requests, but can't you
>> set the character encoding (or content type) when sending a POST request
>> with dojo ?
>>
>>>
>>> Besides, if sling fix the encoding for the request parameter, then
>>> ContainerRequestParameter's encoding and decoding really seems
>>> unnecessary. Even everything is right, decoded every parameter  value in
>>> utf-8 then encode it with the same encoding again is an unnecessary
>>> waste.
>>
>> Reencoding does not always take place, but some times it is required.
>> For example when reading multipart/form-data, Sling must assume an
>> encoding upfront in case it is not sent by the client. And the safest
>> bet is ISO-8859-1 which may be used as a transient encoding before
>> actually encoding in UTF-8.
>>
>> The reason why this works is, that ISO-8859-1 just takes any byte value
>> from the inputstream and assumes it to be a character whose character
>> code is in the 0..255 range.
>>
>> Regards
>> Felix
>>
> 
> 

Reply via email to