Gregor Schneider wrote:
On Mon, Mar 16, 2009 at 3:10 PM, Mikolaj Rydzewski <m...@ceti.pl> wrote:
It doesn't work for me. By default Tomcat uses ISO-8859-1 encoding. And it
will try this encoding to parse input parameters.
That's true, I'm doing the same here for German Umlaute, however:
One link in the Wiki is pointing to HTTP specification section 3.4.1,
however, there's something that I do not understand:
The specs say in 3.4.1:
<quote>
HTTP/1.1 recipients MUST respect the
charset label provided by the sender; and those user agents that have
a provision to "guess" a charset MUST use the charset from the
content-type field if they support that charset, rather than the
recipient's preference, when initially displaying a document. See
section 3.7.1.
</quote>
So, for me as a non-native English speaker, I understand it in such a
way that your conent-encoding must be obliged - or do I get it wrong
here? So, if in the content-encoding UTF-8 is specified, why isn't it
accepted then?
+1.
In other words, according to the HTTP specs (and the Servlet Specs SRV
4.9), if the client sends a form content using the "multipart/form-data"
encoding, and specifies a charset for one of the parts, then the servlet
engine should decode it that way.
And if the client sends a form content using the "multipart/form-data"
encoding but does not specify a charset for any given part, then the
servlet engine should consider that it is iso-8859-1, this being the
default HTTP encoding.
As far as I understand the HTTP specs, something like
request.setCharacterEncoding() should only be used (with a charset
different from iso-8859-1) when a request comes in without a charset
specification (which also indicates a broken client).
Comments anyone ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
