Convertitore Punycode / IDN

Quindi Punycode non è una lingua, un font o un codice paese — è una traduzione tra due grafie dello stesso nome. La grafia Unicode si chiama etichetta U (中文.com, bücher.de), la grafia ASCII si chiama etichetta A (xn--fiq228c.com, xn--bcher-kva.de), e l'idea complessiva di inserire nomi internazionali nel DNS si chiama IDN (nomi di dominio internazionalizzati) o IDNA, l'insieme di regole costruito sopra di essa.

Esiste perché il DNS è stato progettato all'inizio degli anni Ottanta attorno a un alfabeto volutamente minuscolo. Un nome host che attraversa il DNS, entra in un file di zona, in una cache del resolver, in una riga di log o in un certificato TLS, deve essere ASCII semplice — il formato di trasmissione semplicemente non ha un campo per altro. Punycode è la via di fuga: permette a un nome non ASCII di viaggiare come se lo fosse, e permette al ricevente di ricostruire esattamente i caratteri originali. Per questo un dominio cinese funziona in un browser, e perché xn-- è l'unica stringa che si vede in ogni punto in cui la grafia Unicode non può essere inviata.

Ciò che digita (etichetta U)	Ciò che riceve il DNS (etichetta A)	Significato
中文.com	xn--fiq228c.com	Le parole cinesi per «lingua cinese»
中国	xn--fiqs8s	«Cina» in cinese
例え.jp	xn--r8jz45g.jp	esempi giapponesi
bücher.de	xn--bcher-kva.de	bücher tedesco, «libri»
münchen.de	xn--mnchen-3ya.de	Monaco di Baviera
😂.com	xn--e28h.com	Un'etichetta emoji — legale nella codifica, non nella maggior parte dei registri

Un confronto di lunghezza da ricordare: 中文 sono 2 caratteri e 6 byte in UTF-8, ma xn--fiq228c sono 11 byte ASCII. Punycode di solito allunga un nome, mai lo accorcia.

Prenda bücher e osservi i tre passaggi. Il motore si chiama bootstring, e l'intero algoritmo è solo poche decine di righe di codice (può leggerlo nello script di questa pagina).

1. Copi in testa i caratteri semplici. Ogni carattere ASCII di base viene copiato nel suo ordine originale e resta leggibile: bücher → bcher. Poiché qualcosa è stato copiato e qualcosa è rimasto, si aggiunge un singolo - come confine: bcher-.
2. Scriva il resto come numeri in base 36. I caratteri rimanenti vengono trattati in ordine crescente di punto di codice, e ciascuno viene scritto come numero a lunghezza variabile in base 36 dove a=0 … z=25 e 0=26 … 9=35. Per bücher il carattere rimasto ü diventa le cifre kva.
3. Aggiunga il prefisso. La parte codificata accodata alla parte copiata dà bcher-kva, e nel contesto di un dominio si scrive xn--bcher-kva.

Il trucco che rende l'idea brillante è ciò che quei numeri in base 36 contengono: non il carattere stesso, ma un delta — quanto il carattere dista dal punto di codice codificato in precedenza, più dove si colloca all'interno della stringa. Il codificatore percorre i punti di codice in ordine crescente e ogni sequenza di cifre descrive una posizione e una distanza. Dopo ogni carattere un numero condiviso chiamato bias viene aggiornato, così che il numero successivo richieda il minor numero possibile di cifre.

Due conseguenze che può vedere da sé qui sopra:

• I caratteri simili costano poco. Poiché si memorizzano solo le distanze, una serie dello stesso carattere costa quasi nulla: 30 copie di 中 si codificano in xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, solo 36 byte. Un misto misurato di caratteri cinesi non correlati ma vicini comprime circa 41 caratteri in una sola etichetta legale di 63 byte, e un singolo carattere ripetuto arriva a 57.
• I caratteri sparsi costano molto. Un carattere lontano dal precedente richiede un numero delta più lungo. Un testo cinese con molti caratteri diversi costa in genere da 2 a 3 lettere in più per carattere, ed è per questo che un'etichetta CJK esaurisce lo spazio intorno a 20–40 caratteri, anche se il limite dell'etichetta è 63 byte.

