Punycode-Konverter

Was das Tool macht

Dieser Konverter übersetzt internationalisierte Domainnamen (IDNs) zwischen der Form, die Menschen lesen, und der Form, die im DNS gespeichert ist. Gib müller.example ein, und du erhältst xn--mller-kva.example; füge einen xn---Namen ein, und du erhältst das Unicode-Original. Das funktioniert beim Tippen in beide Richtungen, Label für Label – in shop.müller.example bekommt also nur das Label mit Nicht-ASCII-Zeichen das Präfix xn--.

Die Kodierung ist Punycode (RFC 3492), umgesetzt in JavaScript in deinem Browser; nichts, was du eingibst, wird irgendwohin gesendet. Vor dem Kodieren schreibt das Tool jedes Label klein und wendet die Unicode-Normalisierung NFC an, sodass ein vorkomponiertes ü und ein u mit kombinierendem Trema dasselbe Ergebnis liefern. Es wendet nicht jede Abbildungsregel von IDNA2008 oder UTS #46 an; eine erfolgreiche Umwandlung ist daher eine korrekte Kodierung, aber kein Beweis, dass eine Registry den Namen akzeptiert.

Neben dem Ergebnis bekommst du eine Aufschlüsselung jedes Labels (Unicode-Form, ASCII-Form und Länge), eine Prüfung gegen die DNS-Grenzen von 63 Oktetten pro Label und 253 für den ganzen Namen sowie eine Warnung, wenn ein einzelnes Label Schriften mischt, etwa Latein mit Kyrillisch oder Griechisch.

So benutzt du den Konverter

1. Tippe einen Domainnamen, eine vollständige URL oder eine E-Mail-Adresse ein, oder füge sie ein.
2. Die umgewandelte Form aktualisiert sich sofort: Unicode-Eingaben ergeben die xn---Form, xn---Eingaben ergeben Unicode.
3. Lies in der Aufschlüsselung der Labels die Längen, Fehler bei Grenzwerten und eine eventuelle Warnung zu gemischten Schriften.
4. Kopiere die Form, die das Ziel erwartet.

Bei einer URL wird nur der Host umgewandelt; der Rest bleibt, wie er eingegeben wurde. (Im Web werden Nicht-ASCII-Zeichen in Pfad oder Query-String als UTF-8 prozentkodiert, nicht in Punycode umgewandelt.) Bei einer E-Mail-Adresse wird nur der Teil nach dem @ umgewandelt. Ein lokaler Teil wie jürgen hat keine Punycode-Form; die Zustellung an eine solche Adresse setzt SMTPUTF8-Unterstützung (RFC 6531) auf jedem Server auf dem Weg voraus.

Anwendungsfälle

• Einen verdächtigen Link prüfen. Füge eine URL aus einer Nachricht ein, bevor du sie öffnest. Ergibt der Host beim Dekodieren Buchstaben aus zwei Schriften, oder entpuppt sich ein vertraut aussehender Name als xn---Label, sieh genauer hin, bevor du klickst.
• DNS-Einträge schreiben. Zonendateien und die meisten Verwaltungsoberflächen von DNS-Anbietern erwarten die ASCII-Form. Verwende genau diesen String überall, wo ein Eintrag auf den Namen verweist, auch bei CNAME-Zielen und MX-Hosts.
• TLS-Zertifikate beantragen. Zertifizierungsstellen und ACME-Clients erwarten in den Subject Alternative Names die xn---Form. Wer die SAN-Liste eines Zertifikats dekodiert, sieht, welche Unicode-Namen es tatsächlich abdeckt.
• Logs lesen. Webserver-Logs, HTTP-Host-Header und TLS-SNI-Werte enthalten den kodierten Namen. Dekodiere einen unbekannten Eintrag, um ihn lesen zu können.
• E-Mail für eine IDN einrichten. MX-, SPF-, DKIM- und DMARC-Einträge liegen alle unter dem xn---Namen, und eine Adresse wie info@xn--bcher-kva.example funktioniert mit ganz normaler Mail-Software.
• Vor der Registrierung die Länge prüfen. Bei manchen Schriften wird ein Label durch die Kodierung deutlich länger: Das thailändische Label ภาษาไทย mit sieben Zeichen wird zu xn--o3crh0a8bb0k, 16 Oktette – ein Label, das kurz aussieht, kann also trotzdem über 63 kommen.

Einträge und ein Zertifikatsantrag (CSR) für bücher.example verwenden den kodierten Namen wie jeden anderen Hostnamen:

