Typo3 Migration von 4.x auf 6.2 mit Kodierungsproblemen

Wenn eine Typo3-Installation in Version 4.x von Server A nach Server B migriert werden soll kann es zu Problemen mit der Codierung kommen (latin1 vs. utf-8).

(Ein Update mit einem einfachen Weg zur Umcodierung am Ende der Seite!)

Symptome

  • Inhalte / Strings mit Umlauten wird nicht dargestellt, weder im Backend noch im Frontend (z.B. „Menüs“, „Caches löschen“)
  • Bilder im Frontend werden nicht angezeigt, wenn die page Umlaute beinhaltet (genauer: Die Bilder in typo3temp werden nicht generiert)

Ursache

Das Problem ist, dass die Inhalte in der Datenbank in latin1 / iso-8859-1 codiert sind und Typo3 utf-8 nutzt. Dies ist vermutlich aber erst ab einer gewissen PHP-Version >5.2 so, also betrifft vor allem Systeme, bei denen ein PHP-Upgrade durch die Migration verursacht wird.
Damit die Zeichen richtig ausgegeben werden müssen drei Faktoren stimmen:

  • Codierung mit der Typo3 arbeitet
  • Codierung der Datenbankverbindung
  • Codierung der Datenbankinhalte

Problemlösung

Die einfachste und zukunftssicherste Problemlösung ist alle Inhalte auf UTF-8 zu konvertieren, da Typo3 in neueren Versionen standardmäßig mit UTF-8 arbeitet.

  1. Exportieren der Datenbank per mysqldump mit der Option –default-character-set=utf8
  2. Manuelles Ersetzen aller Vorkommnisse von „latin1_“ durch „utf8_“ (z.B. mit vim: :%s/latin1_/utf8_/)
  3. Manuelles Ersetzen aller Vorkommnisse von „DEFAULT CHARSET=latin1“ durch „DEFAULT CHARSET=utf8“ (z.B. mit vim: :%s/DEFAULT CHARSET=latin1/DEFAULT CHARSET=utf8/)
  4. Einspielen des Dumpy mit der Option –default-character-set=utf8
  5. Ändern der localconf.php, folgende Einstellungen ändern:
    $TYPO3_CONF_VARS[‚SYS‘][’setDBinit‘] = ‚SET NAMES utf8;‘; $TYPO3_CONF_VARS[‚BE‘][‚forceCharset‘] = ‚utf-8‘;

Danach sollte Typo3 wieder problemlos laufen und alle Strings richtig ausgeben.
 


Update!

Ein Arbeitskollege von mir, genauer gesagt der Certified Extension-Entwickler und Typo3-Association-Mitglied Torsten Schrade, hat einen weniger fummeligen Weg gefunden, das Ganze über die Bühne zu bringen:

  1. phpmyadmin aufrufen und eine leere DB mit Kollation latin1_general_ci erstellen
  2. Die Datenbank Einspielen als latin1:
    mysql -uXXX -pXXX – -default-character-set=latin1 DATENBANK < DUMP.sql
  3. Ausspielen als latin1/compatible (= ohne Kollationsinformationen):
    mysqldump -uroot -pvagrant – -default-character-set=latin1 – -compatible=mysql40 DATENBANK > DUMP.latin1.sql
  4. Konvertieren mit iconv:
    iconv -f ISO-8859-1 -t UTF-8 DUMP.latin1.sql > DUMP.utf8.sql
  5. DUMP.utf8.sql in bspw. in Textwrangler, vim o.ä. öffnen und darauf achten, dass die Datei in UTF8 angezeigt wird. Konkret also prüfen, ob die Umlaute korrekt dargestellt werden. Stimmen die Umlaute war die Konversion erfolgreich.
  6. Wenn alles stimmt: Bei der Tabellendeklaration im Dump TYPE=MyISAM in ENGINE=MyISAM (und ggf. das gleiche mit InnoDB) ändern und abspeichern, z.B. über „Suchen/Ersetzen“.
  7. phpmyadmin aufrufen, alte Datenbank löschen und neu anlegen, diesmal aber mit Kollation utf8_general_ci
  8. Die konvertierte Datenbank einspielen:
    mysql -uroot -pvagrant –default-character-set=utf8 DB < DUMP.utf8.sql
  9. Fertig.

Im Endeffekt erspart einem das die Suchen/Ersetzen der ganzen Kollationsinformationen, da diese erst gar nicht mit exportiert werden.

Danke an Torsten für diesen Input 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert