IDN-Domains: Webadressen mit Sonderzeichen

Das Internet wird zunehmend internationaler. Der International Telecommunication Union (ITU) zufolge nutzen weltweit mehr als drei Milliarden Menschen die Möglichkeiten des World Wide Web – immer öfter auch in der eigenen Muttersprache. Möglich machen dies sogenannte internationale Domain-Namen (IDN), die Internetnutzern seit 2003 zur Verfügung stehen.

Was ist ein internationalisierter Domain-Name (IDN)?

Bis 2003 durften Domain-Namen lediglich aus den Buchstaben des lateinischen Alphabets, den arabischen Ziffern 0 bis 9 sowie dem Bindestrich (-) bestehen. Grund dafür ist das Domain Name System (DNS), das für die Übersetzung von URLs in IP-Adressen zuständig ist und auf dem Standardzeichensatz ASCII (American Standard Code for Information Interchange) basiert. Dieser entspricht weitestgehend einer Tastatur für die englische Sprache und ist für ein internationales Projekt wie das Internet wenig repräsentativ. Um diesem Missstand entgegenzuwirken, wurde der Internetstandard „Internationalizing Domain Names in Applications“ (IDNA) ins Leben gerufen, der eine standardisierte Übersetzung von Unicode zu ASCII definiert und somit eine Verwendung jedes sinntragenden Schriftzeichens aller bekannten Zeichensysteme in Internetdomains ermöglicht.

IDNA wird als eine der größten Revolutionen in der Geschichte des Internets betrachtet. Vor allem Menschen, die sich asiatischer, arabischer oder afrikanischer Schriftsysteme bedienen und Online-Angebote für den eigenen Sprachraum erstellen möchten, profitieren von internationalisierten Domain-Namen. Doch auch in Deutschland erfreuen sich IDNs in Form von Umlaut-Domains großer Beliebtheit. Theoretisch kann jedes Unicode-Zeichen in einem internationalisierten Domain-Namen verwendet werden. In der Praxis regeln die Domain-Vergabestellen jedoch individuell, welche Sonderzeichen bei der Registrierung erlaubt sind. Die Auswahl variiert daher je nach Top-Level-Domain (TLD). Eine komplette Zeichenliste für die deutsche TLD .de findet sich hier

Mehr als nur eine Domain!

Hier finden Sie Ihre perfekte Domain - z.B. .de Domain + persönlicher Berater

E-Mail-Adresse
24/7 Support
SSL-Sicherheit

Funktionsweise des IDNA

Um sicherzustellen, dass internationalisierte Domain-Namen auch von den zahlreichen Systemen im Internet verarbeitet werden können, die lediglich den ASCII-Zeichensatz unterstützen, lässt sich jeder IDN, der im Unicode vorliegt, in einen sogenannten ACE-String übersetzen, der auf ASCII-Zeichen beruht. So werden URLs im Browser beispielsweise mit Umlauten angezeigt, während der Server die Adressen ausschließlich ASCII-kompatibel verarbeitet. Spezifiziert wird dieses Verfahren im Internetstandard IDNA2003 sowie in der Überarbeitung IDNA2008, die im Jahr 2010 zugelassen wurde. Die Übersetzung von Unicode nach ASCII erfolgt clientseitig (im Webbrowser, E-Mail-Programm etc.) auf Grundlage eines standardisierten Kodierungsverfahrens, das Punycode genannt wird. 

Punycode

Der im RFC 3492 standardisierte Punycode wurde entwickelt, um Unicode-Zeichenketten eindeutig und verlustfrei in ASCII-Zeichen darstellen zu können. Dabei werden alle Nicht-ASCII-Zeichen aus dem Domain-Namen entfernt, kodiert und durch einen Bindestrich getrennt angehängt. Diese Codefolge enthält die Information, um welches Unicodezeichen es sich handelt, sowie dessen Position im Domain-Namen. Darüber hinaus wird jedem so erstellten ACE-String das Präfix xn-- vorangestellt, das die Zeichenfolge unmissverständlich als kodierten IDN gemäß IDNA und Punycode kennzeichnet. Verdeutlichen lässt sich die Funktionsweise des IDNA an einem Beispiel:

IDN-Form: müller-büromöbel.de

ACE-String: xn--mller-brombel-rmb4fg.de

Auf das Präfix xn--, das die Domain als ACE-String kennzeichnet, folgt der von allen Nicht-ASCII-Zeichen bereinigte Domain-Name mller-brombel. Die kodierten Sonderzeichen rmb4fg wurde durch einen Bindestrich getrennt angehängt.

Um Internetnutzern die Übersetzung von ACE nach IDN sowie in umgekehrter Richtung zu erleichtern, bietet die DENIC einen Web-Konverter im Servicebereich kostenlos an.

Unterschiede zwischen IDNA2003 und IDNA2008

Im ursprünglichen Verfahren von 2003 wurden internationalisierte URLs vor der Punycode-Kodierung im sogenannten Nameprep-Verfahren normalisiert. Dabei wurden Großbuchstaben zu Kleinbuchstaben umgewandelt, Steuerzeichen entfernt und äquivalente Zeichen in eine einheitliche Form gebracht. Seit IDNA2008 ist Nameprep jedoch nicht mehr Teil des Übersetzungsverfahrens. IDNA gibt somit keine Normalisierung mehr vor, empfiehlt jedoch einen Algorithmus, der Großbuchstaben in Kleinbuchstaben umwandelt.

Diese Anpassung kommt auch Nutzern im deutschen Sprachraum entgegen, da das in Deutschland geläufige Unicodezeichen „ß“ gemäß IDNA2003 ursprünglich als Äquivalent zu „ss“ definiert wurde. Domains wie www.fußball-ergebnisse.de wurden im Nameprep-Verfahren somit automatisch zu www.fussball-ergebnisse.de normalisiert. Diese Anpassung findet nach IDNA2008 nicht mehr statt. Seit 2010 wird das „ß“ als „Latin small letter sharp s“ korrekt interpretiert und kann als Teil einer Domain registriert werden.

Darüber hinaus werden rund 8.000 Zeichen, die unter IDNA2003 in Domain-Namen möglich waren, unter IDNA2008 nicht mehr unterstützt. Vier Zeichen inklusive „ß“ werden seit der Überarbeitung des Standards anders interpretiert als zuvor. Eine detaillierte Diskussion der Unterschiede zwischen IDNA2003 und IDNA2008 findet sich im Unicode Technical Standard #46

Probleme mit IDNs

Inzwischen sollten alle gängigen Internet-Programme IDN verstehen. Zu Problemen mit internationalisierten Domain-Namen kommt es aber mitunter dadurch, dass der Umstieg von IDNA2003 zu IDNA2008 im Internet noch nicht konsequent vollzogen wurde. Eine Fehlerquelle im deutschen Sprachraum ist die unterschiedliche Interpretation des „ß“. Da IDNA2003 „ß“ zwingend zu „ss“ umwandelt, sind spezielle ß-Domains, die gemäß IDNA2008 registriert werden können, für Systeme, die nach dem veralteten Standard konvertieren, oft nicht auffindbar. Stattdessen gelangen Nutzer auf die entsprechende Domain mit „ss“. Umgehen lassen sich solche Schwierigkeiten, indem Webseitenbetreiber beide Varianten registrieren und die zweite Domain auf die priorisierte Schreibweise per Redirect umleiten.