Probleme mit der Kodierung

[Daniel B.]

Hallo Forengemeinde,

ich bin dabei die Homepage von unserem Sportverein auf das Joomla CMS umzustellen. Dort werden die Inhalte per UTF8 kodiert und gespeichert.

Nun haben wir noch ein Script für die Turnier- und Ligaverwaltung welches die Daten per iso-8859-1 kodiert.

Dieses Script möchte ich nun auch auf UTF8 umstellen.
Ich habe bei allen Dateien oben im meta von charset=iso-8859-1" auf charset=utf-8" umgestellt.
Habe die Dateien selber in Dreamweaver von Westeuropäisch auf Unicode (UTF-8) modifiziert.

Dann habe ich die Tabellen des Scripts heruntergeladen und in Dreamweaver auch in UTF8 umgewandelt. Die charset und Kollations-Angaben dort von latin1 auf utf8 geändert.

Dann eine neue DB mit folgenden Angaben erstellt:
Kollation: utf8_general_ci
Zeichensatz / Kollation der MySQL-Verbindung: tf8_general_ci

Im Firefox und IE werden in den Seiten der Ligaverwaltung die Umlaute auch korrekt angezeigt.

Aber unter phpMyAdmin oder wenn ich den Dump herunterlade, dann werden hierbei die Umlaute falsch angezeigt.
z.B.: ü statt ü oder ä statt ä

Ich probier nun schon seit zwei Tagen woran dies liegen könnte.

Wenn ich z.B. die Tabelle von Joomla in phpMyAmin ansehe oder den Dump runterlade, dann werden die Umlaute jeweils korrekt angezeigt.

Wäre für jeden Tipp und Hilfe dankbar!!

Viele Grüße

Daniel

[hotti]

hi,

Wäre für jeden Tipp und Hilfe dankbar!!

Wenn Deine Seite richtig dargestellt wird, kann Dir doch egal sein, was phpMyAdmin da anzeigt, oder? Was der macht ist selbst mir ein Rätsel, besser gesagt: es ist nicht transparent.

Fröhliche Weihnacht,
Horst Haselhuhn

[Daniel B.]

was phpMyAdmin da anzeigt, oder? Was der macht ist selbst mir ein Rätsel

Ja aber auch der Dump unter Dreamweaver wird mit falschen Umlauten angezeigt.

Wenn Deine Seite richtig dargestellt wird, kann Dir doch egal sein

Eigentlich schon, in Zukunft sollen Joomla Tabellen und Ligaverwaltung in einer DB zusammengeführt werden.
Und die Inhalte Joomla bzw. Liga im jeweiligen anderen Script auch angezeigt werden, evtl. gibt es dann wieder Probleme.

Im Liga-Script kommt es ab und an auch mal vor, dass ich eine Änderung direkt in der Datenbank vornehmen muss.

Dies ist im Moment nicht möglich, weder über phpMyAdmin noch über den Dump.

Daher wär es schon schön, wenn man das Ganze doch irgendwie gerade biegen könnten.

Also falls noch Jemand eine Idee hat, da bin ich ganz Ohr ;)

Frohe Weihnachten
Daniel

[hotti]

hi,

Dies ist im Moment nicht möglich, weder über phpMyAdmin noch über den Dump.

Klar, Du brauchst ein DB-Management-Tool, auf dass Du Dich verlassen kannst. Kurz und knapp: Nimm das DB-Managment selbst in die Hand, auf meiner Site steht, wie ich das mache.

Für die Fehlersuche: Schau Dir Datensätze, die Umlaute enthalten, mit verschiedenen Kodierungen an => so kriegst Du ersteinmal raus, in welcher Kodierung die Zeichen in der DB liegen. Gib "show create table tabellenname" aus, da siehst Du, welche Kollation an die DB gebunden ist oder nicht. Da siehst Du auch, mit welcher Zeichenkodierung die Tabelle deklariert ist. Letzteres ist für den Speicherbedarf zuständig. Die Kollation ist nur bei Stringvergleichen wichtig. Kollation und Charset-Flag haben primär mit der Darstellung nichts zu tun, wichtig ist, in welcher Kodierung die Zeichen in der DB liegen und mit welcher Kodierung sie da rein kommen.

