Punycode- / IDN-converter

Punycode is dus geen taal, geen lettertype en geen landcode — het is een vertaling tussen twee spellingen van dezelfde naam. De Unicode-spelling heet een U-label (中文.com, bücher.de), de ASCII-spelling heet een A-label (xn--fiq228c.com, xn--bcher-kva.de), en het hele idee om internationale namen in DNS op te nemen heet IDN (internationalized domain names) of IDNA, de regels die er bovenop zijn gebouwd.

Het bestaat omdat DNS begin jaren tachtig is ontworpen rond een bewust klein alfabet. Een hostnaam die door DNS reist, in een zonebestand, een resolvercache, een logregel of een TLS-certificaat, moet gewone ASCII zijn — het wire-formaat heeft simpelweg geen veld voor iets anders. Punycode is de ontsnappingsluik: het laat een naam die geen ASCII is reizen alsof dat wel zo is, en laat het ontvangende eind de oorspronkelijke tekens exact reconstrueren. Daarom werkt een Chinees domein in een browser überhaupt, en is xn-- de ene reeks die u overal ziet waar de Unicode-spelling niet verstuurd kan worden.

Wat u typt (U-label)	Wat DNS ontvangt (A-label)	Wat het betekent
中文.com	xn--fiq228c.com	De Chinese woorden voor “Chinese taal”
中国	xn--fiqs8s	“China” in het Chinees
例え.jp	xn--r8jz45g.jp	Japanse voorbeelden
bücher.de	xn--bcher-kva.de	Duits bücher, “boeken”
münchen.de	xn--mnchen-3ya.de	München
😂.com	xn--e28h.com	Een emoji-label — legaal in de codering, niet in de meeste registers

Een lengtevergelijking om te onthouden: 中文 is 2 tekens en 6 bytes in UTF-8, maar xn--fiq228c is 11 ASCII-bytes. Punycode maakt een naam meestal langer, nooit korter.

Neem bücher en kijk naar de drie stappen. De motor heet een bootstring, en het hele algoritme is slechts enkele tientallen regels code (u kunt het lezen in het script van deze pagina).

1. Kopieer de gewone tekens vooraan. Elk basis-ASCII-teken wordt in zijn oorspronkelijke volgorde gekopieerd en leesbaar gehouden: bücher → bcher. Omdat er iets is gekopieerd en iets is overgebleven, wordt een enkel - als grens toegevoegd: bcher-.
2. Schrijf de rest als getallen in grondtal 36. De overige tekens worden verwerkt in oplopende volgorde van codepunten, en elk wordt geschreven als een getal met variabele lengte in grondtal 36, waarbij a=0 … z=25 en 0=26 … 9=35. Voor bücher wordt het overgebleven teken ü de cijfers kva.
3. Plak het voorvoegsel erop. Het gecodeerde deel achter het gekopieerde deel geeft bcher-kva, en in een domeincontext wordt het geschreven als xn--bcher-kva.

De truc die dit slim maakt is wat die grondtal-36-getallen bevatten: niet het teken zelf, maar een delta — hoe ver het teken van het eerder gecodeerde codepunt af ligt, plus waar het in de tekenreeks hoort. De codeerder loopt de codepunten in oplopende volgorde af, en elke reeks cijfers beschrijft een positie en een afstand. Na elk teken wordt een gedeeld getal, de bias, aangepast zodat het volgende getal zo weinig mogelijk cijfers nodig heeft.

Twee gevolgen die u hierboven zelf kunt zien:

• Vergelijkbare tekens zijn goedkoop. Omdat alleen afstanden worden opgeslagen, kost een reeks van hetzelfde teken bijna niets: 30 keer 中 codeert tot xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, slechts 36 bytes. Een gemeten, niet-verwante maar nabije mix van Chinese tekens past ongeveer 41 tekens in één geldig label van 63 bytes, en een enkel herhaald teken komt tot 57.
• Verspreide tekens zijn duur. Een teken ver van het vorige heeft een langer deltagetal nodig. Chinese tekst met veel verschillende tekens kost meestal ongeveer 2–3 extra letters per teken, daarom loopt een CJK-label ergens rond 20–40 tekens op de ruimte, ook al is de labellimiet 63 bytes.

