Punycode- / IDN-omvandlare

Punycode är alltså inte ett språk, ett typsnitt eller en landskod — det är en översättning mellan två stavningar av samma namn. Unicode-stavningen kallas en U-etikett (中文.com, bücher.de), ASCII-stavningen kallas en A-etikett (xn--fiq228c.com, xn--bcher-kva.de), och hela idén att lägga internationella namn i DNS kallas IDN (internationaliserade domännamn) eller IDNA, mängden regler som byggs ovanpå.

Det finns för att DNS konstruerades i början av 1980-talet kring ett medvetet litet alfabet. Ett värdnamn som färdas genom DNS, in i en zonfil, en resolver-cache, en loggrad eller ett TLS-certifikat måste vara ren ASCII — formatet på ledningen har helt enkelt inget fält för något annat. Punycode är utvägen: det låter ett namn som inte är ASCII färdas som om det vore det, och låter mottagarsidan rekonstruera de ursprungliga tecknen exakt. Det är därför en kinesisk domän alls fungerar i en webbläsare, och varför xn-- är den enda sträng man ser överallt där Unicode-stavningen inte kan skickas.

Vad som skrivs (U-etiketten)	Vad DNS får (A-etiketten)	Vad det betyder
中文.com	xn--fiq228c.com	De kinesiska orden för “kinesiska språket”
中国	xn--fiqs8s	“Kina” på kinesiska
例え.jp	xn--r8jz45g.jp	Japanska exempel
bücher.de	xn--bcher-kva.de	Tyska bücher, “böcker”
münchen.de	xn--mnchen-3ya.de	München
😂.com	xn--e28h.com	En emoji-etikett — laglig i kodningen, inte i de flesta register

En längdjämförelse värd att komma ihåg: 中文 är 2 tecken och 6 byte i UTF-8, men xn--fiq228c är 11 ASCII-byte. Punycode gör oftast ett namn längre, aldrig kortare.

Ta bücher och se de tre stegen. Motorn kallas en bootstring, och hela algoritmen är bara ett fåtal dussin rader kod (den kan läsas i sidans skript).

1. Kopiera de vanliga tecknen först. Varje grundläggande ASCII-tecken kopieras i sin ursprungliga ordning och hålls läsbart: bücher → bcher. Eftersom något kopierades och något blev kvar läggs ett enda - till som gräns: bcher-.
2. Skriv resten som bas-36-tal. De återstående tecknen hanteras i stigande kodpunktsordning, och vart och ett skrivs som ett tal med variabel längd i bas 36 där a=0 … z=25 och 0=26 … 9=35. För bücher blir det kvarvarande tecknet ü siffrorna kva.
3. Sätt på prefixet. Den kodade delen fogad till den kopierade delen ger bcher-kva, och i domänsammanhang skrivs det xn--bcher-kva.

Det smarta med detta är vad de bas-36-talen innehåller: inte tecknet självt, utan ett delta — hur långt tecknet ligger från den föregående kodade kodpunkten, plus var det hör hemma i strängen. Kodaren går igenom kodpunkter i stigande ordning, och varje siffergrupp beskriver en position och ett avstånd. Efter varje tecken justeras ett gemensamt tal som kallas bias så att nästa tal behöver så få siffror som möjligt.

Två konsekvenser som syns direkt ovan:

• Liknande tecken är billiga. Eftersom endast avstånd lagras kostar en följd av samma tecken nästan ingenting: 30 kopior av 中 kodas till xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, bara 36 byte. En uppmätt, orelaterad men närliggande blandning av kinesiska tecken får plats med cirka 41 tecken i en laglig 63-byte-etikett, och ett enda upprepat tecken når 57.
• Spridda tecken är dyra. Ett tecken långt från det föregående behöver ett längre deltatal. Kinesisk text med många olika tecken kostar typiskt cirka 2–3 extra bokstäver per tecken, vilket är varför en CJK-etikett tar slut någonstans kring 20–40 tecken trots att etikettgränsen är 63 byte.

