Punycode / IDN-konverter

Punycode er altså ikke et sprog, en skrifttype eller en landekode — det er en oversættelse mellem to stavemåder af det samme navn. Unicode-stavemåden kaldes et U-label (中文.com, bücher.de), ASCII-stavemåden kaldes et A-label (xn--fiq228c.com, xn--bcher-kva.de), og hele idéen om at putte internationale navne ind i DNS kaldes IDN (internationale domænenavne) eller IDNA, sættet af regler der bygger ovenpå.

Den findes, fordi DNS blev designet i begyndelsen af 1980'erne omkring et bevidst lille alfabet. Et værtsnavn, der rejser gennem DNS, ind i en zonefil, en resolver-cache, en loglinje eller et TLS-certifikat, skal være ren ASCII — wire-formatet har simpelthen ikke et felt til andet. Punycode er nødudgangen: det lader et navn, der ikke er ASCII, rejse, som om det var det, og lader modtageren rekonstruere de oprindelige tegn nøjagtigt. Derfor virker et kinesisk domæne overhovedet i en browser, og derfor er xn-- den ene streng, man ser alle steder, hvor Unicode-stavemåden ikke kan sendes.

Hvad man skriver (U-label)	Hvad DNS modtager (A-label)	Hvad det betyder
中文.com	xn--fiq228c.com	De kinesiske ord for „kinesisk sprog“
中国	xn--fiqs8s	„Kina“ på kinesisk
例え.jp	xn--r8jz45g.jp	Japanske eksempler
bücher.de	xn--bcher-kva.de	Tysk bücher, „bøger“
münchen.de	xn--mnchen-3ya.de	München
😂.com	xn--e28h.com	Et emoji-label — lovligt i kodningen, men ikke i de fleste registre

En længdesammenligning værd at huske: 中文 er 2 tegn og 6 byte i UTF-8, men xn--fiq228c er 11 ASCII-byte. Punycode gør normalt et navn længere, aldrig kortere.

Tag bücher og se de tre trin. Motoren kaldes en bootstring, og hele algoritmen er kun få snese linjer kode (den kan læses i denne sides script).

1. Kopiér de almindelige tegn forrest. Hvert grundlæggende ASCII-tegn kopieres i sin oprindelige rækkefølge og holdes læseligt: bücher → bcher. Fordi noget blev kopieret og noget blev tilbage, tilføjes en enkelt - som grænse: bcher-.
2. Skriv resten som tal i base 36. De resterende tegn behandles i stigende kodepunktrækkefølge, og hvert af dem skrives som et tal med variabel længde i base 36, hvor a=0 … z=25 og 0=26 … 9=35. For bücher bliver det resterende tegn ü til cifrene kva.
3. Sæt præfikset på. Den kodede del tilføjet den kopierede del giver bcher-kva, og i en domænekontekst skrives det som xn--bcher-kva.

Tricket, der gør det smart, er, hvad disse base-36-tal indeholder: ikke tegnet selv, men et delta — hvor langt tegnet er fra det forrige kodede kodepunkt, plus hvor det hører hjemme i strengen. Koderen går igennem kodepunkter i stigende orden, og hver cifferrække beskriver en position og en afstand. Efter hvert tegn justeres et fælles tal kaldet bias, så det følgende tal behøver så få cifre som muligt.

To konsekvenser, man selv kan se ovenfor:

• Ens tegn er billige. Fordi kun afstande gemmes, koster en række af det samme tegn næsten intet: 30 kopier af 中 kodes til xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, kun 36 byte. En målt, ikke-relateret men nærliggende blanding af kinesiske tegn pakker cirka 41 tegn ind i ét lovligt 63-byte-label, og et enkelt gentaget tegn når 57.
• Spredte tegn er dyre. Et tegn langt fra det forrige kræver et længere deltatal. Kinesisk tekst med mange forskellige tegn koster typisk cirka 2–3 ekstra bogstaver pr. tegn, og derfor løber et CJK-label tør for plads et sted omkring 20–40 tegn, selvom labelgrænsen er 63 byte.

