Zum Inhalt springen
BCBinary Code Translator
Menü

Konvertierung internationaler Domainnamen

Punycode-Konverter für Domains

Wandle ein Unicode-Label oder eine vollständige Domain in A-Labels mit dem Präfix xn-- um und dekodiere kanonisches Punycode zurück.

Die RFC-3492-Implementierung läuft lokal und führt weder DNS-Abfragen noch Domainregistrierungen aus.

Konvertierungsrichtung
0 Zeichen
0 Zeichen

Die Konvertierung läuft lokal in diesem Browser. Die Eingabe wird nicht hochgeladen.

Noch kein Ergebnis.

Die Rolle von Punycode bei IDNs

Das klassische DNS transportiert ASCII-Labels. Punycode nach RFC 3492 kodiert Nicht-ASCII-Codepoints als Folge aus Buchstaben, Ziffern und Bindestrichen.

In Domainnamen erhält ein kodiertes Label das Präfix xn-- und heißt A-Label. Jeder Abschnitt zwischen Punkten wird getrennt verarbeitet; die gesamte Domain darf nicht als eine einzige Zeichenfolge kodiert werden.

Diese Implementierung deckt die Punycode-Transformation und ein konservatives Labelprofil ab. Sie ersetzt nicht die vollständige UTS-#46-Verarbeitung von Browsern und Registries.

So konvertierst du Punycode

  1. Wähle Vollständige Domain für alle punktgetrennten Labels oder Einzelnes Label für nur einen Abschnitt.
  2. Verwende Kodieren mit einem Unicode-Namen und Dekodieren mit einem A-Label oder einer ASCII-Domain.
  3. Belasse Bindestriche und Punkte an der richtigen Stelle; leere Labels werden abgelehnt.
  4. Prüfe die kanonische Kleinschreibung vor der Verwendung in DNS-Konfigurationen.
  5. Validiere Registry-Regeln, Homographenrisiken und Verfügbarkeit separat.

Punycode-Beispiele für Labels und Domains

Die Fälle behandeln einzelne Labels, vollständige Domains, Schreibweise, Unicode-Punkte und abschließende Root-Punkte.

Eingabe Ausgabe Konvertierungsrichtung Hinweise
bücher xn--bcher-kva Kodieren Deutsches Label. Die einfachen ASCII-Buchstaben bleiben lesbar, während das nicht-ASCII-Zeichen ü im Punycode-Suffix kodiert wird.
mañana xn--maana-pta Kodieren Spanisches Label. Die rohe RFC-3492-Nutzlast lautet maana-pta; die DNS-A-Label-Form ergänzt xn--.
例子 xn--fsqu00a Kodieren Chinesisches Label. Ein Label ohne einfache ASCII-Zeichen erzeugt eine vollständig kodierte Nutzlast.
Münich.Example xn--mnich-kva.example Kodieren Vollständige Domain. Jedes Label wird unabhängig verarbeitet und die ASCII-Ausgabe wird kleingeschrieben normalisiert.
例子。测试 xn--fsqu00a.xn--0zwm56d Kodieren Unicode-Punkt. IDEOGRAPHIC FULL STOP wird vor dem Kodieren der Labels zu einem ASCII-Punkt normalisiert.
XN--BCHER-KVA.example bücher.example Dekodieren A-Label dekodieren. Der Vergleich von ASCII-Labels ist unabhängig von Groß- und Kleinschreibung; die zurückgegebene kanonische A-Label-Form ist kleingeschrieben.

Labels, Punkte und Schreibweise

Das Werkzeug normalisiert verbreitete Unicode-Punktzeichen zu ‘.’ und wandelt Labels in Kleinbuchstaben um. Ein abschließender Root-Punkt ist erlaubt und bleibt erhalten.

Nach der Kodierung muss jedes ASCII-Label 1 bis 63 Zeichen besitzen, darf nicht mit Bindestrich beginnen oder enden und die Domain darf ohne Root-Punkt 253 Zeichen nicht überschreiten.

  • Der Label-Modus akzeptiert keine Punkte.
  • Leere Labels zwischen zwei Punkten sind ungültig.
  • Buchstaben, kombinierende Zeichen, Zahlen und Bindestriche bilden das unterstützte Unicode-Profil.
  • A-Labels müssen mit xn-- beginnen und kanonisch sein.
  • Emoji und Symbole außerhalb des konservativen Profils werden abgelehnt.

