Convertor Punycode / IDN

Deci Punycode nu este o limbă, un font sau un cod de țară — este o traducere între două ortografii ale aceluiași nume. Ortografia Unicode se numește etichetă U (中文.com, bücher.de), ortografia ASCII se numește etichetă A (xn--fiq228c.com, xn--bcher-kva.de), iar ideea întreagă de a pune nume internaționale în DNS se numește IDN (nume de domenii internaționale) sau IDNA, setul de reguli construit peste ea.

Există pentru că DNS a fost proiectat la începutul anilor 1980 în jurul unui alfabet intenționat minuscul. Un nume de gazdă care circulă prin DNS, într-un fișier de zonă, într-un cache de resolver, într-o linie de jurnal sau într-un certificat TLS, trebuie să fie ASCII simplu — formatul de transmisie pur și simplu nu are câmp pentru altceva. Punycode este ieșirea de urgență: lasă un nume care nu este ASCII să circule ca și cum ar fi, iar capătul receptor poate reconstrui exact caracterele originale. De aceea un domeniu chinezesc funcționează deloc într-un browser și de ce xn-- este singurul șir care apare în orice loc unde ortografia Unicode nu poate fi trimisă.

Ce se tastează (eticheta U)	Ce primește DNS (eticheta A)	Ce înseamnă
中文.com	xn--fiq228c.com	Cuvintele chinezești pentru „limba chineză”
中国	xn--fiqs8s	„China” în chineză
例え.jp	xn--r8jz45g.jp	Exemple japoneze
bücher.de	xn--bcher-kva.de	Germana bücher, „cărți”
münchen.de	xn--mnchen-3ya.de	München
😂.com	xn--e28h.com	O etichetă emoji — legală la codificare, nu în majoritatea registrelor

O comparație a lungimii de reținut: 中文 are 2 caractere și 6 octeți în UTF-8, dar xn--fiq228c are 11 octeți ASCII. Punycode face de obicei un nume mai lung, niciodată mai scurt.

Se ia bücher și se urmăresc cele trei mișcări. Motorul se numește bootstring, iar întregul algoritm are doar câteva zeci de rânduri de cod (se poate citi în scriptul acestei pagini).

1. Caracterele simple se copiază la început. Fiecare caracter ASCII de bază se copiază în ordinea originală și rămâne lizibil: bücher → bcher. Pentru că ceva a fost copiat și a rămas ceva, se adaugă o singură - ca limită: bcher-.
2. Restul se scrie ca numere în baza 36. Caracterele rămase se tratează în ordinea crescătoare a punctelor de cod, iar fiecare se scrie ca număr de lungime variabilă în baza 36, unde a=0 … z=25 și 0=26 … 9=35. Pentru bücher, caracterul rămas ü devine cifrele kva.
3. Se adaugă prefixul. Partea codificată atașată părții copiate dă bcher-kva, iar în context de domeniu se scrie xn--bcher-kva.

Trucul care face asta ingenioasă este ce conțin acele numere în baza 36: nu caracterul în sine, ci o deltă — cât de departe este caracterul de punctul de cod codificat anterior, plus unde se află în șir. Codificatorul parcurge punctele de cod în ordine crescătoare, iar fiecare serie de cifre descrie o poziție și o distanță. După fiecare caracter, un număr comun numit bias este ajustat, astfel încât numărul următor să aibă cât mai puține cifre.

Două consecințe care se văd direct mai sus:

• Caracterele asemănătoare sunt ieftine. Pentru că se stochează doar distanțele, o succesiune din același caracter costă aproape nimic: 30 de copii ale lui 中 se codifică în xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, doar 36 de octeți. Un amestec măsurat de caractere chinezești apropiate, fără legătură între ele, încadrează aproximativ 41 de caractere într-o singură etichetă legală de 63 de octeți, iar un singur caracter repetat ajunge la 57.
• Caracterele împrăștiate sunt scumpe. Un caracter departe de cel dinainte are nevoie de un număr delta mai lung. Textul chinez cu multe caractere diferite costă de obicei aproximativ 2–3 litere în plus pe caracter, de aceea o etichetă CJK rămâne fără spațiu pe undeva între 20 și 40 de caractere, deși limita etichetei este de 63 de octeți.

