Checkliste für die Zeichencodierung in HTML

Diese Seite behandelt Szenarien mit unterschiedlichen Zeichensätzen und spricht Empfehlungen aus, um die Zugänglichkeit auf älteren Browsern und Versionen zu verbessern. Die Betonung liegt hier eher auf deutlichen Empfehlungen - die von genügend vielen Browsern interpretiert werden können, sofern diese richtig konfiguriert wurden - als darauf, zu viele Ausnahmen und Sonderfälle zu erklären: Anderes Hilfsmaterial aus diesem Bereich sollte dazu dienen, die verschiedenen Möglichkeiten zu verstehen. Formulareingaben werden hier nicht behandelt. (Einige unvollständige Anmerkungen zu Formulareingaben sind ebenfalls erhältlich.)

Wichtig: Diese Webseite konzentriert sich auf die Form des Dokuments, wie es von einem Web-Server (HTTP-Server) als text/html versendet wird, und behandelt weder das Anfertigen noch das Laden auf den Server. Es gibt zu viele unterschiedliche Details (auch vom Betriebssystem abhängig), um sie hier angemessen zu behandeln. Hingegen ist das, was vom Server zum Client geschickt wird, klar definiert und plattformunabhängig (Anderenfalls wäre es in Hinsicht auf das WWW ein Versagen!), und darauf wollen wir uns hier konzentrieren.

Kompatibilität mit älteren Browsern ist nur dann relevant, wenn es um den content-type text/html geht: Das ist entweden "passendes HTML" oder kompatibles XHTML/1.0 ("appendix C"). Wer XML-Basierte Content-Types gebrauchen will, wird unvermeidbar mit älteren Browsern (und einigen neuen auch) inkompatibel werden. Wenn utf-8 passend ist, dann benutzt das. Es gibt eine Anmerkung zum Schreiben von xhtml/1.0 aus Kompatibilitätsgründen.

Begriffe

Die hier gebrauchte Terminologie wird im HTML und WWW-Kontext gebraucht, was bei Leuten, die Zeichenbehandlung in einem anderen Kontext kennengelernt haben (zB bei Textverarbeitungen) zu Verwirrung führen kann. Hier ist aber nicht der Platz für ein komplettes Tutorial: Ich habe versucht die Checkliste für die verständlich zu halten, die keines vertiefte Kenntnis des Themas haben, aber ich empfehle eine gewisse Vertrautheit mit dem Zeichenmodell anzueignen, um unnötige Verwirrung zu vermeiden.

Zeichenvorrat (character repertoire) oder Zeichensatz (character set) bezeichnet eine Menge von Zeichen ohne Rücksicht auf ihre Anordnung und Codierung. Ein Zeichen kann Schriftzeichen (graphic character) oder Steuerzeichen (control character) sein. Im Folgenden wird nur die Rede von Schriftzeichen sein.
Beispiele:
Latein 1 - die Menge der Zeichen, die in ISO/IEC 8859-1 aufgeführt sind und die zum Schreiben der Sprachen Westeuropas benötigt werden;
Latein 2 - die Menge der Zeichen, die in ISO/IEC 8859-2 aufgeführt sind und die zum Schreiben der Sprachen Mitteleuropas benötigt werden;
Latein 1 und Latein 2 - die Gesamtmenge aller Zeichen, die in ISO/IEC 8859-1 oder in ISO/IEC 8859-2 aufgeführt sind.
Anmerkung:
Im Deutschen wird manchmal das Wort "Zeichensatz" im Sinne von Schrift (font) verwendet, was gänzlich falsch und irreführend ist.

Codierung (encoding, coding) bezeichnet eine Zuordnung von Bitkombinationen zu den Zeichen eines Zeichenvorrats/Zeichensatzes.

