edition W3C.de

HTML 4.01-Spezifikation

Deutsche Übersetzung

Diese Version:
http://www.edition-w3.de/TR/1999/REC-html401-19991224
Aktuelle Version:
http://www.edition-w3c.de/TR/html4
Übersetzer:
Christine Kühnel (Übersetzung, fachliche Kommentierung) <kuehnel@screenexa.net>
Stefan Mintert (Fachlektorat und fachliche Kommentierung) <www.mintert.com/stefan/mail/>
Stefan Schumacher (Übersetzung, fachliche Kommentierung) <sts@schumacher-netz.de>

Bei diesem Dokument handelt es sich um eine Übersetzung eines W3C-Textes. Dieser Text ist urheberrechtlich geschützt; bitte beachten Sie die nachfolgenden Hinweise des Originaldokuments. Die Rechte an der Übersetzung liegen bei den Übersetzern und dem Verlag Addison-Wesley. Die Übersetzung hat keine durch das W3C legitimierte, normative Wirkung. Das einzige maßgebliche Dokument ist das englische Original.

Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung an die Übersetzer.

Kommentare der Übersetzer, die als solche gekennzeichnet sind, unterliegen dem Urheberrecht der Übersetzer. Sie sind nicht Bestandteil des Ursprungsdokuments.

Diese Veröffentlichung ist eine Vorveröffentlichung. Kein Teil dieses Textes darf kopiert werden. Alle Rechte vorbehalten. Nach Abschluss der Arbeit wird das endgültige Dokument unter der oben angegebenen Adresse veröffentlicht. Die jetzige Veröffentlichung während der laufenden Arbeit dient zur Information von Interessierten und zur Prüfung durch die Fachöffentlichkeit. Sollten Sie Fehler finden oder Verbesserungsvorschläge haben, schicken Sie diese bitte per Mail an die Übersetzer.
Folgende Teile liegen noch in Englisch vor und müssen noch in deutscher Fassung generiert werden: (a) Gesamtinhaltsverzeichnis (b) Index


5 Repräsentation von HTML-Dokumenten

Inhaltsverzeichnis

In diesem Kapitel erörtern wir, wie HTML-Dokumente auf einem Computer und über das Internet repräsentiert werden.

Anmerkung der Übersetzer:

Unter der »Repräsentation« ist hier Folgendes zu verstehen: Ein HTML-Dokument wird in irgendeiner Form auf dem Rechner gespeichert und in irgendeiner Form über das Internet übertragen. In diesem Kapitel geht es nun um diese Form: Wie »sieht« ein HTML-Dokument für den Rechner aus, das heißt, wie ist es auf dem Rechner repräsentiert? Diese Frage kann auf ganz unterschiedlichen Ebenen beantworten werden. Selbstverständlich gibt es eine binäre Repräsentation des Dokuments, ebenso eine byte-orientierte Darstellung. Hier geht es nun um die Repräsentation auf Zeichen-Ebene. Das heißt, welche Zeichen gibt es und wie werden diese durch Bytes dargestellt; etwa Ein-Byte-Kodierung, wie ASCII (für amerikanische Texte ausreichend) oder ISO-Latin-1 (für die meisten Westeuropäischen Schriften) oder Mehr-Byte-Kodierungen, wie Unicode (für internationale Schriften).

Der Abschnitt über den Dokumentzeichensatz wendet sich der Frage zu, welche abstrakten Zeichen Teil eines HTML-Dokuments sein können. Zeichen umfassen den lateinischen Buchstaben »A«, den kyrillischen Buchstaben »I«, das chinesische Zeichen für »Wasser« usw.

Der Abschnitt über Zeichenkodierungen wendet sich der Frage zu, wie diese Zeichen in einer Datei oder zur Übertragung über das Internet dargestellt werden können. Da manche Zeichenkodierungen nicht alle Zeichen direkt darstellen können, die ein Autor in einem Dokument verwenden möchte, bietet HTML andere Mechanismen, auf jedes Zeichen zu verweisen, Zeichenreferenzen genannt.

Weil es innerhalb der menschlichen Sprachen eine Vielzahl von Zeichen und eine große Vielfalt der Darstellungsarten dieser Zeichen gibt, muss darauf geachtet werden, dass Dokumente von Benutzerprogrammen rund um den Erdball verstanden werden können.

5.1 Der Dokumentzeichensatz

