Punycode- / IDN-Umwandler

Punycode ist also keine Sprache, keine Schriftart und kein Ländercode — sie ist eine Übersetzung zwischen zwei Schreibweisen desselben Namens. Die Unicode-Schreibweise heißt U-Label (中文.com, bücher.de), die ASCII-Schreibweise heißt A-Label (xn--fiq228c.com, xn--bcher-kva.de), und die ganze Idee, internationale Namen in DNS aufzunehmen, heißt IDN (internationalisierte Domainnamen) bzw. IDNA, das Regelwerk darauf.

Es gibt sie, weil DNS Anfang der 1980er-Jahre um ein bewusst winziges Alphabet herum entworfen wurde. Ein Hostname, der durch DNS reist, in eine Zonendatei, einen Resolver-Cache, eine Protokollzeile oder ein TLS-Zertifikat gelangt, muss reines ASCII sein — das Übertragungsformat hat schlicht kein Feld für anderes. Punycode ist der Ausweg: Er lässt einen Nicht-ASCII-Namen so reisen, als wäre er ASCII, und die Gegenseite kann die ursprünglichen Zeichen genau wiederherstellen. Deshalb funktioniert eine chinesische Domain überhaupt im Browser, und deshalb ist xn-- die eine Zeichenkette, die Sie überall sehen, wo die Unicode-Schreibweise nicht übertragen werden kann.

Was Sie eingeben (U-Label)	Was DNS erhält (A-Label)	Was es bedeutet
中文.com	xn--fiq228c.com	Die chinesischen Wörter für „chinesische Sprache“
中国	xn--fiqs8s	„China“ auf Chinesisch
例え.jp	xn--r8jz45g.jp	Japanische Beispiele
bücher.de	xn--bcher-kva.de	Deutsch bücher, „Bücher“
münchen.de	xn--mnchen-3ya.de	München
😂.com	xn--e28h.com	Ein Emoji-Label — in der Kodierung zulässig, in den meisten Registrierungsstellen nicht

Ein Längenvergleich, den Sie sich merken sollten: 中文 hat 2 Zeichen und 6 Byte in UTF-8, xn--fiq228c aber 11 ASCII-Byte. Punycode macht einen Namen meist länger, nie kürzer.

Nehmen Sie bücher und beobachten Sie die drei Schritte. Die Maschine heißt Bootstring, und der ganze Algorithmus umfasst nur einige Dutzend Zeilen Code (Sie können ihn im Skript dieser Seite lesen).

1. Die einfachen Zeichen werden nach vorne kopiert. Jedes einfache ASCII-Zeichen wird in seiner ursprünglichen Reihenfolge kopiert und bleibt lesbar: bücher → bcher. Weil etwas kopiert und etwas übrig gelassen wurde, wird als Grenze ein einzelnes - angehängt: bcher-.
2. Schreiben Sie den Rest als Zahlen zur Basis 36. Die übrigen Zeichen werden in aufsteigender Codepunkt-Reihenfolge behandelt, und jedes wird als Zahl variabler Länge zur Basis 36 geschrieben, wobei a=0 … z=25 und 0=26 … 9=35 gilt. Bei bücher wird das übrige Zeichen ü zu den Ziffern kva.
3. Setzen Sie das Präfix davor. Der kodierte Teil, an den kopierten Teil angehängt, ergibt bcher-kva, und im Domainkontext wird das als xn--bcher-kva geschrieben.

Der Trick, der das so raffiniert macht, steckt in den Zahlen zur Basis 36: nicht das Zeichen selbst, sondern eine Differenz — wie weit das Zeichen vom zuvor kodierten Codepunkt entfernt liegt, plus wohin es in der Zeichenkette gehört. Der Kodierer geht die Codepunkte in aufsteigender Reihenfolge durch, und jede Ziffernfolge beschreibt eine Position und einen Abstand. Nach jedem Zeichen wird eine gemeinsame Zahl, der sogenannte Bias, angepasst, damit die folgende Zahl möglichst wenige Ziffern braucht.

Zwei Folgen, die Sie oben selbst sehen können:

• Ähnliche Zeichen sind günstig. Da nur Abstände gespeichert werden, kostet eine Folge desselben Zeichens fast nichts: 30 Kopien von 中 ergeben xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, nur 36 Byte. Eine gemessene, nicht verwandte, aber benachbarte Mischung chinesischer Zeichen passt auf etwa 41 Zeichen in ein zulässiges 63-Byte-Label, und ein einzelnes wiederholtes Zeichen erreicht 57.
• Verstreute Zeichen sind teuer. Ein Zeichen, das weit vom vorherigen entfernt liegt, braucht eine längere Differenzzahl. Chinesischer Text mit vielen verschiedenen Zeichen kostet typischerweise etwa 2–3 zusätzliche Buchstaben je Zeichen; deshalb geht einem CJK-Label etwa bei 20–40 Zeichen der Platz aus, obwohl die Grenze 63 Byte beträgt.

