Punycode / IDN átalakító

A Punycode tehát nem nyelv, betűtípus vagy országkód — fordítás ugyanazon név két írásmódja között. A Unicode-írásmódot U-címkének hívják (中文.com, bücher.de), az ASCII-írásmódot A-címkének (xn--fiq228c.com, xn--bcher-kva.de), a nemzetközi nevek DNS-be illesztésének egész ötletét pedig IDN (nemzetközi tartománynevek) vagy IDNA, az erre épülő szabályrendszer.

Azért létezik, mert a DNS a 1980-as évek elején egy szándékosan apró ábécére épült. A DNS-en át utazó gépnevet — zónafájlba, feloldó gyorsítótárba, naplósorba vagy TLS-tanúsítványba — tisztán ASCII-nak kell lennie: a vezetékes formátumnak egyszerűen nincs más mezője. A Punycode kiskapu: lehetővé teszi, hogy egy nem ASCII név ASCII-ként utazzon, a fogadó oldal pedig pontosan visszaállítja az eredeti karaktereket. Ezért működik egyáltalán a kínai tartomány böngészőben, és ezért az xn-- az a karakterlánc, amelyet minden olyan helyen látni, ahol a Unicode-alak nem küldhető el.

Amit beír (U-címke)	Amit a DNS kap (A-címke)	Mit jelent
中文.com	xn--fiq228c.com	A “kínai nyelv” kínai szavai
中国	xn--fiqs8s	“China” kínaiul
例え.jp	xn--r8jz45g.jp	Japán példák
bücher.de	xn--bcher-kva.de	Német bücher, “books”
münchen.de	xn--mnchen-3ya.de	München
😂.com	xn--e28h.com	Emoji-címke — a kódolásban megengedett, a legtöbb regiszterben nem

Érdemes megjegyezni egy hosszúság-összehasonlítást: 中文 2 karakter és 6 bájt UTF-8-ban, de az xn--fiq228c 11 ASCII-bájt. A Punycode általában hosszabbá teszi a nevet, sosem rövidebbé.

A bücher szót vegyük, és figyeljük meg a három lépést. A motort bootstringnek hívják, és az egész algoritmus csak néhány tucat kódsor (az oldal szkriptjében olvasható).

1. A sima karakterek az elejére kerülnek. Minden alap ASCII-karakter eredeti sorrendben másolódik, és olvasható marad: bücher → bcher. Mivel valami lemásolódott és valami maradt, egyetlen - kerül a határhoz: bcher-.
2. A többi karakter base-36 számként íródik. A fennmaradó karakterek kódpontsorrendben kerülnek feldolgozásra, és mindegyik változó hosszúságú base-36 számként íródik, ahol a=0 … z=25 és 0=26 … 9=35. A bücher esetében a fennmaradó ü karakter a kva számjegyekké válik.
3. Az előtag hozzáfűzése. A kódolt rész a másolt részhez fűzve bcher-kva-t ad, tartománykontextusban xn--bcher-kva alakban írva.

A trükk, amely ezt okossá teszi, abban rejlik, mit tartalmaznak ezek a base-36 számok: nem a karakter, hanem egy különbség — mennyire van távol a karakter a korábban kódolt kódponttól, plusz hogy hova kerül a szövegen belül. A kódoló növekvő sorrendben járja be a kódpontokat, és minden számjegy-sorozat egy pozíciót és egy távolságot ír le. Minden karakter után egy közös szám, az eltolás (bias) módosul, hogy a következő számnak a lehető legkevesebb számjegye legyen.

Két következmény fent közvetlenül megfigyelhető:

• A hasonló karakterek olcsók. Mivel csak a távolságok tárolódnak, az azonos karakterek sorozata szinte semmibe sem kerül: 30 darab 中 xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-ra kódolódik, mindössze 36 bájt. Egy mért, egymástól független, de közeli kínai karakterkeverék egyetlen legális, 63 bájtos címkébe nagyjából 41 karaktert zsúfol, egyetlen ismételt karakter pedig 57-et ér el.
• A szétszórt karakterek drágák. Az előzőtől távoli karakter hosszabb különbségszámot igényel. Sok különböző karaktert tartalmazó kínai szöveg karakterenként nagyjából 2–3 extra betűt igényel, ezért egy CJK-címke valahol 20–40 karakternél elfogy, pedig a címkekorlát 63 bájt.

