Tips for JSF character encoding


This article explains some tips for JSF character encoding.

How request character encoding is determined by JSF.

As described in section of JSF specification 1.1 and 1.2, request character encoding is determined in the following order:
  • Charset of Content-Type is used, if exists.
  • Charset of a previous response is used, if stored in a session.
  • Otherwise, request character encoding is unmodified.

Determining correct encoding is crutial because it is used to decode POST parameters.

Obtaining charset from Content-Type is considered the best way, but this usually does not happen because most browsers currently do not send it.

JSF stores previous response character encoding in a session ("javax.faces.request.charset" in case of MyFaces.) Most browsers send requests using the same character encoding as the HTML, so following requests to JSF can assumingly use previous response character encoding as request character encoding.

On an initial request of a session to JSF, whatever request character encoding set by servlet/container is used unmodified. Thus it can fall back to ISO-8859-1 as specified by Servlet Specification 2.4 and 2.5. A common way to specify request character encoding is to build a small servlet filter which call request.setCharacterEncoding.


Here's the tips:
  • Always use servlet filter to set request character encoding. Otherwise, an initial request to JSF will fail to decode parameters correctly.

    If you have a JSF page which uses incoming POST parameters, and a calling page is a simple html page with a form, chances are JSF will fail to process the parameter correctly for the first request, but will succeed for the following requests.

  • Always use only one encoding throughout the application. Otherwise, JSF may fail to decode parameters correctly.

    Note that response encoding is stored by session, not by session and page. If some JSF pages renders response by encoding A, while others renders response by encoding B, accessing the former pages after accessing the latter pages will result in decode failure. This may also happen if response encoding is changed dynamically based on user's preferences, and multiple windows are open while changing the preferences.


  • Even if you set a character encoding in a servlet filter, JSF will override it with the encoding found in Content-Type or the previous response encoding stored in a session. The servlet will use the last request character encoding set to parse form data, on an initial call to request.getParameter. (Modifying q request character encoding after a call to request.getParameter is ignored.) (Added: 2008/10/10)

posted by apptaro at 17:06 | Comment(2) | TrackBack(0) | JSF
The context parameter com.sun.faces.disableUnicodeEscaping can also have a role. For more info checkout the following article:

Posted by Alex K at 2008/12/29 22:02
Thank you Alex for the info.

I've done quick research and will leave a note here:
- com.sun.faces.disableUnicodeEscaping is a parameter specific to Mojarra (GlassFish's JSF implementation) which enables/disables unicode escaping.
- There is no parameter like this in MyFaces, but MyFaces automatically disables unicode escaping when a response charset is UTF-8. See https://issues.apache.org/jira/browse/MYFACES-272 and the source for org.apache.myfaces.shared.renderkit.html.HtmlResponseWriterImpl.
Posted by apptaro at 2009/01/03 13:25
Write Comments
Name: [Required]



Comments: [Required]

Code: [Required]

*Input characters in the image