Das Dekodieren ist dasselbe Rezept rückwärts: den ASCII-Präfix übernehmen, die Ziffern lesen, die Differenzen zurück in Codepunkte umwandeln und jedes neue Zeichen an der Position einfügen, die die Differenz angibt. Im Bootstring gibt es nur kleine Ziffern, deshalb wird ein Großbuchstabe innerhalb eines kodierten Teils abgelehnt, statt geraten zu werden — DNS unterscheidet die Groß-/Kleinschreibung nicht, und beide Schreibweisen zuzulassen würde zwei verschiedene Schreibweisen mehrdeutig machen.

• In der Adressleiste. Browser zeigen unter Umständen xn--fiq228c.com statt 中文.com an. Es ist dieselbe Website. Manche Browser zeigen bewusst die Punycode-Form, wenn ein Name Schriften mischt, genau damit ein verwechselbares Zeichen (kyrillisches а gegenüber lateinischem a) sich nicht in der URL verstecken kann.
• Im DNS selbst. Zonendateien, Antworten von dig / nslookup / DNS-over-HTTPS und Resolver-Protokolle enthalten immer nur die xn---Form; reines Unicode wird abgelehnt oder stillschweigend verstümmelt.
• In TLS-Zertifikaten. Der alternative Antragsname (Subject Alternative Name) einer internationalen Domain wird als A-Label gespeichert (DNS:xn--fiq228c.com); ein Zertifikat, das nicht wie der eingegebene Name aussieht, ist deshalb normal und kein Fehler.
• In Konfiguration und Werkzeugen. Einträge für server_name oder virtuelle Hosts von Webservern, Cookie-Domains, Oberflächen von Hosting-Anbietern und CDNs, Mail-Domains, an eine Domain gebundene API-Schlüssel und Datenbankschlüssel sind in der A-Label-Form sicherer.
• In Tests und Datenpipelines. Einige Bibliotheken übergeben Unicode direkt an den Resolver und scheitern; die Umwandlung in Punycode ist die übliche Lösung. Da die Zuordnung eindeutig ist — ein Unicode-Label entspricht genau einem A-Label — ist die xn---Form außerdem ein stabiler Bezeichner für Protokolle und Suche.

Punycode ist eine umkehrbare Schreibweise, mehr nicht. Sie ist keine Verschlüsselung und kein Sicherheitsmerkmal: Jeder kann sie mit dem Werkzeug oben dekodieren; ein xn---Label sagt also „das wurde kodiert“ und nichts darüber, wem es gehört. Sie ist auch keine Komprimierung — sie macht Text meist länger, wie das Beispiel mit 6 Byte zu 11 Byte oben zeigt. Und sie ist nicht dasselbe wie die anderen Wege, auf denen Unicode durch das Internet reist; diese lösen andere Ebenen des Problems.

Schema	Wandelt was in was um	Wo es verwendet wird	中文 wird zu
Punycode (RFC 3492)	Ein Unicode-Domainlabel in ASCII-Buchstaben und -Ziffern	Nur internationale Domainlabels	xn--fiq228c
UTF-8 (RFC 3629)	Codepunkte in Bytes	Jede Datei- und Webanfrage	E4 B8 AD E6 96 87 (6 Byte)
Prozentkodierung (RFC 3986)	Bytes in %XX-Escapes	URL-Pfade, Abfragezeichenfolgen, Formulardaten	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Bytes in 64 ASCII-Zeichen	Binärdaten in Text, JSON, E-Mail, Data-URLs	5Lit5paH
HTML-Entitäten	Codepunkte in benannte oder numerische Verweise	HTML- und XML-Quelltext	中文
Unicode-Escapes	Codepunkte in \uXXXX	Quelltext und JSON-Zeichenkettenliterale	\u4e2d\u6587

Die praktische Folgerung: Punycode betrifft die Domain-Labels einer URL, nicht die ganze URL. Pfad und Abfragezeichenfolge sind ein anderes Problem und verwenden die Prozentkodierung (siehe URL-Kodierer).