La decodifica è la stessa ricetta al contrario: si copia il prefisso ASCII, si leggono le cifre, si riconvertono i delta in punti di codice e si inserisce ogni nuovo carattere nella stringa nella posizione che il delta codifica. Nel bootstring esistono solo cifre minuscole, ed è per questo che una lettera maiuscola dentro una parte codificata viene rifiutata invece di essere indovinata — il DNS non distingue maiuscole e minuscole, quindi ammettere entrambe renderebbe ambigue due grafie diverse.

• Nella barra degli indirizzi. I browser possono mostrare xn--fiq228c.com al posto di 中文.com. È lo stesso sito. Alcuni browser mostrano deliberatamente la forma Punycode quando un nome mescola alfabeti diversi, proprio perché un carattere simile (cirillico а contro latino a) non possa nascondersi nell'URL.
• Nel DNS stesso. I file di zona, le risposte di dig / nslookup / DNS-over-HTTPS e i log dei resolver contengono sempre e solo la forma xn--; l'Unicode semplice viene rifiutato o alterato silenziosamente.
• Nei certificati TLS. Il nome alternativo del soggetto per un dominio internazionale è memorizzato come etichetta A (DNS:xn--fiq228c.com), quindi un certificato che non sembra il nome digitato è normale, non un'incongruenza.
• Nella configurazione e negli strumenti. Le voci server_name del web server / host virtuali, i domini dei cookie, i pannelli di hosting e CDN, i domini di posta, le chiavi API legate a un dominio e le chiavi dei database sono tutte più sicure in forma di etichetta A.
• Nei test e nelle pipeline di dati. Alcune librerie passano l'Unicode direttamente al resolver e falliscono; convertire prima in Punycode è la soluzione standard. Poiché la mappatura è canonica — un'etichetta Unicode corrisponde esattamente a una etichetta A — la forma xn-- è anche un identificatore stabile per log e ricerche.

Punycode è una grafia reversibile, nient'altro. Non è crittografia e non è una funzione di sicurezza: chiunque può decodificarla con lo strumento sopra, quindi un'etichetta xn-- dice «questo è stato codificato» e nulla su chi ne è il proprietario. Non è nemmeno compressione — di solito allunga il testo, come mostra l'esempio da 6 a 11 byte sopra. E non è la stessa cosa degli altri modi in cui l'Unicode circola su Internet; quelli risolvono altri livelli del problema.

Schema	Trasforma che cosa in che cosa	Dove è usato	中文 diventa
Punycode (RFC 3492)	Un'etichetta di dominio Unicode in lettere e cifre ASCII	Solo etichette di dominio internazionali	xn--fiq228c
UTF-8 (RFC 3629)	Punti di codice in byte	Ogni file e richiesta web	E4 B8 AD E6 96 87 (6 byte)
Codifica percentuale (RFC 3986)	Byte in sequenze di escape %XX	Percorsi URL, stringhe di query, corpi di moduli	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Byte in 64 caratteri ASCII	Binario dentro testo, JSON, e-mail, URL dati	5Lit5paH
Entità HTML	Punti di codice in riferimenti con nome o numerici	Sorgente HTML e XML	中文
Escape Unicode	Punti di codice in \uXXXX	Letterali stringa nel codice sorgente e in JSON	\u4e2d\u6587

In pratica: Punycode si applica alle etichette di dominio di un URL, non all'intero URL. Il percorso e la stringa di query sono un problema diverso e usano la codifica percentuale (vedi Codificatori URL).

