Eine Typo3-Installation auf UTF-8 umzustellen ist teilweise recht verzwickt. So schickte z.B. das Mailformular nur mit Base64 kodierte E-Mails raus, bzw. fügte zwei unterschiedliche Header ein… die Mails die dabei rauskamen waren nicht mehr lesbar. Auch die Installation der Extension, die das Mail-Encoding auf „quoted-printable“ umstellen sollte brachte nichts. Abhilfe schaffte schließlich eine Einstellung in der php.ini Datei:
mbstring.internal_encoding = UTF-8
Desweiteren gab es Probleme beim Einfügen von Multibyte-Zeichensätzen in die Tabellen. Die Datenbank, der Server und alle HTML-Seiten waren auf UTF-8 umgestellt, nur meckerte Typo3 bei manchen Zeichen mit der Fehlermeldung
102: These fields are not properly updated in database: (bodytext) Probably value mismatch with fieldtype.
Abhilfe schaffte die Umstellung des folgenden Wertes auf „3“ statt vorher „1“ im Typo3-Install-Tool:
[multiplyDBfieldSize]
und eine abschließende Aktualisierung der Datenbank mittels „Compare“ im „Database Analyser“ des Installations- Tools. Zusätzlich gibt es wohl einen Bug in der MySQL 4.x Version, so daß eine Umstellung des Charsets der „tt_content“ Tabelle (und damit auch der „bodytext“ Spalte) auf ISO-8859-1 (latin1) nötig war. Um auch die Navigationstitel übersetzen zu können muss zusätzlich die Tabelle „pages_language_overlay“ umgestellt werden. Das habe ich mit folgenden Befehlen an den MySQL Server erreicht:
ALTER TABLE tt_content CONVERT TO CHARACTER SET latin1;
ALTER TABLE pages_language_overlay CONVERT TO CHARACTER SET latin1;
Die Kollation (Sortiervorschrift) muss nicht explizit gesetzt werden, da sie bei diesem Befehl auf die Standard-Kollation des gewählten Charsets gesetzt wird.
Zum Nachlesen: MySQL – Charsets und Collations
Ich hoffe das hilft einigen Typo3-Nutzern mit ähnlichen Problemen. Ich habe mich durch diverse Foren und Mailinglisten-Archive gekämpft bis ich auf die Lösung kam. Unter anderem hat mich dieser Thread von der Typo3 Dev-Mailingliste auf die Idee zur Lösung gebracht: Typo3 Dev Liste
Suchworte: Typo3 UTF-8 Probleme, Kontaktformular Base64 statt 8Bit oder quoted-printable, Sonderzeichen erscheinen nur als Fragezeichen oder Kästchen, Fehler 102 beim speichern in Typo3
Grüße vom eXanto-Team!
Hallo, das mit der Mail geht auch einfacher…
Einfach im Formular ein „hidden_field“ mit dem namen „quoted_printable“ und dem Wert 1.
Danach wird die Mail nicht mehr verkodiert.
sg
Mike
Hi,
ich habe zur Zeit das gleiche Problem. Nur sendet meine Extension die Mails und ich bekomme entweder zwei Mime-Header oder zumindest von wie geisteshand ein UTF-8 Mime-Header. Habe in der php.ini die Aenderung vorgenommen, aber immer noch das Problem…
help
cheese,
Stefan
Hier ist meine Sammlung für die Umstellung:
Komplette Datenbank auf utf-8 umgestellt. (Struktur erstellt => latin1 auf utf8, dann die Daten eingelesen)
0. editiere die typo3conf/localconf.php und füge ein: $TYPO3_CONF_VARS[‚BE‘][‚forceCharset‘] = ‚utf-8‘;
1. Datenbank Dump der Site erstellen
2. Eine Kopie des Dumps konvertieren: recode LATIN1..UTF8 copy_of_dbname.sql
3. Bestehende Datenbanktabellen löschen
4. UTF-8 Dump zurückspielen mysql dbname < copy_of_dbname.sql oder halt erweitert um -u für user und -p für passwort
Angeblich muß man multiplyDBfieldSize auf >1 stellen, wenn der Fehler 102 kommt,
wenn man versucht, in tt_content Umlaute einzugeben. Wenn alles stimmt, kommt dieser Fehler aber nicht. Wenn >1 geht compare Database auch nicht mehr.
Hallo Hugo H.,
was meinst Du mit:
In TS Setup meta charset setzen
???
Grüße
TPITS
http://typo3.org/doc…
Man kann den metaCharset in page.config setzen. Auch das Rendern geht darüber.
Siehe Tabelle
page.config.metaCharset = utf-8
page.config.renderCharset = utf-8
Die Methode mit page.config.metaCharset kannte ich, jedoch nicht im Install Tool setDBinit umzustellen.
Wirklich nett, danke für die Hilfe und die Tipps.
Hallo,
danke für den Hinweis. Ist dieser Punkt mit dem Multibyte-Problem als Bug bekannt? Ich finde es ein wenig unbefriedigend alle Tabellen, die vorher die Kollation UTF-8 hatten auf latin-1 zu konvertieren. Kann man in diesem Fall noch von einer reinen UTF-8 Konvertierung reden? Irgendwie ist das ja nur ein Workaround und ggf. sogar ein Fake oder?
Grüße
Patrick
Hallo Patrick,
ich habe keine Ahnung ob das bekannt ist. Bei manchen Sprachen (russisch, chinesisch, …) gab es da halt Probleme. Ich hatte auch keine Zeit mich noch näher mit dem Problem zu befassen. Deine Einschätzung könnte also richtig sein 😉
Grüße,
Ingo
Ich wurde auf diesen Artikel hingewiesen und möchte auf einige Fehler hinweisen:
– mbstring.internal_encoding wird nur benötigt, wenn im Install-Tool für „t3lib_cs_convMethod“ und „t3lib_cs_utils“ entsprechend „mbstring“ eingestellt wurde.
– „multiplyDBfieldSize“ ermöglicht das Speichern von Multibyte-Daten in Singlebyte-Zeichensätzen wie z.B. Latin1. Das funktioniert zwar, sollte aber nie verwendet werden! (keine Kompatibilität mit fremden Tools wie z.B. phpMyAdmin, falsche Sortierreihenfolge, Probleme bei Datenmigrationen).
=> Viel besser ist es, gleich von Anfang an den richtigen Zeichensatz für die gesamte DB zu verwenden.
– Dasselbe gilt für die Konvertierung der DB nach Latin1: Es ist wenig sinnvoll, für eine UTF-8 Seite den Zeichensatz der Datenbank explizit auf Latin1 zu setzen. Ausserdem kann der Aufruf von „CONVERT TO CHARACTER SET latin1“ zu Datenverlust führen, z.B. wenn die Datenbank bereits UTF-8 ist und Zeichen enthält, welche in Latin1 nicht vorhanden sind. (Wäre die Datenbank bereits vollständig UTF-8, dann müsste sie sowieso nicht in einen anderen Zeichensatz konvertiert werden – das ergibt keinen Sinn!)
Kurz zusammengefasst muss folgendes berücksichtigt werden:
– TYPO3 arbeitet mit Daten und nutzt dafür den Zeichensatz, der in $TYPO3_CONF_VARS[‚BE‘][‚forceCharset‘] eingestellt ist. Standardwert ist ‚iso-8859-1‘ (Latin1) oder je nach Sprache des Backends der jeweilige Standard-Zeichensatz dieser Sprache.
– Die MySQL-Schnittstelle in PHP, die von TYPO3 genutzt wird, verwendet ebenfalls ihr eigenes Charset. Standardwert ist je nach Distribution unterschiedlich, kann mit „SHOW VARIABLES LIKE ‚character_set_%'“ überprüft werden (folgende müssen mit dem o.g. forceCharset übereinstimmen: character_set_client, character_set_connection, character_set_result).
Konfiguration erfolgt entweder über MySQL-Konfiguration (my.ini). Wer nicht sicher ist, kann den Zeichensatz auch von TYPO3 bei jedem Aufruf setzen lassen: $TYPO3_CONF_VARS[‚SYS‘][’setDBinit‘] = ‚SET NAMES utf8;‘
– MySQL selber nutzt dann ebenfalls ein eigenes Charset. Dabei muss insbesondere berücksichtigt werden, dass nicht nur für die Datenbank, sondern für jede Tabelle und sogar für jedes einzelne Feld ein anderer Zeichensatz verwendet werden könnte. (Dieses Gemisch taucht oft auf wenn eine Datenbank nicht richtig migriert wird, darum sollte dies bei Problemen als erstes überprüft werden.)
Richtigerweise sollten auch hier alle Tabellen/Felder ebenfalls mit o.g. Zeichensatz übereinstimmen. Der Zeichensatz, der für die DB ausgewählt wurde, wird jeweils für neu angelegte Tabellen verwendet.
Auch wichtig: „CONVERT TO CHARACTER SET …“ setzt nicht nur die Einstellung für eine Tabelle, sondern konvertiert auch gleich deren Inhalt. Wer bereits fälschlicherweise UTF-8 in eine Latin1-DB schreibt, würde demnach doppelt kodierte Daten erhalten. Eine Lösung für dieses Problem ist hier beschrieben: http://bugs.typo3.org/view.php?id=6098#c15368
(Alternativ müssen halt einfach alle falschen Zeichen manuell korrigiert werden – das ist je nach grösse des Datenbestands verschmerzbar und einfacher…)
Hallo Michael,
danke für die Richtigstellung! Ich arbeite nicht sehr häufig mit Typo3, von daher war ich froh als es damals endlich lief wie es sollte 😉 Ist ja auch schon ein paar Jährchen her… Also – danke für die ausführlichen Informationen!
Gruß,
Ingo
Hi,
das muss ich glatt ausprobieren. lese mich gerade auch ein, weil die Umstellung von Typo3 auf Japanisch echt alles andere als einfach ist. Habe shift_jis in typo3 und sjis_japanese_ci in der Datenbank. So kriege ich dauernd den Fehler noch, und ich sehe nur Fragezeichen. Muss wohl an der php noch liegen. Collations scheinen dabei nicht das Problem zu sein. In Datenbank kann man die Kanji/Kana lesen, aber Typo3 spuckt und schreibt nur Fragezeichen und Sondermüll…