Forum: PC-Programmierung HTML mit charset=iso-8859-1


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Bauform B. (bauformb)


Lesenswert?

Mahlzeit!

kann/darf/sollte man heute noch HTML ohne utf-8 schreiben? Mit <!doctype 
html> ist jedenfalls nur noch charset=utf-8 erlaubt. Aus 
Mikrocontrollern kommt aber freiwillig kein utf-8, aber ° oder µ mag man 
vielleicht trotzdem. Natürlich könnte man das irgendwo konvertieren, 
nur, muss das sein? Früher ging es doch auch.

von K. L. (trollen) Benutzerseite


Lesenswert?

Bauform B. schrieb:
> Aus Mikrocontrollern kommt aber freiwillig kein utf-8

Wer sagt das? Dem Mikrocontroller ist es ziemlich egal welche Folge von 
1 und 0 er ausgibt.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Bauform B. schrieb:
> Aus
> Mikrocontrollern kommt aber freiwillig kein utf-8,

Auch bei String-Literalen ist das schon lange kein Problem mehr:
1
const char* myText = u8"bla öäüß° 貓🐈µ";
Wenn du dann myText ausgibst ist es ganz normales UTF-8. Der 
C-Sourcecode sollte UTF-8 kodiert sein und der Compiler auch 
entsprechend konfiguriert (ist default beim GCC), damit die 
unterschiedlichen Zeichen dort überhaupt abgespeichert werden können.

Das funktioniert sogar wenn du den Sourcecode in einem anderen 
ASCII-kompatiblen Zeichensatz (z.B. ISO8859-15) abspeicherst und das dem 
Compiler mitteilst; der konvertiert das dann automatisch zu UTF-8. Dann 
bist du aber natürlich auf die Zeichen dieses Zeichensatzes beschränkt.

Als Notbehelf kann man die UTF-8 Codepoints auch als Hex-Literale 
manuell eintragen:
1
//                        ö       ä       ü       ß       °        貓          🐈               µ
2
const char* myText = "bla \xC3\xB6\xC3\xA4\xC3\xBC\xC3\x9F\xC2\xB0 \xE8\xB2\x93\xF0\x9F\x90\x88\xC2\xB5";

Besonders wartbar ist das nicht.

: Bearbeitet durch User
von Bauform B. (bauformb)


Lesenswert?

Niklas G. schrieb:
> Auch bei String-Literalen ist das schon lange kein Problem mehr:const
> char* myText = u8"bla öäüß° 貓🐈µ";

> Das funktioniert sogar wenn du den Sourcecode in einem anderen
> ASCII-kompatiblen Zeichensatz (z.B. ISO8859-15) abspeicherst und das dem
> Compiler mitteilst; der konvertiert das dann automatisch zu UTF-8. Dann
> bist du aber natürlich auf die Zeichen dieses Zeichensatzes beschränkt.

Seltsamerweise funktioniert das in einer reinen ISO8859 Umgebung nicht, 
also LANG=C, xterm ohne UTF-8, gcc (Debian 12.2.0-14) 12.2.0. Und wenn 
der Sourcecode schon UTF-8 ist, braucht man den u8 Prefix doch nicht?

Aber egal. Entscheidend ist, dass die Konvertierung ISO8859 nach UTF-8 
trivial und eindeutig ist. In der anderen Richtung funktioniert es auch 
mit viel Aufwand nicht wirklich. Ich bekomme ISO8859-Text und muss den 
auch wieder so ausgeben. Nur wenn eine bestimmte Ausgabe eine andere 
Kodierung braucht, wird kurz vorher konvertiert, z.B. muss für dynamisch 
erzeugtes HTML &amp; usw. erzeugt werden.

Das einzige was mich jetzt stört, ist statisches HTML. Früher durfte man 
charset=iso-8859-1 ausliefern, das war das gleiche bewährte Prinzip wie 
bei der Zeit: innen drin gibt es nur UTC und nur für die Ausgabe wird in 
Lokalzeit konvertiert.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Bauform B. schrieb:
> xterm ohne UTF-8

Wie soll das dann UTF-8 Text darstellen können?!

Bauform B. schrieb:
> Und wenn der Sourcecode schon UTF-8 ist, braucht man den u8 Prefix doch
> nicht?

Doch! Sonst macht der Compiler da was nicht-standardisiertes. Kann sein 
dass es manchmal auch ohne "u8" geht, aber mit u8 ist garantiert dass es 
korrekt funktioniert.

Bauform B. schrieb:
> Entscheidend ist, dass die Konvertierung ISO8859 nach UTF-8 trivial und
> eindeutig ist

Eindeutig ja, trivial nein - du musst immer noch die oberen 128 Zeichen 
in Multibyte-Sequenzen konvertieren. z.B. "ä" in ISO8859-15 ist E4, in 
UTF-8 ist es C3 A4.

Bauform B. schrieb:
> Ich bekomme ISO8859-Text und muss den auch wieder so ausgeben

Aha, wo kommt der her? Das ist dein eigentliches Problem. Mache alles 
in Unicode und du bist die Probleme los. Warum "muss" die HTML-Ausgabe 
ISO8859 sein?

Bauform B. schrieb:
> innen drin gibt es nur UTC und nur für die Ausgabe wird in Lokalzeit
> konvertiert.

Diese Konvertierung ist schon lange hinfällig. Man möchte eigentlich 
überall Unicode nutzen und überhaupt nicht mehr in einen der alten 
Zeichensätze konvertieren. Für die Ausgabe in einen "lokalen" 
Zeichensatz konvertieren bringt nichts wenn man Zeichen mehrerer 
Sprachen mischen möchte. Das Web ist international, eine einzelne 
Website kann Texte vieler Sprachen enthalten, dazu kommen Emoji, diverse 
Symbole, sogar Noten...