Decodarea este aceeași rețetă în sens invers: se copiază prefixul ASCII, se citesc cifrele, se transformă deltele înapoi în puncte de cod și se inserează fiecare caracter nou în șir, în poziția codificată de delta. În bootstring există doar cifre cu litere mici, de aceea o literă majusculă în interiorul unei părți codificate este respinsă în loc să fie ghicită — DNS nu distinge majusculele, deci acceptarea ambelor ar face două ortografii diferite ambigue.

• În bara de adrese. Browserele pot afișa xn--fiq228c.com în loc de 中文.com. Este același site. Unele browsere afișează deliberat forma Punycode când un nume amestecă scripturi, tocmai ca un caracter asemănător (chirilicul а față de latinul a) să nu se ascundă în URL.
• În DNS propriu-zis. Fișierele de zonă, răspunsurile dig / nslookup / DNS-over-HTTPS și jurnalele resolver-ului conțin doar forma xn--; Unicode-ul simplu este respins sau deformat în tăcere.
• În certificatele TLS. Numele alternativ al subiectului pentru un domeniu internațional este stocat ca etichetă A (DNS:xn--fiq228c.com), deci un certificat care nu seamănă cu numele tastat este normal, nu o nepotrivire.
• În configurații și instrumente. Intrările server_name / gazdă virtuală ale serverului web, domeniile cookie-urilor, panourile de găzduire și CDN, domeniile de e-mail, cheile API legate de un domeniu și cheile din baze de date sunt toate mai sigure în forma A-label.
• În testare și fluxuri de date. Unele biblioteci trimit Unicode direct către resolver și eșuează; convertirea întâi în Punycode este remediul standard. Pentru că maparea este canonică — o etichetă Unicode corespunde exact unei singure etichete A — forma xn-- este și un identificator stabil pentru jurnale și căutare.

Punycode este o scriere reversibilă, nimic mai mult. Nu este criptare și nu este o funcție de securitate: oricine o poate decodifica cu instrumentul de mai sus, deci o etichetă xn-- spune „aceasta a fost codificată” și nimic despre cine o deține. Nu este nici compresie — de obicei face textul mai lung, cum arată exemplul de 6 octeți față de 11 octeți de mai sus. Și nu este același lucru cu celelalte moduri în care Unicode circulă pe internet; acestea rezolvă alte straturi ale problemei.

Schemă	Transformă ce în ce	Unde se folosește	中文 devine
Punycode (RFC 3492)	O etichetă de domeniu Unicode în litere și cifre ASCII	Doar etichete de domeniu internaționale	xn--fiq228c
UTF-8 (RFC 3629)	Puncte de cod în octeți	Fiecare fișier și cerere web	E4 B8 AD E6 96 87 (6 octeți)
Codificare procentuală (RFC 3986)	Octeți în escapări %XX	Căi URL, șiruri de interogare, corpuri de formular	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Octeți în 64 de caractere ASCII	Date binare în text, JSON, e-mail, URI de date	5Lit5paH
Entități HTML	Puncte de cod în referințe cu nume sau numerice	Sursa HTML și XML	中文
Escapări Unicode	Puncte de cod în \uXXXX	Literali de cod sursă și șiruri JSON	\u4e2d\u6587

Concluzia practică: Punycode se aplică etichetelor de domeniu ale unui URL, nu întregului URL. Calea și șirul de interogare sunt o problemă diferită și folosesc codificarea procentuală (vezi Codificatoare URL).

