Typo3 mySQL-Datenbank auf UTF-8 umstellen bzw. konvertieren
Wem ist das noch nicht passiert? (ok, verdammt vielen) Man legt ein neues Projekt an, pflegt fröhlich Inhalte ein und freut sich, dass alles so gut läuft. Dann kommt eine neue Sprache als Anforderung und zack - die Datenbank ist entweder als standard für mySQL auf latin1_swedish_ci gestellt oder aber bei größeren typo3-Hostern wie z.B. mittwald auf latin1_german_ci. Was tun? Wie stelle ich die Datenbank auf utf-8 bzw. utf-general_ci um? Und was passiert mit den bestehenden Daten?
- Als allererstes sollte man mit phpMyAdmin einen Datenbankdump machen. Für typo3 gibt es dieses geniale Tool zwar als Extension aber man kann darauf nicht mehr zugreifen wenn man die unten genannten Schritte vornimmt - also phpMyAdmin separat installieren! Die Datenbankzugangsdaten stehen in typo3conf/localconf.php.
- Unter dem Reiter "Exportieren" findet man hierzu alles, was man braucht.
- Die gespeicherte SQL-Datei kopieren und die Kopie öffnen (am besten mit notepad2). Folgende Zeilen entfernen mit "Suchen und Ersetzen" (Strg+H)
CODE:
-
"collate latin1_german1_ci "
-
"DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci "
-
" DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci"
(leerzeichen beachten!)
-
- Jetzt im phpMyAdmin die bestehenden Tabellen (auf keinen Fall die Datenbank!!) löschen. Hierzu auf den Datenbanknamen klicken, alle TABELLEN auswählen und unten im Dropdown "alle löschen" wählen.
- Danach unter dem Reiter "Operationen" die Datenbank-Kollation auf UTF-8(utf-8_general_ci) stellen
das würde bei gelöschter typo3-Datenbank auch gar nicht mehr gehen. - Im Reiter "Importieren" die SQL-Datei wieder in die leere Datenbank einspielen.
Die Tabellen sollten jetzt alle auf UTF-8 gestellt sein. - Danach nur noch im Typo3 - Installtool folgende Schritte machen
- Unter "Database Analyzer" COMPARE auführen.
- Unter "All Configuration" folgendes setzen:
-
CODE:
-
[BE][forceCharset] = utf-8
CODE:-
[SYS][setDBinit] = SET NAMES utf8;
-
SET CHARACTER SET utf8;
-
SET SESSION character_set_server = utf8;
-
SET character_set_connection = utf8;
CODE:-
// für europäische Sprachen
-
[SYS][multiplyDBfieldSize] = 2
-
// für asiatische Sprachen
-
[SYS][multiplyDBfieldSize] = 3
-
-
Fertig, total einfach und im schlimmsten Fall funktioniert nun nix mehr.
Deswegen die Datenbank vorher sichern, wichtig wichtig!
(8 votes, average: 4.13 out of 5)
Loading ...
Am 6. April 2008 um 13:32 Uhr
Danke für die tolle Anleitung.
Zwei Fragen und eine Bemerkung:
Fragen:
1. Was bewirkt
SET SESSION character_set_server = utf8;
SET character_set_connection = utf8;
2. Beim “comparen” schlägt das hier immer fehl, weil der Wert 400 zu gross ist: ALTER TABLE sys_refindex ADD KEY lookup_string (ref_table,ref_string(400)); Was kann man da tun ?
Bemerkung: Wer MysqlDumper verwendet lösche einfach aus der SQL Datei das “DEFAULT CHARSET=latin1″ per suchen und ersetzen.
Am 7. April 2008 um 13:39 Uhr
Hey Stefan,
zu 1:
Wenn ein Client eine Verbindung herstellt, sendet er den Namen des Zeichensatzes, den er verwenden will, an den Server. Der Server stellt auf der Basis dieses Namens die Systemvariablen character_set_client, character_set_results und character_set_connection ein. Im Endeffekt führt der Server eine SET NAMES-Operation unter Verwendung des Zeichensatznamens aus.
(Quelle: http://dev.mysql.com/doc/refman/5.1/de/charset-connection.html)
Heisst also nichts anderes, als dass du hier nochmal explizit sagst “egal, was ankommt, es muss als utf8 verwendet werden. Das gleiche gilt für “SET SESSION character_set_server = utf8;” Hier sagst du mySQL, dass für die aktuell gültige Verbindung utf8 als Zeichensatz verwendet werden soll.
Wenn nach dem comparen dennoch alles funktioniert ist das “normal”. Solange alles funktioniert sollte das nicht wichtig sein. Die Tabelle “sys_refindex” zeigt die Abhängigkeiten von Inhalten auf, z.b. wenn du ein Template an mehrern Stellen in das Include-feld einbaust, dann wird dies in der “sys_refindex” von TYPO3 festgehalten, damit du weisst, dass du ein mehrfach verwendetes Template nicht direkt an Stelle a löschst, da es noch an Stelle b benutzt wird.
Am 23. Mai 2008 um 14:31 Uhr
Bei einem Projekt für eine tschechische TYPO3 Site hat die Vorgensweise sehr gut funktioniert. Die Site ist von einem Projekt in deutscher Sprache abgeändert worden.
Am 23. Mai 2008 um 14:35 Uhr
Hi Axel, es freut mich das zu hören. Hast du noch einen Link zu der Seite?
Am 12. Juni 2008 um 14:17 Uhr
Hallo zusammen,
habe das selbe Problem gehabt und vergessen die db auf utf-8 zu stellen. Leider sind nach diesem vorgang alleumlaute und sonderzeichen im frontend im arsch.
Grüße Florian
Am 13. Juni 2008 um 15:31 Uhr
Hi Florian, eventuell musst du deine SQL-Textdatei mit den bestehenden Umlauten noch durch das iconv Plugin laufen lassen:
http://blechtrottel.net/iconvplugin.html
http://prantl.host.sk/iconv/
Danach sollte es auch gehen. Ich hoffe du hattest Backups der DB?
Am 15. Juni 2008 um 15:27 Uhr
Wenn die Datenbank komplett auf utf-8 umgestellt ist sollte
[SYS][multiplyDBfieldSize] = 1
für alle Sprachen ausreichend sein.
Grüße Georg
Am 12. Juli 2008 um 08:09 Uhr
Danke für die Anleitung. Habe alle Schritte befolgt. Alle Zeichen wurden manuell in Klartext umgewandelt und reimportiert. Nur das Frontend zeigt einmal Seiten richtig dar, zum anderen mit dem Fragezeichen. Was kann ich tun?
Am 12. Juli 2008 um 12:11 Uhr
Die Anzeige ist also gemischt meinst du?
Prüf mal, ob die .sql Datei, nach dem Umwandeln als UTF-8 codiert abgespeichert wurde.
Ansonsten schick mir per Mail mal den Link, ggf. kann ich ja mal reinschauen und wenn die Daten nicht supersicher sind und nicht zu groß, dann pack doch die SQL mal und schick sie rüber.
Am 30. Juli 2008 um 20:51 Uhr
Hallo Markus, das Tabellenfeld HTML der Tabelle cache_pages war aus irgendwelchen Gründen nicht auf utf8_general_ci umgestellt.
Außerdem sind in das Template noch einzutragen:
config.renderCharset = utf-8
config.metaCharset = utf-8
Am 31. Juli 2008 um 08:30 Uhr
Dann läuft’s jetzt rund? Klasse! Das freut mich. Deine Ergänzungen habe ich oben noch angefügt! Danke!
Am 31. Juli 2008 um 22:32 Uhr
Hallo André und alle,
config.renderCharset = utf-8
und
config.metaCharset = utf-8
müssen nicht gesetzt werden, sie sind schon über
[BE][forceCharset] = utf-8
gesetzt. Siehe TSref.
Am 31. Juli 2008 um 22:51 Uhr
ein hin und her…
Am 26. August 2008 um 12:09 Uhr
Tausend Dank für diese Anleitung!
Hat auch für meine inzwischen ein paar tausend Einträge wunderbar funktioniert
Am 29. September 2008 um 23:39 Uhr
Habe ein Problem mit dem Cache:
Alles so durchgeführt wie oben beschrieben, es wird auch alles im BE und FE korrekt dargestellt - wenn der Seitencache leer ist!
Sobald eine Seite erneut aufgerufen wird, kommt die Meldung “ERROR - No template found!”
In der Tabelle “cache_pages” stehen nur die Felder “hash” und “HTML” auf Kollation “utf8_unicode_ci”.
Hat jemand einen Tipp?
Am 29. September 2008 um 23:55 Uhr
…es ist die Tabelle “cache_hash”! Wird diese gelleert, so werde die Seiten (einmalig) wieder angezeigt.
Am 14. November 2008 um 15:06 Uhr
Hallo,
das Problem mit dem Cache ist unter
http://bugs.typo3.org/view.php?id=6006
genauer beschrieben.
Bei mir hat es geholfen im Installtool
den Eintrag
SET CHARACTER SET utf8
unter
[SYS][setDBinit]
zu löschen. Damit wird sonst
SET collation_connection = utf8
gesetzt, was bei serialized Data (cache_pages), also dem Seitencache Probleme macht.
Am 14. November 2008 um 15:11 Uhr
Hallo,
es wird natürlich
SET collation_connection = @@ collation_database
gesetzt. Da bei mir
collation_database = utf8_general_ci
ist, wird damit auch die
collation_connection von utf8_unicode_ci auf utf8_general_ci umgestellt.
Das macht dann leider die im Bug beschriebenen Probleme.
Am 26. Februar 2009 um 09:17 Uhr
Das Importieren dauert ewig bei mir und belastet den Computer ziemlich stark. Kann man nicht das einfach mit mysql < dateiname machen.
Markus: Klar kann man das, aber viele User haben keinen Shell Zugriff und müssen daher mit PHPMyAdmin und den zur Verfügung stehenden Mitteln arbeiten
Am 26. Februar 2009 um 17:07 Uhr
Ich finde die Anleitung recht kompliziert und hat bei mir auch nicht weitergeholfen. Das folgende Vorgehen dagegen führte zum Erfolg.
1. Daten aus Datenbank rausschreiben (z.B. mit mysqldump)
2. Daten nach UTF-8 kodieren
3. Sicherstellen, dass Daten im UTF-8-Format vorliegen. Kann man z.B. mit einer UTF-8-Konsole
(unter Linux: LC_CTYPE=de_DE.UTF-8 xterm -fn ‘-Misc-Fixed-Medium-R-SemiCondensed–13-120-75-75-C-60-ISO10646-1′)
überprüfen. Alle Umlaute sollten richtig dargestellt werden bei Ausgabe der Datei mit more.
4. SQL-Datei editieren. Alle CREATE DATABASE-Anweisungen sollten enden mit: “default character set ‘UTF8′; ” (doppelte Anführungszeichen natürlich nicht mit eingeben).
5. Ebenso verfahren mit allen
CREATE TABLE-Anweisungen.
6. Alle Vorkommen von LATIN1/latin1 in der Datei entfernen wie oben beschrieben
7. Alte Datenbank löschen mit DROP database name;
8. UTF8-Konsole öffnen (wichtig, dass UTF-8!)
9. Eingabe mysql –default-character-set=UTF8 -u username -p
Markus: Die meisten User kommen damit sehr gut klar. Eventuell bist du eher der bash-Typ, (sieht ganz so aus;) ), da ist es natürlich per Console wesentlich komfortabler, allerdings haben wie gesagt nicht alle User Zugriff darauf. Auf jeden Fall vielen Dank für die Beschreibung unter Linux!