Decoderen is hetzelfde recept achterstevoren: kopieer het ASCII-voorvoegsel, lees de cijfers, zet de delta's terug in codepunten, en voeg elk nieuw teken in de tekenreeks in op de positie die de delta codeert. In de bootstring bestaan alleen kleine cijfers, daarom wordt een hoofdletter binnen een gecodeerd deel geweigerd in plaats van geraden — DNS is hoofdletterongevoelig, dus beide schrijfwijzen toestaan zou twee verschillende spellingen dubbelzinnig maken.

• In de adresbalk. Browsers kunnen xn--fiq228c.com tonen in plaats van 中文.com. Het is dezelfde site. Sommige browsers tonen bewust de Punycode-vorm wanneer een naam schriften mengt, precies zodat een op elkaar lijkend teken (Cyrillische а versus Latijnse a) zich niet in de URL kan verbergen.
• In DNS zelf. Zonebestanden, dig / nslookup / DNS-over-HTTPS-antwoorden en resolverlogboeken bevatten altijd alleen de xn---vorm; gewone Unicode wordt geweigerd of stilletjes verminkt.
• In TLS-certificaten. De subject alternative name voor een internationaal domein wordt opgeslagen als A-label (DNS:xn--fiq228c.com), dus een certificaat dat er niet uitziet als de naam die u typte, is normaal en geen afwijking.
• In configuratie en tooling. Vermeldingen van server_name / virtuele hosts van webservers, cookie-domeinen, hosting- en CDN-panelen, maildomeinen, API-sleutels die aan een domein gebonden zijn, en databasesleutels zijn allemaal veiliger in de A-labelvorm.
• In tests en datapijplijnen. Sommige bibliotheken geven Unicode direct door aan de resolver en falen; eerst naar Punycode converteren is de standaardoplossing. Omdat de afbeelding canoniek is — één Unicode-label komt overeen met precies één A-label — is de xn---vorm ook een stabiele identificatie voor logs en zoekopdrachten.

Punycode is een omkeerbare spelling, meer niet. Het is geen versleuteling en het is geen beveiligingsfunctie: iedereen kan het met de bovenstaande tool decoderen, dus een xn---label zegt “dit is gecodeerd” en niets over wie het bezit. Het is ook geen compressie — het maakt tekst meestal langer, zoals het voorbeeld van 6 tot 11 bytes hierboven laat zien. En het is niet hetzelfde als de andere manieren waarop Unicode over internet reist; die lossen andere lagen van het probleem op.

Schema	Zet wat om in wat	Waar het wordt gebruikt	中文 wordt
Punycode (RFC 3492)	Een Unicode-domeinlabel naar ASCII-letters en -cijfers	Alleen internationale domeinlabels	xn--fiq228c
UTF-8 (RFC 3629)	Codepunten naar bytes	Elk bestand en elk webverzoek	E4 B8 AD E6 96 87 (6 bytes)
Procentcodering (RFC 3986)	Bytes naar %XX-escapes	URL-paden, queryreeksen, formulierlichamen	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Bytes naar 64 ASCII-tekens	Binaire gegevens in tekst, JSON, e-mail, data-URL's	5Lit5paH
HTML-entiteiten	Codepunten naar benoemde of numerieke verwijzingen	HTML- en XML-bron	中文
Unicode-escapes	Codepunten naar \uXXXX	Broncode en JSON-tekenreeksliteralen	\u4e2d\u6587

De praktische conclusie: Punycode geldt voor de domeinlabels van een URL, niet voor de hele URL. Het pad en de queryreeks zijn een ander probleem en gebruiken procentcodering (zie URL-encoders).

