nicht angemeldet
UTF-8 lässt deutsche Anführungszeichen verschwinden
Hi, ich habe eine Website im UTF-8-Format. D. h. alle Dateien wurden im UTF-8-Format gespeichert und im Header steht jeweils <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Einige Inhalte werden aus der Datenbank (kurz DB) gelesen. Die DB ist allerdings auf "latin1" eingestellt und lässt sich nicht ohne weiteres umstellen. In der Datenbank selbst werden die anzuzeigenden Daten mit deutschen Anführungszeichen laut phpMyAdmin korrekt gespeichert, z. B. Ferienhaus „Morgenschein“. Wenn ich die Daten auslese und kein utf8_encode verwende, werden Fragezeichen statt der deutschen Anführungszeichen angezeigt (Ferienhaus ?Morgenschein?). Verwende ich utf8_encode, werden die deutschen Anführungszeichen nicht mehr angezeigt. Im Firefox werden sie gar nicht angezeigt und im IE wird stattdessen eine zusätzliche leere Stelle angezeigt. html_entities und html_specialchars bringen es nicht und mit str_replace wüsste ich jetzt auch nicht, was ich ersetzen sollte. iconv hab ich auch schon ausprobiert. iconv("UTF-8","ISO-8859-1", $var) liefert mir "Detected illegal character in input string in...". Andersherum passiert nix.
Gibt es vielleicht noch eine andere Möglichkeit? Vielleicht ein eigenes Skript, dass die Zeichen mit str_replace ersetzt? Damit wäre mir schon geholfen, aber ich weiß nicht, wie ich die Zeichen ersetzen kann.
-
Moin!
Einige Inhalte werden aus der Datenbank (kurz DB) gelesen. Die DB ist allerdings auf "latin1" eingestellt und lässt sich nicht ohne weiteres umstellen.
Das wirst Du aber zwingend müssen.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
Hi!
Hi, ich habe eine Website im UTF-8-Format.
Kodierung wäre der richtige Begriff gewesen, nicht Format.
Die DB ist allerdings auf "latin1" eingestellt und lässt sich nicht ohne weiteres umstellen.
Warum nicht? Die Kodierung der Felder ist eine Sache. Für einen Client ist aber nur wichtig, welche Kodierung er auf seiner Verbindung zum MySQL-Server verwendet. Wenn diese nicht mir der Feld-Kodierung übereinstimmt, kodiert MySQL selbständig um. Siehe SELFHTML-Wiki Themen:Zeichencodierung/MySQL. Du kannst also durchaus mit Clients, die nur Latin1 sprechen wollen, und UTF-8 verwendenden Clients gleichzeitig mit den Daten arbeiten. Dies ist nicht unbedingt uneingeschränkt empfehlenswert, denn die Latin1-Clients können natürlich nicht den vollen Unicode-Zeichensatz nutzen und bekommen für manche Zeichen dann nur Fragezeichen geliefert.
In der Datenbank selbst werden die anzuzeigenden Daten mit deutschen Anführungszeichen laut phpMyAdmin korrekt gespeichert, z. B. Ferienhaus „Morgenschein“.
Zunächst solltest du wissen, dass diese Anführungszeichen kein Bestandteil von ISO-8859-1 sind. Demzufolge sind sie auch kein Bestandteil von Latin1, aber MySQL nennt es zwar Latin1, behandelt es jedoch wie Windows-1252, bei dem die Anführungszeichen im in ISO-8859-1 nicht definierten beziehungsweise anders verwendeten Bereich von x80..x9F liegen.
Wenn ich die Daten auslese und kein utf8_encode verwende, werden Fragezeichen statt der deutschen Anführungszeichen angezeigt (Ferienhaus ?Morgenschein?). Verwende ich utf8_encode, werden die deutschen Anführungszeichen nicht mehr angezeigt. Im Firefox werden sie gar nicht angezeigt und im IE wird stattdessen eine zusätzliche leere Stelle angezeigt. html_entities und html_specialchars bringen es nicht und mit str_replace wüsste ich jetzt auch nicht, was ich ersetzen sollte. iconv hab ich auch schon ausprobiert.
iconv("UTF-8","ISO-8859-1", $var)liefert mir "Detected illegal character in input string in...". Andersherum passiert nix.Das liegt - bei iconv ganz sicher, bei den anderen vermutlich auch - daran, dass du Windows-1252 als Quell-Kodierung angeben musst, nicht ISO-8859-1.
Lo!
-
Mein Held! Vielen, vielen Dank!
Mit
iconv("Windows-1252","UTF-8", $var)funktioniert es jetzt erst mal wie gewünscht.-
Hi!
Mit
iconv("Windows-1252","UTF-8", $var)funktioniert es jetzt erst mal wie gewünscht.Ich würde trotzdem bevorzugen, die Verbindungskodierung so einzustellen, wie du die Daten weiterverarbeiten willst. Zum einen ist es sinnvoll, für Klarheit zu sorgen und die Verbindungskodierung explizit zu setzen, als sich auf einen Defaultwert zu verlassen - dies ist ja nur ein kleiner Aufwand nach dem Connect. Zum anderen brauchst du damit auch keine zusätzliche Konvertierung vorzunehmen, denn das macht MySQL bereits für dich.
Lo!
-
-