Hi Felix,
I know the cause of the problem now.
IE didn't support url encoding in utf-8, I must encode every my post
url.
Thanks for you helping. :)
-----
Jack
在 2008-11-14，下午6:34， Felix Meschberger 写道：
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
