Punycode / IDN-omformer

Punycode er altså ikke et språk, en skrift eller en landskode — det er en oversettelse mellom to stavemåter av samme navn. Unicode-stavemåten kalles en U-etikett (中文.com, bücher.de), ASCII-stavemåten kalles en A-etikett (xn--fiq228c.com, xn--bcher-kva.de), og hele ideen om å sette internasjonale navn inn i DNS kalles IDN (internasjonaliserte domenenavn) eller IDNA, settet med regler bygget oppå det.

Den finnes fordi DNS ble designet tidlig på 1980-tallet rundt et bevisst lite alfabet. Et vertsnavn som reiser gjennom DNS, inn i en sonefil, en resolver-cache, en logglinje eller et TLS-sertifikat, må være ren ASCII — overføringsformatet har rett og slett ikke noe felt for noe annet. Punycode er nødutgangen: det lar et navn som ikke er ASCII reise som om det var det, og lar mottakeren rekonstruere de opprinnelige tegnene nøyaktig. Det er derfor et kinesisk domene i det hele tatt fungerer i en nettleser, og hvorfor xn-- er den ene strengen man ser overalt der Unicode-stavemåten ikke kan sendes.

Det som skrives (U-etikett)	Hva DNS får (A-etikett)	Hva den betyr
中文.com	xn--fiq228c.com	De kinesiske ordene for “kinesisk språk”
中国	xn--fiqs8s	“Kina” på kinesisk
例え.jp	xn--r8jz45g.jp	Japanske eksempler
bücher.de	xn--bcher-kva.de	Tysk bücher, “bøker”
münchen.de	xn--mnchen-3ya.de	München
😂.com	xn--e28h.com	En emoji-etikett — lovlig i kodingen, ikke i de fleste registre

En lengdesammenligning verdt å huske: 中文 er 2 tegn og 6 byte i UTF-8, men xn--fiq228c er 11 ASCII-byte. Punycode gjør vanligvis et navn lengre, aldri kortere.

Ta bücher og se de tre trinnene. Motoren kalles en bootstring, og hele algoritmen er bare noen få titalls linjer kode (den kan leses i skriptet på denne siden).

1. Kopier de vanlige tegnene først. Hvert grunnleggende ASCII-tegn kopieres i opprinnelig rekkefølge og holdes lesbart: bücher → bcher. Fordi noe ble kopiert og noe ble igjen, legges et enkelt - til som grense: bcher-.
2. Skriv resten som tall i base 36. De gjenværende tegnene behandles i økende kodepunktrekkefølge, og hvert skrives som et tall med variabel lengde i base 36 der a=0 … z=25 og 0=26 … 9=35. For bücher blir det gjenværende tegnet ü sifrene kva.
3. Fest prefikset på. Den kodede delen festet til den kopierte delen gir bcher-kva, og i domenekontekst skrives den som xn--bcher-kva.

Trikset som gjør dette smart, er hva base-36-tallene inneholder: ikke tegnet selv, men et delta — hvor langt tegnet er fra det forrige kodede kodepunktet, pluss hvor det hører hjemme i strengen. Koderen går gjennom kodepunktene i stigende rekkefølge, og hver sifferrekke beskriver en posisjon og en avstand. Etter hvert tegn justeres et felles tall kalt bias, slik at det neste tallet trenger færrest mulig sifre.

To konsekvenser som kan ses selv over:

• Like tegn er billige. Fordi bare avstander lagres, koster en rekke av samme tegn nesten ingenting: 30 kopier av 中 kodes til xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, bare 36 byte. En målt, ikke-relatert, men nærliggende blanding av kinesiske tegn får plass til omtrent 41 tegn i én lovlig etikett på 63 byte, og et enkelt gjentatt tegn kommer opp i 57.
• Spredte tegn er dyre. Et tegn langt fra det forrige trenger et lengre delta-tall. Kinesisk tekst med mange ulike tegn koster typisk omtrent 2–3 ekstra bokstaver per tegn, og derfor går en CJK-etikett tom for plass et sted rundt 20–40 tegn, selv om grensen for etiketter er 63 byte.