xn--bcher-kva.example.      3600 IN A     192.0.2.10
www.xn--bcher-kva.example.  3600 IN CNAME xn--bcher-kva.example.
xn--bcher-kva.example.      3600 IN MX    10 mail.xn--bcher-kva.example.

openssl req -new -key site.key -out site.csr \
  -subj "/CN=xn--bcher-kva.example" \
  -addext "subjectAltName=DNS:xn--bcher-kva.example,DNS:www.xn--bcher-kva.example"

Wie Punycode Unicode in einen Hostnamen bringt

Genau genommen kann das DNS-Wire-Format beliebige Bytewerte transportieren. In der Praxis sind Hostnamen aber seit den 1980er-Jahren auf ASCII-Buchstaben, Ziffern und den Bindestrich beschränkt (die LDH-Regel aus RFC 952 und RFC 1123), und Resolver, Mailserver und Zertifikatsprüfungen wurden auf dieser Annahme aufgebaut. Statt sie zu ändern, wandelt IDNA Namen schon in der Anwendung, bevor überhaupt eine Abfrage gesendet wird, in einen String um, der die alte Regel bereits erfüllt.

Punycode arbeitet in zwei Schritten. Zuerst übernimmt es die ASCII-Zeichen des Labels in ihrer Reihenfolge und hängt einen Bindestrich an, falls es welche gab: Aus bücher wird bcher-. Dann beschreibt es jedes fehlende Zeichen mit einer einzigen Zahl, die angibt, welcher Codepoint an welcher Stelle einzufügen ist. Das ü ist U+00FC, dezimal 252. Gezählt ab 128, mit fünf bereits platzierten Buchstaben und damit sechs möglichen Einfügestellen, ergibt sich (252 − 128) × 6 + 1 = 745; die abschließende 1 bedeutet „nach dem ersten Buchstaben“. Diese Zahl wird in einer Base-36-Form variabler Länge mit a–z und 0–9 geschrieben, deren Schwellenwerte sich anpassen, damit kleine Zahlen kurz bleiben. Heraus kommt kva, also xn--bcher-kva. Aus demselben Grund endet auch müller auf -kva: wieder fünf ASCII-Buchstaben, und das ü steht wieder nach dem ersten.

Beim Dekodieren läuft das umgekehrt: Alles vor dem letzten Bindestrich wird übernommen, und die Zeichen danach werden als Einfügungen zurückgelesen. Ein Label ganz ohne ASCII-Buchstaben, wie das thailändische oben, hat nach dem Präfix keinen trennenden Bindestrich. Weil das kodierte Label durchs DNS geht, gilt die Grenze von 63 Oktetten für das kodierte Label, nicht für den Unicode-Text.

Doppelgänger-Domains und die Adressleiste

Viele Buchstaben sehen in verschiedenen Schriften gleich aus. Das kyrillische а (U+0430) gleicht in den meisten Schriftarten dem lateinischen a, sodass bаnk.example mit kyrillischem zweitem Buchstaben wie ein normales Wort aussieht, aber zu xn--bnk-6cd.example kodiert wird. Das nennt man einen Homograph-Angriff.

Browser entscheiden Label für Label, ob sie Unicode oder die xn---Form anzeigen. Die Regeln unterscheiden sich je nach Hersteller, typische Prüfungen sind aber: ob ein Label Schriften in Kombinationen mischt, die echte Namen selten verwenden, ob es komplett aus Buchstaben besteht, die lateinische nachahmen, und ob es einer bekannten Domain stark ähnelt. In Firefox erzwingst du die ASCII-Form für jeden Namen, indem du network.IDN_show_punycode in about:config auf true setzt.

Die Warnung zu gemischten Schriften sucht hier nach mehr als einer Schrift innerhalb eines einzelnen Labels. Ein Label, das komplett aus kyrillischen Buchstaben besteht, die lateinischen ähneln, ist nicht gemischt – ein unauffälliges Ergebnis beweist also nicht, dass ein Name echt ist. Vergleiche den dekodierten Namen mit der Adresse, die du erwartet hast, und tippe die Adresse im Zweifel selbst ein.

Häufige Fragen

Eine saubere Umwandlung zeigt, dass der Name korrekt kodiert ist – nicht, dass er registrierbar oder sicher ist. Registries wenden eigene Zeichenregeln an, und Doppelgänger-Namen kommen auch ohne gemischte Schriften aus.