: Bearbeitet durch User
von Bauform B. (bauformb)


Lesenswert?

Niklas G. schrieb:
> Bauform B. schrieb:
>> Entscheidend ist, dass die Konvertierung ISO8859 nach UTF-8 trivial und
>> eindeutig ist
>
> Eindeutig ja, trivial nein - du musst immer noch die oberen 128 Zeichen
> in Multibyte-Sequenzen konvertieren.

Naja, die Funktion dafür hat 76 Zeilen, für UTF und HTML Entities.

> Bauform B. schrieb:
>> Ich bekomme ISO8859-Text und muss den auch wieder so ausgeben
>
> Aha, wo kommt der her? Das ist dein eigentliches Problem. Mache alles
> in Unicode und du bist die Probleme los.

Lieber neues Abenteuer statt altbewährter Probleme ;)

> Warum "muss" die HTML-Ausgabe ISO8859 sein?

"Muss" natürlich nicht. Also das war so: bisher wurde alles HTML zur 
Laufzeit erzeugt und für die Ausgabe konvertiert, kein Problem. Jetzt 
wollte ich eine Seite statischen Text direkt ausliefern und hab' die 
einfach so eingetippt. Und anschließend gemerkt, dass das so nicht mehr 
erlaubt ist. validator.w3.org meint dazu:
"The character encoding was not declared. Proceeding using windows-1252"
und wenn man mit charset=windows-1252 testet:
"Legacy encoding windows-1252 used. Documents must use UTF-8"

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Bauform B. schrieb:
> Jetzt
> wollte ich eine Seite statischen Text direkt ausliefern

Aber das ist doch genau der einfachste Fall: String-Literal mit "u8" 
deklarieren, charset=utf-8 rein schreiben, genau so 1:1 abschicken, 
fertig.

von Harald K. (kirnbichler)


Lesenswert?

Bauform B. schrieb:
> Früher durfte man
> charset=iso-8859-1 ausliefern

Das "darf" man heute nicht mehr? Wer hat das wann und wo "verboten"?

Niklas G. schrieb:
> Mache alles
> in Unicode und du bist die Probleme los.

... und hast dafür interessante neue Probleme. Schon mal strlen auf 
einen utf-8-String losgelassen und die Länge eines Textes z.B. für die 
Cursorpositionierung auf einem Terminal verwendet?

Oh, und welche VT100-Emulation weiß, was utf-8 ist?

Da ist eine 8-Bit-Codepage einfacher zu handhaben. Verwendet man keine 
allzu superschlaue IDE, kommt die auch damit zurecht, daß Sourcecode 
nicht in utf-8 codiert ist.

Wenn man Webanwendungen auf etwas anderem als einem µC veranstaltet, 
dann hat utf-8 seinen verdienten Platz. Aber auf einem µC? Warum nur? 
Damit Nutzer des Webinterfaces die Chance haben, irgendwelche Texte auch 
in Urdu einzutippen?

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Harald K. schrieb:
> Schon mal strlen auf
> einen utf-8-String losgelassen und die Länge eines Textes z.B. für die
> Cursorpositionierung auf einem Terminal verwendet?

Dafür gibt es Libraries. Moderne Sprachen wie Java haben das integriert, 
bei C und C++ muss man sich halt anders behelfen.

Harald K. schrieb:
> Oh, und welche VT100-Emulation weiß, was utf-8 ist?

Gnome-Terminal, KDE Konsole. Wir reden hier auch vom Web, das ist "ein 
paar" Technologieschritte weiter als VT100.

Harald K. schrieb:
> Damit Nutzer des Webinterfaces die Chance haben, irgendwelche Texte auch
> in Urdu einzutippen?

Warum nicht? Die Ansicht, alles müsse ASCII sein, ist ganz schön 
eurozentrisch. Vielleicht möchte ich meinem Smart-Home-System ja einen 
Sensor als "Küche" bezeichnen, aber der Nachbar möchte lieber 廚房 haben. 
Oder doch 🍳?

Viele Tools und Technologien nutzen heutzutage ausschließlich nur noch 
Unicode, da hat man teilweise gar keine andere Wahl mehr.

: Bearbeitet durch User
von Norbert (der_norbert)


Lesenswert?

Ich muss gestehen das ich noch nicht einmal das Problem sehe:
1
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
2
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
3
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
4
    <head>
5
        <title>äöüÄÖÜß</title>
6
        <meta http-equiv="content-type" content="text/html;charset=iso8859-15" />
7
    </head>
8
    <body>
9
        äöüÄÖÜß
10
    </body>
11
</html>
Editor auf iso8859-15 gestellt und Dokument geschrieben.
Wird im Firefox problemlos akzeptiert und sauber dargestellt.

von Harald K. (kirnbichler)


Lesenswert?

Niklas G. schrieb:
> Dafür gibt es Libraries. Moderne Sprachen wie Java haben das integriert,
> bei C und C++ muss man sich halt anders behelfen.

Ja, oder man lässt es bleiben, einfach, weil es für die konkrete 
Anwendung komplett überflüssig ist.

Meine Frage übrigens hast Du nicht beantwortet:

> Das "darf" man heute nicht mehr? Wer hat das wann und wo "verboten"?

von Bauform B. (bauformb)


Lesenswert?

Norbert schrieb:
> XHTML 1.0 Strict
> Wird im Firefox problemlos akzeptiert und sauber dargestellt.

