UTF8 und PHP
0 
Felix Riesterer
0
UTF8 und PHP
Hola!
Wieder einmal ne Frage zu Zeichencodierungen... allerdings nur kurz:
Kann ich irgendwelche Probleme bekommen wenn ich meine php-Files im Editor als utf8 codiert abspeichere? (Ich meine irgendwas von mangelnder utf8-Unterstützung in php gelesen zu haben) Oder kann ich dann aus den vollen Vorteilen schöpfen, da meine erstellten html-Seiten ja schon als utf8-kodiert ausgegeben werden und ich dann nicht mehr immer hin und her konvertieren muss? (z.B. bei POST/GET parametern)
Danke für Klären.
Gruss
stewe
-
Lieber stewe,
grundsätzlich gilt: Die Zeichenkodierung Deiner PHP-Scripte ist eine Sache, die Zeichenkodierung des generierten HTML-Codes eine (davon in Teilen abhängige) andere. Die Zeichenkodierung der GET- bzw. POST-Werte ist davon abhängig, welche Zeichenkodierung im HTTP-Header (bzw. im passenden <meta>-Element) für das HTML-Dokument angegeben wurde, denn dazu passend sendet der Browser die Daten kodiert ab.
Faustregel: Verwende in allem UTF-8, dann sollte alles zueinander kompatibel sein. PHP-Script in UTF-8 (ohne BOM!) gespeichert, die HTML-Templates ebenso, JavaScript-Dateien sowieso nur in UTF-8 und eventuelle DB-Einträge auch.
Solltest Du in Sachen Daten von und zur DB in Enkodierungsprobleme tappen, hilft Dir das Forumsarchiv weiter.
Die sogenannte mangelnde UTF-8-Unterstützung in PHP macht sich dann bemerkbar, wenn Du Strings mit Sonderzeichen manipulieren willst. So ist z.B.
echo strtolower("AÖÜ"), strtoupper("äöüß");nicht ganz unproblematisch, da intern die Sonderzeichen je nach Einstellung der LOCALES nicht mitkodiert werden. Jedoch hilft hier das Handbuch (und die dort vermerkten User Comments) kompetent weiter.Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)-
Moin!
Die Zeichenkodierung der GET- bzw. POST-Werte ist davon abhängig, welche Zeichenkodierung im HTTP-Header (bzw. im passenden <meta>-Element) für das HTML-Dokument angegeben wurde, denn dazu passend sendet der Browser die Daten kodiert ab.
Naja, so ungefähr. Wenn man im Formular das Attribut accept-charset nutzt, sendet der Browser in dieser Zeichenkodierung. Hier etwas anderes anzugeben als für die ausgegebene Seite ist allerdings sehr unsinnig. Und insgesamt etwas anderes als UTF-8 zu nutzen ist auch nicht sehr schlau... Aber man kann es tun.
Die sogenannte mangelnde UTF-8-Unterstützung in PHP macht sich dann bemerkbar, wenn Du Strings mit Sonderzeichen manipulieren willst. So ist z.B.
echo strtolower("AÖÜ"), strtoupper("äöüß");nicht ganz unproblematisch, da intern die Sonderzeichen je nach Einstellung der LOCALES nicht mitkodiert werden. Jedoch hilft hier das Handbuch (und die dort vermerkten User Comments) kompetent weiter.Korrekt, alle Stringmanipulationen - inklusive regulären Ausdrücken - sind in PHP problematisch, wenn man nicht drüber nachgedacht hat, was man eigentlich genau will.
strlen() liefert beispielsweise immer die Anzahl der Bytes im String. Das ist bei UTF-8 aber nicht gleich der Anzahl der Zeichen.
PHP hat aber intern kein Problem, beispielsweise Funktions- und Variablennamen mit Sonderzeichen (also aus dem Nicht-ASCII-Bereich, ab Codepoint 128 aufwärts) zu verwenden. Die UTF-8-Kodierung sorgt ja gerade dafür, dass beispielsweise Umlaute in zwei für menschen komisch aussehende, aber technisch absolut ungefährliche Zeichen aufgespalten werden.
Das einzige Problem hierbei wäre, wenn man in einem UTF-8-codierten PHP-Skript eine Datei includiert, die z.B. ISO-8859-1-kodiert ist, und beide Dateien nutzen die Variable
$änderung- das ist wegen des Codierungsunterschieds für den Umlaut nicht dieselbe Variable!Aber das Vermeiden von Umlauten in allem, was eventuell Konflikte verursachen könnte (Variablen, Dateinamen, URLs,...), ist Programmierern ja schon irgendwie angeboren. ;)
- Sven Rautenberg
-
strlen() liefert beispielsweise immer die Anzahl der Bytes im String. Das ist bei UTF-8 aber nicht gleich der Anzahl der Zeichen.
Das ist nicht ganz richtig, strlen liefert die Länge des gegebenen Strings und das ist so (lt. Doku) gedacht: "Returns the length of the given string." und keineswegs die Anzahl der Bytes im String.
Die Funktion ist aber eben leider nicht multibyte safe und liefert daher bei UTF-8 falsche Ergebnisse.
Das hat man bei vielen Funktionen behoben, indem man einfach eine Extension zur Verfügung stellt, die aber nicht per default enhalten ist.
Im Falle von strlen() ist das mb_strlen().
Mit PHP 6 wird aber afaik dieser Fehler korrigiert und die betreffenden Funktionen, die jetzt eine mb_-Variante haben, werden Multibyte-Safe.
Man darf sich also auf _keinen Fall_ darauf verlassen, dass strlen() die Anzahl der Bytes in einem geegebenen String zählt bzw. dass das immer so bleiben wird.
-
Moin!
Mit PHP 6 wird aber afaik dieser Fehler korrigiert und die betreffenden Funktionen, die jetzt eine mb_-Variante haben, werden Multibyte-Safe.
PHP 6 ist gerade wieder ganz heftig im Umbruch. Das Entwicklerteam hat nach einer längeren Zeit des Stillstands und der Tendenz, noch mal eine Version 5.4 anzugehen, offenbar die Entscheidung getroffen, die Unicode-Fähigkeiten komplett anders zu realisieren, als bislang getan.
Heißt also: Alle Vermutungen und Hinweise, die bislang für PHP 6 galten, dürften eventuell obsolet werden.
Man darf sich also auf _keinen Fall_ darauf verlassen, dass strlen() die Anzahl der Bytes in einem geegebenen String zählt bzw. dass das immer so bleiben wird.
Doch, ich glaube schon, dass man sich darauf verlassen könnte. Alle derzeitigen PHP-Versionen (3, 4, 5) machen das so, für korrektes Multibyte-Handling existiert mb_strlen(). Das Funktions-Overloading, was die Extension anbietet, würde zwar grundsätzlich strlen() auf mb_strlen() mappen und somit echte Zeichen, und nicht Bytes, zählen, aber die Praxistauglichkeit dieses Overloadings ist dann doch eher kritisch zu betrachten. Man kann nicht Code, der sich um Multibyte-Encodings nicht schert, einfach durch Überladen von Stringfunktionen multibyte-fähig machen - das funktioniert nur eventuell, nicht aber garantiert.
- Sven Rautenberg
-
-
Hi!
Wenn man im Formular das Attribut accept-charset nutzt, sendet der Browser in dieser Zeichenkodierung. Hier etwas anderes anzugeben als für die ausgegebene Seite ist allerdings sehr unsinnig. Und insgesamt etwas anderes als UTF-8 zu nutzen ist auch nicht sehr schlau... Aber man kann es tun.
Das Attribut accept-charset wird nicht von allen bedeutsamen Browsern korrekt beachtet, also kann man es genauso getrost vergessen, wie beispielsweise ­.
Lo!
-
Kitaitirivi!
Das Attribut accept-charset wird nicht von allen bedeutsamen Browsern korrekt beachtet, also kann man es genauso getrost vergessen, wie beispielsweise ­.
Wieso ­ vergessen? Die Version des Konquerors, die doof genug war, den Bindestrich immer anzuzeigen, auch mitten in der Zeile, verstaubt längst im Museum. Es können noch ein paar alte Geckos unterwegs sein, die den ­ ignorieren, aber in denen sieht das Schriftbild ja auch nicht schlechter aus als wenn Du ihn wegläßt. Die aktuellen Versionen aller Browser behandeln ihn korrekt.
Ich bin mir nur hinsichtlich SEO nicht ganz sicher, würde aber erwarten, daß die Suchmaschinen »Beispiel« und »Bei­spiel« als gleich erkennen.
Viele Grüße vom Længlich
--
Mein aktueller Gruß ist:
Apurucayali (gesprochen in Perú)-
Hi!
Das Attribut accept-charset wird nicht von allen bedeutsamen Browsern korrekt beachtet, also kann man es genauso getrost vergessen, wie beispielsweise ­.
Wieso ­ vergessen? [...] Die aktuellen Versionen aller Browser behandeln ihn korrekt.
O.K., dann ziehe ich diese Bemerkung zurück und update mein Wissen.
War Firefox mit Version 3.0 der letzte, der die Implementation vorgenommen hat oder gabe es ein anderes Schlusslicht?Ich bin mir nur hinsichtlich SEO nicht ganz sicher, würde aber erwarten, daß die Suchmaschinen »Beispiel« und »Bei­spiel« als gleich erkennen.
Zumindest gibt es wohl bei der Browser-internen Suchfunktion noch ein Problem: http://aktuell.de.selfhtml.org/weblog/bedingter-zeilenumbruch-shy.
Lo!
-
Chisáhmín!
Wieso ­ vergessen? [...] Die aktuellen Versionen aller Browser behandeln ihn korrekt.
O.K., dann ziehe ich diese Bemerkung zurück und update mein Wissen.
War Firefox mit Version 3.0 der letzte, der die Implementation vorgenommen hat oder gabe es ein anderes Schlusslicht?Meines Wissens war Gecko der letzte, ja.
Ich bin mir nur hinsichtlich SEO nicht ganz sicher, würde aber erwarten, daß die Suchmaschinen »Beispiel« und »Bei­spiel« als gleich erkennen.
Zumindest gibt es wohl bei der Browser-internen Suchfunktion noch ein Problem: http://aktuell.de.selfhtml.org/weblog/bedingter-zeilenumbruch-shy.
Hmm, die Kommentare sind alle über 2 Jahre alt, und einer sagt, daß es im Opera damals schon gefixt wurde. Müßte man mal wieder durchtesten.
Ich finde es aber offen gestanden auch gar nicht so extrem schlimm: Ich würde den ­ ja auf keinen Fall nach jeder Silbe setzen wollen, sondern nur in zusammen­gesetzten Ungetümen, und ich denke mal, daß die meisten User da nur so lange tippen, bis schon das richtige gefunden wird, was meistens vor dem ersten ­ passieren sollte.
Viele Grüße vom Længlich
--
Mein aktueller Gruß ist:
Alabamu (gesprochen in Texas)
-
-
-
-
-
Salut Vinzenz!
Alles klar - dann ist das jetzt geklärt für mich. Mir war bis vor kurzem gar nicht bewusst, dass die PHP-Files natürlich auch ihre eigene Kodierung haben und hab dann festgestellt, dass mein Editor des Vertrauens einige Files automatisch als utf-8 abgespeichert hat, weil da hardgecodete Umlaute und anderes vorkamen und andere als iso westeuropäisch, was bis dahin des Editors Standard war. Entsprechend habe ich mich da jetzt gefragt, ob ich allenfalls noch irgendwo in Probleme laufen könnte, aber dann is ja alles klar.
Das Ding mit den multibyte strings ist allerdings schon mühsam^^ Wäre doch bestimmt machbar gewesen, den altbekannten string funktionen in neueren PHP-versionen einfach die volle mb-Unterstützung mitzugeben, mit nem optionalen Zusätzlichen Kodierungsparameter zum Beispiel..
Gruss und Vielen Dank!
stewe
ps. Probleme mit Umlauten in der DB hab ich wirklich - allerdings liegt das daran dass der DB-Betreiber irgend n'Chaos mit den Kodierungen gemacht hat und es teilweise nicht geschafft hat, die Daten fehlerfrei in die Datenbank zu laden.. Da sieht dann "Unterstützung" schon mal so aus: "Unterst?tzung" Mühsam...
Hat mysql eigentlich eine eigene für Kodierungen zuständige Komponente zur Umwandlung von Datensätzen oder hat die Kodierungsinformation rein informelle Zwecke?-
Hi!
Das Ding mit den multibyte strings ist allerdings schon mühsam^^ Wäre doch bestimmt machbar gewesen, den altbekannten string funktionen in neueren PHP-versionen einfach die volle mb-Unterstützung mitzugeben, mit nem optionalen Zusätzlichen Kodierungsparameter zum Beispiel..
So einfach ist die Geschichte nun auch wieder nicht zu lösen. Um das Problem grundlegend zu sanieren, ist ein Major-Update erforderlich, weswegen ja auch erst PHP6 dafür geplant ist. Es reicht ja nicht nur, ein paar Stringfunktionen zu überarbeiten, da muss jede Funktion untersucht werden, ob Anpassungen vorgenommen werden müssen.
Hat mysql eigentlich eine eigene für Kodierungen zuständige Komponente zur Umwandlung von Datensätzen oder hat die Kodierungsinformation rein informelle Zwecke?
Da MySQL die Daten sortiert zurückgeben sowie andere Stringbearbeitung können muss, ist die Kenntnis der Bedeutung des "Datenhaufens" und damit der Zeichen und iherer Kodierung wichtig. Wenn wegen eines Fehlers beim Umgehen mit den Kodierungen die Daten nicht ordnungsgemäß abgelegt wurden, kann MySQL keine korrekten Ergebnisse liefern.
Lo!
-
Das Ding mit den multibyte strings ist allerdings schon mühsam^^ Wäre doch bestimmt machbar gewesen, den altbekannten string funktionen in neueren PHP-versionen einfach die volle mb-Unterstützung mitzugeben, mit nem optionalen Zusätzlichen Kodierungsparameter zum Beispiel..
Und damit die Abwärtskompatiblität zu allen Verwendungen der Funktionen brechen, die davon ausgehen, dass diese Funktionen 1 Zeichen = 1 Byte liefern? In PHP 6 wird das so gemacht, das bedeutet aber in vielen Fällen ein kleines Refactoring, damit die Scripte ordentlich laufen: < http://forum.de.selfhtml.org/my/?t=196441&m=1316191>
ps. Probleme mit Umlauten in der DB hab ich wirklich - allerdings liegt das daran dass der DB-Betreiber irgend n'Chaos mit den Kodierungen gemacht hat und es teilweise nicht geschafft hat, die Daten fehlerfrei in die Datenbank zu laden.. Da sieht dann "Unterstützung" schon mal so aus: "Unterst?tzung" Mühsam...
Das glaub ich weniger, ich denke eher dass du vergessen hast, der Datenbank zu sagen, in welcher Codierung du mit ihr sprichst - im Fall MySQL wäre das SET NAMES.
Hat mysql eigentlich eine eigene für Kodierungen zuständige Komponente zur Umwandlung von Datensätzen oder hat die Kodierungsinformation rein informelle Zwecke?
Afaik beides - einerseits ist die Codierung wurst, weil in der Datenbank ohnehin nur Bytes herumliegen (natürlich vom Datentyp abhängig) - anderseits kannst du der Datenbank sehrwohl sagen, wie du die Daten gerne haben möchtest.
Das hat aber dann zur Folge, dass du bei falscher Angabe dieser Daten Zeichen zerstörst oder in eine unleserliche form bringst.
Unterstützung in ANSI sieht mit UTF-8 eben meistens nach Unterst?tzung aus während Unterstützung in UTF-8 als ANSI betrachtet z.B. wie Unterstützung aussieht.
Es ist halt ein Unterschied, was tatsächlich in der Datenbank steht:
ANSI: 55 6E 74 65 72 73 74 FC 74 7A 75 6E 67
UTF-8: 55 6E 74 65 72 73 74 C3 BC 74 7A 75 6E 67-
Und damit die Abwärtskompatiblität zu allen Verwendungen der Funktionen brechen, die davon ausgehen, dass diese Funktionen 1 Zeichen = 1 Byte liefern? In PHP 6 wird das so gemacht, das bedeutet aber in vielen Fällen ein kleines Refactoring, damit die Scripte ordentlich laufen: https://forum.selfhtml.org/?t=196441&m=1316191
Naja, wenns über einen zusätzlichen optionalen Parameter laufen würde, könnte bei allen alten Funktionen wo der Parameter nicht angegeben ist der Default=alte Funktionsweise greifen...
Das glaub ich weniger, ich denke eher dass du vergessen hast, der Datenbank zu sagen, in welcher Codierung du mit ihr sprichst - im Fall MySQL wäre das SET NAMES.
Ich zieh meinen Schluss aus der Tatsache, dass ich einige "Wörter" korrekt mit den Umlauten bekomme, andere "W?rter" hingegen nicht. Folglich Datenbankseitiges Problem..
Das hat aber dann zur Folge, dass du bei falscher Angabe dieser Daten Zeichen zerstörst oder in eine unleserliche form bringst.
Das heisst also, dass bei Veränderung der "Kollation" einer Spalte etc nicht nur die DB die Daten anders liest, sondern die Daten zuerst auch von der alten Angabe in die Neue konvertiert werden?
Gruss
stewe
-
Und damit die Abwärtskompatiblität zu allen Verwendungen der Funktionen brechen, die davon ausgehen, dass diese Funktionen 1 Zeichen = 1 Byte liefern? In PHP 6 wird das so gemacht, das bedeutet aber in vielen Fällen ein kleines Refactoring, damit die Scripte ordentlich laufen: https://forum.selfhtml.org/?t=196441&m=1316191
Naja, wenns über einen zusätzlichen optionalen Parameter laufen würde, könnte bei allen alten Funktionen wo der Parameter nicht angegeben ist der Default=alte Funktionsweise greifen...Natürlich, aber eine solch tiefgreifende Änderungen in einer Programmiersprache werden ausreichend diskutiert - wie Sven geantwortet hat, schein mein Informationsstand bez. PHP 6 auch nicht mehr aktuell zu sein.
Ich zieh meinen Schluss aus der Tatsache, dass ich einige "Wörter" korrekt mit den Umlauten bekomme, andere "W?rter" hingegen nicht. Folglich Datenbankseitiges Problem..
Warum, vielleicht fütterst du die Datenbank mal richtig und mal falsch.
Das hat aber dann zur Folge, dass du bei falscher Angabe dieser Daten Zeichen zerstörst oder in eine unleserliche form bringst.
Das heisst also, dass bei Veränderung der "Kollation" einer Spalte etc nicht nur die DB die Daten anders liest, sondern die Daten zuerst auch von der alten Angabe in die Neue konvertiert werden?
Die Kollation betrifft afaik nur die Sortierung und hat mit der Zeichencodierung (Charset) nur indirekt zu tun: http://dev.mysql.com/doc/refman/5.0/en/charset-server.html
-
Natürlich, aber eine solch tiefgreifende Änderungen in einer Programmiersprache werden ausreichend diskutiert
Ja dies macht natürlich Sinn - sonst muss mans dann alle 6 Monate wieder ändern und nach 3 Jahren benützt niemand mehr PHP :)
Warum, vielleicht fütterst du die Datenbank mal richtig und mal falsch.
Ähm, so viel Vertrauen darfst du durchaus auch noch in nen Fremden haben. - Ich würde dieses Statement nicht machen, wenn der Aufbau der Verbindung nicht immer gleich erfolgen würde. (Wobei noch dazukommt, dass sogar in der gleichen Abfrage im gleichen Resultat manche Felder richtig(ö), andere falsch(?) kodiert sind. Genauso bei Ansicht in phpMyAdmin. Jetzt überzeugt? )
Die Kollation betrifft afaik nur die Sortierung und hat mit der Zeichencodierung (Charset) nur indirekt zu tun: http://dev.mysql.com/doc/refman/5.0/en/charset-server.html
Dem selfhtml-Artikel zufolge, den dedlfix verlinkt hat, scheint solch eine Umwandlung tatsächlich stattzufinden.
gruss
stewe
-
Ich mein... wenn ich für die Sucheingabe "H?nde" die entsprechenden Inhalte finde, dann stimmt schon was nicht, oder? :) Ich überlege mir gerade ernsthaft, solange das nicht gefixt ist, einfach auch gleich mal ne zweite Suche zu starten, wo die Umlaute mit nem ? ersetzt sind :D
-
Hi!
Warum, vielleicht fütterst du die Datenbank mal richtig und mal falsch.
Ähm, so viel Vertrauen darfst du durchaus auch noch in nen Fremden haben.Die Fragen hier im Forum zu diesem Thema zeigen immer wieder, dass man dieses Vertrauen nicht haben kann, weil immer wieder zwar die Feldkodierung gefunden und eingestellt wird, aber nicht bekannt ist, dass man nach dem Verbindungsaufbau die Kodierung aushandeln sollte, die man zu verwenden gedenkt, sonst nimmt der Server eienn Defaultwert und das kann chaotisch werden.
Ich würde dieses Statement nicht machen, wenn der Aufbau der Verbindung nicht immer gleich erfolgen würde. (Wobei noch dazukommt, dass sogar in der gleichen Abfrage im gleichen Resultat manche Felder richtig(ö), andere falsch(?) kodiert sind. Genauso bei Ansicht in phpMyAdmin. Jetzt überzeugt? )
Der PMA macht es üblicherweise richtig, er verhandelt die Verbindungskodierung. Wenn du darüber Daten einpflegst und mit deinem Programm ausgelesen falsch siehst, dann hast du deine Verbindungskodierung nicht ausgehandelt und bekommst die Datein in einer Kodierung, die du nicht erwartest. Wenn du ? bekommst, dann ist bei der Umkodierung ein Datenverlust aufgetreten, weil ein bestimmtes Zeichen mit Zielkodierung nicht kodiert werden kann.
Wenn du andererseits eine Kodierung verwendest und MySQL aufgrund einer Default-Einstellung eine andere annimmt, kann es natürlich aus dem Bytestrom nicht die richtigen Zeichen interpretieren. Als Folge siehst du im PMA was falsches, weil MySQL es aufgrund deiner nicht erfolgten Verbindungskodierungsaushandlung nicht besser weiß.
Wenn jetzt jemand deinen Aussagen bezüglich Richtigmachens Glauben schenken soll, müsstest du mal bestätigen, dass du mysql(i)_set_charset() oder ein "SET NAMES"-Statement nach jedem Verbindungsaufbau ausführst, dass genau deine verwendete Kodierung einstellt. Dann hätte man in diesm Punkte Klarheit und kann nach anderen Fehlerursachen suchen.
Lo!
-
Holla!
weil immer wieder zwar die Feldkodierung gefunden und eingestellt wird, aber nicht bekannt ist, dass man nach dem Verbindungsaufbau die Kodierung aushandeln sollte
Ja, dies war für mich auch neu, aber darum gehts ja nicht, dadurch entstehen andere Probleme (mit in der DB richtig abgelegten Daten).
->siehe untenund mit deinem Programm ausgelesen falsch siehst, dann hast du deine Verbindungskodierung nicht ausgehandelt und bekommst die Datein in einer Kodierung, die du nicht erwartest.
Du hast vermutlich nicht richtig gelesen. Wie gesagt, sind die Daten auch bei Ansicht in PMA teilweise falsch (W?rter), teilweise richtig (Wörter). Es geht nicht um mein eigenes Programm und ein Problem beim Auslesen der Daten. Entsprechend findet er auch bei einem PMA-internen Query (Wort='B?r') den B?r, mit (Wort='Bär') aber gar nichts. Folglich sind die Daten teilweise so in der DB abgelegt, was wohl bei falschen Kodierungsvorgängen bei der Erstellung passiert sein dürfte - Die DB wurde von einer anderen Person erstellt. Und hierauf bezog sich auch mein Statement, das angezweifelt worden ist und zu dieser ganzen Diskussion geführt hat.
müsstest du mal bestätigen, dass du mysql(i)_set_charset() oder ein "SET NAMES"-Statement nach jedem Verbindungsaufbau ausführst,
etwa so?
mysql_set_charset('utf8', $DbLink);:)Gruss
stewe :)
-
Hi!
weil immer wieder zwar die Feldkodierung gefunden und eingestellt wird, aber nicht bekannt ist, dass man nach dem Verbindungsaufbau die Kodierung aushandeln sollte
Ja, dies war für mich auch neu, aber darum gehts ja nicht, dadurch entstehen andere Probleme (mit in der DB richtig abgelegten Daten).Das ist aber einer der entscheidenden Punkte, wie man solche Fehler in Zukunft vermeidet. Und dass du nun dieses Wissen dazugewonnen hast, ist ja auch schon mal was Wert.
und mit deinem Programm ausgelesen falsch siehst, dann hast du deine Verbindungskodierung nicht ausgehandelt und bekommst die Datein in einer Kodierung, die du nicht erwartest.
Du hast vermutlich nicht richtig gelesen. Wie gesagt, sind die Daten auch bei Ansicht in PMA teilweise falsch (W?rter), teilweise richtig (Wörter).Dann ist trotzdem die Verbindungskodierung eine mögliche Ursache für Fehler. Ich kenne ja deine Konstellation nicht, kann also nur anhand der bisherigen Erfahrungen raten. Aber gut, die W?rter sind versaut und aller Wahrscheinlichkeit nach auch nicht mehr zu retten, aber die im PMS zu sehenden Wörter müsstest du lassen können und auch über den PMA oder andere Programme mit ordentlich ausgehandelter Kodierung finden.
müsstest du mal bestätigen, dass du mysql(i)_set_charset() oder ein "SET NAMES"-Statement nach jedem Verbindungsaufbau ausführst,
etwa so?mysql_set_charset('utf8', $DbLink);:)Ja, gut so. Es lohnt ja nicht, die Umlaute händisch zu korrigieren, wenn die Ursache bleibt und immer wieder neue Fragezeichen im DBMS landen.
Lo!
-
Hola!
Und dass du nun dieses Wissen dazugewonnen hast, ist ja auch schon mal was Wert.
Absolut. Man lernt immer gerne.
Ja, gut so. Es lohnt ja nicht, die Umlaute händisch zu korrigieren
Das kommt bei diesen Datenmengen sowieso nicht in Frage.. Ausser ich wür mir n'Moment Zeit nehmen und ein Skript schreiben, das mir die Korrektur erleichtern würde.
Auf jeden Fall muss ich mir mal den Ersteller vornehmen..
Gruss
stewe
-
-
-
-
-
-
Hi!
Ich zieh meinen Schluss aus der Tatsache, dass ich einige "Wörter" korrekt mit den Umlauten bekomme, andere "W?rter" hingegen nicht. Folglich Datenbankseitiges Problem..
Wenn A auf Englisch eingestellt ist, B aber deutsch redet, wessen Problem ist es dann? A's, weil er von B nicht mitgeteilt bekommt, dass die Daten deutsch sind, oder B's, weil er falsche Daten von A bekommt?
Das hat aber dann zur Folge, dass du bei falscher Angabe dieser Daten Zeichen zerstörst oder in eine unleserliche form bringst.
Das heisst also, dass bei Veränderung der "Kollation" einer Spalte etc nicht nur die DB die Daten anders liest, sondern die Daten zuerst auch von der alten Angabe in die Neue konvertiert werden?Vielleicht hilft dir dieser Artikel beim Verständnis zum Verhalten MySQLs bezüglich der Zeichenkodierung: http://wiki.selfhtml.org/wiki/Themen:Zeichencodierung/MySQL
Lo!
-
Wenn A auf Englisch eingestellt ist, B aber deutsch redet, wessen Problem ist es dann? A's, weil er von B nicht mitgeteilt bekommt, dass die Daten deutsch sind, oder B's, weil er falsche Daten von A bekommt?
Ähm -super. Erklär mir bitte, wie ein Problem nicht datenbankseitig sein soll, wenn auf immer gleiche Abfragen für gewisse Rows die Ausgabe wunderschön geschieht, bei anderen (immer gleichen) aber Zeichenfehler auftreten? Dann muss dies doch gezwungenermasse an fehlender "Zeichenkodierungskonsistenz" auf Seite der DB liegen.
Entsprechende Felder präsentieren sich übrigens auch in phpMyAdmin mit ?, während dies andere nicht tun...Vielleicht hilft dir dieser Artikel beim Verständnis zum Verhalten MySQLs bezüglich der Zeichenkodierung: http://wiki.selfhtml.org/wiki/Themen:Zeichencodierung/MySQL
Danke für den Link, da steht genau was ich gesagt habe: "Sie kann auch nachträglich geändert werden, wobei die bereits enthaltenen Daten umcodiert werden. "
Gruss
-
Hi!
Wenn A auf Englisch eingestellt ist, B aber deutsch redet, wessen Problem ist es dann? A's, weil er von B nicht mitgeteilt bekommt, dass die Daten deutsch sind, oder B's, weil er falsche Daten von A bekommt?
Ähm -super. Erklär mir bitte, wie ein Problem nicht datenbankseitig sein soll, wenn auf immer gleiche Abfragen für gewisse Rows die Ausgabe wunderschön geschieht, bei anderen (immer gleichen) aber Zeichenfehler auftreten? Dann muss dies doch gezwungenermasse an fehlender "Zeichenkodierungskonsistenz" auf Seite der DB liegen.
Entsprechende Felder präsentieren sich übrigens auch in phpMyAdmin mit ?, während dies andere nicht tun...Eine Erklärung wäre, um ein Beispiel ähnlich dem obigen zu verwenden, wenn A mit dem DBMS englisch spricht, und dies auch ordnungsgemäß jedes Mal mitteilt. Das DBMS weiß nun über die Sprache des Textes Bescheid und kann ihn ordentlich in andere Sprachen übersetzen, wenn diese von irgendjemandem angefordert werden. Wenn B nun allerdings ständig deutsch redet, aber dem DBMS dies nicht mitteilt, geht das DBMS von seiner Default-Einstellung englisch aus und bekommt nun ein Problem beim Interpretieren und übersetzen in andere Sprachen.
Ein Mischmasch tritt dann auf, wenn A und B an der selben Tabelle arbeiten. Dann sind einmal die Daten aus A-Sicht richtig, und ein anderes Mal aus B-Sicht. Wieso sind aber B's deutsche Daten richtig, wenn B sie abfragt, obwohl die Verbindungskodierung auf englisch steht und das DBMS intern Übersetzungen zwischen Verbindung und Feld vornimmt? Nun, in dem Fall hinkt das Beispiel. Mit Zeichenkodierungen ist das in gewissen Konstellationen zwar ohne Datenverlust möglich, jedenfalls wenn B allein arbeitet. Eine Möglichkeit wäre: B sendet UTF-8 (ä=C3A4), MySQL denkt Latin1 (C3=Ã,A4=¤), interpretiert jedes Byte der UTF-8-Bytesequenz eines Zeichens als jeweils eigenes Zeichen und umkodiert das nach UTF-8 (Ã=C383,¤=C2A4) zur Ablage in den Feldern. Auf dem Rückweg zu B wird das wieder nach Latin1 zurückkodiert (C383(UTF-8-Ã)=>C3(Latin1-Ã),C2A4(UTF-8-¤)=>A4(Latin1-¤)), B denkt, es sei UTF-8 (C3A4=ä), und alles scheint richtig. Dass etwas falsch läuft, sieht man erst mit A (bekommt UTF-8: C383=Ã,C2A4=¤ => ä) oder wenn man Sortieren möchte, oder mit CHAR_LENGTH() seitens MySQL die Anzahl der Zeichen zählen will.
Danke für den Link, da steht genau was ich gesagt habe: "Sie kann auch nachträglich geändert werden, wobei die bereits enthaltenen Daten umcodiert werden. "
Das betrifft den Fall, dass Daten in Feldern stehen und die Feldkodierung geändert wird. Dann werden die darin stehenden Daten umkodiert. Das kann natürlich nur dann fehlerfrei stattfinden, wenn zum einen die Daten "damals" beim Einlesen richtig interpretiert werden konnten, jetzt also richtig kodiert abgelegt sind, und zum anderen mit der Zielkodierung alles Zeichen kodiert werden können.
Lo!
-
Salut!
(...)(bekommt UTF-8: C383=Ã,C2A4=¤ => ä) oder wenn man Sortieren möchte, oder mit CHAR_LENGTH() seitens MySQL die Anzahl der Zeichen zählen will.
Wirklich ein interessantes Beispiel.. Voraussetzung für diesen Fall ist allerdings ein mehrfacher (unterschiedlicher A-B) Verbindungsaufbau, der nicht gegeben ist.
Das betrifft den Fall, dass Daten in Feldern stehen und die Feldkodierung geändert wird. (...)
Yup, genau darauf hat sich meine Frage ursprünglich bezogen.
Gruss!
-
-
Ähm -super. Erklär mir bitte, wie ein Problem nicht datenbankseitig sein soll, wenn auf immer gleiche Abfragen für gewisse Rows die Ausgabe wunderschön geschieht, bei anderen (immer gleichen) aber Zeichenfehler auftreten? Dann muss dies doch gezwungenermasse an fehlender "Zeichenkodierungskonsistenz" auf Seite der DB liegen.
Entsprechende Felder präsentieren sich übrigens auch in phpMyAdmin mit ?, während dies andere nicht tun...So wie ich das sehe, bedeutet dies, das du die DB zwar richtig ausließt, das jedoch dort schon Fehler drin sind.
Wie kommen die Daten da rein? Von dir? Wenn ja würde ich an der Stelle ansetzten. Da du ein Mischmasch aus richtig und falsch im PHPmyAdmin hast könnten es auch Altlasten sein.-
Salut!
So wie ich das sehe, bedeutet dies, das du die DB zwar richtig ausließt, das jedoch dort schon Fehler drin sind.
Ja genau dies ist meine Interpretation, die oben angezweifelt wurde und die ganze Diskussion ausgelöst hat :)
Wie kommen die Daten da rein? Von dir?
Leider nicht... Darum auch das "mühsam" im Ausgangsstatement...
Gruss
stewe
-
Ja genau dies ist meine Interpretation, die oben angezweifelt wurde und die ganze Diskussion ausgelöst hat :)
Du verzeihst, wenn man dir hier pauschal unterstellt, dass du etwas falsch machen würdest - ich wage zu behaupten, dass bei Zeichencodierungsproblemen hier in fast alle Fällen der Benutzer/Programmierer Schuld trägt ;)
-
Du verzeihst, wenn man dir hier pauschal unterstellt, dass du etwas falsch machen würdest
Aber sicher doch :) Vor allem waren die daraus folgenden Erläuterungen in anderer Hinsicht durchaus sehr interessant.
- ich wage zu behaupten, dass bei Zeichencodierungsproblemen hier in fast alle Fällen der Benutzer/Programmierer Schuld trägt ;)
Glaube ich auch sofort - Ich selbst habe mich jetzt schon genügend damit herumgeschlagen... Solang man nicht genau weis, wo Kodierungen eine Rolle spielen und wo nicht, ist man immer auf der unsicheren Seite.
Momentan antizipiere ich gerade darauf, einfach mal das betroffene Feld nach ASCII zu konvertieren und wieder zurück nach UTF-8. Dann hab ich bei allen Umlauten nur noch ein '?' in der Datenbank und nicht mehr korrekte und korrumpierte . Und da ich dieses Feld nicht zur eigentlichen Ausgabe, sondern nur zum Auffinden der gesuchten Daten benötige, kann ich dann als Workaround in meiner Suche per php die Umlaute mit ? ersetzen und finde dann auch was ich gesucht habe... :) Zumindest bis der Datensatz vom Ersteller korrigiert worden ist.
Gruss
stewe
-
Ja genau dies ist meine Interpretation, die oben angezweifelt wurde und die ganze Diskussion ausgelöst hat :)
Du verzeihst, wenn man dir hier pauschal unterstellt, dass du etwas falsch machen würdest - ich wage zu behaupten, dass bei Zeichencodierungsproblemen hier in fast alle Fällen der Benutzer/Programmierer Schuld trägt ;)
Prinzipiell ändert meine Aussage nichts daran. Es ist ein Benutzter / Programmierer daran Schuld. Nur halt nicht der, der die Daten ausließt, den PHPmyAdmin macht (im Normalfall) keine Fehler beim auslesen. Sonder der, der die Daten hineinschreibt. Und dort wird einer der von dir beschriebenen Fehler vorhanden sein.
-
-
-
-
-
-
-
-
Hallo Stewe,
Salut Vinzenz!
ich hab' doch noch gar nichts beigetragen und mache auch niemendem ein V für ein F vor ...
... unten wäre noch was offen :-)
Freundliche Grüße
Vinzenz
-
Hallo Stewe,
Salut Vinzenz!
ich hab' doch noch gar nichts beigetragen und mache auch niemendem ein V für ein F vor ...
Hoppala - Hab ich geschlafen? Soll vorkommen... :)
-
-
-
-
moin,
Kann ich irgendwelche Probleme bekommen wenn ich meine php-Files im Editor als utf8 codiert abspeichere?
Dem Code ist das egal. Interessant wirds immer dann, wenn Literale ins Spiel kommen, die in der Script-Datei selbst geschrieben sind und Zeichen enthalten, die mehr als einer 7-bit-Codierung (ASCII) bedürfen. Also Stringvergleiche, Expressions sowie print- oder echo-Anweisungen mit Umlauten u.a. Zeichen wie Euronen.
Noch interessanter wird es sicher, wenn Deine Symbole (Variablennamen, Funktionsnamen...) Umlaute o.a. Zeichen haben, die über die ASCII-Tabelle hinausgehen, siehe dazu die entsprechenden Stellen in der Dokumentation Deiner Scriptsprache.
Hotti