Schicke einen HTTP-Header text/html; charset=utf-8 vor dem Formular mit dem Daten erfasst werden. Damit kommen die Zeichen utf-8 kodiert zum Server und damit auch so in die DB. Prüfe die HTTP-HEader mit einem geeigneten Tool, nutze validator.w3.org um Fehler in der Kodierung zu finden.

Viel Erfolg,
Horst Haselhuhn

[dedlfix]

Hi!

Daher wär es schon schön, wenn man das Ganze doch irgendwie gerade biegen könnten.
Also falls noch Jemand eine Idee hat, da bin ich ganz Ohr ;)

Du musst beim Arbeiten mit MySQL im Wesentlichen zwei Dinge beachten: Die Kodierungseinstellung der einzelnen Felder (ja, Felder, jedes einzeln. Tabellen- bzw. Datenbankkodierung sind Defaultwerte für neu angelegte Felder bzw. Tabellen, wenn man dabei keine explizite Angabe macht) und die Kodierung deiner Verbindung (direkt nach dem Connect zu setzen: mysql(i)_set_charset() oder SET NAMES).

Nun musst du nur noch dafür sorgen, dass die Daten, die du sendest, UTF-8-kodiert sind.

Lo!

[dedlfix]

Hi!

Wenn Deine Seite richtig dargestellt wird, kann Dir doch egal sein, was phpMyAdmin da anzeigt, oder?

Kann es nicht. Denn wenn der PMA was falsches anzeigt ist mit ziemlicher Sicherheit davon auszugehen, dass die Daten falsch abgelegt sind.

Was der macht ist selbst mir ein Rätsel, besser gesagt: es ist nicht transparent.

Was ist denn bei quelloffener Software "nicht transparent"? Definiere genauer, welche Probleme du mit ihm hast, dann kann man dir auch sagen, was du verkehrt machst.

Lo!

[hotti]

Hi!

Wenn Deine Seite richtig dargestellt wird, kann Dir doch egal sein, was phpMyAdmin da anzeigt, oder?

Kann es nicht. Denn wenn der PMA was falsches anzeigt ist mit ziemlicher Sicherheit davon auszugehen, dass die Daten falsch abgelegt sind.

Nö. Mein PMA zeigt z.B. Collationen an, die ich gar nicht ins DBMS gesetzt habe.

Was ist denn bei quelloffener Software "nicht transparent"? Definiere genauer, welche Probleme du mit ihm hast, dann kann man dir auch sagen, was du verkehrt machst.

Transparent ist ein Router, der fragt mich nicht, ob und wie er die Frames taggen soll, sondern bringt meine Daten von a nach b. PMA ist in dem Moment nicht transparent, wo er von mir wissen will, ob in meinem Dump, den ich einspielen möchte, die Zeichen utf8 oder latin1 kodiert sind. Nicht transparent ist eine DB-Management-SW, die was anzeigt, was nicht den Tatsachen entspricht. Transparent ist eine DB-Management-SW, die mir einen Dump so einspielt, wie er vorliegt.

Viele Grüße,
Horst Haselhuhn

[dedlfix]

Hi!

Mein PMA zeigt z.B. Collationen an, die ich gar nicht ins DBMS gesetzt habe.

Kannst du das genauer, nachvollziehbarer beschreiben?

Was ist denn bei quelloffener Software "nicht transparent"? Definiere genauer, welche Probleme du mit ihm hast, dann kann man dir auch sagen, was du verkehrt machst.
PMA ist in dem Moment nicht transparent, wo er von mir wissen will, ob in meinem Dump, den ich einspielen möchte, die Zeichen utf8 oder latin1 kodiert sind.