A visszafejtés ugyanaz a recept visszafelé: az ASCII-előtag másolódik, a számjegyek kiolvasódnak, a különbségek visszaalakulnak kódpontokká, és minden új karakter oda kerül a szövegbe, ahová a különbség mutatja. A bootstringben csak kisbetűs számjegyek vannak, ezért a kódolt részen belüli nagybetű elutasításra kerül, nem találgatásra — a DNS kis- és nagybetű-érzéketlen, így mindkét eset engedése kétértelművé tenné a két különböző írásmódot.

• A címsorban. A böngészők megjeleníthetik a xn--fiq228c.com-ot a 中文.com helyett. Ugyanaz a webhely. Egyes böngészők szándékosan a Punycode-alakot mutatják, ha egy név több írásrendszert vegyít, éppen azért, hogy egy hasonló karakter (cirill а a latin a helyett) ne rejtőzhessen az URL-ben.
• A DNS-ben. A zónafájlok, a dig / nslookup / DNS-over-HTTPS válaszok és a feloldónaplók kizárólag az xn-- formát tartalmazzák; a sima Unicode elutasításra kerül, vagy csendben elrontódik.
• TLS-tanúsítványokban. A nemzetközi tartomány alternatív nevét A-címkeként tárolja (DNS:xn--fiq228c.com), ezért az, hogy a tanúsítvány nem úgy néz ki, mint a beírt név, normális, nem eltérés.
• Konfigurációban és eszközökben. Webszerver server_name / virtuális host bejegyzések, sütitartományok, tárhely- és CDN-panelek, levéltartományok, tartományhoz kötött API-kulcsok és adatbázis-kulcsok mind biztonságosabbak A-címke formában.
• Tesztelésben és adatfolyamokban. Egyes könyvtárak a Unicode-ot közvetlenül a feloldónak adják át, és hibáznak; a Punycode-ra való előzetes átalakítás a szokásos megoldás. Mivel a leképezés kanonikus — egy Unicode-címke pontosan egy A-címkének felel meg — az xn-- forma naplókban és keresésben is stabil azonosító.

A Punycode csak átírás, semmi több. Nem titkosítás és nem biztonsági funkció: bárki visszafejtheti a fenti eszközzel, ezért egy xn-- címke azt mondja, hogy “ez kódolva lett”, de arról semmit, hogy kié. Nem is tömörítés — általában hosszabbá teszi a szöveget, ahogy a fenti 6 bájtos–11 bájtos példa mutatja. És nem azonos az internetes Unicode-továbbítás más módjaival; azok a probléma más rétegeit oldják meg.

Séma	Mit mivé alakít	Hol használják	中文 lesz:
Punycode (RFC 3492)	Unicode tartománycímke ASCII betűkre és számjegyekre	Csak nemzetközi tartománycímkék	xn--fiq228c
UTF-8 (RFC 3629)	Kódpontok bájtokká	Minden fájl- és webes kérés	E4 B8 AD E6 96 87 (6 bájt)
Százalékos kódolás (RFC 3986)	Bájtok %XX escape-ekké	URL-útvonalak, lekérdezési karakterláncok, űrlaptörzsek	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Bájtok 64 ASCII karakterré	Bináris adat szövegben, JSON-ban, e-mailben, adat-URL-ekben	5Lit5paH
HTML-entitások	Kódpontok nevesített vagy numerikus hivatkozásokká	HTML- és XML-forrás	中文
Unicode-escape-ek	Kódpontok \uXXXX-ré	Forráskód és JSON-sztringliterálok	\u4e2d\u6587

A gyakorlati tanulság: a Punycode az URL tartománycímkéire vonatkozik, nem az egész URL-re. Az útvonal és a lekérdezési karakterlánc más probléma, és százalékos kódolást használ (erre a célra az URL-kódolók szolgálnak).

