nicht angemeldet
Umlautprobleme
Hallo,
ich habe eine CSV Datei in Openoffice mit UTF-8 gespeichert.
In mysql ebenso mit UTF-8 importiert.
Im html header meines php scripts, das die Daten einliest, habe ich
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
stehen.
Trotzdem kommen die Umlaute nicht.
Wo könnts klemmen?
Viel Grüße
Norbert
-
Hallo,
Wo könnts klemmen?
Der _Webserver_ muss angewiesen werden, die utf-8-Kodierung im HTTP-Header zu senden:
Content-type: text/html; charset=UTF-8
Das muss ersteinmal stimmen, Kontrolle ob der Browser das erkennt, besser ist eine Kontrolle des Headers selbst z.B. mit Live HTTP Headers (FF Plugin). Dann schauen wir mal weiter.
Hotti
-
Hi,
Wo könnts klemmen?
darfst Du .htaccess?
<files "*.*">
AddDefaultCharset utf-8
</files>Gruesse, Joachim
--
Am Ende wird alles gut. -
Hi!
ich habe eine CSV Datei in Openoffice mit UTF-8 gespeichert.
In mysql ebenso mit UTF-8 importiert.
Trotzdem kommen die Umlaute nicht.
Wo könnts klemmen?Vermutlich hast du dem DBMS nach dem Verbindungsaufbau nicht gesagt, in welcher Kodierung es die Daten liefern soll: SELFHTML-Wiki Themen:Zeichencodierung/MySQL
Lo!
-
Prima!
Hab folgende Zeile in meine dbStart.php eingefügt und die Umlaute sind da.
mysql_query('SET NAMES utf8', $ConnectHnd);Vielen Dank
Vermutlich hast du dem DBMS nach dem Verbindungsaufbau nicht gesagt, in welcher Kodierung es die Daten liefern soll: SELFHTML-Wiki Themen:Zeichencodierung/MySQL
Lo!
-
Hi!
Hab folgende Zeile in meine dbStart.php eingefügt und die Umlaute sind da.
mysql_query('SET NAMES utf8', $ConnectHnd);Verwendest du PHP in einer Version kleiner als 5.2.3 oder warum nimmst du nicht mysql_set_charset()?
Lo!
-
Verwendest du PHP in einer Version kleiner als 5.2.3 oder warum nimmst du nicht mysql_set_charset()?
Weil ich nicht sicher sein kann, welches PHP nachher auf dem Server läuft.
Gruß
-
-
-
-
Hallo Norbert,
das liegt an der Mangelhaften Umsetzung der Unicode-Implementation in PHP. Das haben andere Sprachen schon vor etlichen Jahren richtig umgesetzt. Soll sich ja vielleicht in PHP6 ändern. Und deine Datenbank kann auch nur Basic Multilingual Plane. Damit deckt man nur einen Teilbereich vom Unicode ab.
Alles Probleme die man mit anderen Sprachen und Datenbanken nicht hat.
Kay
-
Hi!
das liegt an der Mangelhaften Umsetzung der Unicode-Implementation in PHP.
Nein, denn dann hätte er Probleme beim Stringverarbeiten. Beim unverändernden Durchreichen vom DBMS an den Browser ist das Manko PHPs nicht relevant. Außerdem gibt es die Multibyte-String-Extension, mit der man bereits heute auch Multibyte-Kodierungen bearbeiten kann.
Und deine Datenbank kann auch nur Basic Multilingual Plane. Damit deckt man nur einen Teilbereich vom Unicode ab.
"Nur" ist gut. Das reicht jedenfalls, wenn man nicht gerade einige seltene Sprachen und Musik-Symbole benötigt oder Mahjong und Domino in Textdarstellung spielen will.
Lo!
-
"Nur" ist gut. Das reicht jedenfalls, wenn man nicht gerade einige seltene Sprachen […] benötigt
Du hast mal eben 47000 chinesische Zeichen unterschlagen.
-
Hi!
"Nur" ist gut. Das reicht jedenfalls, wenn man nicht gerade einige seltene Sprachen […] benötigt
Du hast mal eben 47000 chinesische Zeichen unterschlagen.Ja, bewusst. Vielleicht hätte ich statt "Sprachen" genauer "Zeichen" schreiben sollen, dann stimmt die Aussage wieder, denn die gebräuchlichsten CJK-Zeichen sind bereits in der BMP untergekommen.
Lo!
-
-
Hallo,
Beim unverändernden Durchreichen vom DBMS an den Browser ist das Manko PHPs nicht relevant.
Richtig, aber es reicht schon eine nicht richtig übermittelte und benötigte "BOM UTF-8 Codierung" um eine fehlerhafte Darstellung auf dem Display erzeugen zu können.
BOM kann sehr komplex sein. Aber mein Beitrag hatte auch etwas gutes.
Seit heute kenne ich die Unterschiede zwischen utf8_general_ci und utf8_unicode_ci bei MySQL.Kay
-
-
hi Kay,
Alles Probleme die man mit anderen Sprachen und Datenbanken nicht hat.
Irgendwo hastu Recht, naja, ich sags malso: Mit Perl und MySQL muss ich dem Database_Handle NICHT sagen, ob da UTF-8 oder ISO* als Kodierung übertragen werden soll, die Zeichen kommen da mit der Kodierung an, wie sie entweder in MySQL gespeichert sind oder wieder da reinsollen. Zum Administrieren meiner Remote-MySQL-DB benutze ich daher eigene Scripts, die in Perl geschrieben sind, da kann ich auch mal unverfälscht (ohne Browser) und stichprobenartig nachschauen, in welcher Kodierung Zeichen in der DB tatsächlich gespeichert sind.
Viel Spaß weiterhin,
Hotti-
Hi!
Mit Perl und MySQL muss ich dem Database_Handle NICHT sagen, ob da UTF-8 oder ISO* als Kodierung übertragen werden soll, die Zeichen kommen da mit der Kodierung an, wie sie entweder in MySQL gespeichert sind oder wieder da reinsollen.
Dann beobachtest du entweder was Falsches, oder Perl versteckt das Setzen der Verbindungskodierung, oder bei dir funktioniert es mit den gesetzten Default-Angaben, oder es sieht nur aus deiner Sicht so aus, als ob alles richtig läuft. Das Kapitel Character Set Support und speziell Connection Character Sets and Collations gilt generell für MySQL und nicht nur abzüglich Perl.
Zum Administrieren meiner Remote-MySQL-DB benutze ich daher eigene Scripts, die in Perl geschrieben sind, da kann ich auch mal unverfälscht (ohne Browser) und stichprobenartig nachschauen, in welcher Kodierung Zeichen in der DB tatsächlich gespeichert sind.
Kannst du nicht, denn dann müsstest du einen Dateibetrachter verwenden und dir die Datenbankdateien direkt anschauen. Wann immer du zu MySQL eine Verbindung über den offiziellen Weg aufbaust, kann es unter bestimmten in dem verlinkten Kapitel beschriebenen Umständen zu Umkodierungen kommen, von denen man üblicherweise nichts mitbekommt, wenn alles richtig gemacht wird.
Lo!
-
Hi!
Mit Perl und MySQL muss ich dem Database_Handle NICHT sagen, ob da UTF-8 oder ISO* als Kodierung übertragen werden soll, die Zeichen kommen da mit der Kodierung an, wie sie entweder in MySQL gespeichert sind oder wieder da reinsollen.
Dann beobachtest du entweder was Falsches, oder Perl versteckt das Setzen der Verbindungskodierung, oder bei dir funktioniert es mit den gesetzten Default-Angaben, oder es sieht nur aus deiner Sicht so aus, als ob alles richtig läuft. Das Kapitel Character Set Support und speziell Connection Character Sets and Collations gilt generell für MySQL und nicht nur abzüglich Perl.
Es gibt Scripts, da spielt die auf der Engine eingestellte Collation und Charset keine Rolle. Aus einem mit Perl erstellten DB_Handle lese ich bytes. Defaults in allen Ehren, aber die meisten meiner Tabellen benutzen auch bei mir definierte Attribute.
Zum Administrieren meiner Remote-MySQL-DB benutze ich daher eigene Scripts, die in Perl geschrieben sind, da kann ich auch mal unverfälscht (ohne Browser) und stichprobenartig nachschauen, in welcher Kodierung Zeichen in der DB tatsächlich gespeichert sind.
Kannst du nicht, denn dann müsstest du einen Dateibetrachter verwenden und dir die Datenbankdateien direkt anschauen.
Die Konsole oder auch Textpad als Ausgabemedium stelle ich so ein, dass ich erkennen kann, in welcher Kodierung Zeichen ankommen. Wenn die Konsole versucht, 2 bytes einer utf-8-Kodierung als ISO-8859-1 darzustellen, sehe ich das und ich habe darüber hinaus immer noch die Möglichkeit, die bytes als utf-8-kodierte Zeichen darstellen zu lassen.
Wenn ich Probleme mit Zeichenkodierungen wünschte, könnte ich zu einer anderen Sprache als Perl wechseln ;-)
Sch??ne Gr????e,
Hotti-
Hi!
Das Kapitel Character Set Support und speziell Connection Character Sets and Collations gilt generell für MySQL und nicht nur abzüglich Perl.
Es gibt Scripts, da spielt die auf der Engine eingestellte Collation und Charset keine Rolle. Aus einem mit Perl erstellten DB_Handle lese ich bytes.Ja, solche Anwendungsfälle wären, wenn du entweder binäre Daten speicherst oder wenn du zwar UTF-8 sendest, MySQL aber von Latin1 auf der Verbindung ausgeht. In solchen Fällen darf das DBMS aber keine Handlungen vornehmen, bei der die Zeichenkodierung berücksichtigt werden muss. Das einfache Speichern und Abfragen ohne Stringfunktionen und -vergleiche zu verwenden ist prinzipiell problemlos möglich.
Defaults in allen Ehren, aber die meisten meiner Tabellen benutzen auch bei mir definierte Attribute.
Es geht grad nicht um die Konfiguration der Tabellen sondern um die Konfiguration der Verbindung. Und dieses Thema Verbindungskodierung versuchst du schon seit einer geraumen Weile zu ignorieren.
Zum Administrieren meiner Remote-MySQL-DB benutze ich daher eigene Scripts, die in Perl geschrieben sind, da kann ich auch mal unverfälscht (ohne Browser) und stichprobenartig nachschauen, in welcher Kodierung Zeichen in der DB tatsächlich gespeichert sind.
Kannst du nicht, denn dann müsstest du einen Dateibetrachter verwenden und dir die Datenbankdateien direkt anschauen.
Die Konsole oder auch Textpad als Ausgabemedium stelle ich so ein, dass ich erkennen kann, in welcher Kodierung Zeichen ankommen. Wenn die Konsole versucht, 2 bytes einer utf-8-Kodierung als ISO-8859-1 darzustellen, sehe ich das und ich habe darüber hinaus immer noch die Möglichkeit, die bytes als utf-8-kodierte Zeichen darstellen zu lassen.Du gehst davon nach wie vor davon aus, dass MySQL Daten von und zum Client in und aus den Tabellen unverändert durchreicht. Das ist prinzipiell nicht der Fall, weil MySQL Umkodierungen vornehmen kann und wird, wenn das erforderlich ist. Du siehst also nur das, was MySQL dir übermittelt und nicht unbedingt das, was gespeichert ist. Umkodierungen sind nur dann nicht erforderlich, wenn Feldkodierung und Verbindungsodierung auf dem selben Wert stehen. Um ungewünschte Umkodierungen garantiert zu verhindern, ist es erforderlich, die Verbindungskodierung nicht zu ignorieren. Und siehe da, auch Perl hat da was zum einstellen: DBD/mysql mysql_enable_utf8.
Lo!
-
Moin,
..Und siehe da, auch Perl hat da was zum einstellen: DBD/mysql mysql_enable_utf8.
This option is experimental and may change in future versions.
Viele Grüße,
Hotti-
Hi!
..Und siehe da, auch Perl hat da was zum einstellen: DBD/mysql mysql_enable_utf8.
This option is experimental and may change in future versions.Das kann man nun so deuten, dass Perl immer noch nicht in der Lage ist, ordentlich mit MySQL sprechen zu können, obwohl diese Option nun schon seit der Version 3.0007_1 von Sep 2006 des Moduls DBD-mysql enthalten ist. Oder man könnte annnehmen, dass die Dokumentation in dem Punkt nicht richtig gepflegt ist.
Lo!
-
Hi!
..Und siehe da, auch Perl hat da was zum einstellen: DBD/mysql mysql_enable_utf8.
This option is experimental and may change in future versions.Das kann man nun so deuten, dass Perl immer noch nicht in der Lage ist, ordentlich mit MySQL sprechen zu können, obwohl diese Option nun schon seit der Version 3.0007_1 von Sep 2006 des Moduls DBD-mysql enthalten ist. Oder man könnte annnehmen, dass die Dokumentation in dem Punkt nicht richtig gepflegt ist.
Tja, wie das halt so ist mit experimentellen Features, die es auch in Perl gibt. Was jedoch nicht heißt, dass Perl an sich für einen produktiven Einsatz ungeeignet ist. Was MySQL betrifft, ich habe das Gefühl, dass die Entwickler hinsichtlich Zeichenkodierung immer pragmatischer werden.
Wahrscheinlich ist meine Ansicht:
-Charset interessiert nur beim Platzbedarf (Tagging utf-8 => dreimal soviel bytes werden reserviert),
-Collation interessiert nur bei dafür relevanten Zugriffen (z.B. Stringvergleiche),
-ein DB-Handle transportiert Bytes (nicht Zeichen) und ist hinsichtlich Zeichenkodierung transparent.längst überholt. Meine eher byte- als zeichenorientierte Denkweise werde ich jedoch beibehalten, die leistet gerade in Perl gute Dienste ;-)
Auf jeden Fall danke ich Dir für den interessanten Dialog.
Horst Kleinholz-
Hi!
Wahrscheinlich ist meine Ansicht:
-Charset interessiert nur beim Platzbedarf (Tagging utf-8 => dreimal soviel bytes werden reserviert),
-Collation interessiert nur bei dafür relevanten Zugriffen (z.B. Stringvergleiche),
-ein DB-Handle transportiert Bytes (nicht Zeichen) und ist hinsichtlich Zeichenkodierung transparent.
längst überholt.Nun, MySQL hat zwar erst mit Version 4.1 angefangen, UTF-8 kennenzulernen und Collationen zu berücksichtigen, seitdem gilt jedoch, dass die Schnittstelle nicht nur Bytes entgegennimmt sondern wissen möchte, welche Zeichenkodierung der Client zu sprechen gedenkt.
Meine eher byte- als zeichenorientierte Denkweise werde ich jedoch beibehalten, die leistet gerade in Perl gute Dienste ;-)
Das fällt dir für die Fälle unangenehm auf die Füße, wenn du verschiedene Clients auf den MySQL-Server loslassen willst, die - aus welchen Gründen auch immer - nicht alle die selbe Kodierung sprechen (können).
Lo!
-
-
-
-
-
-
-
-