On 22.01.2020 10:26, Lmhelp1 wrote:
Hello Chris and all,
Sorry for my late answer.
Thank you for the link you suggested me to read.
Adding the element:
<request-character-encoding>UTF-8</request-character-encoding>
to "web.xml" solved my problem.
Glad to hear that.
From an absolute point of view, this is of course again a "patch". But as Chris pointed
out before, it is unfortunately an unavoidable one, due to the fact that the browsers
lamentably fail to always indicate the character set and encoding that they are using for
sending text data to the server.
[RANT:]
(Although they know, and although the specifications provide them with an easy way to do
that. Why that is so is anyone's guess, but the economic losses due to that over the years
must be staggering).
(probably close to the cost of allowing spaces in directories and files names)
On 17/01/2020 3:17 PM, Christopher Schultz wrote:
Your filter changes the encoding of both the request AND the response.
It's likely that fixing the request-encoding was necessary, while
changing the response-encoding was not.
The problem is:
1. The official RFC-defined default character encoding for HTTP is
ISO-8859-1.
2. The browser default appears to be unpredictable, but often UTF-8.
3. The browsers have all agreed not to tell the server what characted
encoding is actually being used.
It's fun. It's a very simply-solved problem: the browser should just
advertise the character encoding and everything would be great. Sadly, n
o.
I would encourage you to read this page in its entirety:
https://cwiki.apache.org/confluence/display/TOMCAT/Character+Encoding
- -chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