Um die Interoperabilität zu unterstützen, fordert SGML, dass jede Anwendung (einschl. HTML) ihren Dokumentzeichensatz spezifiziert. Ein Dokumentzeichensatz besteht aus Folgendem:

Jedes SGML-Dokument (einschl. jeden HTML-Dokuments) ist eine Folge von Zeichen aus dem Vorrat. Computersysteme identifizieren jedes Zeichen anhand seiner Code-Position; zum Beispiel verweisen im ASCII-Zeichensatz die Code-Positionen 65, 66 und 67 in dieser Reihenfolge auf die Zeichen »A«, »B« and »C«.

Der ASCII-Zeichensatz reicht für ein globales Informationssystem wie das Web nicht aus, deswegen nutzt HTML das so genannte Universal Character Set (UCS), einen viel umfangreicheren Zeichensatz, definiert in [ISO10646]. Dieser Standard definiert einen Vorrat von Tausenden von den Völkern der ganzen Welt verwendeten Zeichen.

Der in [ISO10646] definierte Zeichensatz ist Zeichen für Zeichen äquivalent zu Unicode ([UNICODE]). Beide Standards werden von Zeit zu Zeit mit neuen Zeichen aktualisiert; die Neufassungen auf den entsprechenden Websites sollten beachtet werden. In der gegenwärtigen Spezifikation wird »[ISO10646]« verwendet, um auf den Dokumentzeichensatz zu verweisen, während »[UNICODE]« für Verweise auf den Unicode-Bidirektional-Textalgorithmus (siehe Abschnitt 8.2) reserviert ist.

Der Dokumentzeichensatz reicht jedoch nicht aus, um Benutzerprogrammen eine korrekte Interpretation von HTML-Dokumenten, wie sie üblicherweise ausgetauscht werden, als Bytesequenz in einer Datei oder während einer Netzwerk-Übertragung, zu gestatten. Benutzerprogramme müssen die spezifische Zeichenkodierung, die verwendet wurde, um den Dokument-Zeichenstrom in einen Bytestrom zu transformieren, ebenfalls kennen.

5.2 Zeichenkodierungen

Das, was diese Spezifikation Zeichenkodierung (character encoding) nennt, ist in anderen Spezifikationen unter verschiedenen Namen bekannt (was zur Verwirrung führen kann). Das Konzept ist jedoch im ganzen Internet weitgehend gleich. Auch Protokoll-Header, Attribute und Parameter, die sich auf Zeichkodierungen beziehen, benutzen denselben »Zeichensatz« (charset) und dieselben Werte aus dem [IANA]-Register (komplette Liste siehe [CHARSETS]).

Der »charset«-Parameter identifiziert eine Zeichenkodierung; dies ist eine Methode zur Konvertierung einer Folge von Bytes in eine Folge von Zeichen. Diese Konvertierung passt natürlich zum System der Web-Aktivitäten: Server senden HTML-Dokumente als Folge von Bytes zu Benutzerprogrammen; Benutzerpromme interpretieren sie als eine Folge von Zeichen. Die Konvertierngsmethode kann sich zwischen einer einfachen Eins-zu-Eins-Beziehung und komplexen Umsetzungssystemen und -algorithmen bewegen.

Eine einfache Ein-Byte-pro-Zeichen-Kodierungstechnik genügt nicht für Textfolgen aus einem Zeichenvorrat so groß wie [ISO10646]. Zusätzlich zu Kodierungen des vollständigen Zeichensatzes (wie UCS-4) gibt es mehrere verschiedene Kodierungen von Teilen von [ISO10646].

5.2.1 Eine Kodierung wählen

Autoren-Tools (z.B. Texteditoren) können HTML-Dokumente in der Zeichenkodierung ihrer Wahl kodieren; die Wahl hängt weitgehend von den Konventionen der verwendeten Systemsoftware ab. Diese Tools können jede geeignete Kodierung, die die meisten im Dokument enthaltenen Zeichen abdeckt, verwenden, vorausgesetzt, die Kodierung ist korrekt etikettiert. Vereinzelte Zeichen, die nicht unter diese Kodierung fallen, können immer noch durch Zeichenreferenzen dargestellt werden. Diese beziehen sich immer auf den Dokumentzeichensatz, nicht auf die Zeichenkodierung.

