Konvertor Punycode / IDN

Punycode teda nie je jazyk, písmo ani kód krajiny — je to prevod medzi dvoma zápismi toho istého názvu. Zápis Unicode sa nazýva U-štítok (中文.com, bücher.de), zápis ASCII sa nazýva A-štítok (xn--fiq228c.com, xn--bcher-kva.de) a celá myšlienka dávať medzinárodné názvy do DNS sa nazýva IDN (medzinárodné doménové názvy) alebo IDNA, teda súbor pravidiel postavených na nej.

Existuje preto, lebo DNS sa navrhol na začiatku 80. rokov okolo úmyselne malej abecedy. Názov hostiteľa, ktorý cestuje cez DNS, do zónového súboru, do vyrovnávacej pamäte resolvera, do záznamu v logu alebo do certifikátu TLS, musí byť čistý ASCII — formát na drôte jednoducho nemá pole pre niečo iné. Punycode je núdzový východ: umožňuje, aby názov, ktorý nie je ASCII, cestoval, akoby ním bol, a prijímajúca strana presne zrekonštruuje pôvodné znaky. Preto doména v čínštine vôbec funguje v prehliadači a prečo je xn-- jediný reťazec, ktorý sa objaví všade tam, kde sa podoba Unicode poslať nedá.

Čo sa zadáva (U-štítok)	Čo dostane DNS (A-štítok)	Čo to znamená
中文.com	xn--fiq228c.com	Čínske slová pre „čínsky jazyk“
中国	xn--fiqs8s	„Čína“ v čínštine
例え.jp	xn--r8jz45g.jp	Japonské príklady
bücher.de	xn--bcher-kva.de	Nemecky bücher, „knihy“
münchen.de	xn--mnchen-3ya.de	Mníchov
😂.com	xn--e28h.com	Štítok s emoji — v kódovaní legálny, v väčšine registrov nie

Stojí za zapamätanie porovnanie dĺžok: 中文 má 2 znaky a 6 bajtov v UTF-8, ale xn--fiq228c má 11 bajtov ASCII. Punycode názov zvyčajne predĺži, nikdy nie skráti.

Vezme sa bücher a sledujú sa tri kroky. Motor sa volá bootstring a celý algoritmus má len niekoľko desiatok riadkov kódu (možno ho prečítať v skripte tejto stránky).

1. Obyčajné znaky sa skopírujú dopredu. Každý základný znak ASCII sa skopíruje v pôvodnom poradí a zostane čitateľný: bücher → bcher. Keďže sa niečo skopírovalo a niečo zostalo, ako hranica sa pripája jedna -: bcher-.
2. Zvyšok sa zapíše ako čísla o základe 36. Zvyšné znaky sa spracúvajú vo vzostupnom poradí kódových bodov a každý sa zapíše ako premenlivodĺžkové číslo o základe 36, kde a=0 … z=25 a 0=26 … 9=35. Pre bücher sa zvyšný znak ü zmení na číslice kva.
3. Prilepenie prefixu. Zakódovaná časť pripojená ku skopírovanej časti dáva bcher-kva a v doménovom kontexte sa zapisuje ako xn--bcher-kva.

Trik, vďaka ktorému je to šikovné, spočíva v tom, čo tieto čísla o základe 36 obsahujú: nie samotný znak, ale delta — ako ďaleko je znak od predtým zakódovaného kódového bodu, plus kde patrí v rámci reťazca. Kódovač prechádza kódové body vo vzostupnom poradí a každá skupina číslic opisuje pozíciu a vzdialenosť. Po každom znaku sa upraví spoločné číslo nazývané bias, aby nasledujúce číslo potrebovalo čo najmenej číslic.

Dva dôsledky, ktoré sa dajú overiť vyššie:

• Podobné znaky sú lacné. Keďže sa ukladajú len vzdialenosti, séria rovnakého znaku stojí takmer nič: 30 kópií 中 sa zakóduje na xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, len 36 bajtov. Namerané, nesúvisiace, ale blízke zmiesi čínskych znakov vtesnajú približne 41 znakov do jedného legálneho štítku s 63 bajtmi a jeden opakovaný znak dosiahne 57.
• Rozptýlené znaky sú drahé. Znak ďaleko od predchádzajúceho potrebuje dlhšie číslo delta. Čínsky text s mnohými rôznymi znakmi zvyčajne stojí približne 2–3 navyše písmená na znak, a preto CJK štítok dôjde miesta niekde okolo 20–40 znakov, hoci limit štítku je 63 bajtov.

