Punycode / IDN-Konverter

Was ist Punycode?#

Das Domain Name System wurde auf ASCII aufgebaut — den Buchstaben A-Z, Ziffern und dem Bindestrich. Wie löst also ein Browser eine Domain wie 中文.com oder münchen.de auf, deren Zeichen nicht in diesem Alphabet stehen? Die Antwort ist Punycode (und das IDN-Framework drumherum): eine umkehrbare Kodierung, die jedes Nicht-ASCII-Label in eine ASCII-sichere Form verwandelt, die mit dem Präfix xn-- beginnt. Das DNS sieht immer nur xn--fiq228c.com; der Browser zeigt Ihnen 中文.com.

Dieses Werkzeug konvertiert in beide Richtungen:

• Nach ASCII nimmt eine Unicode-Domain oder E-Mail und erzeugt die xn---Form, die DNS und Zertifikate tatsächlich tragen. Jedes Label wird unabhängig konvertiert — münchen.中文.com wird zu xn--mnchen-3ya.xn--fiq228c.com, wobei das abschließende .com unangetastet bleibt, weil es bereits ASCII ist.
• Nach Unicode macht das Umgekehrte: Es liest xn---Label zurück in die menschenlesbare Schrift.

E-Mail wird ebenfalls behandelt. Das Werkzeug erkennt das @, konvertiert nur den Domain-Teil und lässt den lokalen Teil (den Postfachnamen) unangetastet — sodass Büchner@中文.com zu Bü[email protected] wird, niemals eine verfälschte Ganz-String-Konvertierung.

Verwendung#

1. Wählen Sie Nach ASCII oder Nach Unicode am Umschalter oben links. Das Werkzeug schlägt zudem eine Richtung vor, wenn es ein xn---Label in Ihrer Eingabe bemerkt.
2. Fügen Sie eine Domain oder eine E-Mail in die Eingabe-Fläche ein. Die Kopfzeile zeigt, ob sie als Domain oder E-Mail erkannt wurde.
3. Das konvertierte Ergebnis füllt die Ausgabe-Fläche; klicken Sie auf Kopieren, um es zu übernehmen.
4. Unter den Flächen zeigt die Tabelle Detail pro Label jedes Label und was daraus wurde — praktisch, wenn eine lange Domain mehrere Nicht-ASCII-Label hat und nur einige sich geändert haben.
5. Verwenden Sie Ausgabe → Eingabe, um die Ausgabe zurück in die Eingabe zu verschieben und die Richtung zu drehen (ein schneller Round-Trip-Check), Beispiel, um münchen.中文.com zu laden, und Leeren, um zurückzusetzen.

Eckpunkte#

• Beide Richtungen, jedes Label für sich. Jedes Label wird unabhängig konvertiert und die Detail-Tabelle zeigt genau, welche sich geändert haben und welche ASCII blieben.
• E-Mail-bewusst. Ein einzelnes @ wird erkannt und der Postfachname bewahrt; nur die Domain-Seite wird kodiert. Eingaben mit mehreren @-Zeichen werden mit einer klaren Meldung abgelehnt, statt das Ergebnis stillschweigend zu korrumpieren.
• Separator-Normalisierung. Der vollbreite Punkt ．, der ideographische Punkt 。 und das Halbbreite-｡ werden alle als das ASCII-. behandelt, das sie im IDN wirklich sind, sodass eingefügter Text nicht bricht.
• Streng bei fehlerhafter Eingabe. Ein schlechtes xn---Label (zum Beispiel xn--!!) liefert einen sauberen Fehler, der auf das fehlerhafte Label zeigt, statt eine falsche Domain zu erzeugen.
• Ehrlich über den Scope. Der Compliance-Hinweis unter dem Werkzeug stellt klar: Dies implementiert die Punycode-Kodierung und den Mapping-Schritt — es ist kein vollständiger IDNA2008-Gültigkeitsprüfer, deshalb kann ein technisch ungültiges ACE-Label hier dennoch dekodiert werden.

Konkretes Beispiel#

Beim Konvertieren Nach ASCII wird der Platzhalter münchen.中文.com zu:

xn--mnchen-3ya.xn--fiq228c.com

Das Detail zeigt drei Label, zwei davon konvertiert: münchen → xn--mnchen-3ya, 中文 → xn--fiq228c und .com unangetastet, weil es bereits ASCII war. Wechseln Sie zu Nach Unicode und fügen Sie das Ergebnis wieder ein, um münchen.中文.com exakt zurückzugewinnen.

Einige weitere echte Konvertierungen, die man gesehen haben sollte:

中文.com           → xn--fiq228c.com
münchen.de        → xn--mnchen-3ya.de
😂.com             → xn--g28h.com
café.fr           → xn--caf-dma.fr
日本語.jp          → xn--wgv71a119e.jp
Büchner@中文.com   → Bü[email protected]   (E-Mail: Postfach bewahrt)

Das letzte ist der Fall, der Leute austrickst: naive Werkzeuge kodieren den ganzen String und brechen die Adresse. Hier ändert sich nur der Domain-Teil nach dem @.

FAQ#

Warum wird meine Emoji-Domain zu einem so kurzen xn---Label?#

Eine einzeichen-Emoji-Domain wie 😂.com wird zu xn--g28h.com, weil Punycode für ein Label mit einem Nicht-ASCII-Zeichen gefolgt von ASCII außergewöhnlich kompakt ist — es kodiert die Positionen und Codepunkte der Nicht-ASCII-Zeichen relativ zu den ASCII-Zeichen, sodass ein einzeicheniges Label sehr wenige Bytes braucht. Längere oder variantenreichere Nicht-ASCII-Label erzeugen längere ACE-Strings.

Die Ausgabe sieht genauso aus wie die Eingabe — ist etwas passiert?#

Wenn jedes Label in Ihrer Eingabe bereits reines ASCII ist (zum Beispiel example.com), gibt es nichts zu kodieren, und die Ausgabe gleicht der Eingabe. Die Detail-Tabelle ist der zuverlässige Indikator: ein Label, dessen Ausgabe seiner Eingabe gleicht, wurde nicht konvertiert, weil es nicht nötig war.

Ich habe eine E-Mail eingefügt und der lokale Teil wurde nicht konvertiert. Ist das korrekt?#

Ja, und es ist absichtlich. Internationalisierte E-Mail (SMTPUTF8) erlaubt UTF-8 im Postfachnamen, aber es in xn-- zu konvertieren ist für den häufigen Fall falsch — der lokale Teil ist kein DNS-Name und wird nicht über Punycode aufgelöst. Dieses Werkzeug konvertiert nur die Domain-Seite, die der Teil ist, der DNS-sicher sein muss. Deshalb werden auch mehrere @-Zeichen abgelehnt: Sie machen „die Domain-Seite“ mehrdeutig.

Kann ich die ASCII-Form verwenden, um jede Domain zu registrieren oder aufzulösen?#

Für die Auflösung durch jeden modernen Browser oder Resolver: ja. Für die Registrierung sind die Regeln strenger: IDNA2008 verbietet bestimmte Zeichen und Normalisierungen, die ältere Mappings (IDNA2003) erlaubten. Dieses Werkzeug führt die Kodierung treu aus, führt aber nicht die vollständigen IDNA2008-Gültigkeitsprüfungen durch, deshalb könnte ein String, der hier sauber kodiert, von einem Registrar dennoch abgelehnt werden. Im Zweifel bestätigen Sie mit dem Lookup-Werkzeug Ihres Registrars.