Avkodningen är samma recept baklänges: kopiera ASCII-prefixet, läs siffrorna, gör om deltana till kodpunkter och infoga varje nytt tecken i strängen på den position som deltat kodar. Endast gemena siffror finns i bootstringen, vilket är varför en versal bokstav inuti en kodad del avvisas i stället för att gissas — DNS är skiftlägesoberoende, så att tillåta båda skiftlägena skulle göra två olika stavningar tvetydiga.

• I adressfältet. Webbläsare kan visa xn--fiq228c.com i stället för 中文.com. Det är samma webbplats. Vissa webbläsare visar med avsikt Punycode-formen när ett namn blandar skriftsystem, just för att en likartad bokstav (kyrillisk а mot latinsk a) inte ska kunna gömma sig i URL:en.
• I DNS själv. Zonfiler, dig / nslookup / DNS-over-HTTPS-svar och resolverloggar innehåller bara någonsin xn---formen; vanlig Unicode avvisas eller förvanskas tyst.
• I TLS-certifikat. Det alternativa ämnesnamnet för en internationell domän lagras som en A-etikett (DNS:xn--fiq228c.com), så ett certifikat som inte ser ut som namnet som skrevs in är normalt, inte en felmatchning.
• I konfiguration och verktyg. Webbserverns server_name- / virtuella värdposter, cookie-domäner, hosting- och CDN-paneler, maildomäner, API-nycklar bundna till en domän och databasnycklar är alla säkrare i A-etikettform.
• I tester och datapipelines. Vissa bibliotek skickar Unicode direkt till resolvern och misslyckas; att konvertera till Punycode först är den vanliga lösningen. Eftersom avbildningen är kanonisk — en Unicode-etikett motsvarar exakt en A-etikett — är xn---formen också en stabil identifierare för loggar och sökning.

Punycode är en omvändbar stavning, inget mer. Det är inte kryptering och inte en säkerhetsfunktion: vem som helst kan avkoda den med verktyget ovan, så en xn---etikett säger “det här kodades” och ingenting om vem som äger den. Det är inte heller komprimering — det gör oftast texten längre, som exemplet 6-byte till 11-byte ovan visar. Och det är inte samma sak som de andra sätten Unicode färdas över internet; dessa löser andra lager av problemet.

Schema	Vad som omvandlas till vad	Var det används	中文 blir
Punycode (RFC 3492)	En Unicode-domänetikett till ASCII-bokstäver och siffror	Endast internationella domänetiketter	xn--fiq228c
UTF-8 (RFC 3629)	Kodpunkter till byte	Varje fil och webbförfrågan	E4 B8 AD E6 96 87 (6 byte)
Procentkodning (RFC 3986)	Byte till %XX-escapes	URL-sökvägar, frågesträngar, formulärinnehåll	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Byte till 64 ASCII-tecken	Binärdata i text, JSON, e-post, data-URL:er	5Lit5paH
HTML-entiteter	Kodpunkter till namngivna eller numeriska referenser	HTML- och XML-källkod	中文
Unicode-escapes	Kodpunkter till \uXXXX	Källkod och JSON-strängliteraler	\u4e2d\u6587

Den praktiska slutsatsen: Punycode gäller domänetiketterna i en URL, inte hela URL:en. Sökvägen och frågesträngen är ett annat problem och använder procentkodning (se URL-kodare).

