Problem mit Darstellung Typographischer Anführungszeichen

[Niehztog]

Hi,

bei einer ganz normalen PHP Applikation, die Usereingaben in einer Textarea in einer MySQL Datenbank speichert und danach wieder auf einer HTML Seite anzeigt, tritt das Problem auf, dass Typographische Anführungszeichen nicht richtig dargestellt werden können.
Es handelt sich um:
“ (“) und
” (”)

Firefox zeigt anstelle der Anführungszeichen kleine weiße Boxen mit 00/93 bzw. 00/94 an.

Die Seite ist in UTF-8 gehalten. Leider finde ich keine Möglichkeit mit einem str_replace die Anführungszeichen durch ihre HTML-Entity Entsprechungen zu ersetzen.

Hat jemand damit schon Erfahrung?

Gruß
Niehztog

[Gunnar Bittersmann]

@@Niehztog:

Es handelt sich um:
“ (“) und
” (”)

Firefox zeigt anstelle der Anführungszeichen kleine weiße Boxen mit 00/93 bzw. 00/94 an.

Die Seite ist in UTF-8 gehalten.

Vermutlich nicht, sonst würde es keine Probleme geben.

Wird die Seite auch als UTF-8 ausgeliefert? [QA-CHANGING-ENCODING]

Leider finde ich keine Möglichkeit mit einem str_replace die Anführungszeichen durch ihre HTML-Entity Entsprechungen zu ersetzen.

Das solltest du auch nicht tun. [QA-ESCAPES]

Live long and prosper,
Gunnar

[Niehztog]

Die Seite ist in UTF-8 gehalten.

Vermutlich nicht, sonst würde es keine Probleme geben.

Wird die Seite auch als UTF-8 ausgeliefert? [QA-CHANGING-ENCODING]

Ja wird sie. An irgendeiner Stelle muss mit dem encoding was scheif laufen, ich hab keine Ahnung wie man an die Sache rangeht.

Niehztog

[Malcolm Beck´s]

hi,

Wird die Seite auch als UTF-8 ausgeliefert?

Ja wird sie. An irgendeiner Stelle muss mit dem encoding was scheif laufen, ich hab keine Ahnung wie man an die Sache rangeht.

Vielleicht während der Verbindung.

mfg

[EKKi]

Mahlzeit Niehztog,

Firefox zeigt anstelle der Anführungszeichen kleine weiße Boxen mit 00/93 bzw. 00/94 an.

Was steht im Quelltext? Was steht bei anderen Browsern im Quelltext?

Die Seite ist in UTF-8 gehalten.

Und die Datenbank? Und die Verbindung dahin? Und die Tabelle?

MfG,
EKKi

[Niehztog]

Mahlzeit Niehztog,

"Mahlzeit" ;)

Was steht im Quelltext? Was steht bei anderen Browsern im Quelltext?

Im Quelltext zeigt Firefox das gleiche komische Platzhalterzeichen an.
Im Quelltext vom IE7 steht “ bzw. ”

Die Seite ist in UTF-8 gehalten.

Und die Datenbank? Und die Verbindung dahin? Und die Tabelle?

Ja, die Datenbank ist UTF-8, aber die Tabelle bzw. das Entsprechende Feld latin1_german1_ci. Bisher gabs mit Unicode Zeichen aber nie Probeme, weil MySQL Problemlos UTF8 in dem LATIN1 Feld ablegen 8und auch wieder rauskriegen) konnte.

[dedlfix]

echo $begrüßung;

Was steht im Quelltext? Was steht bei anderen Browsern im Quelltext?
Im Quelltext zeigt Firefox das gleiche komische Platzhalterzeichen an.
Im Quelltext vom IE7 steht “ bzw. ”

Die Kästchendarstellung im FF 00/93 und 00/94 sowie “ und ” (als Windows-1252 betrachtet) deuten auf falsche Kodierung der Zeichen “ und ” hin. An den Unicode-Position 0093 und 0094 (Hex) befinden sich keine darstellbaren Zeichen. Die von dir gesuchten Zeichen befinden sich an Position 201C und 201D. Du hast schlicht eine falsche Kodierung. Beide Zeichen kommen auch nur in Windows-1252 vor, nicht jedoch in ISO-8859-1.

Die Seite ist in UTF-8 gehalten.
Und die Datenbank? Und die Verbindung dahin? Und die Tabelle?
Ja, die Datenbank ist UTF-8, aber die Tabelle bzw. das Entsprechende Feld latin1_german1_ci.

Latin1 entspricht unter MySQL Windows-1252, ansonsten eigentlich ISO-8859-1. Die Frage nach der Verbindungskodierung hast du ignoriert, die ist wichtig wenn der MySQL-Server und der Client eine gemeinsame Sprache sprechen sollen. Zum Ablegen der Daten ist die Tabellenkodierung uninteressant, nur die Feldkodierung zählt letztlich.

Bisher gabs mit Unicode Zeichen aber nie Probeme, weil MySQL Problemlos UTF8 in dem LATIN1 Feld ablegen 8und auch wieder rauskriegen) konnte.

