Kategorien
- [-]Developer (94)
- API (14)
- Backend (16)
- Extensions (26)
- HTML & CSS (4)
- Typoscript (31)
- [-]Redaktionelles (15)
- Anleitungen (6)
- Tipps (6)
- Sonstiges (36)
Schlagwortwolke
| « | Februar 2012 | » | ||||
|---|---|---|---|---|---|---|
| S | M | T | W | T | F | S |
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | |||
Letzte Nachrichten
- Cookie Control und die europäische Cookie-Richtlinie
- 18.05.2012 21:41
- Schafft er es auf die erste Seite?
- 18.05.2012 14:39
- TYPO3camp Berlin 2012
- 11.05.2012 15:35
- Webdesign in Zeiten des iPad 3: und immer noch mehr Pixel.
- 10.05.2012 17:14
Letzte Kommentare
- Hallo David, das ist ein guter Tipp, werde ich mir...
- 13.05.2012 13:19
- Hallo! In der Aufzählung gehst du nicht auf den verfügbaren...
- 12.05.2012 14:35
- Müsste eigentlich so funktionieren, ich mache es hier ja...
- 10.04.2012 13:03
- Erst einmal - Danke für die Extension. Eine Frage habe...
- 10.04.2012 10:30
In eigener Sache
Peter Linzenkirchner, Lisardo Multimedia in Augsburg. Freelance und Partner für Design- und Webagenturen in Augsburg und München. Pixelgenaue Templates, valides HTML, barrierearm. TYPO3-Projekte, Extension-Programmierung und mehr ...
Umlautprobleme beim Dumpen einer Datenbank
Ich hatte die letzten Tage wieder lausige Probleme mit einer TYPO3-Installation, deren Datenbank-Tabellen in latin1 kodiert waren (DEFAULT CHARSET=latin und Kollation latin1_swedish_ci), in denen sich aber utf8-Daten befinden. Wenn man den Dump auf die übliche Art erstellt - oder auch z. B. über phpMyAdmin - erhält man beim Wiedereinspielen Umlautprobleme dieser Art: ö für ö. Das passiert, weil utf8-Daten beim Dumpen nochmals nach utf8 kodiert werden ...
Dieser Müll passiert immer dann, wenn die Tabellen in MySQL als latin angelegt wurden (DEFAULT CHARSET=latin, meist noch in MySQL 3.x) und auch über eine Datenverbindung mit SET NAMES latin1 beschickt wurden (weil das der Standard in php war), in TYPO3 aber forceCharset =utf-8 eingestellt wurde (eben ohne gleichzeitig setDBinit auf "SET NAMES utf8" zu setzen).
Damit konnte man mit einem normal installierten MySQL 3.x sehr einfach erreichen, dass TYPO3 die Daten auf der Webseite selbst als utf8 präsentiert und sie auch so in den Tabellen abspeichert - leider aber in latin-kodierten Tabellen und über eine latin-Verbindung. Die Konsequenz ist, dass MySQL der Meinung ist, dass es latin-Daten in den Tabellen hat, und deshalb beim Erstellen eines Dumps die Daten dann ganz folgerichtig nach utf8 kodiert. Da die Daten aber leider schon in utf8 sind erhalten wir Datenmüll.
In etwa war mir schon klar, was passiert und warum, nur eine saubere Lösung wußte ich keine. Eine wirklich gute Beschreibung des Problems (und vor allem praktikable Lösungswege!!) habe ich gerade jetzt in einem richtig guten Artikel von Kristian Köhntopp gefunden: FAQ: Mein mysqldump zerstört meine Umlaute.
Lesebefehl für alle, die sich mit derartig verkorksten TYPO3-Installationen rumschlagen müssen. Seine Regel am Schluss kann ich nur dringend unterstreichen:
»Lüge die Datenbank nicht an. Wenn Du SET NAMES latin1 eingestellt hast, sende latin1. Wenn Du SET NAMES utf8 eingestellt hast, sende utf8.«
Also: $TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8' erfordert zwingend auch $TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;' sonst gibts Datenmüll.
Nachtrag
Ich habe gerade wieder so eine Installation in den Fingern :-( Aber mit der Lösung von Köhntopp klappt es bei mir, etwa in der Art:
- mysqldump --default-character-set latin1 -uUser -pPassword -hHost DB-Name | sed -e's/SET NAMES latin1/SET NAMES utf8/' > datei.sql
- Kommentare

