MySQL
MySQL unterstützt das explizite Setzen eines Encodings sowohl für eine ganze Tabelle, als auch für einzelne Tabellenspalten. Das Anlegen einer Tabelle kann z.B. über ein SQL-Statement der Form
create TABLE test ( ... ) CHARACTER SET utf8;
bewerkstelligt werden. Die spaltenweise Spezifikation ist nach folgendem Schema abzuwickeln:
CREATE TABLE t (c CHAR(20) CHARACTER SET utf8 COLLATE utf8_bin);
Weitere Informationen zu den verschiedenen UTF-8 Varianten finden sich in einer Informationsseite von MySQL.
Apache Webserver
Man sollte darauf achten, dass in den Konfigurationsoptionen des Apache 2 Webservers die Option AddDefaultCharset
nicht spezifiziert ist oder den Wert off
besitzt. Falls diese Option nicht verwendet wird, erfolgt (zum Glück) auch kein Eintrag in den HTTP-Header. Die Spezifikation des Inhalts lautet dann Content-Type: text/html
, andernfalls wird der Wert im Header etwa in der Form Content-Type: text/html; charset=ISO-8859-1
eingetragen. In der Kombination Apache 2.0.55 auf Ubuntu 6.06 war dieser Wert explizit in /etc/apache2/conf.d/charset eingetragen! Es hat den Anschein, dass diese Defaultkonfiguration in debianbasierten Distributionen häufig anzutreffen ist.
In Abhängigkeit der anderen Apache-Konfigurationsparameter (insbesondere der Einträge für AddCharset
) ist es gegebenenfalls möglich, das Ausliefern der Webseiten mit einem falschen Encoding-Eintrag im HTTP-Header zu verhindern, indem man die entsprechenden Seiten mit dem zusätzlichen Suffix .utf8
versieht. Aus einer Datei namens xxx.html
würde also xxx.html.utf8
. Sogar der Name Workaround erscheint mir für diesen Ansatz zu hoch gegriffen.
Mittels PHP lässt sich das Ausliefern der Webseiten mit einem falschen Encoding-Eintrag im HTTP-Header auch verhindern. Siehe hierzu die entsprechende Anmerkung für PHP.
Tomcat Webserver
Anmerkung: In diesem Abschnitt wird nicht zwischen Java Servlets und Java Server Pages unterschieden, da die hier besprochenen Aspekte für beide Ansätze Gültigkeit haben und im allgemeinen 1:1 übertragbar sind. So enthält etwa das Interface javax.servlet.http.HttpServletRequest
auch eine Methode namens setCharacterEncoding
, so dass die unten gemachten Aussagen für Java Server Pages auf Servlets übertragbar sein sollten.
Man sollte darauf achten, dass in den Konfigurationsoptionen des Servers (Datei conf/server.xml
) im Tag Connector folgende Attributeinstellungen gesetzt sind:
- useBodyEncodingForURI="false"
- URIEncoding="UTF-8"
Servlets in Tomcat: Grundsätzlich sollten servlets mit der Anweisungszeile <%@ page pageEncoding="UTF-8" %>
beginnen, dann sind am wenigsten Probleme zu erwarten. Offensichtlich wird in diesem Fall dafür gesorgt, dass
- der von der Coyote Komponente erzeugte Java-Zwischencode im richtigen Encoding erzeugt wird (was relevant ist, wenn die Sourcen der .jsp Datei selbst Umlaute enthalten),
- im HTTP Header der Wert für Content-Type korrekt gesetzt wird, per Default ist das ISO-8859-1!
Falls Formulardaten via POST
an eine Java Server Page übertragen werden sollen, ist darauf zu achten, dass in der .jsp-Datei zusatzlich folgende Einstellung vorgenommen wird:
request.setCharacterEncoding("UTF-8");
Anmerkung: das Encoding, in dem die eigentlichen HTML-Daten erzeugt werden, kann auch mit dem Aufruf von response.setCharacterEncoding(...);
gesetzt werden. Das ist jedoch überflüssig, wenn die oben erwähnte Zeile <%@ page pageEncoding="UTF-8" %>
in der .jsp-Datei verwendet wurde, und sollte daher i.a. nicht benutzt werden.
Siehe zum Thema Servlets und Java Server Pages auch den Abschnitt zum Programmieren mit Java.