Ja, aber wie lange noch?
"Error: Obsolete doctype. Expected <!DOCTYPE html>"
Die Browser-Programmierer könnten das ernst nehmen und den alten 
vergammelten charset Code rauswerfen.

von Harald K. (kirnbichler)


Lesenswert?

Bauform B. schrieb:
> Die Browser-Programmierer könnten das ernst nehmen und den alten
> vergammelten charset Code rauswerfen.

Das eine hat mit dem anderen nichts zu tun:
1
<!DOCTYPE html>
2
<html>
3
<head>
4
<meta charset="utf-8">

Und statt des impliziten, da default "utf-8" darf da natürlich auch was 
anderes stehen.

Oder hast Du eine definitive Quelle, die beschreibt, daß man das nicht 
mehr "dürfe"?

Schon am Threadbeginn schriebst Du:

Bauform B. schrieb:
> Mit <!doctype
> html> ist jedenfalls nur noch charset=utf-8 erlaubt.

... was offenkundig nicht stimmt, wenn man die andere Codierung angibt:
1
<meta charset="ISO-8859-1">

Wo bitte soll das "verboten" oder auch nur "deprecated" sein?

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> Editor auf iso8859-15 gestellt und Dokument geschrieben.
> Wird im Firefox problemlos akzeptiert und sauber dargestellt.
Das ist das Problem: Editor und Browser müssen das gleiche Encoding 
verwenden, damit das funktioniert.

Ich hatte da kürzlich beim Webseiten-Bau erst wieder Probleme mit und 
habe mich davon verabschiedet, irgendwelchen Text noch zu filtern oder 
nach ASCII oder ISO-irgendwas umzuschneidern. Wenn man als Encoding 
heute UTF-8 vorgibt, bekommt man es von aktuellen Systemen/Browsern 
auch, alles andere ist nicht sicher ob's funktioniert oder nicht. Dafür 
können alle Texteditoren heute UTF-8. Also kompletter Wechsel auf UTF-8, 
das kann alles... und alles andere ist nicht zukunftssicher.

von Johannes F. (jofe)


Lesenswert?

Bauform B. schrieb:
> Früher durfte man
> charset=iso-8859-1 ausliefern

... das übrigens schon seit längerer Zeit von standardkonformen Browsern 
als windows-1252 behandelt wird (welches die selten genutzten 
C1-Steuerzeichen von ISO 8859-1 durch druckbare Zeichen ersetzt).

https://developer.mozilla.org/en-US/docs/Web/API/Encoding_API/Encodings

von Norbert (der_norbert)


Lesenswert?

Ben B. schrieb:
> Das ist das Problem:
Nein, das ist die Lösung: Webseiten-Kodierung und Zeichensatz der Daten 
müssen übereinstimmen.

> Editor und Browser müssen das gleiche Encoding
> verwenden, damit das funktioniert.

Exakt, wobei ich Generator und Browser sagen würde.

So wie ich das verstanden habe, soll die HTML Seite im µC erzeugt und 
mit Daten gefüllt werden.
Also ist das die einfachste und sinnvollste Vorgehensweise (wenn man mit 
dem ISO8859 Zeichensatz auskommt).

Und das wird ganz gewiss auch in absehbarer Zeit (und weit darüber 
hinaus) unterstützt.

Warum also komplizierte UTF-8 Kapriolen im µC treiben?

von Daniel D. (danielduese)


Lesenswert?

Bauform B. schrieb:
> kann/darf/sollte man heute noch HTML ohne utf-8 schreiben?

Ich denke die Antworten laufen alle in die gleiche Richtung, weil utf-8 
wirklich einfach zu handhaben ist, vorausgesetzt du nutzt utf-8-fähige 
Funktionen wie utf8_strlen, utf8_substr...
Wenn du ohnehin mit dem ISO8859-x Zeichensatz auskommst (mit den wenigen 
Sonderzeichen), dann werden deine utf8_ Funktionen sehr klein.
Ansonsten gibt's für Multibyte-Zeichensätze Standard-Bibliotheken

Edit, eigentlich reicht dir ja eine, die ISO in UTF-8 konvertiert, vor 
jeder Ausgabe. Dann kannst du intern im Zeichensatz deiner Gewohnheit 
arbeiten.

: Bearbeitet durch User
von Rolf M. (rmagnus)


Lesenswert?

Bauform B. schrieb:
> Seltsamerweise funktioniert das in einer reinen ISO8859 Umgebung nicht,
> also LANG=C, xterm ohne UTF-8, gcc (Debian 12.2.0-14) 12.2.0. Und wenn
> der Sourcecode schon UTF-8 ist, braucht man den u8 Prefix doch nicht?

Es gibt in C und damit auch bei GCC die Unterscheidung zwischen dem 
Charset im Quellcode und dem im erzeugten Programm. Der Compiler 
konvertiert das dann. Solange die gleich sind (und die meisten scheinen 
zu glauben, dass die zwingend gleich sein müssten), wird man sich da in 
der Regel nicht drum kümmern müssen. Wenn sie aber unterschiedlich sein 
sollten, muss man das dem Compiler natürlich mitteilen, beim GCC mit den 
Optionen -finput-charset und -fexec-charset.

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Rolf M. schrieb:
> Wenn sie aber unterschiedlich sein sollten, muss man das dem Compiler
> natürlich mitteilen, beim GCC mit den Optionen -finput-charset und
> -fexec-charset.

Letzteres ist unnötig wenn man das String-Literal mit "u8" markiert, 
dann kommt immer UTF-8 raus.

Norbert schrieb:
> So wie ich das verstanden habe, soll die HTML Seite im µC erzeugt und
> mit Daten gefüllt werden

