Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

POST parameters using wrong encoding in JSF 1.2

I'm having a problem with charset encoding in my web application (JSF 1.2, Spring and Tomcat 7), and I've ran out of ideas of what to test to see where it is going wrong.

Whenever I submit something like 'çã' I get 'çã': that means my data POSTed as UTF-8 is being converted to ISO-8859-1 somewhere in the JSF life cycle.

I know that the wrong conversion is UTF-8 to ISO-8859-1 cause it's the same output for:

System.out.println(new String("çã".getBytes("UTF-8"), "ISO-8859-1"));

I believe that the wrong conversion is somewhere in the JSF life cycle (can it be before?) cause I set up a validator in my MB:

public void debugValidator(FacesContext context, UIComponent component,
        Object object) throws ValidationException {
    System.out.println("debug validator:");
    System.out.println(object);
    System.out.println("\n");
    throw new ValidationException("DEBUG: " + object.toString());
}

and its message returns as: "DEBUG: çã"

  • I have in all my .xhtml pages the first line as <?xml version="1.0" encoding="UTF-8"?>.
  • I'm using Facelets, which according to BalusC's article uses UTF-8 by default
  • So it wouldn't need but I set up anyway, Spring's CharacterEncodingFilter in my web.xml to set the request character encoding to UTF-8.
  • I put URIEncoding="UTF-8" in Tomcat's server.xml file, just to guarantee
  • It is not my browser's fault, it prints the same thing in the console, and my environment is all UTF-8.

Do you have any idea of what more can I test? What could be my wrong assumption?

Thanks in advance!

like image 382
Elias Dorneles Avatar asked Dec 21 '22 04:12

Elias Dorneles


2 Answers

BalusC's answer helped me to better understand the problem, but what solved it for me was putting the Character Encoding Filter as the FIRST filter in the chain (putting it above all the others in the web.xml file).

This is the filter I used:

<!-- filter enforcing charset UTF-8 - must be first filter in the chain! -->
<filter>
    <filter-name>characterEncodingFilter</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>characterEncodingFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Apparently, the data was read before the parameter was set by the filter. I got the hint from this page: http://tech.top21.de/techblog/20100421-solving-problems-with-request-parameter-encoding.html

Thanks everybody!

like image 184
Elias Dorneles Avatar answered Jan 03 '23 04:01

Elias Dorneles


The symptoms indicate that the browser has sent the data using ISO-8859-1 encoding instead of UTF-8. This in turn means that the HTTP response Content-Type header is not been set with the proper charset attribute. In for example Firebug, you can find it out as follows:

enter image description here

You're right that Facelets uses UTF-8 by default. But very early versions of Facelets weren't programmed to use UTF-8 by default. See also among others issue 46 and issue 53. Facelets is currently at 1.1.15.B1.

As to your attempts to fix it, the presence of the XML prolog is not strictly necessary and its encoding isn't used in any way to set the response encoding, it's only used by the XML parser to decode the inputstream to characters. Spring's filter is also not necessary, but that it didn't solve the problem after you added it is enough evidence that it's the client who has sent the data as ISO-8859-1.

like image 36
BalusC Avatar answered Jan 03 '23 02:01

BalusC