Server und Proxies können eine Zeichenkodierung »on the fly« ändern (genannt Transkodierung), um den Anforderungen von Benutzerprogrammen gerecht zu werden (siehe Abschnitt 14.2 in [RFC2616], »the 'Accept-Charset' HTTP request header«). Server und Proxies müssen ein Dokument nicht mit einer Zeichenkodierung bedienen, die den vollständigen Dokumentzeichensatz umfasst.

Im Web häufig verwendete Zeichenkodierungen sind ISO-8859-1 (auch als »Latin-1« bezeichnet; verwendbar für die meisten westeuropäischen Sprachen), ISO-8859-5 (die die kyrillische Schrift unterstützt), SHIFT_JIS (eine japanische Kodierung), EUC-JP (eine andere japanische Kodierung) and UTF-8 (eine Kodierung von ISO 10646, die eine unterschiedliche Bytezahl für verschiedene Zeichen nutzt). Die Namen für Zeichenkodierungen unterscheiden nicht zwischen Groß- und Kleinschreibung, so dass zum Beispiel »SHIFT_JIS«, »Shift_JIS« und »shift_jis« äquivalent sind.

Diese Spezifikation schreibt nicht vor, welche Zeichenkodierungen ein Benutzerprogramm unterstützen muss.

Konforme Benutzerprogramme (siehe Abschnitt 4.1) müssen alle Zeichen in allen Zeichenkodierungen, die sie erkennen, korrekt auf ISO 10646 abbilden (oder sie müssen sich verhalten, als ob sie so arbeiten würden).

Anmerkung der Übersetzer:

Die meistverbreitete Kodierung von deutschsprachigen Texten dürfte ISO-8859-1 sein. Auch diese HTML-Spezifikation enthält im (englischen) Original folgendes meta-Element:

<meta http-equiv="Content-Type" 
      content="text/html; 
      charset=ISO-8859-1">

Da es in dieser Thematik immer wieder Missverständnisse gibt, insbesondere bei HTML-Einsteigern, sei auf einen wichtigen Punkt nachdrücklich hingewiesen: Es genügt nicht, einfach die Kodierung ISO-8859-1 (oder irgendeine andere) anzugeben. Selbstverständlich muss das Dokument dann auch genau so kodiert sein. Auch in dieser Hinsicht bietet es sich an, Web-Seiten vom W3C-Validator prüfen zu lassen: http://validator.w3.org/.

Zur Veranschaulichung hier noch ein Beispiel. Das folgende Bild zeigt einen Teil des Editors, mit dem diese Übersetzung geschrieben wurde. Der untere Bereich zeigt die hexadezimale Kodierung des Textes, der hier in ISO-8859-1 kodiert ist.

ISO-8850-1-Kodierung eines Dokuments

Und nun zum Vergleich dasselbe Dokument in einer 2-Byte-Unicode-Kodierung. Beachten Sie, dass in der Textansicht im Editor kein Unterschied zu erkennen ist, dass jedoch pro Zeichen zwei Bytes verwendet werden. Dieser Editor bietet die Möglichkeit, beim Speichern das platzsparendere UTF-8 zu verwenden.

2-Byte-Kodierung eines Dokuments

ISO-8859-1 enthält übrigens nicht das Euro-Zeichen. Statt dessen kann ISO-8859-15 verwendet werden, allerdings kann man davon ausgehen, dass diese Kodierung von einer kleineren Anzahl Programme unterstützt wird. Das Euro-Entity &euro; dürfte die sicherste (aber vielleicht nicht bequemste) Wahl sein (siehe auch Abschnitt 5.3, »Zeichenreferenzen«).

Im Hinblick auf das XML-basierte XHTML sei darauf hingewiesen, dass XML 1.0 verlangt, dass jedes verarbeitende System mindestens die Kodierungen UTF-8 und UTF-16 beherrscht. Die Internet Engineering Task Force (IETF) verlangt in ihrem RFC 2277 »IETF Policy on Character Sets and Languages«, dass Protokolle in der Lage sein müssen, die UTF-8-Kodierung zu verwenden. Nachzulesen unter http://www.ietf.org/rfc/rfc2277.txt.