Dekódovanie je ten istý postup spätne: skopíruje sa ASCII prefix, prečítajú sa číslice, delty sa premenia späť na kódové body a každý nový znak sa vloží do reťazca na pozíciu, ktorú delta kóduje. V bootstringu existujú len malé číslice, a preto sa veľké písmeno v zakódovanej časti odmietne namiesto hádania — DNS nerozlišuje veľkosť písmen, takže povoliť obe by spravilo dve rôzne podoby nejednoznačnými.

• V adresnom riadku. Prehliadače môžu zobraziť xn--fiq228c.com namiesto 中文.com. Je to ten istý web. Niektoré prehliadače tvar Punycode zobrazujú zámerne, keď názov mieša písma, práve aby sa v URL nemohol skryť podobný znak (cyrilské а verzus latinské a).
• V samotnom DNS. Zónové súbory, odpovede dig / nslookup / DNS-over-HTTPS a záznamy resolvera obsahujú len tvar xn--; čistý Unicode sa odmietne alebo potichu pokazí.
• V certifikátoch TLS. Alternatívny názov subjektu pre medzinárodnú doménu sa ukladá ako A-štítok (DNS:xn--fiq228c.com), takže certifikát, ktorý nevyzerá ako zadaný názov, je normálny, nie nesúlad.
• V konfigurácii a nástrojoch. Záznamy server_name webového servera / virtuálneho hostiteľa, domény cookies, panely hostingu a CDN, e-mailové domény, kľúče API viazané na doménu a databázové kľúče sú v tvare A-štítkov bezpečnejšie.
• Pri testovaní a dátových reťazcoch. Niektoré knižnice posielajú Unicode priamo do resolvera a zlyhávajú; štandardným riešením je najprv previesť na Punycode. Keďže mapovanie je kanonické — jeden Unicode štítok zodpovedá presne jednému A-štítku — je tvar xn-- aj stabilným identifikátorom pre záznamy a vyhľadávanie.

Punycode je obrátiteľný zápis, nič viac. Nie je to šifrovanie ani bezpečnostná funkcia: každý ho dekóduje vyššie uvedeným nástrojom, takže štítok xn-- hovorí „toto bolo zakódované“ a nič o tom, kto ho vlastní. Nie je to ani kompresia — zvyčajne text predĺži, ako ukazuje príklad 6 až 11 bajtov vyššie. A nie je to to isté ako iné spôsoby, akými Unicode putuje internetom; tie riešia iné vrstvy problému.

Schéma	Mení čo na čo	Kde sa používa	中文 sa zmení na
Punycode (RFC 3492)	Štítok domény Unicode na písmená a číslice ASCII	Iba štítky medzinárodných domén	xn--fiq228c
UTF-8 (RFC 3629)	Kódové body na bajty	Každý súbor a webová požiadavka	E4 B8 AD E6 96 87 (6 bajtov)
Percent-kódovanie (RFC 3986)	Bajty na zápisy %XX	Cesty URL, reťazce dotazu, telá formulárov	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Bajty na 64 znakov ASCII	Binárne údaje v texte, JSON, e-mailu, dátových URL	5Lit5paH
Entity HTML	Kódové body na pomenované alebo číselné odkazy	Zdrojový kód HTML a XML	中文
Unicode escape sekvencie	Kódové body na \uXXXX	Zdrojový kód a reťazcové literály JSON	\u4e2d\u6587

Praktické ponaučenie: Punycode sa týka doménových štítkov URL, nie celej URL. Cesta a reťazec dotazu sú iný problém a používajú percent-kódovanie (súvisiace: Kódovanie URL).

