UTF-8 Sorgen

[Bjnas]

Hallo liebes Forum

Nach einigen Webauftritten versuchte ich mal was Neues.

Eine Website mit Formularen, PHP und MySql mit dem Charset Utf8.

Alle möglichen Einstellungen sind gemacht, MySql ,PHP, Content-type alle mit UTF-8 deklariert. Aber es läuft einfach nicht sauber mit den Umlauten. Diese Probleme hatte ich nie bei charset=ISO-8859-1.

Habe es nun hingekriegt das auf der Homepage alles korrekt dargestellt wird, gehe ich aber mit phpMyAdmin 2.11.9.6 in die DB, nur noch kryptische Zeichen zB. Möller statt Müller.
Daten von Formularen muss ich mit utf8_decode($_POST['']) decoden das preg_match sie korrekt vergleicht.

Änderungen über Formularfelder ab Homepage werden danach korrekt dargestellt, anders im phpMyAdmin.

Wie sieht das bei Euch aus, auch solche Probleme? Hab ich was Übersehen?

Bisschen ratlos

Bruno

[dedlfix]

Tach!

Habe es nun hingekriegt das auf der Homepage alles korrekt dargestellt wird,

Das muss noch nichts heißen.

gehe ich aber mit phpMyAdmin 2.11.9.6 in die DB, nur noch kryptische Zeichen zB. Möller statt Müller.

Dann sind deine Daten ins DBMS in einer falschen Kodierung gelangt. Die müssten erstmal so korrigiert werden, dass sie der PMA richtig anzeigt, dann sind sie auch im DBMS richtig eingetragen.

Daten von Formularen muss ich mit utf8_decode($_POST['']) decoden das preg_match sie korrekt vergleicht.

Nein. Das macht erstens deine Bemühungen um UTF-8 für alles jenseits ISO-8859-1 zunichte und zweitens kennen die preg-Funktionen einen Modifizierer/Modifier, der sie UTF-8 verarbeiten lässt.

Wie sieht das bei Euch aus, auch solche Probleme? Hab ich was Übersehen?

Vermutlich. Schau mal auf http://wiki.selfhtml.org/wiki/Themen:Zeichencodierung, besonders den MySQL-Anschnitt.

dedlfix.

[Bjnas]

Danke Dir für die Infos, habs das auch schon gelesen.

Jetzt habe ich mal mein SQL Klasse neu hochgeladen und dort ein Satz eingefügt gehabt.

$this->dbc->set_charset('utf8');

Nun sind die ganzen Umlaute auf der Seite wieder zur SAU.

Also hat die DB obwohl Text Zellen auf UFT8 eingestellt was anderes Reingeschrieben.

Muss man halt nochmal drüber.

Werde wieder berichten.

Danke

[dedlfix]

Tach!

$this->dbc->set_charset('utf8');
Nun sind die ganzen Umlaute auf der Seite wieder zur SAU.
Also hat die DB obwohl Text Zellen auf UFT8 eingestellt was anderes Reingeschrieben.

Ja, weil du bisher dem DBMS nicht gesagt hast, welche Kodierung die Daten haben, die du mit ihm austauschen willst. Wie soll es dann wissen, was es zu tun hat, damit in den Feldern eine bestimmte Kodierung zu liegen kommt? Also hat es wohl gemäß seiner Defaultkonfiguration angenommen, du schickst ihm Latin1. Da die Felder auf UTF-8 konfiguriert sind, bleibt ihm wohl nicht viel mehr übrig, als umzukodieren.

Du sendest UTF-8, MySQL nimmt Latin1 an und kodiert zum Speichern nach UTF-8 um. Ergebnis ist eine "doppelte" UTF-8-Kodierung. Beim Abfragen nimmt es an, es soll die Latin1 schicken, wandelt also das angebliche UTF-8 wieder zurück nach Latin1, du denkst es ist UTF-8 und alles scheint bestens. Die ungewünschte Umkodierung wurde auf dem Rückweg wieder umgekehrt.

dedlfix.

[Bjnas]

Du sendest UTF-8, MySQL nimmt Latin1 an und kodiert zum Speichern nach UTF-8 um. Ergebnis ist eine "doppelte" UTF-8-Kodierung. Beim Abfragen nimmt es an, es soll die Latin1 schicken, wandelt also das angebliche UTF-8 wieder zurück nach Latin1, du denkst es ist UTF-8 und alles scheint bestens. Die ungewünschte Umkodierung wurde auf dem Rückweg wieder umgekehrt.

Ja das macht Sinn, aber was könnte das Verhalten von preg_match hervorrufen.
Ich sende die Daten inkl.  accept-charset="UTF-8" . in der Form.

Wenn ich denn Modifier /u nehme erhalte ich folgende Fehlermeldung zurück.

Warning: preg_match() [function.preg-match]: Compilation failed: invalid UTF-8 string at offset 6

[dedlfix]

Tach!

Ich sende die Daten inkl.  accept-charset="UTF-8" . in der Form.

Daran halten sich nicht alle Browser. Wichtiger ist die Kodierungsangabe der Seite. Die sollte sowieso vorhanden sein, bevorzugt im Content-Type-HTTP-Header (gewinnt immer) oder ersatzweise im gleichnamigen Meta-Element (auch fürs Offline-Speichern wichtig).