• Die Größenbegrenzungen stammen von DNS, nicht von Punycode. Ein Label darf höchstens 63 Byte und ein vollständiger Name höchstens 255 Byte lang sein (RFC 1034 / 1035). Da ein A-Label reines ASCII ist, entspricht die Byte-Anzahl der Zeichenanzahl, und jedes Nicht-ASCII-Zeichen verbraucht einen Teil dieses Budgets — etwa ein Zeichen Budget je 1–4 Punycode-Buchstaben.
• Punycode wandelt alles um; Registrierungsstellen erlauben nur manches. Die IDNA-Regeln liegen darüber und beschränken, welche Codepunkte überhaupt registriert werden dürfen — Großbuchstaben, Leerzeichen, Satzzeichen wie ! und Markierungen sind in einer echten Domain nicht zulässig. Diese Seite führt die Umwandlung nach RFC 3492 durch und kodiert deshalb gern Text, den eine Registrierungsstelle ablehnen würde.
• Bleiben Sie bei einer Schrift. IDNA rät davon ab, Schriften innerhalb eines einzigen Labels zu mischen, gerade wegen Angriffen mit verwechselbaren Zeichen. Ein Name lässt sich kodieren und trotzdem unbrauchbar sein oder von Browsern auf eine Sperrliste gesetzt werden.
• Nicht doppelt kodieren. xn--, gefolgt von bereits kodiertem Text, ist ungültig; und ein Label, das rein ASCII ist, ändert sich überhaupt nie — es gibt nichts zu kodieren, also wird kein Präfix hinzugefügt.
• Ein abschließender Punkt ist in Ordnung. 例え.jp. ist ein vollständig qualifizierter Name, und das leere Label am Ende bleibt erhalten; leere Labels in der Mitte sind als Hostnamen ungültig.

„Warum erscheint meine chinesische Domain in der Adressleiste als xn--fiq228c.com?“

Weil der Browser sich dafür entschieden hat, das A-Label anzuzeigen. Die Website ist dieselbe; nutzen Sie die Dekodierungsrichtung dieser Seite, um die Unicode-Form zu sehen, oder kodieren Sie die Unicode-Form, um zu prüfen, ob beide Schreibweisen übereinstimmen.

„Muss ich meine DNS-Einträge, mein Zertifikat oder mein Hosting ändern?“

Nein. Behalten Sie das xn---A-Label überall dort bei, wo eine Maschine den Namen liest (DNS, Zertifikate, Konfigurationen), und verwenden Sie die Unicode-Form nur dort, wo ein Mensch ihn liest.

„Warum ist das Ergebnis länger als das, was ich eingegeben habe?“

Weil die Kodierung nicht die Zeichen selbst trägt, sondern Abstände zur Basis 36, und das 36-Zeichen-Alphabet Zahlen ausschreiben muss, die groß werden können. Das Wachstum ist zu erwarten, kein Fehler.

„Warum sagt das Dekodieren ‘Großbuchstabe’?“

Weil die Bootstring-Ziffern nur als Kleinbuchstaben definiert sind (a-z, 0-9). Ein großes A-Z nach dem letzten Bindestrich ist unter Berücksichtigung der Groß-/Kleinschreibungsunabhängigkeit von DNS mehrdeutig und wird deshalb gemeldet, statt stillschweigend geraten zu werden.

„Gilt Punycode für den Teil vor dem @ in einer E-Mail-Adresse?“

Nur der Domainteil ist ein DNS-Name und kann Punycode sein. Der lokale Teil wird vom Mailsystem behandelt, nicht von DNS, daher gilt diese Kodierung für ihn nicht.

„Können zwei verschiedene Unicode-Namen dasselbe A-Label erzeugen?“

Nein. Die Kodierung ist injektiv: Verschiedene Codepunktfolgen erzeugen immer verschiedene Bootstrings, daher ergibt das Dekodieren von xn--fiq228c genau 中文 und nichts anderes. Verwechselbar sein kann nur das Aussehen — verschiedene Zeichen, die einander ähnlich sehen. Das ist eine Eigenschaft des Unicode-Zeichenvorrats, nicht der Kodierung.

• RFC 3492 — Punycode, die auf dieser Seite umgesetzte Bootstring-Kodierung. Die oben genannten bekannten Testwerte werden mit den Beispielzeichenketten dieses Dokuments geprüft.
• RFC 5890, RFC 5891, RFC 5892 und Unicode UTS #46 — IDNA2008 und seine Auslegung in Browsern, also die Regeln, die festlegen, welche Zeichen zulässig sind, wie Labels normalisiert werden und wie Schriften gemischt werden dürfen.
• RFC 1034 und RFC 1035 — die von DNS übernommenen Grenzen von 63 Byte je Label und 255 Byte je Name.
• RFC 3490 und RFC 3491 — die ältere Generation IDNA2003, abgelöst durch IDNA2008. Wenn sich ein Name in älterer Software anders verhält, liegt das meist daran.

Hinweis zum Umfang: Dieses Werkzeug führt nur die Umwandlung nach RFC 3492 durch. Es ist kein IDN-Prüfer und prüft weder Registrierungsregeln noch Preise oder Verfügbarkeit einer Domain — und da es nie das Netzwerk anfragt, kann es nicht sagen, ob ein Name existiert.

Probieren Sie es oben aus: Fügen Sie 中文 ein und drücken Sie Text → Punycode kodieren, um das A-Label zu sehen, oder fügen Sie xn--fiq228c ein und drücken Sie Punycode dekodieren → Text, um die Zeichen zurückzuholen.