Einführung
Netscape 7.1 ist der erste kommerzielle Browser, der eine eingebaute Unterstützung für Internationalized Domain Name nach dem neuen IETF RFC von 2003 hat.
Ein Internationalized Domain Name (IDN) ist eine Domain oder ein host name, der andere Buchstaben als nur die in ASCII definierten nutzt. Bis vor kurzem erlaubten Domainnamen nur eine Teilmenge von Buchstaben (der 7-bit ASCII Charset). Durch die Verbreitung des Internet in weitere Länder der Erde, in denen kein Englisch gesprochen wird, wurde es immer mehr klar, dass die Beschränkung der Nutzung von Domainnamen auf eine Teilmenge des Latin alphabet nicht ideal ist.
Viele der europäischen Sprachen benutzen das lateinische Alphabet mit zusätzlichen akzentuierten Buchstaben zum Schreiben, konnten diese aber nicht in Domainnamen benutzen. Sprecher dieser Sprachen war es nicht möglich bekannte Namen in ihrer jeweiligen Sprache als Teil eines Domainnames zu verwenden.
In den letzten paar Jahren gab es eine Menge an IETF Aktivitäten um die Protokolle, die beim Handling von nicht-ASCII Buchstaben in Domainnamen beteiligt sind zu standardisieren. Im März 2003 wurden drei wichtige RfCs dazu vom IETF akzeptiert (3490, 3491, 3492). Diese drei neuen RfCs machen es nun für DNS Server möglich, dass diese nicht-ASCII Domains registrieren und ermöglichen es für Hersteller von Anwendungen, dass diese standardisierten Support für die Behandlung von nicht-ASCII Buchstaben in Domainnamen einbauen.
Wie IDN funktioniert
Wenn ein Webbrowser einen host name wie https://developer.mozilla.org sieht, gibt er eine Anfrage an den DNS Resolver Service (ist meistens im Betriebssystem eingebaut) weiter, welcher wiederum eine Anfrage zum nächsten DNS Server sendet, der eine IP Adresse zurück liefert, die zum Hostnamen passt. Diese IP Adresse wird dann dazu benutzt um zum fraglichen Webserver zu verbinden.
IDN erlaubt Host- und Domainnamen mit nicht-ASCII Zeichen als Usereingabe in die Adressleiste eines Browsers oder für URLs, die einer Website eingebunden sind. Auf der Netzwerkprotokoll-Ebene ergibt sich keine Änderung an der Einschränkung, dass nur eine Teilmenge des ASCII-Zeichensatzes verwendet werden kann. Wenn die Eingabe des Benutzers nicht-ASCII Zeichen als Teil eines Domainnamens enthält oder eine Website einen Link enthält, der nicht-ASCII Zeichen verwendet muss die Anwendung dies in eine spezielles Format umwandeln welches nur die übliche Teilmenge des ASCII Zeichensatzes verwendet. RFC 3490 (Internationalizing Domain Names in Applications (IDNA)) definiert die Zeichen die in IDN benutzt werden. Auch definiert dieser wie eine Anwendung nicht-ASCII Zeichen auf so eine Weise verarbeiten soll, dass diese im Einklang steht mit bestehenden Restriktionen in Hinblick auf host names.
Wie die Mozilla Browser nicht-ASCII Domainnamen behandeln
Unicode und Nameprep
Wenn Mozilla von einem Benutzer eine IDN Eingabe über die Adressleiste empfängt oder eine Anfrage nicht-ASCII host name links zu verarbeiten vorliegt, wandelt es zuerst diese Eingabe in Unicode um. Anschließend normalisiert und validiert es diese Eingabe um diese konform zu den Anforderungen an einen URI zu machen.
Der Prozess wandelt Großbuchstaben in Kleinbuchstaben um, vereinheitlicht Zeichen mit mehreren Darstellungsweisen, z.B. die Umwandlung von Kana Zeichen halber Breite im Japanischen in Zeichen mit voller Breite, entfernt verbotene Zeichen (z.B. Leerzeichen), eliminiert Zweideutigkeiten in bidirektionalem Text (z.B. Arabisch und Hebräisch) und prüft ob nicht zugewiesene Zeichen aus dem Unicode Zeichenraum verwendet werden - diese werden für "query strings" erlaubt, sind aber bei "stored strings" wie z.B. bei der Dateneingabe für eine Domainregistrierung verboten.
Dieser Prozess wird "Nameprep" genannt und wird nach dem RFC 3491 (en) (Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)) und dem RFC 3454 (en) (Preparation of Internationalized Strings ("stringprep")) ausgeführt.
ASCII-kompatible Kodierung (ACE)
Der nächste Schritt ist die Umwandlung der 8-Bit Zeichen in Unicode zu 7-Bit Zeichen, die nur bestimmte ASCII Zeichen verwenden dürfen. Während der Diskussionsphase von der Entwicklung des IDN Protokolls gab es ein paar konkurrierende, ASCII-kompatible Kodierungsschema (aka ASCII-compatible encoding (ACE)), aber man konnte sich schließlich darauf einigen einen Typ von ACE, der "Punnycode" genannt wird, zu standardisieren. Dieser ist definiert im RFC 3492 (en) (Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)).
Der Punnycode Vorschlag nutzt nur eine beschränkte Anzahl von ASCII Zeichen und Nummern (a-z0-0) und den Bindestrich (-). Er wurde als sprachunabhängig, überlegen in der Kompression, kompakt in Hinsicht auf die Codegröße, round-trip safe und überlegen in Hinsicht auf die Kodierung von chinesischen/japanischen/koreanischen Zeichen dargestellt.
Der letzte Schritt des Prozesses ist es, dass ACE Präfix der Ausgabe der Nameprep/stringprep und Punnycode Verarbeitung voranzustellen. Da Punnycode nur ASCII Zeichen enthält, ist es möglich, dass sich diese Ausgabe, wenn auch unwahrscheinlich, mit einem existierenden Domainnamen deckt. Um so eine Kollision zu vermeiden definiert RFC 3490 ein spezielles Präfix, nämlich "xn--", für die Ausgabe des ACE (Punnycode). Andere Kodierungen benutzen andere Präfixe, z.B. "bq--" bei RACE, aber all diese außer dem Standard Präfix "xn--" für ACE sind jetzt in IDN verboten.
Domainnamen-Registrierung
Nachdem die technischen Standards vom IETF eingeführt wurden, war das letzte noch verbleibende Problem, dass sich die Registrare auf eine internationale Richtlinie zur Verwendung von IDN Zeichen einigen müssen. Dies wurde mit der Veröffentlichung der ICANN Richtlinie für IDN (en) im Juni 2003 bewerkstelligt. Diese Richtlinie erlaubt es Domainnamen Registraren in jedem Land die Nutzung von bestimmten Zeichen in Domainnamen zu beschränken. Da das Unicode Repertoire Zeichen enthält, die in keiner lebenden Sprache mehr verwendet werden und es auch Zeichen gibt, die in den meisten Sprachen nicht für die Erstellung von URIs/URLs geeignet sind, erlaubt die ICANN Richtlinie dem governing body den Registraren jedes Landes angemessene Beschränkungen für die Benutzung solcher Zeichen zu setzen.
Da dieses letzte Hindernis für eine Standardisierung nun aus dem Weg geräumt wurde, wird erwartet, dass die Registrare schnell voranschreiten um diese neuen RFCs für existierende und kommende IDN Registrierungen einzuführen.
Der JPRS (Japan Registry Service (en)) hat sich dazu entschieden die neue RFC Implementierung (en) am 10. Juli 2003, nur ein paar Wochen nachdem die Richtlinie des ICANN veröffentlich wurde, einzuführen. Dies macht es für Netscape 7.1/Mozilla 1.4 User möglich japanische Domainnamen unter der Topleveldomain .jp ohne weitere Änderungen nur mit der eingebauten IDN-Funktionalität aufzurufen.
Beispiele aus der Wirklichkeit
Punycode
Es gibt einige Beispiele von IDN, die Sie mit Netscape 7.1 testen können, welcher Punycode als standardmäßiges IDN Encoding nutzt. Zum Beispiel können die meisten Beispiellinks auf den folgenden Testseiten ohne weitere Einstellungen benutzt werden:
- https://www.nunames.nu/eu-lang-test.htm (Domain names mit Latin 1)
- https://www.nunames.nu/lldemo/default.htm (Domain names in anderen Sprachen)
Seit July 10, 2003 und danach, kann man eine Vielzahl von japanischen Domain name Seiten unter der .jp Toplevel-Domain ohne weitere Einstellungen in Netscape 7.1/Mozilla 1.4 erreichen:
RACE (Row-based ASCII Compatible Encoding)
Fast alle IDN Registrierungsdaten werden zu Punycode bis zum Ende 2003 verändert. Einige Länder werden schnell dabei sein, z.B. Japan wie oben genannt, aber andere wie .com und .net Toplevel-Domains werden länger brauchen.
Die meisten der existierenden Seiten nutzen das ASCII-kompatible Encoding, welches als RACE oder "Row-based ASCII Compatible Encoding" bekannt ist, welches allerdings kein akzeptierter Standard von IETF. Wenn Sie IDN Testseiten unter .com und .net Toplevel-Domains finden und wenn Sie nicht auf diese Seiten zugreifen können, sollten Sie den folgenden Workaround nutzen, bis Punycode komplett vorhanden ist:
Netscape 7.1 oder Mozilla 1.4:
- Tippen Sie about:config in die Adressleiste. Es werden alle Präferenzen für Ihr System angezeigt. Diese Einstellungen können geändert werden oder neue können erstellt werden ohne, dass der Browser beendet werden muss.
- Erstellen Sie einen neuen Eintrag über Neu > String über einen rechts-Klick. Der Name lautet: network.IDN_prefix. Der Wert sollte "bq--" lauten. Das wird von Puncycode auf RACE umschalten.
- Als nächstes erstellen Sie einen weiteren Eintrag über rechts-Klick Neu > Boolean. Der Name lautet: network.IDN_testbed. Der Wert sollte "true" lauten.
- Jetzt wechseln Sie auf eine IDN Seite unter .com und .net Toplevel-Domain. Sie sollten erfolgreich auf eine dieser Beispielseiten landen.
- Vergessen Sie nicht den Wert dieser Einstellungen auf "default" zu setzen, wenn Sie mit dem Testen fertig sind!
Vorbehalte und Rückschlüsse
Netscape 7.1/Mozilla 1.4 verfügt über eine gute Unterstützung von Internationalized Domain Names und ist der erste Browser mit eingebautem Support für neue RFC's für IDN vom IETF. Das bedeutet, dass es nicht länger notwendig ist, dass ein Plug-in für nicht-ASCII Domain names installiert werden muss.
Netscape/Mozillas Unterstützung für IDN ist nicht ohne Fehler. Ein bemerkenswerter Fehler ist, dass nicht-ASCII names nicht immer richtig in allen UI Bereichen angezeigt werden. Nicht-ASCII names werden nicht immer in der Adresszeile dargestellt, da ACE zu Unicode Umwandlung noch nicht implementiert ist.
IDN ist ein globaler Trend und wird von einer Großzahl von Seiten angenommen und machen es für durchschnittliche Internetuser außerdem einfacher Webseiten zu finden. Viele Webseiten rund um die Welt sind werden ihre host names mit der entsprechenden Domain name Registrierung für ihre Toplevel-Domains einrichten. Netscape 7.1 und Mozilla 1.4 spielen dabei eine signifikante Rolle, damit IDN weiter entwickelt wird.
Original Document Information