• Storleksgränserna kommer från DNS, inte från Punycode. En etikett får vara högst 63 byte och ett komplett namn högst 255 byte (RFC 1034 / 1035). Eftersom en A-etikett är ren ASCII är antalet byte lika med antalet tecken, och varje icke-ASCII-tecken förbrukar en del av budgeten — ungefär 1 tecken av budgeten per 1–4 Punycode-bokstäver.
• Punycode konverterar allt; registren tillåter bara vissa saker. IDNA-reglerna ligger ovanpå och begränsar vilka kodpunkter som överhuvudtaget får registreras — versaler, mellanslag, skiljetecken som ! och flaggor är inte lagliga i en riktig domän. Denna sida utför RFC 3492-konverteringen, så den kodar gärna text som ett register skulle avvisa.
• Använd ett skriftsystem per etikett. IDNA avråder från att blanda skriftsystem inom en enskild etikett just på grund av likartade attacker. Ett namn kan kodas och ändå vara oanvändbart, eller användbart men blockerat av webbläsare.
• Dubbelkoda inte. xn-- följt av redan kodad text är ogiltigt, och en etikett som är ren ASCII ändras aldrig alls — det finns inget att koda, så inget prefix läggs till.
• En avslutande punkt är ok. 例え.jp. är ett fullständigt kvalificerat namn och den tomma etiketten i slutet behålls; tomma etiketter i mitten är inte giltiga värdnamn.

“Varför visas min kinesiska domän som xn--fiq228c.com i adressfältet?”

Eftersom webbläsaren valde att visa A-etiketten. Webbplatsen är identisk; använd den här sidans avkodningsriktning för att se Unicode-formen, eller koda Unicode-formen för att kontrollera att båda stavningarna stämmer överens.

“Behöver jag ändra mina DNS-poster, certifikat eller hosting?”

Nej. Behåll xn---A-etiketten överallt där en maskin läser namnet (DNS, certifikat, konfigurationer) och använd Unicode-formen endast där en människa läser det.

“Varför blir resultatet längre än det som skrevs in?”

Eftersom kodningen inte bär själva tecknen utan bas-36-avstånd, och 36-teckensalfabetet måste stava ut tal som kan vara stora. Tillväxt är förväntad, inte en bugg.

“Varför säger avkodningen ‘versal bokstav’?”

Eftersom bootstring-siffrorna enbart är definierade med gemener (a-z, 0-9). En versal A-Z efter sista bindestrecket är tvetydig när DNS:s skiftlägesoberoende beaktas, så den rapporteras i stället för att tyst gissas.

“Gäller Punycode delen före @ i en e-postadress?”

Endast domändelen är ett DNS-namn och kan vara Punycode. Den lokala delen hanteras av e-postsystemet, inte av DNS, så denna kodning gäller inte för den.

“Kan två olika Unicode-namn ge samma A-etikett?”

Nej. Kodningen är injektiv: olika kodpunktsföljder ger alltid olika bootstrings, så avkodning av xn--fiq228c ger exakt tillbaka 中文 och inget annat. Det som kan kollidera är utseendet — olika tecken som ser likadana ut — vilket är en egenskap hos Unicode-repertoaren, inte hos kodningen.

• RFC 3492 — Punycode, den bootstring-kodning som implementeras på denna sida. De kända vektorerna ovan kontrolleras mot exempelsträngarna i det dokumentet.
• RFC 5890, RFC 5891, RFC 5892 och Unicode UTS #46 — IDNA2008 och dess tolkning i webbläsare, reglerna som avgör vilka tecken som är lagliga, hur etiketter normaliseras och hur skriftsystem får blandas.
• RFC 1034 och RFC 1035 — gränserna på 63 byte per etikett och 255 byte per namn, ärvda från DNS.
• RFC 3490 och RFC 3491 — den äldre IDNA2003-generationen, ersatt av IDNA2008. Om ett namn beter sig annorlunda i gammal programvara är det oftast därför.

Omfattningsnotering: detta verktyg utför RFC 3492-konvertering och ingenting annat. Det är ingen IDN-validerare och kontrollerar inte registreringsregler, priser eller tillgänglighet för en domän — och eftersom det aldrig kontaktar nätverket kan det inte tala om om ett namn finns.

Prova ovan: klistra in 中文 och tryck på Koda text → Punycode för att se A-etiketten, eller klistra in xn--fiq228c och tryck på Avkoda Punycode → text för att få tillbaka tecknen.