Dekoding er den samme oppskriften baklengs: kopier ASCII-prefikset, les sifrene, gjør deltaene om til kodepunkter, og sett inn hvert nye tegn i strengen på posisjonen deltaet koder. Det finnes bare små sifre i bootstring, og derfor avvises en stor bokstav inni en kodet del i stedet for å gjettes — DNS er ufølsom for store/små bokstaver, så å tillate begge ville gjort to ulike stavemåter tvetydige.

• I adressefeltet. Nettlesere kan vise xn--fiq228c.com i stedet for 中文.com. Det er samme nettsted. Noen nettlesere viser med vilje Punycode-formen når et navn blander skriftsystemer, nettopp slik at et likt utseende tegn (kyrillisk а mot latinsk a) ikke kan gjemme seg i adressen.
• I selve DNS. Sonefiler, dig / nslookup / svar fra DNS-over-HTTPS og loggene til resolveren inneholder bare xn---formen; vanlig Unicode avvises eller forvrenges stille.
• I TLS-sertifikater. Alternativt emnenavn for et internasjonalt domene lagres som en A-etikett (DNS:xn--fiq228c.com), så et sertifikat som ikke ser ut som navnet man skrev, er normalt og ikke en feil.
• I konfigurasjon og verktøy. Webserverens server_name / virtuelle vertsoppføringer, informasjonskapsel-domener, hosting- og CDN-paneler, e-postdomener, API-nøkler bundet til et domene og databasenøkler er alle tryggere i A-etikettform.
• I testing og datapipelines. Noen biblioteker sender Unicode rett til resolveren og feiler; å konvertere til Punycode først er den vanlige løsningen. Fordi avbildningen er kanonisk — én Unicode-etikett tilsvarer nøyaktig én A-etikett — er xn---formen også en stabil identifikator for logger og søk.

Punycode er en reversibel stavemåte, ikke noe mer. Det er ikke kryptering, og det er ikke en sikkerhetsfunksjon: hvem som helst kan dekode den med verktøyet over, så en xn---etikett sier “dette ble kodet” og ingenting om hvem som eier den. Det er heller ikke komprimering — det gjør vanligvis tekst lengre, som eksemplet med 6 byte mot 11 byte over viser. Og det er ikke det samme som de andre måtene Unicode reiser rundt på internett; de løser ulike lag av problemet.

Skjema	Gjør hva om til hva	Hvor det brukes	中文 blir
Punycode (RFC 3492)	En Unicode-domenetikett til ASCII-bokstaver og -siffer	Bare internasjonale domeneetiketter	xn--fiq228c
UTF-8 (RFC 3629)	Kodepunkter til byte	Hver fil og hver webforespørsel	E4 B8 AD E6 96 87 (6 byte)
Prosentkoding (RFC 3986)	Byte til %XX-escapes	URL-stier, spørringsstrenger, skjemainnhold	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Byte til 64 ASCII-tegn	Binær data i tekst, JSON, e-post, data-URL-er	5Lit5paH
HTML-entiteter	Kodepunkter til navngitte eller numeriske referanser	HTML- og XML-kildekode	中文
Unicode-escapes	Kodepunkter til \uXXXX	Kildekode og JSON-strenglitteraler	\u4e2d\u6587

Det praktiske poenget: Punycode gjelder domenetikettene i en URL, ikke hele URL-en. Stien og spørringsstrengen er et annet problem og bruker prosentkoding (se URL-kodere).