• A méretkorlátokat a DNS adja, nem a Punycode. Egy címke legfeljebb 63 bájt, a teljes név legfeljebb 255 bájt (RFC 1034 / 1035). Mivel az A-címke tisztán ASCII, a bájtszám megegyezik a karakterszámmal, és minden nem ASCII karakter elhasznál a keretből — nagyjából 1 karakter keret 1–4 Punycode-betűre jut.
• A Punycode mindent átalakít; a regiszterek csak bizonyos dolgokat engednek. Az IDNA-szabályok ráépülnek, és korlátozzák, mely kódpontok regisztrálhatók egyáltalán — a nagybetűk, szóközök, írásjelek, például !, és a zászlók nem szerepelhetnek valódi tartománynévben. Ez az oldal az RFC 3492 átalakítást végzi, ezért szívesen kódol olyan szöveget is, amelyet egy regiszter elutasítana.
• Egy írásrendszeren belül tartás ajánlott. Az IDNA tiltja az írásrendszerek keverését egyetlen címkén belül, pont a hasonló karakteres támadások miatt. Egy név kódolható, és mégis használhatatlan lehet, vagy használható, de a böngészők feketelistára tehetik.
• Kettős kódolás nem történik. xn-- már kódolt szöveg előtt érvénytelen, a tisztán ASCII-címke pedig soha nem változik — nincs mit kódolni, ezért nem adódik előtag.
• A záró pont rendben van. 例え.jp. teljesen minősített név, a végén lévő üres címke megmarad; a közepén lévő üres címkék nem érvényes gépnevek.

“Miért jelenik meg egy kínai tartomány a címsorban xn--fiq228c.com alakban?”

Mert a böngésző az A-címkét jelenítette meg. Az oldal ugyanaz; a visszafejtési irány mutatja a Unicode-alakot, vagy a Unicode-alak kódolásával ellenőrizhető, hogy a két írásmód egyezik-e.

“Szükséges a DNS-rekordok, a tanúsítvány vagy a tárhely módosítása?”

Nem. Az xn-- A-címke minden olyan helyen megtartandó, ahol gép olvassa a nevet (DNS, tanúsítványok, konfigurációk); a Unicode-alak csak ott használandó, ahol ember olvassa.

“Miért hosszabb az eredmény, mint a beírt szöveg?”

Mert a kódolás nem a karaktereket hordozza, hanem base-36 távolságokat, és a 36 karakteres ábécének nagy számokat is ki kell fejeznie. A növekedés elvárt, nem hiba.

“Miért mondja a visszafejtés, hogy ‘nagybetű’?”

Mert a bootstring számjegyei csak kisbetűsek (a-z, 0-9). Az utolsó kötőjel utáni nagybetűs A-Z kétértelmű, ha figyelembe vesszük a DNS kis- és nagybetű-érzéketlenségét, ezért nem találgatjuk ki csendben, hanem jelezzük.

“Vonatkozik-e a Punycode az e-mail-cím @ előtti részére?”

Csak a tartománynév-rész DNS-név, és lehet Punycode. A helyi rész a levelezőrendszer kezeli, nem a DNS, így ez a kódolás rá nem vonatkozik.

“Adhat két különböző Unicode-név ugyanolyan A-címkét?”

Nem. A kódolás injektív: különböző kódpontsorozatok mindig különböző bootstringeket adnak, ezért az xn--fiq228c visszafejtése pontosan a 中文-ot adja, mást nem. Ami ütközhet, az a megjelenés — egymáshoz hasonló különböző karakterek —, ami a Unicode-repertoár tulajdonsága, nem a kódolásé.

• RFC 3492 — a Punycode, a bootstring-kódolás, amelyet ez az oldal valósít meg. A fent idézett ismert vektorok a dokumentum mintasztringjeivel egyeznek.
• RFC 5890, RFC 5891, RFC 5892 és a Unicode UTS #46 — az IDNA2008 és böngészőoldali értelmezése: azok a szabályok, amelyek eldöntik, mely karakterek legálisak, hogyan normalizálódnak a címkék, és hogyan keverhetők az írásrendszerek.
• RFC 1034 és RFC 1035 — a DNS-ből örökölt 63 bájtos címke- és 255 bájtos névkorlát.
• RFC 3490 és RFC 3491 — a régebbi IDNA2003 generáció, amelyet az IDNA2008 váltott fel. Ha egy név régi szoftverben másképp viselkedik, ez általában az oka.

Hatókör-megjegyzés: ez az eszköz kizárólag RFC 3492 átalakítást végez. Nem IDN-érvényesítő, és nem ellenőrzi a regisztrációs szabályokat, a tartománydíjakat vagy a tartomány elérhetőségét — mivel soha nem fordul a hálózathoz, nem tudja megmondani, létezik-e egy név.

Fent kipróbálható: a 中文 szöveg beillesztése után a Szöveg kódolása → Punycode gombbal megkapható az A-címke, a xn--fiq228c beillesztése után pedig a Punycode dekódolása → szöveg gombbal visszakaphatók a karakterek.