Wieso das? Soll er nicht fragen und raten, was du ihm vorsetzt? Oder soll er irgendwas nehmen, was ihm grad passt (eingestellt ist)?

Nicht transparent ist eine DB-Management-SW, die was anzeigt, was nicht den Tatsachen entspricht. Transparent ist eine DB-Management-SW, die mir einen Dump so einspielt, wie er vorliegt.

Wenn der PMA etwas anzeigt, dann das was konfiguriert ist. Keine Software kann mit absoluter Zuverlässigkeit erraten, was für eine Kodierung vorliegt. Wenn das was konfiguriert ist, nicht mit dem Inhalt übereinstimmt, dann hat irgendjemand Inhalt gesendet, für den die Kodierung nicht ausgehandelt war und der Default-Wert nicht gestimmt hat.

Etwas "so einzuspielen wie es vorliegt" geht nur bei binären Daten, bei dem jedes Byte für sich genommen werden kann und es nicht als Zeichen interpretiert werden muss. Wann immer ein Byte oder eine Bytefolge als Zeichen interpretiert werden soll, muss über die verwendete Kodierung Klarheit herrschen.

Lo!

[hotti]

hi,

Wenn der PMA etwas anzeigt, dann das was konfiguriert ist.

Genau. Was Anderes erwarte ich nicht. Was speziell den PMA betrifft, will ich hier nicht weiter ausdehnen, sonst denkt hier noch einer ich bashe ;-)

Apropos bash: Auch ein gutes Werkzeug in Sachen TroubleShooting bei CharsetIssues. BashUser sollten die .bashrc kennen und wie damit Locale eingestellt werden (LC_COLLATE, LC_CTYPE).

Ansonsten weise ich gerne auf weitere Werkzeuge hin wie tcpdump und validator.w3.org und im Zweifelsfall sollte sich ein Programmierer auch nicht genieren, einen UserInput auch mal in eine Datei zu schicken um zu sehen, was da ankommt.

Diese Hinweise sollten genügen, schönen Abend noch und
viele Grüße an Alle,
Horst Haselhuhn

[Sven Rautenberg]

Moin!

Dann eine neue DB mit folgenden Angaben erstellt:
Kollation: utf8_general_ci
Zeichensatz / Kollation der MySQL-Verbindung: tf8_general_ci

Und "SET NAMES UTF8" als ersten Query nach der DB-Connection gemacht? Oder mysqli_set_charset benutzt?

Aber unter phpMyAdmin oder wenn ich den Dump herunterlade, dann werden hierbei die Umlaute falsch angezeigt.
z.B.: ü statt ü oder ä statt ä

phpMyAdmin arbeitet korrekt. Dein Datenbankschreiben ist falsch. Und weil du beim Lesen den gleichen Fehler umgekehrt machst, passt es auf deinen eigenen Seiten wieder. Ist aber trotzdem falsch, weil beispielsweise Textsuchen oder Sortierungen nicht korrekt funktionieren werden.

- Sven Rautenberg

[Daniel B.]

Und "SET NAMES UTF8" als ersten Query nach der DB-Connection gemacht?

Danke für die Beschreibung, ich wusste gar nicht das DB schreiben und Lesen selber noch kodiert ist. Wieder etwas dazu gelernt.

Ich habe nun in der Klasse der DB Connection SET Names und SET CHARACTER SET eingefügt:

     $this->link_ID=mysql_connect($host,$user,$pw);  
        if (!$this->link_ID) {  
            $this->stop("Keine Verbindung zum Datenbank - Server<br>");  
        }  
		  
		mysql_query("SET NAMES 'utf8'");  
		mysql_query("SET CHARACTER SET 'utf8'");  
		  
        $select=@mysql_select_db($db,$this->link_ID);  
        if(!$select) {  
            $this->stop("Datenbank konnte nicht geoeffnet werden<br>");  
        }