• Veľkostné limity pochádzajú z DNS, nie z Punycode. Jeden štítok môže mať najviac 63 bajtov a celý názov najviac 255 bajtov (RFC 1034 / 1035). Keďže A-štítok je čisto ASCII, počet bajtov sa rovná počtu znakov a každý znak mimo ASCII spotrebuje časť tohto rozpočtu — zhruba 1 znak rozpočtu na 1–4 písmená Punycode.
• Punycode prevedie čokoľvek; registre povoľujú len niečo. Nad tým platia pravidlá IDNA, ktoré obmedzujú, ktoré kódové body sa vôbec smú registrovať — veľké písmená, medzery, interpunkcia ako ! a príznaky nie sú v skutočnej doméne legálne. Táto stránka vykonáva konverziu RFC 3492, takže ochotne zakóduje text, ktorý by register odmietol.
• Text zostáva v jednom písme. IDNA odrádza od miešania písem v jednom štítku práve kvôli útokom podobnými znakmi. Názov sa dá zakódovať a stále nemusí byť použiteľný, alebo je použiteľný, no prehliadače ho zaradia na zoznam blokovaných.
• Kódovanie sa nerobí dvakrát. xn-- nasledované už zakódovaným textom je neplatné a štítok čisto ASCII sa nikdy nemení — nie je čo kódovať, preto sa nepridáva žiadny prefix.
• Koncová bodka je v poriadku. 例え.jp. je úplný názov a prázdny štítok na konci sa zachová; prázdne štítky v strede nie sú platné názvy hostiteľov.

„Prečo sa čínska doména zobrazuje ako xn--fiq228c.com v adresnom riadku?“

Pretože prehliadač zobrazil A-štítok. Web je ten istý; na zobrazenie tvaru Unicode slúži smer dekódovania tejto stránky, alebo sa tvar Unicode zakóduje a overí sa, že sa obe podoby zhodujú.

„Musí sa meniť záznamy DNS, certifikát alebo hosting?“

Nie. Tvar xn-- A-štítku sa používa všade, kde názov číta stroj (DNS, certifikáty, konfigurácie), a tvar Unicode len tam, kde ho číta človek.

„Prečo je výsledok dlhší, než čo sa zadalo?“

Pretože kódovanie nenesie samotné znaky, nesie vzdialenosti v číselnej sústave o základe 36, a abeceda s 36 znakmi musí zapísať čísla, ktoré môžu byť veľké. Rast je očakávaný, nie chyba.

„Prečo dekódovanie hlási veľké písmeno?“

Pretože číslice bootstringu sú definované len malými písmenami (a-z, 0-9). Veľké A-Z za poslednou pomlčkou je nejednoznačné, keď sa berie do úvahy, že DNS nerozlišuje veľkosť písmen, preto sa nahlási namiesto toho, aby sa potichu hádalo.

„Vzťahuje sa Punycode na časť pred znakom @ v e-mailovej adrese?“

Doménovú časť je len názov DNS a môže byť v Punycode. Lokálnu časť spracúva poštový systém, nie DNS, takže sa na ňu toto kódovanie nevzťahuje.

„Môžu dva rôzne názvy Unicode vytvoriť rovnaký A-štítok?“

Nie. Kódovanie je injektívne: rôzne postupnosti kódových bodov vždy dajú rôzne bootstringy, takže dekódovanie xn--fiq228c vráti presne 中文 a nič iné. Kolidovať však môže vzhľad — rôzne znaky, ktoré si vyzerajú podobne — a to je vlastnosť repertoáru Unicode, nie kódovania.

• RFC 3492 — Punycode, kódovanie bootstring implementované na tejto stránke. Uvedené známe vektory sú overené voči vzorovým reťazcom v tomto dokumente.
• RFC 5890, RFC 5891, RFC 5892 a Unicode UTS #46 — IDNA2008 a jeho výklad v prehliadačoch, pravidlá, ktoré určujú, ktoré znaky sú platné, ako sa štítky normalizujú a ako sa môžu miešať písma.
• RFC 1034 a RFC 1035 — limity 63 bajtov pre štítok a 255 bajtov pre názov zdedené z DNS.
• RFC 3490 a RFC 3491 — staršia generácia IDNA2003, nahradená IDNA2008. Ak sa názov v starom softvéri správa inak, zvyčajne je to práve tým.

Poznámka k rozsahu: tento nástroj vykonáva len konverziu RFC 3492 a nič iné. Nie je to validátor IDN a nekontroluje pravidlá registrácie, ceny ani dostupnosť domény — a keďže nikdy nekontaktuje sieť, nemôže povedať, či názov existuje.

Vyskúšať to možno vyššie: vloží sa 中文 a stlačí sa Kódovať text → Punycode, čím sa zobrazí A-štítok, alebo sa vloží xn--fiq228c a stlačí sa Dekódovať Punycode → text, čím sa znaky získajú späť.