Wer sich mit diesem Thema eingehender beschäftigen möchte, findet beim W3C ein Arbeitspapier mit dem Titel »Character Model for the World Wide Web 1.0«. Das Dokument gibt es noch nicht in deutscher Übersetzung. In Englisch ist es unter http://www.w3.org/TR/charmod/ zu finden. Sobald es eine Übersetzung gibt, wird sie voraussichtlich unter http://www.edition-w3c.de/TR/charmod/ erhältlich sein.

Anmerkungen zu spezifischen Kodierungen 

Wenn HTML-Text in UTF-16 (charset=UTF-16) übertragen wird, sollten die Textdaten in Übereinstimmung mit [ISO10646], Abschnitt 6.3 und [UNICODE], Absatz C3, Seite 3-1 in Netzwerk-Bytefolge (»big-endian«, höherwertiges Byte zuerst) übertragen werden.

Um die Chancen einer ordnungsgemäßen Interpretation zu maximieren, wird zudem empfohlen, dass Dokumente, die als UTF-16 übertragen werden, immer mit dem Zeichen »ZERO-WIDTH NON-BREAKING SPACE« beginnen (hexadezimal FEFF, auch »Byte Order Mark« (BOM) genannt), welches bei Byte-Umkehrung zu hexadezimal FFFE wird, einem garantiert unbestimmten Zeichen. So könnte ein Benutzerprogramm, wenn es ein FFFE (hexadezimal) als erstes Bytes des Textes erhält, wissen, dass die übrigen Bytes bis zum Ende des Textes umgekehrt werden müssen.

Das UTF-1-Transformationsformat aus [ISO10646] (bei IANA registriert als ISO-10646-UTF-1) sollte nicht benutzt werden. Informationen über ISO 8859-8 und den Bidirektionalalgorithmus finden Sie in der Anmerkung »Bidirektionalität und Zeichenkodierung« in Abschnitt 8.2.4 .

5.2.2 Spezifizieren der Zeichenkodierung

Wie stellt ein Server fest, welche Zeichenkodierung für ein Dokument, das er anbietet, gilt? Manche Server prüfen die ersten paar Bytes eines Dokuments oder vergleichen mit einer Datenbank bekannter Kodierungen und Dateien. Viele moderne Server geben Webmastern mehr Einflussmöglickeiten auf die Zeichensatzkonfiguration als alte Server. Webmaster sollten diese Mechanismen nutzen, um einen »charset«-Parameter zu senden, wann immer das möglich ist. Sie sollten jedoch Vorsicht walten lassen, um ein Dokument nicht mit einem falschen Wert im »charset«-Parameter zu identifizieren.

Woher weiß ein Benutzerprogramm, welche Zeichenkodierung verwendet wurde? Der Server sollte diese Information anbieten. Der direkteste Weg für einen Server, das Benutzerprogramm über die Zeichenkodierung des Dokuments zu informieren, ist die Verwendung des »charset«-Parameters im »Content-Type«-Header-Feld des HTTP-Protokolls ([RFC2616], Abschnitte 3.4 und 14.17). Zum Beispiel zeigt der folgende HTTP-Header an, dass die Zeichenkodierung EUC-JP ist:

Content-Type: text/html; charset=EUC-JP

Bitte lesen Sie die Definition von text/html in Abschnitt 4, »Konformität«.

Das HTTP-Protokoll ([RFC2616], Abschnitt 3.7.1) führt ISO-8859-1 als Standardkodierung an, sollte der »charset«-Parameter im »Content-Type«-Header-Feld fehlen. In der Praxis hat sich diese Empfehlung als nutzlos erwiesen, weil manche Server es nicht gestatten, einen »charset«-Parameter zu senden und andere nicht entsprechend konfiguriert sein können, den Parameter zu senden. Deswegen dürfen Benutzerprogramme keinen Standardwert für den »charset«-Parameter annehmen.

Um Server- oder Konfigurationseinschränkungen zu begegnen, können HTML-Dokumente explizite Angaben über die Zeichenkodierung des Dokuments enthalten; das META-Element kann benutzt werden, Benutzerprogrammen diese Information zur Verfügung zu stellen.

Zum Beispiel sollte ein Dokument die folgende META-Deklaration enthalten, um zu spezifizieren, dass die Zeichenkodierung des aktuellen Dokuments »EUC-JP« ist:

<META http-equiv="Content-Type" content="text/html; charset=EUC-JP">