Dann hast du vermutlich bisher unter Ignorieren der Verbindungskodierung UTF-8-Daten gesendet. Der Default-Wert der Verbindungskodierung wird auf Latin1 gestanden haben, weswegen die Mehrbytesequenzen von UTF-8 als einzelne Latin1-Zeichen interpretiert und abgespeichert wurden. Rückzu liefert MySQL wieder Latin1 aus und du interpretierst das als UTF-8. Dass dabei keine Probleme auftreten ist nur bei oberflächlicher Beobachtung richtig. Schon das Ermitteln von Stringlängen mit der Funktion CHARACTER_LENGTH() ergibt falsche Werte. Auch passen in Felder mit definierter Länge je nach Anzahl und Länge der UTF-8-Sequenzen effektiv entsprechend weniger Zeichen.

Dein Problem wäre auch gar nicht weiter aufgefallen, hätte nicht irgendwas die Zeichen “ und ” in einer falsche UTF-8-Kodierung gebracht. Wer oder was das allerdings war kann ich dir nicht sagen.

echo "$verabschiedung $name";

[Niehztog]

Ich habs jetzt geschafft mein Problem ganz einfach zu rekonstruieren:

Neue Datei anlegen im ISO Format:

[code=php]
<?php
header( 'Content-Type: text/html; charset=utf-8' );
print_r(utf8_encode('“”'));
[/code]

Es muss also nicht unbedingt mit dem Einsatz der MySQL Datenbank zu tun haben. Steckt da schon nen Fehler drin?

[dedlfix]

echo $begrüßung;

Ich habs jetzt geschafft mein Problem ganz einfach zu rekonstruieren:
Neue Datei anlegen im ISO Format:

Der Begriff "ISO" ist hier viel zu allgemein verwendet. Von ISO-8859 gibt es schon 16 Varianten. Du meinst vermutlich ISO-8859-1

print_r(utf8_encode('“”'));

Die Funktion arbeitet mit ISO-8859-1, das diese beiden Zeichen nicht enthält. Sie können deshalb nur als die beiden Steuerzeichen STS und CCH behandelt werden. Daraus erhältst du selbstverständlich auch nur die UTF-8-Kodierung für diese Steuerzeichen, nicht jedoch die für “ und ”. Wenn ein Browser bei ISO-8859-1 als Seitenkodierung und accept-charset-Attribut im Formular bei Eingabe der beiden Zeichen “ oder ” (oder anderer aus dem Windows-1252-Bereichn 80..9F) selbige als Windows-1252-kodiert zu dir sendet handelt er nach dem Motto: "Meine Lösung - dein Problem". Normalerweise kann er dir diese Zeichen legal nicht zusenden. Es gibt auch keine Reglung für irgendeine Ersatzdarstellung. Du kannst das Problem mit den PHP Extensions iconv (bevorzugt) oder recode (alt und weniger leistungsfähig) lösen, indem du von Windows-1252 nach UTF-8 kodieren lässt. Doch iconv und recode gehören nicht unbedingt zur Standardausrüstung von PHP.

Es muss also nicht unbedingt mit dem Einsatz der MySQL Datenbank zu tun haben.

Ja, MySQL hat hier keine Schuld, aber du hast da auch noch eine Baustelle offen.

Am besten wird es sein, wenn du alles komplett auf UTF-8 umstellst. Beachte dabei, dass alle Beteiligten a) mit UTF-8 umgehen können müssen und b) über die Verwendung von UTF-8 informiert sein müssen. Beteiligte sind mindestens Browser, PHP und MySQL.

PHP kann beimPunkt a) derzeit nur eingeschränkt mithalten. Wenn du keine Stringverarbeitung (Zeichen zählen, Zeichenketten trennen) damit machen möchtest, ist das egal. Wenn doch, gibt es die Multibyte-String-Extension, die aber auch nicht überall zur Verfügung steht (und wohl auch nicht sehr performant ist).

Für MySQL bedeutet a), dass die Felder eine entsprechende Kodierungseinstellung haben, und b), dass die Verbindungskodierung auszuhandeln ist (Stichwörter: mysql_set_charset(), SET NAMES, hiesiges Archiv).

Ein Problem sehe ich, das sind die derzeitigen Datenbankinhalte, die sicher nicht korrekt kodiert sind. Wenn du mit dem phpMyAdmin schaust, und der alles richtig anzeigt, hast du doch kein Problem. Wenn er aber Nicht-ASCII-Zeichen nicht richtig zeigt, musst du das erstmal korrigieren. Besonderes Augenmerk solltest du auf die Windows-1252-Zeichen legen, zu denen nicht nur deine beiden Problemkinder, sondern auch das €-Zeichen gehört. Wenn du es nicht korrigiert bekommst (vor dem Probieren Sicherheitskopie anlegen!), melde dich noch einmal mit einem Beispiel, wie die Sonderzeichen derzeit vom PMA dargestellt werden.

echo "$verabschiedung $name";