Wie Bootstring-Punycode arbeitet

Punycode übernimmt zuerst grundlegende ASCII-Zeichen und stellt Nicht-ASCII-Codepoints anschließend als variable Deltas dar. Ein adaptiver Bias hält typische nahe Werte kurz.

Der Decoder rekonstruiert diese Deltas, fügt Codepoints an den richtigen Positionen ein und verwirft Überläufe, ungültige Ziffern und Surrogate.

Die Implementierung folgt RFC 3492 direkt und bringt keine neue Abhängigkeit mit. Moderne IDNA-Regeln bleiben Aufgabe des verbrauchenden Systems.

Wann Punycode benötigt wird

Punycode stellt internationale Namen in Feldern dar, die nur ASCII-DNS-Labels akzeptieren.

Element Beschreibung
DNS-Konfiguration Verwaltungsoberflächen können das A-Label mit xn-- statt der sichtbaren Unicode-Form verlangen.
Linkprüfung Beide Formen helfen bei der Kontrolle internationaler Ziele.
Datenmigration Ältere Systeme speichern häufig die kanonische ASCII-Form.
Zertifikatsdebugging SAN-Einträge und Logs können Punycode anzeigen.
Eingabevalidierung Labelgrenzen erkennen unmögliche Namen vor einer Abfrage.

Domainfehler und Sicherheitsgrenzen

Gültiges Punycode beweist weder Sicherheit, Registrierung noch Zulässigkeit. Optisch ähnliche Zeichen können Homographenangriffe ermöglichen.

Registries wenden IDNA, Normalisierung, Zeichentabellen und TLD-Richtlinien an. Diese Seite fragt solche Regeln nicht ab.

  • xn-- ist kein Echtheitsnachweis.
  • Zwei aufeinanderfolgende Punkte erzeugen ein leeres Label.
  • Bindestriche am Anfang oder Ende sind ungültig.
  • Labels über 63 Zeichen sind ungültig.
  • Kanonische Dekodierung wird durch erneute Kodierung geprüft.

Punycode, URL-Encoding und IDNA

Punycode kodiert Unicode-Domainlabels. Percent-Encoding kodiert Bytes in anderen URL-Bestandteilen und darf Punycode im Host nicht ersetzen.

IDNA ist der größere Regelsatz für zulässige Unicode-Namen und deren Abbildung. Punycode ist nur der reversible Kernalgorithmus.

Element Beschreibung
IDNA / UTS #46 Fügt Mapping, Normalisierung und Browser-Validitätsregeln hinzu.
URL-Encoding Stellt Bytes in Pfaden, Queries und anderen Teilen als %HH dar.
ASCII-DNS Verwendet die A-Labels, hängt aber weiterhin von Auflösung und externen Richtlinien ab.

Häufige Fragen zu Punycode

Führt das Werkzeug DNS-Abfragen aus?

Nein. Es wandelt Text ausschließlich lokal um.

Warum erscheint das Präfix xn--?

Es kennzeichnet ein ASCII-Label, dessen Rest Punycode enthält.

Wird eine Domain als Ganzes kodiert?

Nein. Jedes Label zwischen Punkten wird separat behandelt.

Bleiben Großbuchstaben erhalten?

Nein. DNS-Namen werden kanonisch kleingeschrieben.

Verhindert Punycode Homographenangriffe?

Nein. Zusätzliche Sicherheits- und Registry-Regeln sind erforderlich.

Wurde eine Abhängigkeit hinzugefügt?

Nein. Der RFC-3492-Algorithmus ist im Projekt implementiert und in der Lieferung dokumentiert.

Verwandte Tools

Alle Tools anzeigen

Cookie-Einstellungen

Verwalte deine Cookie-Einstellungen. Notwendige Cookies können nicht deaktiviert werden.

Notwendig

Erforderlich

Erforderlich für Sprachauswahl, Datenschutzeinstellungen und grundlegende Website-Funktionen.

Cookies: NEXT_LOCALE

Analyse

Optionale Analyse-Cookies helfen uns, den Traffic zu verstehen und die Website zu verbessern.

Cookies: _ga, _gid, _gat, _clck, _clsk

Werbung

Optionale Werbe-Cookies können genutzt werden, um relevante Anzeigen zu zeigen und deren Leistung zu messen.

Cookies: __gads, _gcl_au, IDE