Zeichenkodierung
bubble
- menschelei
Hi Leute,
ich hab folgendes Problem bei meiner Webseite:
Ich habe mir einen Editor für BBCode geschrieben und dabei ist mir aufgefallen, das kein Unicode sondern ASCII angezeigt wird. Dacht ich mir,
dass ich einfach via php
header("Content-Type: text/html; charset=utf-8");
und mit der Meta-Angabe
meta http-equiv="content-type" content="text/html; charset=utf-8">
alles richtig mache... Allerdings wird aus einem "♥" dann bei der Webseite ein "♥" und das ist ja irgendwie falsch.
Dann dachte ich das ich auf UTF-16 stellen muss aber dann kamen nur japanische/chinesische Schriftzeichen. Mein nächster Gedanke war utf-32, da wurden allerdings nur noch schwarze Rauten mit weißen Fragezeichen angezeigt. :(
Auf einer Webseite, bei der ich weiß, dass der Unicode so funktioniert wie ich es an sich haben möchte (www.jappy.de) ist utf-8 angegeben. Nun versteh ich nicht warum es bei mir nicht funktioniert.
Wisst ihr was ich falsch mache bzw. welche Zeichenkodierung benutzt ihr für eure Webseiten?
mfg bubble
Wisst ihr was ich falsch mache bzw. welche Zeichenkodierung benutzt ihr für eure Webseiten?
Nur weil du sagst, dass Encoding sei dies oder das, wird das nicht automatisch die bestehenden Bytes korrigieren.
Das Beste ist, man wählt von Anfang an, UTF-8. Falls man aber Dateien hat, die in einem iso-Typ erstellt wurden, so müssen diese Files konvertiert werden.
Dazu musst du entweder einen lokalen Editor bemühen, oder aber die Konversion mittels deiner serverseitigen Scriptsprache vornehmen.
mfg Beat
Gibt es auch noch eine andere mögliche Fehlerquelle?
Weil ich jetzt alle relevanten Dateien im Unicode-Format hab, aber die Ausgabe immer noch falsch ist :[
mfg bubble
Hi!
Gibt es auch noch eine andere mögliche Fehlerquelle?
Weil ich jetzt alle relevanten Dateien im Unicode-Format hab, aber die Ausgabe immer noch falsch ist :[
Unicode ist kein Format (auch wenn manche Editoren das so nennen). Ein Format wäre UTF-8. Fehlerquellen gibt es eine Menge. Wenn du dein Problem lösen willst, versuch dir Grundlagen und Wissen zur Thematik Zeichenkodierung zu erarbeiten. Alternativ lass jemanden draufschauen, der Erfahrung hat. Link zum Problemkind?
Lo!
Link zum Problemkind?
http://tdv.td.ohost.de/AbwesiImage/site/
Man sieht es z.B. im Menü, da das ü nicht richtig dargestellt wird.
Und beim "Editor" bei textgröße [ö und ß], sowie wenn man Unicode-Zeichen eingibt und auf Vorschau klickt =/
Und was mir noch auf gefallen ist, sobald ich utf-8 angegeben hab, werden Zeilenumbrüche nicht mehr mit <br> ersetzt.
$text = preg_replace("/\n/","<br>\n",$text);
Auch folgender Aufruf brachte mir nicht mehr das gewünschte Ergebnis:
$text = nl2br($text);
mfg bubble
Tach,
http://tdv.td.ohost.de/AbwesiImage/site/
Man sieht es z.B. im Menü, da das ü nicht richtig dargestellt wird.
Und beim "Editor" bei textgröße [ö und ß],
die Datei wird zwar mit UTF-8 ausgeliefert ist aber weiterhin ISO-kodiert auch wenn er ein BOM enthält, der nur bei einer UTF-Kodierung Sinn ergeben würde (im Allgemeinen aber eher Probleme verursacht und deswegen vermieden werden sollte). Was für einen Editor hast du denn genutzt, um die Dateien umzukodieren? Ich würde dir jetzt einfach mal Notepad++ empfehlen (falls du Windows einsetzt), im Menü Kodierung zuerst die alte Kodierung auswählen (falls das nicht automatisch passiert) und dann zu UTF-8 ohne BOM umkodieren.
sowie wenn man Unicode-Zeichen eingibt und auf Vorschau klickt =/
Das klingt danach als würdest du die eingegebenen Zeichen nicht vernünftig weiterverarbeiten und wenn man in den Header schaut, den bbcode.php zurückgibt, sieht man, dass es ISO-8859-1 zurückliefert.
mfg
Woodfighter
Hallo,
Link zum Problemkind?
http://tdv.td.ohost.de/AbwesiImage/site/
Man sieht es z.B. im Menü, da das ü nicht richtig dargestellt wird.
richtig, das ist auch offensichtlich nicht in UTF-8 codiert, sondern steht als Byte mit dem Code 0xFC im Quellcode. Also nach ISO-8859-x codiert.
Und was mir noch auf gefallen ist, sobald ich utf-8 angegeben hab, werden Zeilenumbrüche nicht mehr mit <br> ersetzt.
$text = preg_replace("/\n/","<br>\n",$text);
Auch folgender Aufruf brachte mir nicht mehr das gewünschte Ergebnis:
$text = nl2br($text);
Das ist aber eine ganz andere Baustelle und hat nichts mit der Zeichencodierung zu tun.
Ciao,
Martin
Hi!
Link zum Problemkind?
http://tdv.td.ohost.de/AbwesiImage/site/
Mit der Firefox-Extension livehttpheaders sehe ich den HTTP-Header Content-Type mit einem charset-Parameter utf-8. Auch gibt es ein gleichnamiges Meta-Element mit der selben charset-Angabe. Diese wird aber beim Vorhandensein der Angabe im HTTP-Header nicht verwendet (darf nicht, der HTTP-Header hat eine höhere Priorität).
Das Dokument selbst beginnt mit einer BOM (Byte-Order-Markierung). Das sieht man, wenn man sich die Quelltextansicht nimmt und dort die Zeichenkodierung auf ISO-8859-1 stellt. Dann wird das Dokument gemäß dieser Kodierung zu lesen versucht und man sieht die typische Sequenz  am Anfang. Die BOM wird nicht benötigt, Windows' Notepad fügt sie beim Speichern als "UTF-8" ungefragt ein. Nimm einen Editor, der die BOM weglassen kann, beispielsweise Notepad++.
Man sieht es z.B. im Menü, da das ü nicht richtig dargestellt wird.
Und beim "Editor" bei textgröße [ö und ß], sowie wenn man Unicode-Zeichen eingibt und auf Vorschau klickt =/
Das title-Element hat als Inhalt einen "Frontalzusammenstoß", der UTF-8-kodiert ist. Dann kommt irgendwann das "Menü", das aber ISO-8859-1-kodiert ist, ebenso "textgröße". Fügst du Dokumente zusammen? Dann sind diese anscheinend unterschiedlich kodiert. Wenn die Daten aus MySQL kommen, dann verhandelst du vielleicht nicht die gewünschte Kodierung.
Das erkennt man, wenn man die Zeichenkodierung zwischen UTF-8 und ISO-8859-1 wechselt. Mal ist das eine richtig zu sehen, mal das andere. Da ISO-8859-1 eine Ein-Byte-Kodierung ist, sieht man für jedes Byte einer UTF-8-Sequenz ein eigenes Zeichen. Anders gesagt: Jedes Byte der UTF-8-Sequenz wird gemäß ISO-8859-1 gelesen als eigenes Zeichen interpretiert (und dargestellt). Hingegen folgen die Bytes einer UTF-8-Sequenz bestimmten Regeln, die üblicherweise durch die normale Verwendung von ISO-8859-1-kodierten Umlauten und dergleichen nicht eingehalten wird. Ergebnis ist dann das Darstellen des Ersatzzeichens � und manchmal auch das "Verschlucken" eines oder mehrerer nachfolgender Bytes, die für den Erkennungsversuch der UTF-8-Sequenz draufgehen.
Und was mir noch auf gefallen ist, sobald ich utf-8 angegeben hab, werden Zeilenumbrüche nicht mehr mit <br> ersetzt.
$text = preg_replace("/\n/","<br>\n",$text);
Auch folgender Aufruf brachte mir nicht mehr das gewünschte Ergebnis:
$text = nl2br($text);
Die Angeben im HTTP-Header oder Meta-Element haben keinen Einfluss auf die Arbeitsweise PHPs. Lediglich preg_replace() kann mit UTF-8-kodierten Texten umgehen, wenn du den entsprechenden Modifizierer angibst. Das ist aber auch unabhängig von den beiden genannten Angaben. Jedenfalls kann ich derzeit keine Ursache für dieses Verhalten sehen. Wenn du dafür die Ursache suchen willst, lass dir genau anzeigen, was du bekommst/hast und was nach dem Ersetzen rausgekommen ist. Dazu schaut man sich am besten die Bytes an, was mit bin2hex() geht, aber auch url_encode() lässt sich dafür sehr gut missbrauchen. Dessen Ergebnis ist etwas einfacher zu lesen, weil es die ASCII-Buchstaben und Ziffern nicht "verhext".
Lo!
hi,
dass ich einfach via php
header("Content-Type: text/html; charset=utf-8");
Prüf mal, ob dieser HTTP-Header auch tatsächlich gesendet wird (Plugin FF oder Wireshark).
Wisst ihr was ich falsch mache bzw. welche Zeichenkodierung benutzt ihr für eure Webseiten?
UTF-8 und zwar unverändert von der Datenquelle (Dateien, mySQL...) bis zum Browser.
Hotti
Hi Leute,
Danke für die viele Hilfe und die Aufklärung :]
Es funktioniert jetzt einwandfrei, der Fehler war dieses BOM, da ich den Windows Editor verwendet hab. Jetzt mit Notepad++ geht alles viel besser!
mfg bubble
Hi!
Danke für die viele Hilfe und die Aufklärung :]
Es funktioniert jetzt einwandfrei, der Fehler war dieses BOM, da ich den Windows Editor verwendet hab. Jetzt mit Notepad++ geht alles viel besser!
Der "Frontalzusammenstoß" und das "menü" sowie das Herz sind nun richtig UTF-8-kodiert, aber die "textgröße" ist noch ISO-8859-1.
Lo!