Nein, es ist eine statische Seite. Und die lässt sich trivial als UTF-8 
String Literal im Flash ablegen und dann 1:1 abschicken.

von Bauform B. (bauformb)


Lesenswert?

Harald K. schrieb:
> Bauform B. schrieb:
>> Die Browser-Programmierer könnten das ernst nehmen und den alten
>> vergammelten charset Code rauswerfen.
>
> Das eine hat mit dem anderen nichts zu tun:
> <!DOCTYPE html>
> <html>
> <head>
> <meta charset="utf-8">
>
> Und statt des impliziten, da default "utf-8" darf da natürlich auch was
> anderes stehen.
>
> Oder hast Du eine definitive Quelle, die beschreibt, daß man das nicht
> mehr "dürfe"?

Wie immer ist es etwas komplizierter. Was wo erlaubt ist hängt natürlich 
vom DOCTYPE ab und mit HTML5 ist nur noch utf-8 erlaubt. 
validator.w3.org sagt dazu eindeutig "Error", nicht einmal "Warning".

Mit HTML4.01 Strict oder Transitional ist iso-8859 erlaubt. Das wäre 
eine saubere Sache, falls ich wirklich kein utf-8 haben will (aber s.u.)

Beitrag "Re: HTML mit charset=iso-8859-1"
Mit XHTML aus dem Beitrag bekam ich gestern "Error: Obsolete doctype. 
Expected <!DOCTYPE html>". Das ist heute nicht reproduzierbar!?

Aber egal, wir schreiben das Jahr 2024, tendenziell ist alles außer 
HTML5 obsolete, oder?

von Rolf M. (rmagnus)


Lesenswert?

Niklas G. schrieb:
> Rolf M. schrieb:
>> Wenn sie aber unterschiedlich sein sollten, muss man das dem Compiler
>> natürlich mitteilen, beim GCC mit den Optionen -finput-charset und
>> -fexec-charset.
>
> Letzteres ist unnötig wenn man das String-Literal mit "u8" markiert,
> dann kommt immer UTF-8 raus.

Man könnte genauso sagen: Das "u8" ist unnötig. Wenn man das 
exec-charset entsprechend einstellt, kommt auch immer UTF-8 raus. Es 
kommt letztlich drauf an, ob man nur ganz bestimmte Strings in UTF-8 
haben will, so dass man genau diese dann explizit als solche markiert, 
oder ob sowieso alles UTF-8 sein soll.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Rolf M. schrieb:
> Wenn man das exec-charset entsprechend einstellt, kommt auch immer UTF-8
> raus.

Das ist aber ein Compiler-spezifischer "Hack", nur dazu da, den Mangel 
der alten C-Standards auszugleichen, den Zeichensatz nicht im Code 
angeben zu können. Das "u8" funktioniert garantiert immer mit allen 
Compilern.

von Rolf M. (rmagnus)


Lesenswert?

Niklas G. schrieb:
> Rolf M. schrieb:
>> Wenn man das exec-charset entsprechend einstellt, kommt auch immer UTF-8
>> raus.
>
> Das ist aber ein Compiler-spezifischer "Hack", nur dazu da, den Mangel
> der alten C-Standards auszugleichen, den Zeichensatz nicht im Code
> angeben zu können.

Nein. Im C-Standard gibt es offiziell das "source character set" und das 
"execution character set", zwischen denen der Compiler konvertieren 
muss. Welche das konkret sind, bleibt dem Compiler überlassen. Der GCC 
gibt hier nicht welche fest vor, sondern bietet die Möglichkeit, beide 
über die genannten Kommandozeilenparameter auszuwählen. Das ist kein 
"Hack".

> Das "u8" funktioniert garantiert immer mit allen Compilern.

Wie gesagt: Wenn ich ein paar ganz bestimmte Strings als UTF-8 
kennzeichnen will und andere nicht, dann nutze ich das. Wenn es aber eh 
alles gleich sein soll, schreibe nicht vor sämtliche Stringliterale im 
gesamten Programm ein u8 davor, sondern stelle einfach das execution 
charater set entsprechend ein.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Rolf M. schrieb:
> Der GCC
> gibt hier nicht welche fest vor, sondern bietet die Möglichkeit, beide
> über die genannten Kommandozeilenparameter auszuwählen. Das ist kein
> "Hack".

Okay, wenn das so ist, ist es zwar ein Hack, verlässt sich aber trotzdem 
darauf dass man es im Compiler einstellen kann. Ein standardkonformer 
Compiler muss das nicht anbieten und könnte einen auf einen Zeichensatz 
festnageln.

Rolf M. schrieb:
> schreibe nicht vor sämtliche Stringliterale im
> gesamten Programm ein u8 davor

Naja, 2 Zeichen damit es garantiert immer funktioniert... Gute Programme 
sollten keine speziellen Compileroptionen benötigen um überhaupt zu 
funktionieren - solche Optionen gehen schnell mal verloren wenn man 
Sourcecode zwischen IDEs austauscht o.ä.

von Εrnst B. (ernst)


Lesenswert?

Norbert schrieb:
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> Editor auf iso8859-15 gestellt und Dokument geschrieben.
> Wird im Firefox problemlos akzeptiert und sauber dargestellt.

Vorsicht, Trugschluss:
Es gab nie wirklich Browser, die XHMTL unterstützt haben.
Der Internet Explorer z.B. konnte das NIE, was dann auch der Todesstoß 
für XHTML war.

Firefox konnte XHTML nur, wenn es mit Content-Type: 
application/xhtml+xml
im HTTP-Header ausgeliefert wurde (meta http-equiv reicht NICHT).

