Given the symptoms, UTF-8 data is been redisplayed using ISO-8859-x encoding. The ?
(LATIN SMALL LETTER C WITH CARON (U+010D)) exist in UTF-8 of bytes 0xC4
and 0x8D
. According to the ISO-8859-1 codepage layout those bytes represent the characters ?
and [nothing] respectively, which is exactly what you're seeing.
This particular problem can have many causes. As Facelets by itself already uses UTF-8 by default to process HTTP POST request parameters and to write the HTTP response, there should/can be nothing which you need to fix/change in the Java/JSF side.
However, when you're manually grabbing a request parameter before JSF creates/restores the view (e.g. in a custom filter), then it may be too late for Facelets to set the right request character encoding. You'd need to add the following line to the custom filter before continuing the chain, or in a new filter which is mapped before the filter causing the trouble:
request.setCharacterEncoding("UTF-8");
Also, when you've explicitly/implicitly changed the Facelets' default character encoding by for example <?xml version="1.0" charset="ISO-8859-1"?>
or <f:view encoding="ISO-8859-1">
, then Facelets will use ISO-8859-1 instead. You'd need to replace it by UTF-8
or remove them altogether.
If that's not it, then only the database side is the major suspect. In that side I can see two possible causes:
- The DB table is not using UTF-8.
- The JDBC driver is not using UTF-8.
How exactly to solve it depends on the DB server used. Usually you need to specify the charset during CREATE
of the DB table, but you can usually also alter it using ALTER
. As to the JDBC driver, this is usually to be solved by explicitly specifying the charset as connection URL parameter. For example, in case of MySQL:
jdbc:mysql://localhost:3306/db_name?useUnicode=yes&characterEncoding=UTF-8
See also:
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…