Konstantin Kolinko wrote:
2014-07-07 21:07 GMT+04:00 Terence M. Bandoian <tere...@tmbsw.com>:
On 7/5/2014 6:36 PM, André Warnier wrote:
I agree with André about the difficulties of debugging character encodings.
A couple of things you might check are the character encodings of the page
and the form. The character encoding of the page may be set with the
Content-type meta tag:
<meta http-equiv="Content-type" content="text/html;charset=UTF-8"/>
Setting explicit value for "content" attribute like that is risky. The
value must match the Content-Type HTTP header produced by web server.
If they do not match, some browsers ignore both and start guessing the
encoding.
I usually write it as
<%@ page contentType="text/html; charset=UTF-8" %>
...
<META http-equiv="Content-type" content="<%=response.getContentType() %>">
Yes, this is why I requested from the OP that he verifies *in the browser*,
what the
browser thinks the character set of the page is.
That is because browsers are inconsistent in interpreting server-sent
responses. Some
browsers will strictly respect what the server sends as a "Content-type" header
(which,
according to the RFCs, they should do), but some will not (IE various versions
over the
years are particular offenders in that respect).
By asking this, I was trying not to confuse the matter even further.
If the OP had answered and mentioned anything else than Unicode UTF-8, then
that would
have been the trigger to dig deeper as to why this was the case.
It is often easy, and often tempting, to just provide a "recipe" that sems to
work and
solves the immediate problem.
Unfortunately, such recipes then have a tendency to break down when conditions
change
slightly, such as one user using a slightly different version of browser e.g.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