Wenn's ein normaler text/html Header war, oder du einfach nur die Datei 
aufmachst, landet es nicht im XHTML-Parser, sondern im 
HTML4-Quirks-Parser.
Der sieht dann eine stark fehlerhafte HTML-Datei, aber der Parser ist 
fehlertolerant genug um trotzdem was sinnvolles darzustellen.

Und bei HTML4 war iso8859-1 noch üblich.

von Norbert (der_norbert)


Lesenswert?

Εrnst B. schrieb:
> nur, wenn es mit Content-Type:
> application/xhtml+xml
> im HTTP-Header ausgeliefert wurde

Ahh, interessant zu wissen (und zu merken.) ;-)
Dennoch, sowohl der Indianer2 als auch die X-Maschine scheinen das 
bereits als Default (ohne Konfigurationseingriff meinerseits) zu 
verwenden.

von Norbert (der_norbert)


Lesenswert?

So geht's nun auch Fehlerfrei (und Warnungsfrei) durch den 
»https://validator.w3.org/check«
1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
2
<html lang="de">
3
    <head>
4
        <title>äöüÄÖÜß</title>
5
        <meta http-equiv="content-type" content="text/html;charset=iso-8859-15">
6
    </head>
7
    <body>
8
        äöüÄÖÜß
9
    </body>
10
</html>

von Harald K. (kirnbichler)


Lesenswert?

Norbert schrieb:
> So geht's nun auch Fehlerfrei (und Warnungsfrei) durch den
> »https://validator.w3.org/check«

Also sind die hier von einigen Leuten aufgebrachten Behauptungen, es 
wäre nur noch utf-8 zulässig, schlichtweg nicht zutreffend, und man kann 
sich auf µCs weiterhin den Aufriss sparen, utf-8-kompatible 
Stringfunktionen zu verwenden.

von Norbert (der_norbert)


Lesenswert?

So sehe ich das auch.

Möchte mir auch gar nicht vorstellen wie viele Webseiten urplötzlich 
nicht mehr gescheit funktionieren würden, wenn man das ganze ISO-8859 
Codeset Zeug plötzlich und ohne Not verbieten oder nicht mehr 
unterstützen würde.

Man trifft aber gerne mal auf Webseiten die ISO-8859 ausliefern und 
UTF-8 annoncieren. Das gibt immer lustige Klötzchen, bis man dem Browser 
manuell sagt wie er es korrekt dekodieren soll.

von Harald K. (kirnbichler)


Lesenswert?

Norbert schrieb:
> Man trifft aber gerne mal auf Webseiten die ISO-8859 ausliefern und
> UTF-8 annoncieren.

Das ist dann halt ein Fehler. Schon immer so gewesen.

Was es auch gibt, sind Webseiten, die irgendwas ausliefern, aber nicht 
bekanntgeben, was das für 'ne Codierung ist. Mag sein, daß frühere 
Browser in solchen Fällen von einem Default wie ISO-8859-1 ausgegangen 
sind, und heutige Browser das anders handhaben. Tatsächlich ist im 
Zusammenhang mit dem weiter oben diskutierten <!Doctype> auch 
beschrieben, daß jetzt implizit von utf-8 ausgegangen wird, solange 
nicht explizit was anderes angegeben wird.


Daß man als Nutzer am Browser rumspielen muss, um die Codierung zu 
"reparieren", ist schon immer nur Fehlerbehandlung gewesen.

von Norbert (der_norbert)


Lesenswert?

Harald K. schrieb:
> Das ist dann halt ein Fehler. Schon immer so gewesen.

Ja klar. Das sind zumeist, sagen wir mal ›Legacy‹-Sites welche einfach 
auf neue Server umkopiert werden. Ohne das man ihnen ein wenig Liebe und 
Fürsorge angedeihen lässt. ;-)

Harald K. schrieb:
> Daß man als Nutzer am Browser rumspielen muss, um die Codierung zu
> "reparieren", ist schon immer nur Fehlerbehandlung gewesen.

Yep. Aber man kann wenigstens korrigierend eingreifen…

von Ein T. (ein_typ)


Lesenswert?

Bauform B. schrieb:
> Aber egal, wir schreiben das Jahr 2024, tendenziell ist alles außer
> HTML5 obsolete, oder?

Vielleicht noch nicht obsolet, aber zumindest veraltet. Nimm halt 
einfach UTF-8, alles andere ist ein Kampf gegen Windmühlen (oder den 
Fortschritt).

von Harald K. (kirnbichler)


Lesenswert?

Hatten wir das nicht mittlerweile geklärt, daß es keinen Zusammenhang 
zwischen HTML5 und utf-8 gibt, außer, daß das bei HTML5 als default 
angenommen wird, wenn nicht explizit 'ne andere Codierung angegeben ist?

Es wird also niemandem was weggenommen.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Harald K. schrieb:

> Hatten wir das nicht mittlerweile geklärt, daß es keinen Zusammenhang
> zwischen HTML5 und utf-8 gibt, außer, daß das bei HTML5 als /default/
> angenommen wird, wenn nicht explizit 'ne andere Codierung angegeben ist?
>
> Es wird also niemandem was weggenommen.

Ein paar Bytes sind das schon. Immer dann, wenn man halt was anderes als 
den Default haben will. Wo kann ich die Erstattung einklagen? ;o)

von Mathias A. (mrdelphi)


Lesenswert?

Harald K. schrieb:
> Hatten wir das nicht mittlerweile geklärt, daß es keinen Zusammenhang
> zwischen HTML5 und utf-8 gibt, außer, daß das bei HTML5 als /default/
> angenommen wird, wenn nicht explizit 'ne andere Codierung angegeben ist?