• I limiti di dimensione vengono dal DNS, non da Punycode. Una etichetta può avere al massimo 63 byte e un nome completo al massimo 255 byte (RFC 1034 / 1035). Poiché un'etichetta A è puro ASCII, il numero di byte coincide con il numero di caratteri, e ogni carattere non ASCII consuma parte di quel budget — circa 1 carattere ogni 1–4 lettere Punycode.
• Punycode converte qualsiasi cosa; i registri consentono solo alcune cose. Le regole IDNA si collocano sopra e limitano quali punti di codice possano essere registrati — lettere maiuscole, spazi, punteggiatura come ! e i contrassegni non sono ammessi in un vero dominio. Questa pagina esegue la conversione RFC 3492, quindi codificherà senza problemi un testo che un registro rifiuterebbe.
• Resti in un solo alfabeto. IDNA sconsiglia di mescolare alfabeti in una stessa etichetta proprio per via degli attacchi con caratteri simili. Un nome può essere codificato e comunque inutilizzabile, oppure utilizzabile ma inserito in una lista nera dai browser.
• Non codifichi due volte. xn-- seguito da testo già codificato non è valido, e un'etichetta di puro ASCII non cambia affatto — non c'è nulla da codificare, quindi non si aggiunge alcun prefisso.
• Un punto finale va bene. 例え.jp. è un nome completo e l'etichetta vuota finale viene mantenuta; le etichette vuote in mezzo non sono nomi host validi.

“Perché il mio dominio cinese compare come xn--fiq228c.com nella barra degli indirizzi?”

Perché il browser ha scelto di mostrare l'etichetta A. Il sito è identico; usi la direzione Decodifica di questa pagina per vedere la forma Unicode, oppure codifichi la forma Unicode per verificare che entrambe le grafie coincidano.

«Devo cambiare i record DNS, il certificato o l'hosting?»

No. Mantenga l'etichetta A xn-- ovunque una macchina legga il nome (DNS, certificati, configurazioni) e usi la forma Unicode solo dove la legge una persona.

«Perché il risultato è più lungo di quello che ho digitato?»

Perché la codifica non trasporta i caratteri stessi, ma distanze in base 36, e l'alfabeto di 36 caratteri deve scrivere numeri che possono essere grandi. La crescita è prevista, non è un errore.

«Perché la decodifica dice «lettera maiuscola»?»

Perché le cifre del bootstring sono definite solo in minuscolo (a-z, 0-9). Una A-Z maiuscola dopo l'ultimo trattino è ambigua, visto che il DNS non distingue maiuscole e minuscole, quindi viene segnalata invece di essere indovinata in silenzio.

«Punycode si applica alla parte prima della @ in un indirizzo e-mail?»

Solo la parte di dominio è un nome DNS e può essere in Punycode. La parte locale è gestita dal sistema di posta, non dal DNS, quindi questa codifica non si applica ad essa.

«Due nomi Unicode diversi possono produrre la stessa etichetta A?»

No. La codifica è iniettiva: sequenze di punti di codice diverse producono sempre bootstring diversi, quindi decodificando xn--fiq228c si ottiene esattamente 中文 e nient'altro. Ciò che può coincidere è l'aspetto — caratteri diversi che si assomigliano — che è una proprietà del repertorio Unicode, non della codifica.

• RFC 3492 — Punycode, la codifica bootstring implementata in questa pagina. I vettori noti citati sopra sono verificati con le stringhe di esempio di quel documento.
• RFC 5890, RFC 5891, RFC 5892 e Unicode UTS #46 — IDNA2008 e la sua interpretazione lato browser, le regole che decidono quali caratteri sono validi, come le etichette vengono normalizzate e come possono essere mescolati gli alfabeti.
• RFC 1034 e RFC 1035 — i limiti di 63 byte per etichetta e di 255 byte per nome ereditati dal DNS.
• RFC 3490 e RFC 3491 — la generazione precedente di IDNA2003, sostituita da IDNA2008. Se un nome si comporta diversamente nel vecchio software, di solito è per questo.

Nota sull'ambito: questo strumento esegue solo la conversione RFC 3492 e nient'altro. Non è un validatore IDN e non verifica le regole di registrazione, i prezzi o la disponibilità di un dominio — e poiché non contatta mai la rete, non può dirle se un nome esiste.

Provi sopra: incolli 中文 e prema Codifica testo → Punycode per vedere l'etichetta A, oppure incolli xn--fiq228c e prema Decodifica Punycode → testo per riavere i caratteri.