Tip: Tomcat 5.x Encoding-Problematik...

Das Encoding-Problem ist wohl vielen bekannt - ich wollte mir auch schon ein "Schei* Encoding" T-Shirt bestellen...

Im Apache Tomcat 6 reichte bei mir immer ein

request.setCharacterEncoding("UTF-8");

bei folgendem Seitenkopf in der JSP

<%@ page pageEncoding=”UTF-8″ contentType=”text/html; charset=UTF-8″%>

und ich konnte die Anfrageparameter in UTF-8 ohne Probleme auslesen.

Natürlich sollte man das wie z.B. im Spring-Framework wenn möglich in einen eigenen Servlet-Filter (siehe CharacterEncodingFilter) auslagern.

Beim Tomcat 5.x hatte ich mit diesem Vorgehen leider kein Glück. Weder die Context-Konfigurationsoptionen "URIEncoding" noch "useBodyEncodingForURI" in der Konfigurationsdatei brachten Besserung. Dieses Problem hatten aber wohl schon mehrere Anwender - siehe hier.

Bisher konnte ich das Problem leider nur auf folgendem Weg lösen:

String firstname = request.getParameter("firstname");
if (firstname != null) {
    firstname = new String(firstname.getBytes("ISO-8859-1"),"UTF-8");
}

In diesem Fall konvertiere ich den Parameter von "ISO-8859-1" nach "UTF-8". Das sollte laut Tomcat FAQ auch kein Problem darstellen, da das Default-Encoding bei Servlets laut dem FAQ auch "ISO-8859-1" sein sollte:

Default Encoding for POST

ISO-8859-1 is defined as the default character set for HTTP request and response bodies in the servlet specification (request encoding: section 4.9 for spec version 2.4, section 3.9 for spec version 2.5; response encoding: section 5.4 for both spec versions 2.4 and 2.5). This default is historical: it comes from sections 3.4.1 and 3.7.1 of the HTTP/1.1 specification.

Update 14.07.2009: Ich konnte mit folgender Testseite alle drei Tomcat-Versionen:

• 5.0.28
• 5.5.27
• 6.0.20

erfolgreich testen. Bei allen Versionen ergab der Test das gleiche Verhalten. Meine Encoding-Testseite funktionierte problemlos wenn nicht vor dem "setCharacterEncoding" ein Anfrage-Parameter abgefragt wurde.

Wirklich komisch - ich muss nochmal genau nachforschen warum das ältere Projekt im Tomcat 6.x problemlos mit dieser Variante funktionierte und bei Tomcat 5.x Probleme bereitet hatte.

Update 15.07.2009: Das Rätsel ist gelöst! eine jar-Datei hat zu diesem Phänomen bei dem alten Projekt geführt. In meinem Fall eine jar-Datei des CMS FirstSpirit namens "fs-access.jar". Wenn diese aus dem "WEB-INF/lib"-Verzeichnis entfernt wird und "setCharacterEncoding" verwendet wird funktioniert auch im Tomcat 5.x alles wie erwartet. Evtl. ist die "fs-access.jar" in diesem Fall eine veraltete Version. Warum der Tomcat 5.x damit ein Problem hat und der Tomcat 6.x nicht ist mir aber immer noch ein Rätsel.

Update 15.07.2009 / 2: Die Kontext-Konfiguration "URIEncoding" wirkt sich nur auf das URI-Encoding aus! d.h. das muss verwendet werden wenn man die Parameter z.B. im Querystring übergibt (HTTP-Methode GET). Wenn das in der server.xml konfiguriert wurde kann man sich das Umwandeln von "ISO-8859-1"-Zeichenfolgen nach "UTF-8" sparen.

Weitere Informationen:

• utf-8 in java webapplikationen
• Tomcat Wiki UTF-8
• Tomcat Character Encoding FAQ