• Størrelsesgrensene kommer fra DNS, ikke fra Punycode. En etikett kan være på høyst 63 byte, og et komplett navn på høyst 255 byte (RFC 1034 / 1035). Siden en A-etikett er ren ASCII, er antall byte lik antall tegn, og hvert ikke-ASCII-tegn bruker en del av budsjettet — omtrent 1 tegn budsjett per 1–4 Punycode-bokstaver.
• Punycode konverterer alt; registrene tillater bare noe. IDNA-reglene ligger oppå og begrenser hvilke kodepunkter som i det hele tatt kan registreres — store bokstaver, mellomrom, tegnsetting som ! og flagg er ikke lovlige i et ekte domene. Denne siden utfører RFC 3492-konverteringen, så den koder gladelig tekst et register ville avvist.
• Bruk ett skriftsystem. IDNA frarådes blanding av skriftsystemer innenfor én etikett, nettopp på grunn av angrep med likende tegn. Et navn kan kodes og fortsatt være ubrukelig, eller brukbart men svartelistet av nettlesere.
• Ikke dobbeltkod. xn-- etterfulgt av allerede kodet tekst er ugyldig, og en etikett som bare er ASCII, endres aldri — det finnes ingenting å kode, så ingen prefiks legges til.
• Et avsluttende punktum er greit. 例え.jp. er et fullstendig kvalifisert navn, og den tomme etiketten på slutten beholdes; tomme etiketter i midten er ikke gyldige vertsnavn.

“Hvorfor vises det kinesiske domenet mitt som xn--fiq228c.com i adressefeltet?”

Fordi nettleseren valgte å gjengi A-etiketten. Nettstedet er identisk; bruk dekodingsretningen på denne siden for å se Unicode-formen, eller kod Unicode-formen for å kontrollere at begge stavemåtene stemmer.

“Må jeg endre DNS-postene, sertifikatet eller hostingen min?”

Nei. Behold xn---A-etiketten overalt maskiner leser navnet (DNS, sertifikater, konfigurasjon), og bruk Unicode-formen bare der et menneske leser den.

“Hvorfor er resultatet lengre enn det jeg skrev?”

Fordi kodingen ikke bærer selve tegnene, men base-36-avstander, og 36-tegnsalfabetet må stave ut tall som kan bli store. Vekst er forventet, ikke en feil.

“Hvorfor sier dekodingen ‘stor bokstav’?”

Fordi bootstring-sifrene er definert bare med små bokstaver (a-z, 0-9). En stor bokstav A-Z etter siste bindestrek er tvetydig når DNS-ens ufølsomhet for store/små bokstaver tas i betraktning, så den rapporteres i stedet for å gjettes.

“Gjelder Punycode for delen før @ i en e-postadresse?”

Bare domenedelen er et DNS-navn og kan være Punycode. Lokaldelen håndteres av e-postsystemet, ikke av DNS, så denne kodingen gjelder ikke for den.

“Kan to ulike Unicode-navn gi samme A-etikett?”

Nei. Kodingen er injektiv: ulike kodepunktsekvenser gir alltid ulike bootstring-strenger, så dekoding av xn--fiq228c gir nøyaktig 中文 og ingenting annet. Det som kan kollidere er utseende — ulike tegn som ser like ut — og det er en egenskap ved Unicode-repertoaret, ikke ved kodingen.

• RFC 3492 — Punycode, bootstring-kodingen som er implementert på denne siden. De kjente vektorene nevnt over er kontrollert mot eksempelstrengene i dokumentet.
• RFC 5890, RFC 5891, RFC 5892 og Unicode UTS #46 — IDNA2008 og dens tolkning i nettleseren, reglene som avgjør hvilke tegn som er lovlige, hvordan etiketter normaliseres, og hvordan skriftsystemer kan blandes.
• RFC 1034 og RFC 1035 — grensene på 63 byte for etiketter og 255 byte for navn, arvet fra DNS.
• RFC 3490 og RFC 3491 — den eldre IDNA2003-generasjonen, erstattet av IDNA2008. Hvis et navn oppfører seg annerledes i gammel programvare, er dette vanligvis grunnen.

Omfangsmerknad: dette verktøyet utfører bare RFC 3492-konvertering og ingenting annet. Det er ikke en IDN-validator og sjekker ikke registreringsregler, priser eller tilgjengelighet for et domene — og siden den aldri kontakter nettverket, kan den ikke fortelle om et navn finnes.

Prøv det over: lim inn 中文 og trykk Kod tekst → Punycode for å se A-etiketten, eller lim inn xn--fiq228c og trykk Dekod Punycode → tekst for å få tegnene tilbake.