Hmm wenn ich das von Norbert richtig verstehe, geht es da um HTML 4 -- 
während bei HTML5 demnach nur UTF-8 erlaubt ist:

Bauform B. schrieb:
> Was wo erlaubt ist hängt natürlich vom DOCTYPE ab und mit HTML5 ist nur
> noch utf-8 erlaubt. validator.w3.org sagt dazu eindeutig "Error", nicht
> einmal "Warning".

von Εrnst B. (ernst)


Lesenswert?

Mathias A. schrieb:
> während bei HTML5 demnach nur UTF-8 erlaubt ist:

Im Gegensatz zu HTML4 ist bei HTML5 genau spezifiziert, wie der Browser 
den verwendeten Zeichensatz herausfinden soll.

https://html.spec.whatwg.org/multipage/parsing.html#determining-the-character-encoding

Ist etwas länger, liegt daran dass das Charset an X verschiedenen 
Stellen (HTTP, <?xml, <meta usw.) angegeben werden kann, und da Regeln 
sind was bei inkonsistenten Angaben "gewinnt".

Harald K. schrieb:
> <meta charset="ISO-8859-1">
>
> Wo bitte soll das "verboten" oder auch nur "deprecated" sein?

Selbes Dokument, 13.2.3.3
>> User agents must support the encodings defined in Encoding, including,
>> but not limited to, UTF-8, ISO-8859-2, ISO-8859-7, ISO-8859-8, windows-874,
>> windows-1250, windows-1251, windows-1252, windows-1254, windows-1255,
>> windows-1256, windows-1257, windows-1258, GBK, Big5, ISO-2022-JP, Shift_JIS,
>> EUC-KR, UTF-16BE, UTF-16LE, UTF-16BE/LE, and x-user-defined.
>> User agents must not support other encodings.

Also, Spec sagt: Nimm windows-1252 statt ISO8859-1, und schon wäre es 
erlaubt in HTML5.
Und etwas weiter versteckt/verlinkt findest du die Aliase, mit denen 
andere Charset-Namen auf unterstützte Charsets verbogen werden:

https://encoding.spec.whatwg.org/#concept-encoding-get

Da ist übrigens spezifiziert, dass charset="ascii" ebenfalls als 
"windows-1252" behandelt wird.

Also: Nicht verboten, aber "obsoleter Charset", Browser nimmt einfach 
win1252 stattdessen.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Und wie wird man all dieses ganze komplett bescheuerte Durcheinander
am besten los?

-> UTF-8.

von Harald K. (kirnbichler)


Lesenswert?

Εrnst B. schrieb:
> Selbes Dokument, 13.2.3.3
>>> User agents must support the encodings defined in Encoding, including,
>>> but not limited to, UTF-8, ISO-8859-2, ISO-8859-7, ISO-8859-8, windows-874,
>>> windows-1250, windows-1251, windows-1252, windows-1254, windows-1255,
>>> windows-1256, windows-1257, windows-1258, GBK, Big5, ISO-2022-JP, Shift_JIS,
>>> EUC-KR, UTF-16BE, UTF-16LE, UTF-16BE/LE, and x-user-defined.
>>> User agents must not support other encodings.

Das hast Du gesehen? "But not limited to"

Jeder Link an dieser Stelle verweist übrigens auf 
https://encoding.spec.whatwg.org/#legacy-single-byte-encodings

Interessant ist in dem "Encoding"-Dokument auch diese Stelle:
1
4.2. Names and labels
2
3
The table below lists all encodings and their labels user agents
4
must support. User agents must not support any other encodings or
5
labels.
6
7
(...)
8
9
Legacy single-byte encodings
10
11
(...)
12
13
windows-1252   "ansi_x3.4-1968"
14
                "ascii"
15
                "cp1252"
16
                "cp819"
17
                "csisolatin1"
18
                "ibm819"
19
                "iso-8859-1"
20
                "iso-ir-100"
21
                "iso8859-1"
22
                "iso88591"
23
                "iso_8859-1"
24
                "iso_8859-1:1987"
25
                "l1"
26
                "latin1"
27
                "us-ascii"
28
                "windows-1252"
29
                "x-cp1252"

https://encoding.spec.whatwg.org/#names-and-labels

Und damit ist "iso-8859-1" sehr wohl legitim und mitnichten 
"deprecated", "verboten" oder was auch immer.


Außerdem steht in dem Dokument auch dieses:
1
13.2.3.1 Parsing with a known character encoding
2
3
When the HTML parser is to operate on an input byte stream that 
4
has a known definite encoding, then the character encoding is 
5
that encoding and the confidence is certain.

Was Du da zitierst, ist der Abschnitt, der beschreibt, wie eine 
automatische Erkennung einer Codierung zu erfolgen hat, also etwas, was 
gar nicht erst geschieht, wenn die Codierung explizit angegeben ist.

von Εrnst B. (ernst)


Lesenswert?

Harald K. schrieb:
> Und damit ist "iso-8859-1" sehr wohl legitim und mitnichten
> "deprecated", "verboten" oder was auch immer.

Doch, genau das steht da. Exakt in der Tabelle, die du zitierst.

Wenn du iso-8859-1 angibst, verwendet der Browser NICHT iso-8859-1, 
sondern immer windows-1252. Es gibt keine Möglichkeit mehr, einen 
HMTL5 Browser zur Verwendung von iso-8859-1 zu zwingen, egal was du in 
welche Header/meta-tags schreibst.

