Unterstützung von Internationalized Domain Names (IDN) in Mozilla Browsern
Aus MDC
Achtung! Übersetzung ist nicht vollständig, siehe Domain Names (IDN) Support in Mozilla Browsers für den ganzen Artikel auf Englisch.
Inhaltsverzeichnis |
[bearbeiten] 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.
[bearbeiten] Wie IDN funktioniert
Wenn ein Webbrowser einen host name wie http://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ückliefert, 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.
[bearbeiten] Wie die Mozilla Browser nicht-ASCII Domainnamen behandeln
[bearbeiten] 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.
[bearbeiten] 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.
[bearbeiten] 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 Veö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.