Afkodning er den samme opskrift baglæns: kopiér ASCII-præfikset, læs cifrene, omregn deltaerne til kodepunkter, og indsæt hvert nyt tegn i strengen på den position, deltaet koder. Der findes kun cifre med små bogstaver i bootstringen, og derfor afvises et stort bogstav inde i en kodet del i stedet for at blive gættet — DNS er ufølsom over for store/små bogstaver, så hvis begge slags var tilladt, ville to forskellige stavemåder blive tvetydige.

• I adresselinjen. Browsere kan vise xn--fiq228c.com i stedet for 中文.com. Det er den samme side. Nogle browsere viser med vilje Punycode-formen, når et navn blander skriftsystemer, netop så et lignende tegn (kyrillisk а over for latinsk a) ikke kan gemme sig i URL'en.
• I selve DNS. Zonefiler, dig / nslookup / DNS-over-HTTPS-svar og resolverlogfiler indeholder kun nogensinde xn---formen; almindelig Unicode afvises eller ødelægges stille.
• I TLS-certifikater. Det alternative emnenavn for et internationalt domæne gemmes som et A-label (DNS:xn--fiq228c.com), så et certifikat, der ikke ligner det navn, der blev indtastet, er normalt og ikke en uoverensstemmelse.
• I konfiguration og værktøjer. Webserverens server_name- / virtuelle værtsposter, cookie-domæner, hosting- og CDN-paneler, mail-domæner, API-nøgler bundet til et domæne og databasenøgler er alle tryggere i A-label-form.
• I test og datapipelines. Nogle biblioteker sender Unicode direkte til resolveren og fejler; at konvertere til Punycode først er den standardmæssige løsning. Fordi afbildningen er kanonisk — ét Unicode-label svarer til præcis ét A-label — er xn---formen også en stabil identifikator til logfiler og søgning.

Punycode er en omkehrbar stavemåde, intet andet. Det er ikke kryptering, og det er ikke en sikkerhedsfunktion: enhver kan afkode det med værktøjet ovenfor, så et xn---label siger "dette er kodet" og intet om, hvem der ejer det. Det er heller ikke komprimering — det gør normalt tekst længere, som eksemplet 6 byte til 11 byte ovenfor viser. Og det er ikke det samme som de andre måder, Unicode rejser rundt på internettet; de løser andre lag af problemet.

Skema	Omdanner hvad til hvad	Hvor det bruges	中文 bliver til
Punycode (RFC 3492)	Et Unicode-domænelabel til ASCII-bogstaver og -cifre	Kun internationale domænelabels	xn--fiq228c
UTF-8 (RFC 3629)	Kodepunkter til bytes	Hver fil og webanmodning	E4 B8 AD E6 96 87 (6 byte)
Procentkodning (RFC 3986)	Bytes til %XX-escapes	URL-stier, forespørgselsstrenge, formularindhold	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Bytes til 64 ASCII-tegn	Binære data i tekst, JSON, e-mail, data-URL'er	5Lit5paH
HTML-entiteter	Kodepunkter til navngivne eller numeriske referencer	HTML- og XML-kildekode	中文
Unicode-escapes	Kodepunkter til \uXXXX	Kildekode og JSON-strengliteraler	\u4e2d\u6587

Den praktiske konklusion: Punycode gælder for domænelabels i en URL, ikke for hele URL'en. Stien og forespørgselsstrengen er et andet problem og bruger procentkodning (se URL-kodere).