Codierter Zeichensatz (coded character set) oder kurz Code (code) bezeichnet einen Zeichenvorrat/Zeichensatz zusammen mit einer Codierung. Sind die Bitkombinationen stets 8 Bit lang, spricht man von einem 8-Bit-Code. Ein codierter Zeichensatz wird häufig durch eine Code-Tabelle (code table) in Form einer Matrix grafisch dargestellt.
Beispiele:
US-ASCII - der in ISO/IEC 646 festgelegte 7-Bit-Code;
ISO-8859-1 - Latein 1 mit der in ISO/IEC 8859-1 festgelegten Codierung;
TIS-620 - Code nach der Thailändischen Norm TIS-620;
Windows-1252 - Microsofts Code Page 1252 für MS Windows (Westeuropa).

Codiertes Zeichen bezeichnet ein Zeichen in einer bestimmten Codierung; d.h. ein einzelnes Byte (Oktett) im Fall eines 8-Bit-Codes oder eine geeignete Bytefolge im Fall einer Multibyte-Codierung.
Im Unterschied dazu kann ein Zeichen in HTML auch durch eine der &-Formen (als Zeichenname durch &entity;, als Zeichennummer &#number; dezimal (breit Unterstützt) oder auch &#xhhhh; hexadezimal (weniger Unterstützt)) dargestellt werden.

Theoretisch sind die drei verschiedenen Arten der Zeichendarstellung - das codierte Zeichen, die Zeichennummer und (wo vorhanden) die benannte Characterentity - völlig gleichwertig in HTML. Sinn dieser Checkliste ist es, die praktischen Probleme zu untersuchen, die in tatsächlichen Situationen die eine oder die andere Darstellung vorteilhafter erscheinen lassen. Diese Situationen werden unten als "Szenarien" vorgestellt.

Deklarieren als bezeichnet die Angabe der bestimmten Codierung, in der das Dokument vom HTTP-Server auszusenden ist. In der MIME-Terminologie geschieht das durch den Parameter charset, der als Abkürzung für "coded character set" aufzufassen ist. Dazu sollte im HTTP-Header  Content-Type: text/html;charset=...  angegeben werden. Nach den HTML-Regeln kann man dies auch über die Zeile  <meta http-equiv="Content-Type" content="text/html;charset=...">  im Kopf des HTML-Dokuments angeben. Dies ist aber sowohl theoretisch als auch praktisch weniger zufriedenstellend, wie hier detailliert ausgeführt.
Im Kopf von XHTML-Dokumenten könnte die Zeile  <?xml version="1.0" encoding="..."?>  erforderlich sein.
Die entsprechenden Bezeichnungen wie UTF-8, ISO-8859-1, Windows-1252 sind bei der IANA registriert. Nichtregistrierte beginnen mit einem x-, z.B. x-Mac-Cyrillic.

Ein 8-Bit-Zeichenvorrat repräsentiert den größten Zeichenvorrat, den viele ältere Browser zu einem bestimmten Zeitpunkt unterstützen können - zumindest mit regelrechten Techniken. (Beachte: Ein HTML-Dokument hat gänzlich in einer Codierung zu sein; es ist nicht möglich, die Codierung mitten in einem einzelnen Dokument zu ändern.) Viele dieser älteren Browser unterstützen mehrere 8-Bit-Zeichenvorräte: typischerweise indem der Browser, abhängig von der empfangenen Zeichencodierung, automatisch zwischen verschiedenen 8-Bit-Schriften wechselt.
Einige neuere Browserversionen, auch wenn sie Unicode nicht vollständig unterstützen, können trotzdem Dokumente verarbeiten mit einem umfangreicherem Zeichenvorrat als nur einem einzigem 8-Bit-Code, wie zum Beispiel in Szenario 5 gezeigt.

Ich werde nicht versuchen, chinesische, japanische, koreanische (CJK) Schriftzeichen zu behandeln, weil sich diese außerhalb meiner Sachkenntnis befinden.

Szenario Zeichenvorrat Empfehlung Anmerkung
1 Latein-1 Zeichenname &entityname; (weit unterstützt und einfach zu merken) oder Zeichennummer &#number;.
Als ISO-8859-1 deklarieren.
Inbesondere denjenigen empfohlen, die plattformübergreifend (z.B. mit Macs) arbeiten, ohne die notwendigen Fachkenntnise im Umgang mit 8-Bit-codiertem Text zu haben.
Siehe auch die Hinweise der WDG.
2 Latein 1 Alternative zu Szenario 1:
8-Bit-codierte Zeichen, deklariert als ISO-8859-1.
Entgegen einem weit verbreiteten Aberglauben sind 8-Bit-codierte Zeichen im WWW unbeschränkt zulässig (siehe auch die Anmerkung A).
3 Latein-1 mit typographischen Erweiterungen durch Windows (Anführungszeichen, Gedankenstriche usw.) Nicht empfohlen, siehe Anmerkung B. Falls ohnehin ein erweiterter Zeichenvorrat verwendet wird, dann mit Szenario 6 (eventuell 7).
3a Der Windows Latein-1 Vorrat
inclusive des EURO
Proprietär und nicht wirklich empfohlen, aber zugegebenermaßen sogar von recht alten Browsern, die mit dem Szenario 6 nicht zurchtkommen, recht weit unterstützt: gebrauche 8-bit Zeichen, die mit charset=windows-1252 codiert sind.
Alternativ: Anmerkung B.
Die zukunftsorientierte Herangehensweise sind die Szenarien 6 oder 7.
Eine kombinierte Latein-1 mit einem anderen 8-Bit Vorrat (zB. Latein-2 oder Latein-9/iso-8859-15) Abdeckung könnte durch Szenario 5 erreicht werden. Siehe auch die Diskussion in Anmerkung B.
&euro; wird inzwischen recht weit unterstützt, und kann in Szenario 1 oder 2 verwendet werden.
4 Ein 8-Bit-Zeichenvorrat Wähle einen 8-Bit-Code, der für den gewünschten Zeichenvorrat geeignet ist (vorzugsweise eine ISO-Codierung, z.B. ISO-8859-7 für Griechisch, oder eine weit verbreitete, z.B. TIS-620 für Thailändisch).
Gebrauche entsprechend deklarierte 8-Bit-Zeichen.
Diese Dokumentenform ist für eine große Zahl von Browserversionen zugänglich, auch für ältere, obwohl möglicherweise zusätzliche Einstellungen oder Schriften nötig sind, um die Vorteile der Browserfähigkeiten zu nutzen. Einige Punkte werden von J.Korpela behandelt.
Die Unterstützung für iso-8859-15 ist bei älteren Browsern schlecht.
5 Latein 1 zusammen mit einem anderen 8-Bit-Zeichenvorrat Zeichen, die nicht in Latein 1 sind, wie in Szenario 4 als 8-Bit-codierte Zeichen, mit der entsprechenden Codierung (charset) deklariert. Zeichen aus Latein 1 wie in Szenario 1 mittels &entity; darstellen. Diese Dokumentenform ist vollgültig und für jeden RFC-2070-konformen Client zugänglich, aber viele Zeichen versagen bei den 4er Versionen von Netscape. Siehe Anmerkung F.
Siehe Szenario 8 für eine mögliche Umgehung.
6 Mehr als ein 8-Bit-Zeichenvorrat, aber überwiegend lateinischer Text Nur us-ascii Zeichen (d.h. 7 Bit) verwenden und alle anderen Zeichen, auch die aus Latein 1, mittels &-Notation darstellen. Für Latein-1-Zeichen, wird &entity; empfohlen, für den Rest &#bignumber; (Unicode-Werte), auch dort, wo ein HTML-4-Zeichenname definiert ist, weil die Browserunterstützung verbreiteter ist.
Dokument als UTF-8 deklarieren.
Dies benötigt natürlich eine Browserversion, die HTML 4/RFC 2070 genügend unterstützt. Dementsprechend werden einige Browserversionen, die den Szenarien 4 oder 5 gewachsen sind, ausgeschlossen. Der Browser könnte weitere Einstellungen benötigen, um diese Fähigkeiten zu ermöglichen, z.B. weitere Schriften und Voreinstellungen. Vergleiche auch Szenario 8.
Siehe Anmerkung C.
7 Mehr als ein 8-Bit-Zeichenvorrat, nicht überwiegend lateinischer Text Gebrauche Zeichen, die tatsächlich mit UTF-8 codiert sind, entsprechend deklariert. Wie Szenario 6 ist dies eine vollgültige Art, um Dokumente auszusenden, und sie ist sowohl für jeden RFC2070-konformen Browser, als auch für die 4er Versionen von Netscape akzeptabel. Die Browserunterstützung für beide Arten scheint ziemlich gleich zu sein. Die zu erwartenden Schwierigkeiten sind nicht die Browser, sondern die Autoren, die dieses ungewohnte Datenformat falsch handhaben.
8 Kompromisslösung für Szenario 5 mit den Techniken der Szenarien 6 oder 7, für die Browser, die das unterstützen Erstelle das Dokument in zwei unterschiedlichen Versionen (oder generiere diese bei Bedarf "on the fly").
Nutze die "server negotiation" (ausgehend vom Header Accept-charset des Clients), um eine UTF-8-Version an diejenigen Clients zu senden, die angeben dies zu verstehen (das schließt die 4er Versionen von Netscape ein, die ansonsten in dieser Hinsicht fehlerhaft sind), während alle anderen Clients die Version nach Szenario 5 bekommen. Siehe Anmerkung D.

Kommentare

Vielseitigkeit: Alle Codierungstechniken, die hier empfohlen werden, gebrauchen gültige Techniken in Übereinstimmung mit den veröffentlichten Regeln und können (unter Beachtung der Einschränkungen der empfohlenen Schemata) automatisch von der einen in die andere Art konvertiert werden. Somit ist es nicht wesentlich, dass ein Editor/Werkzeug die empfohlene Form exakt produziert: Man kann eine Form automatisch in eine andere Form konvertieren.

Eine kleine Warnung: Auch wenn die hier diskutierten Browserversionen technisch fähig sind, das Beschriebene umzusetzen, ist es nicht sicher, dass eine bestimmte Browserinstallation das auch beherrscht: Der Benutzer könnte eine spezielle Schrift benötigen (z.B. für Thailändisch, Armenisch, ...) oder manuell eine benutzerdefinierte Zeichencodierung einstellen müssen, wenn der Browser diese in Frage kommende Codierung nicht explizit unterstützt. Man kann erwarten, dass Benutzer in diesen Gegenden die Details bereits gelöst haben. Falls aber auch "Außenseiter" diese Dokumente korrekt betrachten sollen, könnte es vorteilhaft sein, eine kleine Testseite mit einem Screenshot (damit die Ergebnisse verglichen werden können) bereitzustellen. Einige Anmerkungen zu evtl. notwendigen Einstellungen (die am Browser vorgenommen werden müssen) und Veränderungen am System sollten auch mitgegeben werden.

Ein wichtiger Punkt ist die Zugänglichkeit der Dokumente nicht nur für die Browser der Benutzer, sondern auch für Suchmaschinen. A. Prilop warnt, dass viele Suchmaschinen mit der Codierung UTF-8 noch nicht zurechtkommen - Es scheint, dass frühere Probleme inzwischen behoben sind, aber um optimale Ergebnisse zu erzielen könnte es sinnvoll sein passende 8-Bit codierungen als Alternativen zur UTF-8 Version (wie in Szenario 8 gezeigt) bereitzustellen.
Der Gebrauch von der Latein 1 Character entities &entityname; anstelle anderer Darstellungsarten, hilft, Zeichenketten mit Latein-1-Zeichen wiederzufinden. Aber natürlich hilft das nicht bei Zeichen, die sich nicht in dem Zeichenvorrat Latein 1 befindet.

Bei den Zeichennamen von HTML 4.0 außerhalb von Latein 1 gibt es ein Dilemma. Einerseits gibt es keinen Zweifel, dass das Format &#bignumber; weiter implementiert ist als das Format &entityname;, sei es auch nur wegen der 4er Versionen von Netscape. Andererseits wird wahrscheinlich ein Browser, der &entityname; nicht versteht, etwas eingermaßen Verständliches anzeigen (nämlich das Wort "entityname"); während einer, der &#bignumber; nicht versteht, wahrscheinlich unverständlichen Müll darstellen wird (oder in einigen Browserversionen die Zahl bignumber "modulo 256" nehmen und das Zeichen entsprechend dem Ergebnis anzeigen!). Somit ist eine generelle Empfehlung, welche Form vorzuziehen ist, schwierig: es hängt nicht nur vom Kontext ab, sondern auch, welches Fehlerverhalten vorgezogen wird.


Anmerkungen

[A] 8-Bit-codierte Zeichen

Entgegen einem weit verbreiteten Aberglauben sind 8-Bit-codierte Zeichen im WWW unbeschränkt zulässig: Wenn man außerhalb des Zeichenvorrates Latein 1 arbeitet und eine weite Browserabdeckung wünscht, hat man tatsächlich wenig Auswahl (vgl. Szenario 4). Jedoch sind Dokumente mit 8-Bit-Zeichen weniger robust gegenüber Fehlern bei der Erstellung und beim Publizieren im WWW. Probleme können auftreten beim Betrachten von lokalen Dateien und bei der Übertragung zwischen verschiedenen Plattformen, etwa mittels FTP:// - ein Protokoll, das keine charset-Deklaration kennt.

Dennoch empfehle ich, Dokumente so zu gestalten, dass sie über einen richtig konfigurierten HTTP-Server betrachtet werden können, und sich nicht von eher lokalen Problemen beeinflussen zu lassen.

[B] Typographische Zeichen aus Windows

Der Windows Latein-1 Zeichenvorrat (in der Windows-1252 Codierung) deckt den gesamten ISO Latein-1 Vorrat, zusammen mit einigen zusätzlichen Zeichen: typografischen Feinheiten (em-dash, en-dash, etc) und Zeichen aus dem Latein-9 Vorrat (Z-hacek, S-hacek, das EURO-Zeichen, etc.: vergleiche J. Korpelas Übersicht) ab. Latein-9 ist der Vorrat der iso-8859-15 Codierung.

Hier wird nicht empfohlen diesen proprietären Vorrat zu verwenden, nur um die typografischen Feinheiten zu bekommen (Szenario 3). Es könnte aber Situationen geben, wo eine größere Zahl an Windowszeichen gewünscht wird. Die Verwendung ist diskussionswürdig (obwohl ich Ihr engegentrete), dass der Gebrauch von Windows-1252 Zeichen der Verwendung von Unicodezeichen vorzugswürdig ist; diese Option wir als Szenario 3a aufgeführt.

Grundsätzlich werden zwei "nicht-Standard-Techniken" genutzt, die kein gültiges HTML 4 sind, um die typographischen Zeichen aus Windows (Anführungszeichen, Gedankenstriche usw.) in HTML darzustellen. Die gültigen HTML-4-Techniken könnten bei den Szenarien 6 oder 7 ohne grundsätzliche Kritik angewandt werden; aber sie würden die Zugänglichkeit des Dokumentes für Browser beschränken, die diesen Teil von HTML 4 unterstützen - was keine so gute Idee ist, wenn ein erweiterter Zeichenvorrat nicht aus einem anderen Grund benötigt wird.

Die beiden "nicht-Standard-Techniken" basieren auf theoretisch anfechtbaren Prinzipien und sie können auch ungünstige praktische Auswirkungen haben, wie auf der Seite des "Demoronizers" treffsicher dargelegt. Es gibt auch einen informativen Artikel von J. Korpela.

Die weiterverbreitete "nicht-Standard-Technik" gebraucht undefinierte Zeichennummern &#number; im Bereich von 128 bis 159 dezimal, welche die veröffentlichten HTML-Regeln als unbelegt ausweisen. Mir wurde von einem SGML-Spezialisten versichert, dass SGML selbst den Gebrauch dieser undefinierten Werte in gegenseitiger Übereinstimmung zwischen den Parteien erlaubt und dass dies der Grund ist, dass formale Validatoren diese nicht bemängeln. Ihr Gebrauch in HTML wird als Unsauber angesehen und der W3C Validator bemängelt diese inzwischen. Ich kann nicht leugnen, dass dieser Missbrauch, statistisch betrachtet, weit unterstützt wird (weil statistisch betrachtet viele Leute die Software von Microsoft nutzen und einige andere Hersteller keine Alternative sehen, als diesen Gebrauch ebenfalls zu unterstützen, unabhängig davon, was die Regeln festschreiben); aber für eine weite Abdeckung durch viele Browser und Versionen sollte dies vermieden werden.

Die weniger verbreitete der beiden Methoden ist der Gebrauch der Zeichencodierung Windows-1252 (die schließlich doch noch bei IANA registriert wurde), um dann diese Zeichen als tatsächliche 8-Bit-Zeichen zu senden (Bytes mit Werten im Bereich 128 bis 159 dezimal). Obwohl die Registrierung durch die IANA aussagt, dass diese Codierung legal im Zusammenhang mit MIME im Internet verwendet werden kann, heißt das nicht, dass WWW-Clients diese auch zwingend unterstützen müssen. Wieder haben wir die Situation, dass man mit dieser Zeichencodierung, obwohl sie statistisch betrachtet wegen des Einflusses dieses Herstellers weitverbreitet ist, eine größere Browserabdeckung erhält, wenn man Browser nicht mit dieser Codierung herausfordert. Wenn man (wider meine bessere Empfehlung!) dies doch macht, dann gibt es immer noch einen kleinen Vorteil, wenn man dennoch die Latein-1-Zeichen mit ihrer &entityname;-Notation in HTML verwendet, weil diese sogar von Clients verstanden werden, die die Codierung charset=Windows-1252 nicht verstehen.

Ein vernünftiger gültiger Ansatz wäre es, die typographischen Zeichen aus Windows durch ihre HTML-4-Zeichennamen wie &mdash;, &rsquo;, &trade; usw. darzustellen. Diese sind in der Tat schon eine ganze Weile bekannt und werden von einer Zahl alter Browser verstanden, die UTF-8 nicht unterstützen und demnach nicht imstande wären, die Darstellung durch &#bignumber; zu verstehen. Leider wird diese Vorgehensweise sabotiert durch das Versäumnis, diese Zeichennamen in Netscape 4.* zu implementieren.

Die Einbindung von &euro; scheint besser als die anderer HTML4.0 Zeichenentitäten zu sein, aber immer noch nicht unproblematisch: J.Korpela's page on the euro: Ich schlage vor, dass, wenn der EURO das einzige zusätzlich benötigte Zeichen ist, die Verwendung von &euro; in den Szenarien 1 oder 2 akzeptabel ist, auch wenn ein Teil der Browser/Plattformen damit Probleme hat. Mir scheinen die Resultate besser zu sein, als der Versuch iso-8859-15 in einem HTML context zu verwenden. Wenn rechtliche Genauigkeit gefordert wird, ist die einzige vertretbare Empfehlung die Verwendung des Bankencodes: EUR.

Eine weitere gültige Vorgehensweise ist das Dokument als charset=iso-8859-1 zu deklarieren und die MS-Windows Zeichen durch die entsprechende &#bignumber; Unicode Referenz einzubinden. Dies funktioniert mit Win-NN4 Versionen gut, aber es ist wahrscheinlich, dass es auf anderen Plattformen zu Problemen kommt zB Macs; neuere X-basierte (dH Linux) Versionen von NN4 scheinen ein brauchbares Rückfallverhalten für diese Zeichen zu haben.

Alles in allem empfehle ich, diese Zeichen zu vermeiden; es sei denn, das Dokument benötigt bereits einen größeren Zeichenvorrat wie in den Szenarien 6 oder 7. Dann kann man annehmen kann, dass jeder Browser, der diesen Szenarien entspricht, auch den typographischen Zeichen aus Windows gewachsen ist - natürlich in einer korrekten HTML-Repräsentierung ausgedrückt.

Soweit ich sehe ist mit WebTV der Gebrauch der windows-1252 Codierung der einzige praktisch taugliche "standardkonforme" (obwohl proprietäre) Weg etwas zusätzlich zu iso-8859-1 zu bekommen. WebTV scheint die angegebene Codierung zu ignorieren und alles als ein modifiziertes Windows-1252 zu behandeln (Das EURO Zeichen, wie auch Z-hacek und z-hacek fehlen in der von mir getesteten Version: Microsoft ist am Zug und vielleicht kann man sie überzeugen, nochmals in ihre eigene Spezifikation der Zeichencodierung hineinzuschauen?). WebTV behauptet zwar HTML4 zu unterstützen, aber Unicode Referenzen der Windows Zeichen, wie zB &#8220;, werden nicht korrekt angezeigt, was ein böser Fehler ist. Es wurde berichtet, dass er auf &#number; Referenzen im Bereich 128 bis 159 dezimal auf dieselbe Weise reagiert wie auf die entsprechenden codierten Zeichen. Wie bereits angemerkt, sind diese numerischen Referenzen in standard HTML nicht akzeptabel, während die windows-1252 codierten Zeichen zulässing sind (obwohl die Zeichencodierung proprietär ist).

[C] Der "konservative" Ansatz zu i18n

Diese Technik (wie auch in der Kurzübersicht erklärt) beruht auf der Tatsache, dass die Unicode-Codierung UTF-8 als echte Obermenge von US-ASCII konstruiert wurde. Wir schreiben also unsere Seite ausschließlich mit ASCII-Zeichen, deklarieren aber als UTF-8 (was ja tatsächlich stimmt), um Netscape 4.* in seinen Modus zu verleiten, wo er Unicode-Zeichen zur Darstellung verwendet. Dies ist eine vollgültige Option in HTML 4 (obschon eine sehr aufwendige, wenn eine größere Zahl von Zeichen durch &#bignumber; dargestellt werden muss), und wird demnach auch von jedem Client, der diesen Teil von RFC 2070 und HTML 4 unterstützt, akzeptiert werden. Siehe die Kurzübersicht für weitere Überlegungen.

Ich empfehle den Gebrauch der Notation &#bignumber; sogar für die Zeichen, für die HTML-4-Regeln einen Namen &entityname; festlegen, weil diese Zeichennamen (abgesehen von den Latein-1-Zeichen) nicht so weit unterstützt werden, wie man hofft (wiederum ist Netscape 4.* der größte Schuldige).

Zu beachten ist, dass alle Browser, auch wenn sie technisch fähig sind, diese Empfehlungen umzusetzen, nur funktionieren, wenn sie mit den entsprechenden Schriften konfiguriert sind. Es mag zusätzliche Probleme mit X-basierten Versionen (zB Linux) von Netscape 4.*, die nur teilweise Unterstützung für Unicode haben, zu geben.

[D] "Accept-charset negotiation"

Dieser Ansatz führt leider auch nicht dazu, dass ein "Szenario 5" Dokument für ältere Browser zugänglich wird, wenn Sie keine der beiden Techniken unterstützen. Aber es gibt auch nicht viel, was wir für diese machen können (außer Grafiken), wenn das Dokument einen größeren Zeichenvorrat verlangt.

Weil es keine sichere Möglichkeit der Feststellung gibt, ob die Einstellungen des Benutzers zufriedenstellend sind, muss ich folgern, dass es akzeptabel ist, dass diese Variante eines Dokumentes zum Client gesendet wird, wenn dieser utf-8 in seinem Accept-charset Header aufführt: Es hat keinen Zweck, die Zeichenkette User-Agent daraufhin zu untersuchen, dass Netscape identifiziert und ausgeschlossen wird (eine solche Torheit sollte beinahe immer vermieden werden).

Clients, die keine Unterstützung für UTF-8 signalisieren, würden demnach die Dokumentenvariante mit der Codierung aus Szenario 5 zugesendet bekommen. Dies wird auch einigermaßen gut abgedeckt (z.B. Win IE 3 und einige weniger weit verbreitete Browser, die (vor recht langer Zeit) getestet wurden - vergleiche den i18n Browsertest).

Es ist vollkommen in Ordnung, beide Varianten explizit anzubieten, wenn man den Betrachtern die Wahlmöglichkeit geben will oder man sich nicht mit der "Server-side negotiation" verheddern will. Ich selber möchte Benutzer nicht mit technischen Details belasten; aber manchmal lässt sich das nicht vermeiden.

Obwohl Formulareingaben hier nicht explizit behandelt werden, sei erwähnt: Die (Mac- und Win-) Netscape 4.* Versionen zeigen mittels Accept-charset an, dass sie fähig sind, UTF-8 zu verarbeiten (Sie sind tatsächlich fähig dieses anzuzeigen), aber sie können bei Formularen nicht mit UTF-8 umgehen. Ich arbeite daran, ein Schriftstück über Formulareingaben und i18n zu erstellen, wo diese Probleme angesprochen werden.

[F] Szenario 5: Probleme mit Netscape 4

Die 4er Versionen von Netscape sind in diesem Szenario grundsätzlich unbrauchbar, obwohl es eine Zahl an Möglichkeiten gibt, die funktionieren. Im Wesentlichen weigert sich Netscape 4.*, Zeichen anzuzeigen, wenn diese als &entityname; oder &#number; dargestellt werden, diese aber im Zeichenvorrat des Clients nicht verfügbar sind. Kurz gesagt, von dieser armseligen Browserfamilie werden &-Notationen nur unterstützt, wenn sie theoretisch nicht benötigt werden und sie versagen genau dann, wenn sie benötigt würden.

Mit im wesentlichen lateinischen Schriftzeichen, z.B. Mitteleuropäisch, Baltisch, Türkisch, kann man immer noch den Großteil der akzentuierten Zeichen verwenden, die man bei Latein 1 brauchen würde: Es wird empfohlen, dass, wegen der Unzugänglichkeiten verschiedener Software, die Latein-1-Zeichen durch die Namen &entityname; dargestellt werden, obwohl die 8-Bit-codierten Zeichen theoretisch gleichwertig sind.

[X]Compatible XHTML/1.0 (Appendix C)

Wenn man Appendix-C kompatibel XHTML/1.0 schreiben will, gibt es nach der Spezifikation vom Grundsatz her zei Möglichkeiten die Zeichencodierung (charset) zu deklarieren:

Die Auswahl des passenden charset ist mit dem oben geschriebenen identisch: Der einzige Unterschied in dieser Hinsicht "passendes HTML" und kompatibles XHTML/1.0 ist die Art der Ankündigung der Deklaration für den Client.

Der verbreiteste Fehler scheint zu sein, dass nur ein meta http-equiv angegeben wird, aber das kommt für XML zu spät, denn dort wurde schon auf Grund anderer Voraussetzungen (in Abwesenheit der <?xml...> Deklaration und das Fehlen einer BOM) utf-8 als Zeichencodierung festgelegt. Wenn jetzt ein meta eine andere Zeichencodierung bestimmt, zum Beispiel iso-8859-1, dann ist das Resultat sehr problematisch.


Letzte Änderung des Originals am: 05. Juni 2003, 18:37:50 BST, der Übersetzung: 10. Juli 2003

Original materials © Copyright 1994 - 2003 by A. J. Flavell & Glasgow University
Übersetzung © Copyright 2001 - 2003 by Dominik Boecker
Ich danke A. J. Flavell und A. Prilop für ihre bereitwillige und großzügige Hilfe bei der Übersetzung!


Überarbeitet durch Andreas Prilop, 7. August 2001, 14:15 MESZ


Diese Seite ist eine Übersetzung von http://ppewww.ph.gla.ac.uk/~flavell/charset/checklist.

Web-Technik und Anleitungen.