Wenn ich denn Modifier /u nehme erhalte ich folgende Fehlermeldung zurück.
Warning: preg_match() [function.preg-match]: Compilation failed: invalid UTF-8 string at offset 6

Dann schau dir mal an, was du da wirklich hast. Mach eine mit urlencode() behandelte Kontrollausgabe. Das ist zwar nicht dafür vorgesehen, eignet sich aber wunderbar.

dedlfix.

[Bjnas]

Danke für Deine Hilfe

Dann schau dir mal an, was du da wirklich hast. Mach eine mit urlencode() behandelte Kontrollausgabe. Das ist zwar nicht dafür vorgesehen, eignet sich aber wunderbar.

Also urlencode() von zB. äöü ergibt %C3%A4%C3%B6%C3%BC aus dem Formular

Das würde ja nach http://www.utf8-zeichentabelle.de/ stimmen. Wieso frisst das Preg_match nicht?

Die Site ist mit header("Content-type: text/html; charset=UTF-8"); per PHP

und content="text/html; charset=utf-8" codiert.

[Bjnas]

Ja Freu, Fehler gefunden

In meinem Hmtl Editor hatte ich zwar UTF-8 eingestellt, aber kopierten und eingefügten Text waren Ascii. Der Fehler kam nicht vom Formularstring sondern vom Suchstring. Als der Code nach UTF-8 konvektiert wurde funktioniert /u und das ohne utf8_decode.

Hoffe jetzt hab i alle Fallstricke gefunden.

Danke

Bruno

[Gunnar Bittersmann]

@@Bjnas:

nuqneH

Ja Freu, Fehler gefunden

In meinem Hmtl Editor hatte ich zwar UTF-8 eingestellt, aber kopierten und eingefügten Text waren Ascii.

Zeichen* sind in ASCII und UTF-8 exakt gleich codiert.

Du meinst vermutlich nicht ASCII, sondern ISO 8859-1.

Qapla'

* das betrifft natürlich nur die in ASCII (7 Bit) codierbaren Zeichen, also U+0000 bis U+007F.

[Bjnas]

@@Bjnas:

nuqneH

Ja Freu, Fehler gefunden

In meinem Hmtl Editor hatte ich zwar UTF-8 eingestellt, aber kopierten und eingefügten Text waren Ascii.

Zeichen* sind in ASCII und UTF-8 exakt gleich codiert.

Du meinst vermutlich nicht ASCII, sondern ISO 8859-1.

Qapla'

* das betrifft natürlich nur die in ASCII (7 Bit) codierbaren Zeichen, also U+0000 bis U+007F.

Das kann schon sein, im Webocton Editor steht halt Ascii/Ansi als Standardeinstellung

[Gunnar Bittersmann]

@@dedlfix:

nuqneH

[Die Kodierungsangabe] sollte sowieso vorhanden sein, bevorzugt im Content-Type-HTTP-Header (gewinnt immer) oder ersatzweise im gleichnamigen Meta-Element

Nicht ersatzweise, sondern zusätzlich.

(auch fürs Offline-Speichern wichtig).

Eben.

Qapla'

[hotti]

hi,

Habe es nun hingekriegt das auf der Homepage alles korrekt dargestellt wird, gehe ich aber mit phpMyAdmin 2.11.9.6 in die DB, nur noch kryptische Zeichen zB. Möller statt Müller.

Es sieht aus wie utf8, aber das sind die Bytes. MySQL kennt also nicht die Kodierung, überzeuge Dich davon, indem Du in ein Select mal die UPPER(feldname)-Funktion einbaust: MySQL wird die Bytes nicht in Großbuchstaben umwandeln. Das macht MySQL erst, wenn bereits beim Insert ausgehandelt wurde, dass Strings mit UTF8-Kodierung kommen, siehe dazu auch die Hinweise von dedlfix (Stichwort: Set Names) und die von ihm geposteten Links dazu.

Hotti

[dedlfix]

Tach!

Habe es nun hingekriegt das auf der Homepage alles korrekt dargestellt wird, gehe ich aber mit phpMyAdmin 2.11.9.6 in die DB, nur noch kryptische Zeichen zB. Möller statt Müller.
Es sieht aus wie utf8, aber das sind die Bytes.

Nein, das sind Zeichen. Der PMA zeigt Zeichen an, weil er mit MySQL die zu verwendende Zeichenkodierung auf seiner Verbindung ausgehandelt hat. Tatsächlich bekommt er die UTF-8-Bytesequenzen der Zeichen à und ¶ gesendet.

Das Fehlerbild kommt zustande, weil MySQL in einem früheren Vorgang von einer Latin1-Kodierung ausgegangen ist, tatsächlich aber UTF-8 gesendet bekam, so dass er die Bytesequenzen als einzeln Zeichen interpretiert hat. Somit sind die Zeichen à und ¶ gespeichert. Je nach konfigurierter Feld-Kodierung sind sie so oder so im Speicher abgelegt.

MySQL kennt also nicht die Kodierung, überzeuge Dich davon, indem Du in ein Select mal die UPPER(feldname)-Funktion einbaust: MySQL wird die Bytes nicht in Großbuchstaben umwandeln.

Dass es aber nicht Bytes sondern Zeichen sind, kannst du mit einem LOWER(feldname) nachvollziehen, denn dann sähest du 㶠statt ö.

dedlfix.