• Størrelsesgrænserne kommer fra DNS, ikke fra Punycode. Et label må højst være 63 byte, og et helt navn højst 255 byte (RFC 1034 / 1035). Fordi et A-label er ren ASCII, er byte-antallet lig med tegnantallet, og hvert ikke-ASCII-tegn bruger en del af det budget — cirka 1 tegn af budgettet pr. 1–4 Punycode-bogstaver.
• Punycode konverterer alt; registre tillader kun noget. IDNA-reglerne ligger ovenpå og begrænser, hvilke kodepunkter der overhovedet må registreres — store bogstaver, mellemrum, tegnsætning som ! og flag er ikke lovlige i et rigtigt domæne. Denne side udfører RFC 3492-konverteringen, så den koder gerne tekst, som et register ville afvise.
• Bliv i ét skriftsystem. IDNA frarådes at blande skriftsystemer inde i ét label, netop på grund af angreb med lignende tegn. Et navn kan kodes og alligevel være ubrugeligt, eller brugeligt men sat på en blokeringsliste af browsere.
• Kod ikke to gange. xn-- efterfulgt af allerede kodet tekst er ugyldigt, og et label, der kun består af ASCII, ændrer sig slet ikke — der er intet at kode, så der tilføjes intet præfiks.
• Et efterstillet punktum er i orden. 例え.jp. er et fuldt kvalificeret navn, og det tomme label til sidst bevares; tomme labels midt i navnet er ikke gyldige værtsnavne.

„Hvorfor vises mit kinesiske domæne som xn--fiq228c.com i adresselinjen?“

Fordi browseren valgte at vise A-labelet. Siden er den samme; brug denne sides afkodningsretning til at se Unicode-formen, eller kod Unicode-formen for at kontrollere, at begge stavemåder stemmer overens.

„Skal DNS-poster, certifikat eller hosting ændres?“

Nej. Behold xn---A-labelet alle steder, en maskine læser navnet (DNS, certifikater, konfigurationer), og brug Unicode-formen kun, hvor et menneske læser det.

„Hvorfor er resultatet længere end det, jeg skrev?“

Fordi kodningen ikke bærer selve tegnene, bærer den base-36-afstande, og det 36 tegn lange alfabet skal stave tal, der kan blive store. Vækst er forventet, ikke en fejl.

„Hvorfor siger afkodningen „stort bogstav“?“

Fordi bootstring-cifrene kun er defineret med små bogstaver (a-z, 0-9). Et stort A-Z efter den sidste bindestreg er tvetydigt, når DNS' ufølsomhed over for store/små bogstaver tages i betragtning, så det rapporteres i stedet for at blive gættet stille.

„Gælder Punycode for delen før @ i en e-mailadresse?“

Kun domænedelen er et DNS-navn og kan være Punycode. Den lokale del håndteres af mailsystemet, ikke af DNS, så denne kodning gælder ikke for den.

„Kan to forskellige Unicode-navne give det samme A-label?“

Nej. Kodningen er injektiv: forskellige kodepunktsekvenser giver altid forskellige bootstrings, så afkodning af xn--fiq228c giver præcis 中文 og intet andet. Det, der kan kollidere, er udseendet — forskellige tegn, der ligner hinanden — og det er en egenskab ved Unicode-repertoiret, ikke ved kodningen.

• RFC 3492 — Punycode, bootstring-kodningen implementeret på denne side. De kendte testvektorer ovenfor er tjekket mod eksempelstrengene i dokumentet.
• RFC 5890, RFC 5891, RFC 5892 og Unicode UTS #46 — IDNA2008 og dens fortolkning i browseren, reglerne der afgør, hvilke tegn der er lovlige, hvordan labels normaliseres, og hvordan skriftsystemer må blandes.
• RFC 1034 og RFC 1035 — grænserne på 63 byte for label og 255 byte for navn, arvet fra DNS.
• RFC 3490 og RFC 3491 — den ældre IDNA2003-generation, afløst af IDNA2008. Hvis et navn opfører sig anderledes i gammel software, er det som regel grunden.

Afgrænsning: dette værktøj udfører RFC 3492-konvertering og intet andet. Det er ikke en IDN-validator og kontrollerer ikke registreringsregler, priser eller ledighed for et domæne — og da det aldrig kontakter netværket, kan det ikke fortælle, om et navn findes.

Prøv det ovenfor: indsæt 中文 og tryk på Kod tekst → Punycode for at se A-labelet, eller indsæt xn--fiq228c og tryk på Afkod Punycode → tekst for at få tegnene tilbage.