Browser rendern Eurozeichen/Eurosymbol in ISO-8859-1

[Forumsgast]

header('Content-Type: text/html; charset=ISO-8859-1');

// Ceci n'est pas un euro symbole
echo "\x80"; 

x80 ist in ISO-8859-1 der C1-Kontrollcode PAD. Alle Browser, die ich gerade da hatte (Firefox, Chromium, Safari, diverse Internet Explorer), rendern allerdings anstandslos das Eurozeichen, wie es an der Stelle etwa in Windows-1252 kodiert ist.

[Forumsgast]

ISO-8859-1 enthält eigentlich kein Euro-Zeichen. Dafür ist ISO-8859-15 da. Oder eben Unicode.
So, was ist jetzt konkret deine Frage? Oder war das nur eine Feststellung?

[Forumsgast]

Ja, das war eine Feststellung/ein Rant. Ich empfinde solche bewusst gemachten Fehler als überaus unschön.

[Forumsgast]

Ja, das war eine Feststellung/ein Rant. Ich empfinde solche bewusst gemachten Fehler als überaus unschön.

Im Prinzip gebe ich dir ja recht. Aber welche Software benutzt (heutigentags) schon Control-Characters? Noch dazu die oberen 32? Und ein Browser rendert den Text einfach nur, er gibt ihn nicht an andere Software weiter. Es ist also faktisch wurst, wie er diesen Zeichenbereich interpretiert.

Andererseits sind mit Windows arbeitende, "Webdesigner" und die unter Windows im WWW Surfenden ihre "Standards" gewöhnt. Würde jetzt ein Browser statt der erwarteten Zeichendarstellung nach der Codepage 1252 nur die lustige Raute mit dem Fragezeichen drin darstellen, würden die garantiert den Browser(hersteller) für unfähig erklären. Da beugt man sich eben den Erwartungen der "Mehrheit".

[Forumsgast]

Wahrscheinlich wissen viele auch nicht, dass ISO-8859-1 kein €-Zeichen enthält, weshalb eine solche Korrektur vorgenommen wird (zulasten eines Zeichens, das < 0,03% der Webdesigner brauchen).

[Forumsgast]

Mir ist klar, warum Browser sich so verhalten, wie sie sich verhalten. Das mag für den Ausgabekontext „HTML im Browser“ aus Herstellersicht hinsichtlich des Wettbewerbs nachvollziehbar – wenn auch falsch – sein.

Aber morgen heißt es dann: „In meinem PDF sind nur so weiße Kästen statt des Eurozeichens. In der Anwendung ist aber alles richtig. Was kann ich tun?“ Oder: „Wollte die Anwendung endlich auf UTF-8 umstellen, aber Eurozeichen werden zu Fragezeichen.“ Oder auch nur: „Drucker druckt nur weiße Kästen.“

Die Browserhersteller scheinen davon auszugehen, dass einem normalen Entwickler/HTML-Autor nicht zugetraut werden kann, einen passenden Zeichensatz zu wählen. Sie gehen aber anscheinend gleichzeitig davon aus, dass ein normaler Entwickler weiß, dass er an dieser Stelle binär falsche Daten erzeugt, die weitere Bearbeitung benötigen, wenn sie in einem anderen Kontext verwendet werden sollen. Das ist paradox.

Am Rande werden so andere Software-Stacks unter einen gewissen Druck gesetzt, denselben Fehler zu implementieren, was schlicht und ergreifend schlecht ist.

Für mich persönlich ist das keine Staatsaffäre, denn ich weiß, wie Zeichensätze funktionieren. Da ich mich aber kürzlich fragte, wie es das Eurozeichen durch eine bestimmte ISO-8859-1-Anwendung schafft, hielt ich es für sinnvoll, das Thema zu problematisieren. Vielleicht wird dieser Thread ja per Suchmaschine gefunden und hilft ein oder zwei anderen Leuten.

[Forumsgast]

- http://www.w3.org/TR/2009/WD-html5-2...er-encodings-0

Puh, sieht wohl so aus, als müssten Browser nach der HTML5-Spezifikation (in früheren habe ich nicht geguckt) ISO-8859-1 als Windows-1252 interpretieren.

(via http://xhtmlforum.de/65017-html5-w3c...2-warning.html)

[Forumsgast]

Aber morgen heißt es dann: „In meinem PDF sind nur so weiße Kästen statt des Eurozeichens. In der Anwendung ist aber alles richtig. Was kann ich tun?“ Oder: „Wollte die Anwendung endlich auf UTF-8 umstellen, aber Eurozeichen werden zu Fragezeichen.“ Oder auch nur: „Drucker druckt nur weiße Kästen.“

Hast Du die Sachen denn mal in eine Datei geschrieben? Ich sehe jetzt keinen größeren Sinn darin, dass ein Browser irgendein Control-Character darstellen soll. Wenn Du dagegen einen Binär-Mimetyp anforderst, werden die das doch sicher korrekt ausliefern?!

[Forumsgast]

Ich glaube hier kann man HTML5 keine Schuld geben, denn mir ist das vor Jahren schon mal aufgefallen. Es wurde also schon immer so gemacht und mit HTML5 erst zum Standard. Trost ist ja, dass UTF-8 unterstützt werden muss. UTF-7 und UTF-32 hat Firefox ja schon gestrichen (https://developer.mozilla.org/en/fir...for_developers).

[Forumsgast]

@nikosch:

Ja, binär wird alles korrekt ausgeliefert, es ist nur unter Umständen einfach das falsche Byte.

Mir ging's glaube ich damals darum, dass es Leute dazu verleitet, falsche Bytes etwa in eine Datenbank einzutragen. ISO-8859-1-Eingabeformular, „€“-Zeichen eingetippt, 0x80 landet im DB-Feld, das als Charset ebenfalls ISO-8859-1 gesetzt hat. Bei Ausgabe in HTML ist das (offenbar) unproblematisch, aber falls die DB-Daten mit einer Software weiterverarbeitet werden, die diesen Windows-1252-Fallback nicht mitmacht, sondern ISO-8859-1 sauber interpretiert, wird's meines Erachtens kritisch.

[Forumsgast]

Hmm, genau darum gings vermutlich beim Fallback. Letztlich hast Du auch keine Kontrolle, ob jemand einen Windows-1252 Umlaut eingibt oder einen UTF-8 Umlaut.

[Forumsgast]

Das sieht aber dann im Rahmen irgendeiner Ausgabe der Webanwendung sofort falsch aus, beim Eurozeichen würde von der Darstellung alles passen, weshalb das wohl erstmal nicht auffällt.

Für meinen Geschmack (mag natürlich weitere Argumente geben) ist der HTML-Standard an der Stelle vielleicht zu deskriptiv. Sie standardisieren eben das, was die Leute tun. Und das ist in dem Fall: den Unterschied zwischen ISO-8859-1 und Windows-1252 nicht kennen.