• Limitele de dimensiune vin din DNS, nu din Punycode. O etichetă poate avea cel mult 63 de octeți, iar un nume complet cel mult 255 de octeți (RFC 1034 / 1035). Deoarece o etichetă A este pur ASCII, numărul de octeți este egal cu numărul de caractere, iar fiecare caracter non-ASCII consumă o parte din acest buget — aproximativ 1 caracter din buget la 1–4 litere Punycode.
• Punycode convertește orice; registrele permit doar unele lucruri. Regulile IDNA se așază deasupra și restricționează ce puncte de cod pot fi înregistrate — literele majuscule, spațiile, semnele de punctuație precum ! și indicatorii nu sunt legale într-un domeniu real. Această pagină efectuează conversia RFC 3492, deci va codifica fericită un text pe care un registru l-ar respinge.
• Un singur script pe etichetă. IDNA descurajează amestecul de scripturi într-o singură etichetă tocmai din cauza atacurilor cu caractere asemănătoare. Un nume poate fi codificat și totuși să fie inutilizabil, sau utilizabil dar blocat de browsere.
• Nu se codifică de două ori. xn-- urmat de text deja codificat este invalid, iar o etichetă pur ASCII nu se modifică niciodată — nu există nimic de codificat, deci nu se adaugă niciun prefix.
• Punctul final este în regulă. 例え.jp. este un nume complet calificat, iar eticheta goală de la sfârșit se păstrează; etichetele goale din mijloc nu sunt nume de gazdă valide.

„De ce apare domeniul chinezesc ca xn--fiq228c.com în bara de adrese?”

Pentru că browserul a ales să afișeze eticheta A. Site-ul este identic; se folosește direcția Decodare a acestei pagini pentru a vedea forma Unicode sau se codifică forma Unicode pentru a verifica dacă ambele ortografii coincid.

„Trebuie să schimb înregistrările DNS, certificatul sau găzduirea?”

Nu. Se păstrează eticheta A xn-- peste tot unde o mașină citește numele (DNS, certificate, configurații), iar forma Unicode se folosește doar acolo unde o citește un om.

„De ce este rezultatul mai lung decât ce am scris?”

Pentru că codificarea nu transportă caracterele în sine, ci distanțe în baza 36, iar alfabetul de 36 de caractere trebuie să scrie numere care pot fi mari. Creșterea este de așteptat, nu o eroare.

„De ce spune decodarea «literă cu majusculă»?”

Pentru că cifrele bootstring sunt definite doar cu litere mici (a-z, 0-9). O literă A-Z cu majusculă după ultima liniuță este ambiguă, având în vedere că DNS nu distinge majusculele, deci se raportează în loc să fie ghicită în tăcere.

„Se aplică Punycode părții dinaintea @ dintr-o adresă de e-mail?”

Doar partea de domeniu este un nume DNS și poate fi Punycode. Partea locală este tratată de sistemul de e-mail, nu de DNS, deci această codificare nu i se aplică.

„Pot două nume Unicode diferite să producă aceeași etichetă A?”

Nu. Codificarea este injectivă: secvențe diferite de puncte de cod produc întotdeauna bootstring-uri diferite, deci decodarea lui xn--fiq228c dă înapoi exact 中文 și nimic altceva. Ce poate coincide este aspectul — caractere diferite care arată la fel — ceea ce ține de repertoriul Unicode, nu de codificare.

• RFC 3492 — Punycode, codificarea bootstring implementată în această pagină. Vectorii cunoscuți de mai sus se verifică cu șirurile exemplu din acel document.
• RFC 5890, RFC 5891, RFC 5892 și Unicode UTS #46 — IDNA2008 și interpretarea sa din browser, regulile care decid ce caractere sunt legale, cum se normalizează etichetele și cum pot fi amestecate scripturile.
• RFC 1034 și RFC 1035 — limitele de 63 de octeți pentru etichetă și 255 de octeți pentru nume, moștenite din DNS.
• RFC 3490 și RFC 3491 — generația mai veche IDNA2003, înlocuită de IDNA2008. Dacă un nume se comportă diferit în software vechi, de obicei acesta este motivul.

Notă de domeniu: acest instrument efectuează conversia RFC 3492 și nimic altceva. Nu este un validator IDN și nu verifică regulile de înregistrare, prețurile sau disponibilitatea unui domeniu — iar pentru că nu contactează niciodată rețeaua, nu poate spune dacă un nume există.

Se încearcă mai sus: se lipește 中文 și se apasă Codifică text → Punycode pentru a vedea eticheta A, sau se lipește xn--fiq228c și se apasă Decodează Punycode → text pentru a recupera caracterele.