• Groottelimieten komen van DNS, niet van Punycode. Eén label mag maximaal 63 bytes zijn en een volledige naam maximaal 255 bytes (RFC 1034 / 1035). Omdat een A-label puur ASCII is, is het aantal bytes gelijk aan het aantal tekens, en elk niet-ASCII-teken neemt een deel van dat budget in beslag — ongeveer 1 teken budget per 1–4 Punycode-letters.
• Punycode zet alles om; registers staan maar sommige dingen toe. IDNA-regels liggen erbovenop en beperken welke codepunten überhaupt geregistreerd mogen worden — hoofdletters, spaties, leestekens zoals ! en vlaggen zijn niet legaal in een echt domein. Deze pagina voert de RFC 3492-conversie uit, dus hij codeert gewillig tekst die een register zou weigeren.
• Blijf binnen één schrift. IDNA ontmoedigt het mengen van schriften binnen één label, precies vanwege aanvallen met op elkaar lijkende tekens. Een naam kan worden gecodeerd en toch onbruikbaar zijn, of bruikbaar maar door browsers op een zwarte lijst gezet.
• Codeer niet dubbel. xn-- gevolgd door al gecodeerde tekst is ongeldig, en een label dat puur ASCII is verandert helemaal niet — er valt niets te coderen, dus wordt geen voorvoegsel toegevoegd.
• Een afsluitende punt is prima. 例え.jp. is een volledig gekwalificeerde naam en het lege label aan het einde blijft bewaard; lege labels in het midden zijn geen geldige hostnamen.

“Waarom staat mijn Chinese domein als xn--fiq228c.com in de adresbalk?”

Omdat de browser ervoor koos het A-label weer te geven. De site is identiek; gebruik de decodeerrichting van deze pagina om de Unicode-vorm te zien, of codeer de Unicode-vorm om te controleren dat beide spellingen overeenkomen.

“Moet ik mijn DNS-records, certificaat of hosting wijzigen?”

Nee. Houd het xn---A-label overal waar een machine de naam leest (DNS, certificaten, configuraties), en gebruik de Unicode-vorm alleen waar een mens hem leest.

“Waarom is het resultaat langer dan wat ik typte?”

Omdat de codering de tekens zelf niet bevat, maar grondtal-36-afstanden, en het alfabet van 36 tekens getallen moet spellen die groot kunnen zijn. Groei is te verwachten, geen fout.

“Waarom zegt het decoderen ‘hoofdletter’?”

Omdat bootstring-cijfers alleen in kleine letters zijn gedefinieerd (a-z, 0-9). Een hoofdletter A-Z na het laatste koppelteken is dubbelzinnig zodra DNS-hoofdletterongevoeligheid in aanmerking wordt genomen, dus wordt die gemeld in plaats van stilletjes geraden.

“Geldt Punycode voor het deel vóór de @ in een e-mailadres?”

Alleen het domeindeel is een DNS-naam en kan Punycode zijn. Het lokale deel wordt door het mailsysteem afgehandeld, niet door DNS, dus deze codering geldt er niet voor.

“Kunnen twee verschillende Unicode-namen hetzelfde A-label opleveren?”

Nee. De codering is injectief: verschillende reeksen codepunten geven altijd verschillende bootstrings, dus het decoderen van xn--fiq228c geeft precies 中文 terug en niets anders. Wat kan botsen is de verschijning — verschillende tekens die er gelijk uitzien — en dat is een eigenschap van de Unicode-repertoire, niet van de codering.

• RFC 3492 — Punycode, de bootstring-codering die op deze pagina is geïmplementeerd. De hierboven genoemde bekende vectoren worden gecontroleerd tegen de voorbeeldreeksen in dat document.
• RFC 5890, RFC 5891, RFC 5892 en Unicode UTS #46 — IDNA2008 en zijn interpretatie aan de browserkant, de regels die bepalen welke tekens geldig zijn, hoe labels worden genormaliseerd en hoe schriften gemengd mogen worden.
• RFC 1034 en RFC 1035 — de labellimiet van 63 bytes en de naamlimiet van 255 bytes die uit DNS zijn overgenomen.
• RFC 3490 en RFC 3491 — de oudere IDNA2003-generatie, vervangen door IDNA2008. Als een naam zich in oude software anders gedraagt, komt dat meestal hiervandaan.

Reikwijdtenoot: deze tool voert alleen de RFC 3492-conversie uit. Het is geen IDN-validator en controleert geen registratieregels, prijzen of beschikbaarheid van een domein — en omdat hij nooit het netwerk benadert, kan hij u niet vertellen of een naam bestaat.

Probeer het hierboven: plak 中文 en druk op Tekst coderen → Punycode om het A-label te zien, of plak xn--fiq228c en druk op Punycode decoderen → tekst om de tekens terug te krijgen.