UTF-8 Umstellung oder Reparatur eines vorhandenen TYPO3-Systems

Das Ziel soll sein, ein System bestehend aus Datenbank, Datenbank-Verbidung und TYPO3 mit durchgängiger UTF-8-Kodierung zu bekommen.

Der erste Teil hat das Vorgehen bei einer neuen TYPO3-Installation beschrieben. In der Praxis kommt es aber auch oft vor, dass man ein vorhandenes System vorfindet, bei dem keine durchgängige UTF-8 Kodierung besteht. Meist ist zwar TYPO3 mit forceCharset und die MySQL-Datenbank korrekt mit UTF-8 Zeichensatz konfiguriert, die Datenbank-Verbindung zwischen TYPO3 und der Datenbank wird aber manchmal vergessen. In der der Standardeinstellung und somit auch bei den meisten Hostern, erfolgt die Verbindung zwischen PHP und der MySQL-Datenbank über latin1. Im Ergebnis landen dann doppelt UTF-8-kodierte Daten in der Datenbank.

Im Betrieb fällt es nicht auf, da alle Sonderzeichen wie z.B. Umlaute korrekt dargestellt werden. Erst bei einem Umzug der Datenbank oder wenn man die Daten außerhalb von TYPO3 verwenden möchte stellt man fest, das etwas nicht stimmt.

Die Problematik und weitere Szenarien werden ausgiebig im TYPO3 Kochbuch in Kapitel 2.10 ”Den Zeichensatz einer bestehenden TYPO3- Installation prüfen und auf UTF-8 umstellen” behandelt. Die wichtigsten Schritte gibt es hier. Zunächst müssen Informationen über das bestehende System gesammelt werden.

1. Zeichensatz der Datenbank

SELECT distinct(character_set_name) FROM INFORMATION_SCHEMA.COLUMNS WHERE table_schema = 'datenbank_name' AND NOT character_set_name IS NULL

2. Zeichensatzhandhabung der MySQL-Verbindung

Wurde $TYPO3_CONF_VARS['SYS']['setDBinit'] = ‘SET NAMES utf8′; in localconf.php gesetzt? Dann erfolgt die Kommunikation der TYPO3-DB-API mit dem MySQL Server über UTF-8. Ansonsten erfolgt die Verbindung im MySQL-Modul von PHP standardmäßig über latin1. Im Zweifel müssen die Variablen character_set_client, character_set_connection und character_set_result über eine TYPO3-DB-API Abfrage geprüft werden (SHOW VARIABLES LIKE ‘character_set_%’).

3. Zeichensatzkonfiguration von TYPO3

Wert von forceCharset prüfen. Wenn dieser nicht gesetzt ist, benutzt TYPO3 standardmäßig den Zeichensatz ISO 8859-1 (Latin 1).

Ergebnis

	TYPO3	Verbindung	Datenbank	Ergebnis
1.	Latin1	Latin1	Latin1	OK: Latin1
2.	Latin1	Latin1	UTF-8	OK: UTF-8 (TYPO3 vor 4.2: Binärfelder: Latin1)
3.	Latin1	UTF-8	Latin1	nicht möglich, sofern Umlaute verwendet werden
4.	Latin1	UTF-8	UTF-8	nicht möglich, sofern Umlaute verwendet werden
5.	UTF-8	Latin1	Latin1	durchgängig UTF-8-kodierte Daten in Latin1-Datenbank
6.	UTF-8	Latin1	UTF-8	doppelt UTF-8-kodierte Daten in Datenbank (TYPO3 vor 4.2: Binärfelder: korrektes UTF-8)
7.	UTF-8	UTF-8	Latin1	OK: Latin1 (TYPO3 vor 4.2: Binärfelder: UTF-8)
8.	UTF-8	UTF-8	UTF-8	OK: UTF-8

Zu 5.: UTF-8-kodierten Daten in der Latin1-Datenbank

mysqldump -u USER -p --default-character-set=latin1 datenbank_name > datenbank_name.sql

Zu 6.: Doppelt UTF-8-kodierten Daten

mysqldump -u USER -p --default-character-set=latin1 datenbank_name > datenbank_name.sql

In allen anderen Fällen:

mysqldump -u USER -p datenbank_name > datenbank_name.sql

Im Ergebnis hat man nun immer einen Dump mit korrekt kodierten UTF-8-Daten. Aber: mysqldump speichert den beim Dump verwendeten Zeichensatz, ebenso wie den Zeichensatz der Datenbank, innerhalb der Dump-Datei mit ab. Aus diesem Grund müssen innerhalb des Dumps alle Vorkommen von latin1 nach utf8  (innerhalb von SET NAMES latin1 oder DEFAULT Max. CHARSET latin1) abgeändert werden.

Nun wird TYPO3 für UTF-8 eingerichtet (siehe Teil 1) und danach der Dump wieder eingespielt. Dazu löscht man die vorhandene Datenbank (DROP DATABASE datanbank_name;) und lädt den Dump über:

mysql -u USER -p datenbank_name < datenbank_name.sql

Was man jetzt noch prüfen sollte: Sind die HTML-Templates auch UTF-8 Kodiert? Und natürlich wie immer das ganze System gründlich testen.