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.

12 Responses to UTF-8 Umstellung oder Reparatur eines vorhandenen TYPO3-Systems

  1. Johannes sagt:

    Bei deinen mysqldump-Befehlen fehlt vor den Parametern ein zweites –

    zB. –default-character-set statt -default-character-set

    oder variiert das von Distribution zu Distribution?

    Auf jeden vielen Dank für den Artikel: Sehr wertvolles Basiswissen – Gut recherchiert und super zusammengeschrieben!

    lG aus Salzburg!

    • Johannes sagt:

      Ah – Und bevor man den SQL-Dump aus Fall (5) wieder reimportiert (in eine utf8-DB), sollte man in Zeile 10 des Exports

      /*!40101 SET NAMES latin1 */;

      in

      /*!40101 SET NAMES utf8 */;

      ändern: Ansonsten hat es bei mir nicht geklappt.

      lG aus Salzburg

    • Websolutions sagt:

      Danke für die Info! WordPress macht aus den Doppelstrichen einen Gedankenstrich. Die Befehle stehen nun innerhalb des code-Tags und nun sollte es stimmen.

      Dein 2. Punkt war im Text von mir mit „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.“ angemerkt.

  2. […] Reihenfolge, damit später nicht zwei verschiedene Zeichensätze in der Datenbank landen. Ein zweiter Artikel zeigt, wie man ein vorhandenes TYPO3-Projekt […]

  3. Leandre sagt:

    Vielen Dank für diesen äußerst nützlichen Artikel!
    Er hat eine stundenlange Odysee von trial & error beim Erstellen der Dumps und anschließendem Einspielen beendet.
    Danke!

  4. Joegi sagt:

    Vielen Dank für den ausführlichen Artikel. Konnte die DB mit chinesischen, russischen Inhalten erfolgreich auf utf-8 konvertieren.

  5. Christine sagt:

    Noch eine UTF-8-Verständnisfrage:
    Wie werden z.B. deutsche Umlaute in phpMyAdmin dargestellt, wenn alles korrekt auf UTF-8 eingestellt ist?

    schön oder schön?

    Wenn ich deine Reparatur bei Fall 6 (doppelt UTF-8 kodierte Daten) anwende, erhalte ich einen Dump mit einfach UTF-8 kodierten Daten, was ja schon mal bedeutend besser ist. Umlaute werden in phpMyAdmin dann so dargestellt: „schön“ und leider auch im Frontend. Erst, wenn ich die Umlaute von ö auf ö etc. umstelle, wird auch im Forntend alles korrekt ausgegeben.

    • Websolutions sagt:

      In phpMyAdmin sollten die Umlaute auch korrekt angezeigt werden.

      Kann es sein, dass Du im Dump nicht „alle Vorkommen von latin1 nach utf8“ abgeändert hast, bevor Du den Dump wieder importiert hast?

    • Christine sagt:

      Sorry, Entwarnung:
      Das passiert nur, wenn ich den mysqldump direkt über das Textinputfeld „SQL-Befehl(e) in Datenbank xyz ausführen:“ einspiele.
      Beim „normalen“ Import, werden die Umlaute korrekt importiert.

  6. rs@work sagt:

    Danke für diese perfekt strukturierte und gute Anleitung – die Tabelle ist super – hat mir sehr geholfen.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: