Typo3-Datenbank und utf-8

bin gerade dabei, mich mit der Typo3-Datenbank genauer vertraut zu machen und die Datenwege in diesem Zusammenhang im Typo3 zu verstehen. Dabei bin ich auf folgende Ungereimheit gestoßen, die ich nicht begreife.

Meine Datenbank für Typo3 ist mit utf8_unicode_ci angelegt. Ein Blick über phpMyAdmin in die Datenbankstruktur zeigt, dass bis auf die Spaltenebene alles utf8_unicode_ci angelegt ist.

Das BE läuft dazu mit forceCharset = utf-8. Alles klappt soweit gut, es gibt im BE und FE keine Probleme mit Zeichensatzausreißern.

Schaue ich jedoch mit einem ebenfalls auf utf-8 konfiguriertem phpMyAdmin (MySQL-Zeichensatz: UTF-8 Unicode (utf8-), Zeichensatz / Kollation der MySQL-Verbindung: utf8_unicode_ci)in die Datensätze der Datenbank hinein, dann sehe ich einen Haufen Zeichensatzfehler darin.

Aus Überstärkungstraße wird z.B. Ãœberstärkungstraße.

Obwohl also ein Zeichensatzproblem im Datensatz vorzuliegen scheint, stört das Typo3 nicht.

Kann sich jemand einen Reim darauf machen und mir erklären, wie das zustande kommt und, wenn ich keinen Konfigurationsfehler eingebaut habe, weshalb es trotzdem funktioniert? Gibt es in Typo3 eine weitere Einstellung die für utf-8 gesetzt werden muss, damit das Beschreiben der Datenbank sauber wird?

Ganz harmlos ist diese Geschichte so wie geschildert übrigens nicht. Versucht man einen Dump einer solchen Datenbank z. B. mit phpMyAdmin und spielt es in eine andere Typo3 Umgebung ein, schlagen die Kodierungsfehler voll zu.

Moin Moin !

kanticus schrieb

Aus Überstärkungstraße wird z.B. Ãœberstärkungstraße.

Obwohl also ein Zeichensatzproblem im Datensatz vorzuliegen scheint, stört das Typo3 nicht.

Ist kein Problem. Umlaute werden in utf-8 mit zwei bis vier Bytes kodiert. Lies mal den Wikipedia-Artikel dazu, das sollte einiges Licht ins Dunkel bringen: http://de.wikipedia.org/wiki/UTF-8

kanticus schrieb

Ganz harmlos ist diese Geschichte so wie geschildert übrigens nicht. Versucht man einen Dump einer solchen Datenbank z. B. mit phpMyAdmin und spielt es in eine andere Typo3 Umgebung ein, schlagen die Kodierungsfehler voll zu.

Dann stimmt vielleich der Zeichensatz der zweiten Datenbank nicht?

CU
Stephan

Danke KaffDaddy für Deine Antwort.

Habe die ganze Geschichte nochmal nachgeschaut - deshalb die Sendepause bis jetzt.

Die Geschichte mit der utf-8 Kodierung kenne ich.

Meinem Verständnis nach dürfte aber trotzdem, wenn der komplette Vermittlungsweg als Übertragung eines utf-8-kodierten Inhalts sauber abläuft und keine Umkodierung stattfindet, keine solchen Ergebnisse zeitigen. (Meine auch das Einsehen der Datenbank mit phpMyAdmin, wenn es richtig konfiguriert ist)

Den Vermittlungsweg bin ich jetzt nochmal nachgegangen. Datenbank erstellt in beiden Fällen mit DEFAULT CAHARACTER SET utf8 COLLATE utf8_unicode_ci. Tabellen und Felder der Datenbank in utf-8. Typo3 arbeitet in forceCharset = utf-8.

phpMyAdmin arbeitet mit:
MySQL-Zeichensatz: UTF-8 Unicode (utf8-)und
Zeichensatz / Kollation der MySQL-Verbindung: utf8_unicode_ci.

Der Test-Text: "Üäö ist fein, ß könnte es aber auch sein1?" eingegeben und eingesehen im BE und ausgegeben im FE, alles kein Problem. Es handet sich dabei um einen Seitentitel.

Der gleiche Text eingesehen über phpMyAdmin in der Typo3-Datenbank mit obiger Konfiguration: Üäö ist fein, ß könnte es aber auch sein1?

Lege ich einen page-Datensatz im phpMyAdmin in dieser Datenbank an, ergibt das das richtige "Üäö ist fein, ß könnte es aber auch sein1?" im phpMyAdmin.

Im BE von Typo3 sieht der Text so aus: "��� ist fein, � k�nnte es aber auch sein1?"

Und im FE, die Überraschung, stimmt der Text innerhalb des body der Seite wieder. Aber auch nur dort, denn seine Ausgabe in der Titelleiste des Browser ist wie im BE nicht korrekt.

Es scheint mir also, als ob das BE die Stelle ist, die die utf-8 Kette unterbricht. Im ersten Fall beim Schreiben in die DB, wo kein utf-8 Inhalt ankommt (phpMyAdmin zeigt die Falschkodierung). Beim Auslesen wird dies aber wieder behoben. Im zweiten Fall liegt der Inhalt in der DB richtig kodiert. Das Auslesen des Inhalts ins BE schlägt deshalb fehl, die Darstellung im Body des utf-8 Html-Dokuments im Browser funktioniert aber wieder.

Das würde zu der Beobachtung von mir passen, dass wenn man in einer utf-8 Installation im Install-Tool einen Sonderzeichennamen wählt, z. B. Überfließer, im BE dieser Name falsch kodiert an der Weltkugel wiedergegeben wird.

Ist das möglich, dass das BE trotz forceCharset = utf-8 nicht richtig im UTF-8 arbeitet?

(trotz <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> der BE-Seiten?)

Gibt es zusätzliche Einstellung, die neben forceCharset = utf-8 noch gesetzt werden müssen?

Gruß

Kanticus

Hallo Kanticus

Genau dasselbe Problem hat mich heute Nacht wachgehalten! #angry# Ich war nicht bereit zu akzeptieren, dass in PHPMyAdmin und in den Dumps unlesbare Zeichen erschienen, auch wenn in Typo3 alles gut funktionierte.

Nach der Umstellung im BE auf forceCharset = utf-8 geht Typo3 davon aus, dass die Kommunikation mit der Datenbank nur noch in UTF-8 läuft. MySQL nahm aber bei mir weiterhin "latin-1" Zeichen entgegen, die eigentlich UTF-8 wären. Die verstümmelten Zeichen kommen daher, dass viele UTF-8 Zeichen in latin-1 nicht existieren. Die Ausgabe in Typo3 geht aber problemlos, weil die Datenbank das "Pseudo-Latin-1" Zeichen ausgibt, welches von Typo3 als UTF-8 interpretiert wird. Aber in PHPMyAdmin wirkt sich der Fehler aus, weil das Zeichen hier als latin-1 interpretiert wird, so wie es eingegeben wurde. (Ich hoffe, dass ich das einigermassen verständlich erklärt habe)

Die Lösung: In der Einstellung BE->[setDBinit] gibst du das ein: SET NAMES utf8
Nun sprechen Typo3 und MySQL dieselbe Sprache.

Gruss, Dave

Hallo Dave,

Danke für Deine zielführende Antwort. Habe es auf einem mager bestückten Testsystem ausprobiert und siehe da: die Datenbank wird nach erneutem Speichern der bisher eingetragenen Inhalte wieder sauber.

Nur hier liegt auch ein großer Stolperstein dieser Anpassung. Hat man eine Datenbank erst einmal mit Inhalten ohne die von Dir beschriebene Einstellung befüllt, bring diese Anpassung die komplette Typo3 Installation gewaltig aus dem Tritt.

Nach der Umstellung sprang bei mir die BE-Sprache auf englisch, das Basis-Template wurde nicht gefunden, das Content kommt bei Sonderzeichen nicht mehr klar, ...

Kurz gesagt: es wird eine komplette Überarbeitung der ganzen Website fällig.

Dein Einstellungsvorschlag gehörte also zur Grundkonfiguration von Typo3 für Datenbanken auf utf-8 Basis, damit diese unter Umständen gewaltige Nacharbeit nicht fällig wird.

Sehe ich das alles richtig?

Eine Frage taucht außerdem bei mir auf. Wie reagieren die Extensions auf diese Anpassung? Hast Du Erfahrungen damit?

Wäre nett, nochmal von Dir zu hören.

Gruß

kanticus

Hallo Kanticus

Es ist einfacher als du denkst! (Und ich bis gestern Nacht gedacht habe...) Ab der Version 4.1 speichert MySQL intern alles in UTF-8. Wenn weder forceCharset noch setDBInit gesetzt sind, kommunizieren Typo3 und MySQL in latin-1, wobei MySQL die Konvertierung der Zeichen automatisch erledigt. Die "Collate" Eigenschaft betrifft nur die Sortierung und nicht die Speicherung von Daten in MySQL.

Sobald du beide Optionen umstellst, kommunizieren Typo3 und MySQL über UTF-8 - der Umweg über latin-1 entfällt. Das funktioniert bei den Seiteninhalten und auch bei den Extensions.

Ärgerlich ist bloss, wenn nur eine der beiden Optionen gesetzt ist - in diesem Fall sprechen Typo3 und MySQL unterschiedliche Sprachen. Das ist mir leider auch passiert - meine einzige Lösung dafür war es, einen Dump der Version zurückzuspielen, als noch beide Optionen deaktiviert waren.
Am Besten ist es, gleich von Anfang an beide zu setzen.

Hoffe das hilft dir weiter...

Gruss, Dave

Waaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa #angry# #angry#
Wieso lese ich das erst jetzt - waaaaaaaaaaaaaaa

Ich hab vorgestern eine Seite auf UTF-8 umgestellt. Dafür habe ich mit recode das sql-File recoded, hab das SQL-File neu eingespielt und bin danach jede Seite durch gegangen, weil recode keine ß und keine Ü recodiert hat. Bei ~100 Seiten +300 Bilder in DAM war das eine scheiß Arbeit.

Heute wunder ich mich, wieso in phpmyadmin alles so komisch ausschaut, google ein bisschen und finde diesen Thread. setDBInit schnell in die conf eingetragen und siehe da - alle Änderungen waren für die Katz! Wuäh!

Wieso steht das denn nirgends so FETT wie möglich? Narf!

Eine weitere Beobachtung dazu.

Setzt man, wie oben beschrieben, die Installtion in UTF-8 auf, ergibt sich bei der Nutzung von externen Dateien über INCLUDE TYPOSCRIPT ein Problem. Enthält diese Datei Strings, muss sie natürlich in utf-8 kodiert sein, damit diese in den Seiten richtig dargestellt werden. Dies klappt auch einwandfrei. TSOB mag allerdings den Code aus dieser Datei nicht und meldet ihn als fehlerhaft. Speichert man die externe Datei in ISO ist er still. Die Seiten weisen dann jedoch Kodierungsfehler auf.

Weiß nicht, wie gravierend diese Fehlermeldungen des TSOB sind und ob daraus Verarbeitungsfehler resultieren können.

Vielleicht können die Programmierer unter Euch dies mal kommentieren.

Hi, doofe Frage dazu: Wie äußert sich das? Wo und wie zeigt der Objectbrowser, dass die Dateien fehlerhaft sind? Ich hab auch alle .ts files auf utf-8 umgestellt. Bisher sieht aber alles i.O. aus. Wo würde TSOB denn die Fehler anzeigen?

Wenn Du im Template Modul im Menü TSOB wählst und der TSOB Syntax-Fehler im TS findet, blendet er in rot:

Errors and warnings
1: Line 1617: The script is short of 1 end brace(s)

Klaue doch mal einfach eine schließende Klammer in Deinem TS irgendwo, dann machst Du damit Bekanntschaft. (nicht vergessen, die Klammer wieder hinterher zu ergänzen!)

Genau hier motzt Typo3 bei mir die INCLUDES an.