Die META-Deklaration darf nur verwendet werden, wenn die Zeichenkodierung derart aufgebaut ist, dass ASCII-wertige Bytes für ASCII-Zeichen stehen (mindestens bis das META-Element gelesen wurde). META-Deklarationen sollten so früh wie möglich im HEAD-Element erscheinen.

Für Fälle, in denen weder das HTTP-Protokoll noch das META-Element Informationen über die Zeichenkodierung eines Dokuments bereitstellt, bietet HTML bei verschiedenen Elementen auch das charset-Attribut. Durch Kombination dieser Mechanismen kann ein Autor die Chancen beträchtlich erhöhen, dass das Benutzerprogramm die Zeichenkodierung erkennt, wenn der Benutzer eine Ressource lädt.

Zusammenfassend sei bemerkt: Konforme Benutzerprogramme müssen die folgende Reihenfolge bei der Ermittlung der Zeichenkodierung eines Dokuments beachten (von der höchsten zur niedrigsten Priorität):

  1. Einen HTTP-»charset«-Parameter in einem »Content-Type«-Feld.
  2. Eine META-Deklaration mit »http-equiv«, gesetzt auf »Content-Type« und einem gesetzten Wert für »charset«.
  3. Das in einem eine externe Ressource kennzeichnenden Element gesetzte charset-Attribut.

Zusätzlich zu dieser Liste kann das Benutzerprogramm Heuristik und Benutzereinstellungen verwenden. Zum Beispiel benutzen viele Benutzerprogramme die Heuristik, um die verschiedenen Kodierungen für japanischen Text voneinander zu unterscheiden. Benutzerprogramme haben auch üblicherweise eine vom Benutzer einstellbare lokale Standardkodierung, die sie anwenden, wenn andere Indikatoren fehlen.

Benutzerprogramme können einen Mechanismus bieten, der es Benutzern gestattet, inkorrekte »Zeichensatz«-Information zu überschreiben. Wenn ein Benutzerprogramm solch einen Mechanismus anbietet, sollte es das jedoch nur für die Browserfunktionalität tun und nicht für Editierfunktionen, um das Erstellen von Webseiten zu vermeiden, die mit einem inkorrekten »charset«-Parameter gekennzeichneten sind.

Anmerkung: Sollte es für spezifische Anwendungen erforderlich werden, auf Zeichen außerhalb von [ISO10646] zu verweisen, sollten die Zeichen einer privaten Zone zugewiesen werden, um Konflikte mit gegenwärtigen oder künftigen Versionen des Standards zu vermeiden. Davon wird jedoch aus Gründen der Portierbarkeit dringend abgeraten.

5.3 Zeichenreferenzen

Eine gegebene Zeichenkodierung kann eventuell nicht in der Lage sein, alle Zeichen des Dokumentzeichensatzes darzustellen. Für solche Kodierungen, oder wenn Hard- bzw. Softwarekonfigurationen Benutzern bei einigen Dokumentzeichen nicht gestatten, sie direkt einzugeben, können Autoren SGML-Zeichenreferenzen nutzen. Zeichenreferenzen sind von der Zeichenkodierung unabhängige Mechanismen zur Eingabe beliebiger Zeichen aus dem Dokumentzeichensatz.

Zeichenreferenzen können in HTML in zwei Formen erscheinen:

Zeichenreferenzen innerhalb von Kommentaren haben keine spezielle Bedeutung; sie sind lediglich Kommentardaten.

Anmerkung: HTML bietet andere Wege der Darstellung von Zeichen, insbesondere eingebettete Graphiken (siehe Abschnitt 13).

Anmerkung: In SGML ist es in einigen Fällen möglich, das abschließende »;« nach einer Zeichenreferenz zu entfernen (z.B. an einem Zeilenumbruch oder unmittelbar vor einem Tag). Unter anderen Umständen darf es nicht entfernt werden (z.B. in der Mitte eines Wortes). Um Probleme mit Benutzerprogrammen zu vermeiden, die verlangen, dass dieses Zeichen vorhanden ist, raten wir dringend dazu, das »;« in allen Fällen zu verwenden.

5.3.1 Numerische Zeichenreferenzen

Numerische Zeichenreferenzen geben die Code-Position eines Zeichens im Dokumentzeichensatz an. Numerische Zeichenreferenzen können zwei Formen annehmen:

Hier sind einige Beispiele numerischer Zeichenreferenzen:

Anmerkung: Obwohl die hexadezimale Repräsentation nicht in [ISO8879] definiert ist, ist anzunehmen, dass sie wie in [WEBSGML] beschrieben, in der Überarbeitung enthalten sein wird. Diese Konvention ist besonders nützlich, weil Zeichenstandards im Allgemeinen hexadezimale Repräsentationen verwenden.

5.3.2 Zeichen-Entity-Referenzen

Um Autoren eine intuitivere Möglichkeit zu geben, auf Zeichen im Dokumentzeichensatz zu verweisen, bietet HTML eine Kollektion von Zeichen-Entity-Referenzen. Zeichen-Entity-Referenzen verwenden symbolische Namen, so dass sich Autoren keine Code-Positionen merken müssen. Zum Beispiel verweist die Zeichen-Entity-Referenz &aring; auf das kleine »a« mit einem Kreis darüber; »&aring;« ist leichter zu merken als &#229;.

HTML 4 definiert nicht für alle Zeichen im Dokumentzeichensatz eine Zeichen-Entity-Referenz. Zum Beispiel gibt es keine Zeichen-Entity-Referenz für den kyrillischen Großbuchstaben »I«. Die in HTML 4 definierten finden Sie in der vollständigen Liste der Zeichen-Entity-Referenzen (siehe Abschintt 24).

Zeichen-Entity-Referenzen unterscheiden zwischen Groß- und Kleinschreibung. So weist &Aring; auf ein anderes Zeichen (großes A mit Kreis) als &aring; (kleines a mit Kreis).

Vier Zeichen-Entity-Referenzen verdienen besondere Beachtung, da sie oft verwendet werden, um spezielle Zeichen zu vermeiden:

Autoren, die das »<«-Zeichen im Text einsetzen wollen, sollten »&lt;« (ASCII dezimal 60) verwenden, um mögliche Verwechslungen mit dem Beginn eines Tags (öffnender Begrenzer des Start-Tags, start tag open delimiter) zu vermeiden. Analog sollten Autoren im Text »&gt;« (ASCII dezimal 62) anstelle von »>« benutzen. Sie gehen damit Problemen aus dem Wege, die in älteren Benutzerprogrammen auftreten können. Dies kann dann passieren, wenn »>« innnerhalb von in Anführungszeichen stehenden Attributwerte auftaucht und ein Benutzerprogramm darin fälschlicherweise das Ende eines Tags (schließender Tag-Begrenzer) erkennt.

Autoren sollten »&amp;« (ASCII dezimal 38) anstelle von »&« verwenden, um Verwechslungen mit dem Beginn einer Zeichen-Entity-Referenz (öffnender Begrenzer einer Entity-Referenz) zu vermeiden. Autoren sollten auch in Attributwerten »&amp;« benutzen, da Zeichenreferenzen in CDATA-Attributwerten erlaubt sind.

Einige Autoren verwenden die Zeichen-Entity-Referenze »&quot;«, um doppelte Anführungszeichen (") zu kodieren, weil dieses Zeichen zur Begrenzung von Attributwerten verwendet werden kann.

5.4 Nicht darstellbare Zeichen

Ein Benutzerprogramm kann eventuell nicht in der Lage sein, alle Zeichen eines Dokuments sinnvoll darzustellen, zum Beispiel, weil ihm ein passender Zeichensatz (Font) fehlt, ein Zeichen einen Wert hat, der in der internen Zeichenkodierung des Benutzerprogramms nicht ausgedrückt werden kann, usw.

Weil es viele verschiedene Dinge gibt, die in solch einem Fall getan werden können, schreibt dieses Dokument kein bestimmtes Verhalten vor. Abhängig von der Implementierung können nicht darstellbare Zeichen auch vom darunterliegenden Anzeigesystem und nicht von der Anwendung selbst behandelt werden. Bei Fehlen eines besseren Verhaltens, zum Beispiel angepasst an die Erfordernisse einer speziellen Schrift (script) oder einer Sprache, empfehlen wir für Benutzerprogramme das folgende Verhalten:

  1. Einen deutlich erkennbaren, aber unaufdringlichen Mechanismus wählen, um den Benutzer über fehlende Ressourcen zu informieren.
  2. Die hexadezimale Form verwenden (nicht die dezimale), wenn fehlende Zeichen durch ihre numerische Repräsentation dargestellt werden, weil das die in Zeichensatz-Standards verwendete Form ist.