Macht praktisch keinen Unterschied, da alle druckbaren Zeichen aus dem 
Iso-Charset im Win-Charset an derselben Stelle enthalten sind.


Wenn du's nicht glaubst, bau dir ein Test-HTML, setz charset auf 
ISO8859-1 und schreib ein 0x8C Byte rein. Wenn der Browser das als "Œ" 
rendert, benutzt er win1252 entgegen deiner Anweisung.

: Bearbeitet durch User
von Harald K. (kirnbichler)


Lesenswert?

Εrnst B. schrieb:
> Wenn du iso-8859-1 angibst, verwendet der Browser NICHT iso-8859-1,
> sondern immer windows-1252.

OK. Ich denke, daß man damit gut leben kann.

Es ging mehr um die Behauptung, alles außer utf-8 wäre "verboten". Und 
genau das ist es nicht.

von Foobar (asdfasd)


Lesenswert?

Ich war auch etwas erstaunt über das "nur UTF-8" und habe mal 
nachgeschaut.  Es scheint tatsächlich so zu sein: ein HTML-5-Dokument 
<!doctype html>) ist immer UTF-8 auch wenn der charset was anderes sagt. 
Der angegebene charset wird bei Formulardaten und ein paar anderen 
Stellen benutzt, das Dokument selbst soll aber als UTF-8 interpretiert 
werden.  Kommt mir etwas extrem vor (hab es vielleicht auch falsch 
verstanden, ist alles ziemlich zerstreut), insb wenn das schon im 
HTTP-Content-Type steht, kann es aber auch irgendwie verstehen - wenn du 
HTML-5 willst, dann bitte auch UTF-8.  Was die Browser machen steht 
wieder auf einem anderen Blatt - eine Autodetektion für pre-HTML-5 haben 
sie ja eh schon drin ...

von Harald K. (kirnbichler)


Lesenswert?

Foobar schrieb:
> Es scheint tatsächlich so zu sein: ein HTML-5-Dokument
> <!doctype html>) ist immer UTF-8 auch wenn der charset was anderes sagt.

Wie kommst Du darauf?

von Sebastian W. (wangnick)


Lesenswert?

Harald K. schrieb:
> Wie kommst Du darauf?

Ich finde in https://html.spec.whatwg.org/ 4.2.5.4: "Regardless of 
whether a character encoding declaration is present or not, the actual 
character encoding used to encode the document must be UTF-8."

LG, Sebastian

von Harald K. (kirnbichler)


Lesenswert?

Das wäre in dieser Absolutheit ziemlich widersinnig; wozu dann all' der 
an den anderen Stellen beschriebene Aufriss mit der Angabe des Encoding 
und der automatischen Erkennung? Das riecht wie die Beschreibung der 
Farbauswahl beim Ford T: Jede Farbe ist erlaubt, solange sie "schwarz" 
heißt.

Ich nehme sehr stark an, daß die Autoren dieses Textes möchten, daß /in 
Zukunft/ nur noch utf-8 eingesetzt wird, darauf deutet

> To enforce the above rules, authoring tools must default to
> using UTF-8 for newly-created documents.

hin.

von Sebastian W. (wangnick)


Lesenswert?

Harald K. schrieb:
> wozu dann all' der
> an den anderen Stellen beschriebene Aufriss mit der Angabe des Encoding

Tja. Ich hab mich auch gewundert. Aber im Standard ist auch an den 
anderen Stellen beschrieben, dass man bei Angabe des Encoding nur 
UTF-8 als Encoding angeben darf ...

LG, Sebastian

von Harald K. (kirnbichler)


Lesenswert?

Nun, ich bin kein "Webdesigner"; und ich werde in den wenigen 
Anwendungen, die ich dafür habe, weiterhin geflissentlich über derartig 
widersprüchliche Ansagen hinwegsehen. "Webdesigner" ist schließlich auch 
keine Berufsbezeichnung, sondern eher ein Schimpfwort.

von Ralf D. (doeblitz)


Lesenswert?

Sebastian W. schrieb:
> Harald K. schrieb:
>> wozu dann all' der
>> an den anderen Stellen beschriebene Aufriss mit der Angabe des Encoding
>
> Tja. Ich hab mich auch gewundert. Aber im Standard ist auch an den
> anderen Stellen beschrieben, dass man bei Angabe des Encoding *nur*
> UTF-8 als Encoding angeben darf ...

Der Standard unterscheide deutlich zwischen Producer und Consumer. Eun 
Producer darf nur noch UTF-8 verwenden, ein Consumer muss aber auch die 
ganzen Legacy-Encodings noch verstehen und korrekt in UTF-8 
transformieren können.

Wer also HTML-Content in Windows-1252 kodiert ausgibt, der produziert 
non-conforming documents, die aber trotzdem (noch) korrekt angezeigt 
werden (sollten).

von Harald K. (kirnbichler)


Lesenswert?

Ralf D. schrieb:
> Wer also HTML-Content in Windows-1252 kodiert ausgibt, der produziert
> non-conforming documents

Weiter oben im Thread beschreibt jemand eine Sitzung mit einem 
HTML-Validator, der diese Kombination nicht bemängelt.
Beitrag "Re: HTML mit charset=iso-8859-1"

Hmm.

von Mathias A. (mrdelphi)


Lesenswert?

Harald K. schrieb:
> Ralf D. schrieb:
>> Wer also HTML-Content in Windows-1252 kodiert ausgibt, der produziert
>> non-conforming documents
>
> Weiter oben im Thread beschreibt jemand eine Sitzung mit einem
> HTML-Validator, der diese Kombination nicht bemängelt.
> Beitrag "Re: HTML mit charset=iso-8859-1"
>
> Hmm.

