Umlaut-Domains (IDN) richtig einrichten

Acht Jahre ist es jetzt her, dass in Internet-Domains auch Umlaute möglich sind. Das ganze hat sich bis Heute nicht durchgesetzt. – Aus gutem Grund, denn leider haben die meisten Software-Entwickler einfach den Schuss nicht gehört. Normalerweise sollten IDNs unsichtbar sein, die Kodierung im Hintergrund arbeiten. Doch das Gegenteil ist der Fall: Das Netz ist voll von „xn--irgendwas“-Domains, die auch genau so angezeigt werden. Und wer will schon eine kryptische Domain mit sinnlosen Zeichen besitzen? Welcher Nutzer kann oder will sich das merken?

Die Schuldigen:

  • Server-Entwickler. Apache beispielweise beherrscht bis heute keinen nativen Punycode. Die Folge ist, dass der sog. Hostname kodiert angegeben werden muss, und nicht zuletzt auch kodiert wieder ausgegeben wird, wenn Scripte auf Server-Variablen zurückgreifen.
  • Suchmaschinen, die sowohl kodierte als auch unkodierte Domains in ihren Index aufnehmen, was zu einem wüsten Link-Mix führt. Niemand der eine Umlaut-Domain besitzt, kann ernsthaft wollen, dass diese sich nur in kodierter Form verbreitet. Dabei wäre es so einfach für Google & co., Domains nur in der lesbaren Darstellung aufzunehmen.
  • Browser-Entwickler, die aus nicht nachvollziehbaren Gründen, Domains und Links kodiert anzeigen, und außerdem eine Liste von TLDs führen, in denen internationale Domainnamen „erlaubt“ sind. Es gibt keinen wirklich sinnvollen Grund, diese Kodierung nicht komplett zu verstecken, und außerdem grundsätzlich anzuwenden.

„Eigentlich ist das der richtige Name“ heißt es dann. Aber „eigentlich“ sind ASCII-Zeichen auch Bytecode. Trotzdem käme niemand auf die Idee, diese nur kodiert anzuzeigen. Und im Gegensatz zur unüberschaubaren Liste verschiedener Zeichensätze existiert mit Punycode sogar ein weltweit einheitlicher Standard, der dennoch oft ungenutzt bleibt. Die Folge ist, dass Website-Betreiber mit Umlauten im Namen meist nach wie vor auf ASCII-Domains setzen, was auch deshalb sinnvoll ist, da sich diese Adressen auf jeder Tastatur problemlos eingeben lassen, aber trotzdem gezwungen sind, IDN-Domains zusätzlich zu registrieren, um zu verhindern, dass Domaingrabber ihre Nutzer auf völlig andere Seiten leiten.

Trotzdem gibt es für Seitenbetreiber, die auf Umlaut-Domains setzen einige Möglichkeiten, zumindest ein Stück weit darauf Einfluss zu nehmen, dass Ihre Domains auch so verwendet werden können, wie es ursprünglich gedacht war. Auf jeden Fall sollte darauf geachtet werden, die Domain in Links und im HTML-Code grundsätzlich nur mit Umlauten anzugeben. Die Browser sind in der Lage, diese umzuwandeln. Hierbei kann auch das Element „<Base>“ helfen. Wer ärger mit Zeichensätzen vermeiden will, kann dabei auch gerne auf HTML-Entities zurückgreifen.

Ein code wie
<link rel="stylesheet" href="http://www.k&auml;sebrot.example/style.css" type="text/css" />
geht vollkommen klar.

Web-Scripte, beispielsweise Content-Management-Systeme, oder Foren- und Wiki-Software, bieten häufig die Möglichkeit, in den Einstellungen eine Domain fest vorzugeben, anstelle der automatischen Erkennung. IDN-Webmaster sollten diese Möglichkeiten nutzen.

Zu guter Letzt kann auch der Web-Server angewiesen werden, derartige Fehler gar nicht erst zu machen. Mit einem kleinen Workaround ist auch das möglich. Beispielsweise lässt sich für den Apache folgende Konfiguration wählen:

<VirtualHost>
    ServerName www.käsebrot.example
    ServerAlias www.xn--ksebrot-5wa.example
    UseCanonicalName On
</VirtualHost>

Hierbei muss leider unbedingt darauf geachtet werden, dass die Zeichenkodierung der Konfigurations-Datei mit der des HTML-Dokuments übereinstimmt. ISO 8859-1 wird empfohlen, da dies die Standardkodierung ist, in der Fehlermeldungen und Header ausgegeben werden. Scripte die UTF-8 verwenden, müssen entsprechend umwandeln.

Mit der Direktive „UseCanonicalName“ zwingen wir den Apache, sich selbst grundsätzlich mit dem unter „ServerName“ angegebenen Namen zu verlinken. Zusätzlich geben wir aber die kodierte Form unter „ServerAlias“ an, denn der Apache kapiert sonst nicht, welchen vHost er nutzen soll. Nutzt man keine namensbasierten, virtuellen Hosts, kann der ServerAlias natürlich auch weg gelassen werden. Bei anderen Server-Produkten gibt es sicher ähnliche Möglichkeiten.

Beherzigt man diese Tipps, hat man eine relativ gute Chance, die eigene Domain so im Internet zu finden, wie man es gerne hätte: Lesbar und mit Umlauten. Ob es all die Probleme wert ist, oder man nicht doch lieber ganz auf diese Fehlentwicklung verzichtet, muss letztlich jeder für sich entscheiden.

Die Kommentare sind geschlossen.