Wenn ich jetzt über ein Formular des Ligascripts einen Eintrag vornehme, dann werden nun in phpMyAdmin und auch im Dump selber die Umlaute richtig dargestellt.

Aber im Script selber werden die Umlaute dieses neuen Eitrags nun nicht richtig dargstellt.

Ich denke dies liegt nun an dem Fehler beim Lesen, kannst Du mir da noch einen Tipp geben, wo ich dies richtig einstelle?

Danke & Gruß Daniel

[dedlfix]

Hi!

Und "SET NAMES UTF8" als ersten Query nach der DB-Connection gemacht?
Ich habe nun in der Klasse der DB Connection SET Names und SET CHARACTER SET eingefügt:

Seltsam: Niemand hier erwähnt SET CHARACTER SET, und wenn dann nur, um davor zu warnen, dass das Verwenden ohne dessen Wirkung verstanden zu haben, zu Datenverlust führen kann. Trotzdem wird es immer wieder gern als zweites dazugeschrieben. Lass es weg, es sein denn, du weißt genau was du tust, wovon aber nicht auszugehen ist, wenn du es direkt nach SET NAMES verwendest. Beide Statements ändern die selben Werte, überschreiben sich damit gegenseitig, jedoch in unterschiedlicher Weise. SET NAMES will man gemeinhin haben, das andere nicht.

Noch besser wäre aber mysql_set_charset(), wenn dir PHP > 5.2 zur Verfügung steht. Mit kleineren Versionen sollte man heute sowieso nicht mehr arbeiten, wenn man sich das aussuchen darf.

Wenn ich jetzt über ein Formular des Ligascripts einen Eintrag vornehme, dann werden nun in phpMyAdmin und auch im Dump selber die Umlaute richtig dargestellt.
Aber im Script selber werden die Umlaute dieses neuen Eitrags nun nicht richtig dargstellt.

Du musst nach jedem Verbindungsaufbau die Kodierung aushandeln, damit jeder der Beteiligten genau weiß, wie der Bytestrom zu interpretieren ist. Wenn du das auch nur einmal weglässt, wird eine Default-Einstellung verwendet und du bekommt zufällig richtig kodierte Daten oder auch nicht.

Ich denke dies liegt nun an dem Fehler beim Lesen, kannst Du mir da noch einen Tipp geben, wo ich dies richtig einstelle?

Wenn die Daten vom DBMS richtig geliefert werden, was mit einer Kontrollausgabe der Bytewerte und einem anschließenden Vergleich mit einer Kodiertabelle überprüft werden kann, dann hast du vermutlich beim Durchreichen an den Browser was verändert oder nicht richtig deklariert. Das von dir im Eingangsposting erwähnte Meta-Element ist nur ein Ersatz für den gleichnamigen HTTP-Header, der Vorrang vor diesem Meta-Element hat.

(Übrigens ist dieses Thema schon zur Genüge nachgefragt und eigentlich auch erschöpfend im Archiv beantwortet worden.)

Lo!

[Daniel B.]

Du musst nach jedem Verbindungsaufbau die Kodierung aushandeln, damit jeder der Beteiligten genau weiß, wie der Bytestrom zu interpretieren ist.

Ja daran lag der Fehler, bei der fehlerhaften Ausgabe, wurde die Abfrage nicht über die DB Klasse gemacht, sondern die DB Abfrage war hartkodiert.

Hab dies nun auch auf die DB Klasse geändert und dann war die Anzeige auf der Seite auch richtig.

Seltsam: Niemand hier erwähnt SET CHARACTER SET

Hab ich wieder gelöscht.
Hatte gesucht wie SET NAMES genau einzubinden ist, und da hatte ich das einfach mitkopiert. Werd ich nicht wieder machen ;)

Danke für die Hilfe.

Gruß Daniel

[Struppi]

Aber unter phpMyAdmin oder wenn ich den Dump herunterlade, dann werden hierbei die Umlaute falsch angezeigt.

Mit welchem Programm betrachtest du die Dumps?

Struppi.