9

I can normally write czech string to the form:

enter image description here

But after validation (and also when I send the collected string to database) the string is in some other charset:

enter image description here

h:outputTexts (jméno, příjmení) are still shown normally, h:inputTexts are not.

Where should I look for the problem?

UPDATE: HTTP response headers:

enter image description here

SOLUTION:

  • create filter with request.setCharacterEncoding("UTF-8") in Filter#doFilter()
  • check all xml to have UTF-8 configured
  • add <f:view contentType="text/html" encoding="UTF-8"/> to main xhtml
  • add these lines to hibernate.cfg.xml:

    <property name="hibernate.connection.characterEncoding">utf8</property>

    <property name="hibernate.connection.useUnicode">true</property>

gaffcz
  • 3,469
  • 14
  • 68
  • 108
  • can you post the source of the jsp/xhtml ? – Konstantin Yovkov Nov 07 '11 at 10:39
  • pls take a look at my updated answer.. – gaffcz Nov 07 '11 at 10:43
  • That aren't the response headers. That are the request headers :) You need to post whatever you **retrieved** from the server, not what you've sent to the server. But that you're using Safari rings some bells ... – BalusC Nov 07 '11 at 15:05
  • Aha, it's quite a new for me, I have a bit explore it :) What does it mean "Safari rings some bells"? – gaffcz Nov 07 '11 at 15:11
  • Just check *Net* tab of Firebug or *Network* tab of Chrome tools (press F12). As to Safari, I vaguely recall some related issues with Safari, but I can't seem to find anything nor to recall in more detail. I'd at least try it in different browsers (IE, FF, GC, etc) to exclude Safari itself from being suspect. – BalusC Nov 07 '11 at 15:20
  • Aha, thank you very much. Please take a look at my updated QUESTION :-) I've never used the safari before, I'm using only Chrome, MFF and IE sometimes :) – gaffcz Nov 07 '11 at 16:28
  • Okay, content-type response header looks fine (which is indeed also confirmed by proper labels). This means that the problem is in parsing the request parameters. In theory, using `request.setCharacterEncoding("UTF-8")` in a `Filter#doFilter()` should solve it, but that shouldn't be necessary for JSF 2.0 on Facelets. First, what JSF impl/version exactly are you using and what JSF-related context parameters do you all have in your `web.xml`? – BalusC Nov 07 '11 at 16:55
  • Mojarra v2.1.3 (javax.faces.jar) now, and mojarra-2.1.2-FCS before.. And JSF related part of XML will be in my question in minute. – gaffcz Nov 07 '11 at 17:12

3 Answers3

4

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:

  1. The DB table is not using UTF-8.
  2. 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:

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Thank you Balusc, and really changes the charset, but each of them are different when I writting a strings to inputTexts and after form validation. And the validation phase is before sending data to database, so it should has nothing to do with database.. or not? – gaffcz Nov 07 '11 at 14:03
  • I suggest to remove `` from all pages (it may do more harm than good, you want ultimately end up with HTML in browser, not XHTML) and stick to `` in master page. And yes, you're right, I completely overlooked that you're actually validating the data and thus it can impossibly have made a roundtrip to the DB :) – BalusC Nov 07 '11 at 14:07
  • `` is removed, `` is in master page only and it's still the same :) What is interesting, that in my other application built on the same basics, everything works fine and I'm not able to find any principial difference... – gaffcz Nov 07 '11 at 14:27
  • What are you seeing in the HTTP response headers? – BalusC Nov 07 '11 at 14:29
  • Answer? Which answer? You've only a question. – BalusC Nov 07 '11 at 15:05
  • Balusc, `request.setCharacterEncoding("UTF-8")` in a `Filter#doFilter()` solved the validation form issue! Finally you were right even with MySql char encoding (ěščřžýáíé ?š??žýáíé). I've solved it adding `hibernate.connection.useUnicode` and `characterEncoding` properties to my hibernate xml file. Please update your answer and I'll accept it :) – gaffcz Nov 08 '11 at 10:05
  • I did that, but I still wonder why `request.setCharacterEncoding("UTF-8")` is mandatory. I have the feeling that this is a workaround. You also said yourself, in your other application which was similarly built, everything works fine. I'd still be curious to the real cause of the problem. – BalusC Nov 08 '11 at 12:08
3

Try this solution: http://ibnaziz.wordpress.com/2008/06/10/spring-utf-8-conversion-using-characterencodingfilter/ In my cases it helps (with russian)

In web.xml add Spring's character encoding filter:

<filter>
    <filter-name>encodingFilter</filter-name>
    <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
    <init-param>
        <param-name>encoding</param-name>
        <param-value>UTF-8</param-value>
    </init-param>
    <init-param>
        <param-name>forceEncoding</param-name>
        <param-value>true</param-value>
    </init-param>
 </filter>

 <filter-mapping>
    <filter-name>encodingFilter</filter-name>
    <url-pattern>/*</url-pattern>
 </filter-mapping>
Sergey Vedernikov
  • 7,609
  • 2
  • 25
  • 27
  • 1
    Thank you Sergey, but it didn't help :) – gaffcz Nov 07 '11 at 11:46
  • 3
    That would require the whole Spring library in your classpath which is pretty clumsy. All that filter *basically* does is invoking `request.setCharacterEncoding("UTF-8")`. For that you can also just create a custom filter. – BalusC Nov 07 '11 at 13:03
0

I had exactly the same problem with validation form and I solved it with Sergey's answer.

BUT your filter needs to be in first position in your web.xml. Moving my filter from 3rd to first position solved my problem.

Hope it helps.

(Primefaces 3.2, JSF 2.1.2 with Jboss 7.1)

Guillaume
  • 466
  • 5
  • 19