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.
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.
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
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 & 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.
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
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"
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.
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?
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
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.
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"?
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.
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?
> 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.
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
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?
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
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
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.
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?
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.
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.
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.
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.ä.
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.
Ε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.
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>
|
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.
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.
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.
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…
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).
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.
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)
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".
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.
Und wie wird man all dieses ganze komplett bescheuerte Durcheinander am besten los? -> UTF-8.
Ε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.
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
Ε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.
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 ...
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?
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
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.
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
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.
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).
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.
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?
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
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.
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.
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.
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.
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".
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 :(
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.