Wenn ich das recht sehe, wird dort HTML 4 und nicht 5 verwendet oder?

von Bauform B. (bauformb)


Lesenswert?

Harald K. schrieb:
> Weiter oben im Thread beschreibt jemand eine Sitzung mit einem
> HTML-Validator, der diese Kombination nicht bemängelt.
> Beitrag "Re: HTML mit charset=iso-8859-1"
>
> Hmm.

Ich finde, Ralf hat es gut und eindeutig erklärt.

Ralf D. schrieb:
> Der Standard unterscheide deutlich zwischen Producer und Consumer. Eun
> Producer darf nur noch UTF-8 verwenden, ein Consumer muss aber auch die
> ganzen Legacy-Encodings noch verstehen und korrekt in UTF-8
> transformieren können.
>
> Wer also HTML-Content in Windows-1252 kodiert ausgibt, der produziert
> non-conforming documents, die aber trotzdem (noch) korrekt angezeigt
> werden (sollten).

Den letzten Satz könnte man noch verfeinern: natürlich gehört zu 
Windows-1252 ein HTML4 Doctype, dann wird das auch conforming, deshalb 
meckert der validator nicht. Aber es ist immer noch deprecated.

: Bearbeitet durch User
von Norbert (der_norbert)


Lesenswert?

Bauform B. schrieb:
> Den letzten Satz könnte man noch verfeinern: natürlich gehört zu
> Windows-1252 ein HTML4 Doctype, dann wird das auch conforming, deshalb
> meckert der validator nicht. Aber es ist immer noch deprecated.

HTML4 ist nicht deprecated!
HTML4 Transitional ist nicht deprecated!

Nur einige wenige Elemente sind deprecated. Von denen reden wir hier 
aber gar nicht, da sie einfach nur (größtenteils) in Style Sheets 
gewandert sind.

Im Umkehrschluß:
HTML5 und UTF-8 ist valid.
HTML4 und alles an ISO-8859-x sowie auch UTF-8 ist valid.

Das ergibt sich aber auch alles wenn man die docs liest.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Was mich im Grunde daran nervt ist, daß sich der Browser eines DAU an 
nichts zu halten braucht. Wenn ich mitteile hey, sende mir deine Daten 
bitte als ISO-0815-irgendwas, und der DAU gibt dann irgendwelche 
Sonderzeichen ein, bekommt man trotz seiner Anfrage entweder 
irgendwelchen Müll oder ein anderes Encoding zurück, mit dem man sich 
dann herumschlagen darf. In jedem Land gibt's irgendwelche Umlaute oder 
gern genutzte Sonderzeichen, die den erwarteten Rahmen der Eingaben 
sprengen.

Also bin ich der Meinung, man sollte dieses offensichtlich nicht in 
vollem Umfang funktionierende System vergessen und stattdessen eines 
benutzen, was das Problem auf jeden Fall löst. Wenn man sich einmal 
daran gewöhnt hat, auch an den zusätzlichen Aufwand beim Programmieren - 
wobei der mit Hinblick auf User-Eingaben und die Sicherheit von 
Datenbanken sowieso erforderlich ist - dann hat man das Problem nicht 
mehr. Wenn der User dann Scheiße eingibt, bekommt er zwar immer noch 
Scheiße zurück - aber wenigstens exakt seine eigene und keine, die man 
als Programmierer verzapft hat.

von Norbert (der_norbert)


Lesenswert?

Ben B. schrieb:
> Also bin ich der Meinung, man sollte dieses offensichtlich nicht in
> vollem Umfang funktionierende System vergessen und stattdessen eines
> benutzen, was das Problem auf jeden Fall löst.

Nur das wir hier von einem sehr simplen µC reden, der ganz 
offensichtlich nur einige wenige Sonderzeichen (°,…) ausgeben soll.
Und das kanna und das tuta ohne sich rückwärts über zu beugen…

Und ebenso ohne Aspekte zu berücksichtigen, welche auf einer großen 
Webapplikation durchaus zuträfen, hier jedoch völlig belanglos sind.

von Ein T. (ein_typ)


Lesenswert?

Harald K. schrieb:
> Hatten wir das nicht mittlerweile geklärt, daß es keinen Zusammenhang
> zwischen HTML5 und utf-8 gibt, außer, daß das bei HTML5 als /default/
> angenommen wird, wenn nicht explizit 'ne andere Codierung angegeben ist?

Spielt das eine Rolle?

> Es wird also niemandem was weggenommen.

Davon redet doch keiner.

UTF-8 ist erlaubt, die einfachste, und die komfortabelste Lösung. Und 
damit ist die Frage des TO besser beantwortet als mit Deinem ganzen 
Genörgel.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Ein T. schrieb:
> UTF-8 ist erlaubt, die einfachste, und die komfortabelste Lösung

Sehe ich auch so.

Norbert schrieb:
> Und das kanna und das tuta ohne sich rückwärts über zu beugen…

Ein u8 dem String-Literal voranzustellen oder meinetwegen den Execution 
Charset festzulegen ist m.E. kein "rückwärts über beugen".

von Bauform B. (bauformb)


Lesenswert?

Harald K. schrieb:
> Es wird also niemandem was weggenommen.

Warte nur. extern int errno haben sie uns auch weggenommen. Und Scrollen 
auf der Linux Textkonsole. Das fehlt mir immer noch, fast jeden Tag :(

von Daniel F. (df311)


Lesenswert?

Bauform B. schrieb:
> Und Scrollen auf der Linux Textkonsole.

tmux ;-)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.