Strumenti per sviluppatori · URL codificatore e decodificatore
Punycode vs codifica percentuale: come vengono gestiti i domini e i percorsi nonASCII
· Sfondo
internazionalizzazione punycode codifica dell'URL
Un URL con un nome host nonASCII e un percorso nonASCII utilizza due codifiche completamente diverse. Questo post spiega IDNA e punycode per l'host, la codifica percentuale per tutto il resto e perché esiste la suddivisione.
L'indirizzo che mostra "münchen.example" in un browser e "xn--mnchen-3ya.example" in un altro: un host, due ortografie
La città München appare in un nome di dominio tedesco. Nella barra degli indirizzi del tuo browser, potresti vedere münchen.example visualizzato normalmente. Copia l'indirizzo da un'altra applicazione e verrà visualizzato come xn--mnchen-3ya.example, una stringa solo ASCII che non assomiglia per niente al testo tedesco. Uno URL, due ortografie, entrambe assolutamente valide. Nessuno dei due è sbagliato; rappresentano lo stesso dominio utilizzando set di caratteri completamente diversi. La differenza riflette un vincolo fondamentale su come funziona DNS e su come l'infrastruttura Internet prevede che i nomi host vengano trasmessi.
Segmenti di percorso come /café/ necessitano di codifica ma utilizzano un sistema diverso. Non-ASCII é diventa %C3%A9 nei percorsi. Perché la differenza? I vincoli DNS richiedono punycode per i nomi host.
Perché i nomi host non possono utilizzare la codifica percentuale: etichette DNS, caratteri consentiti e limiti di lunghezza
Le etichette DNS, i singoli segmenti di un nome host separati da punti, hanno regole molto rigide. Possono contenere solo ASCII lettere, cifre, trattini e trattini bassi. Hanno limiti di lunghezza: ciascuna etichetta può contenere al massimo 63 ottetti e il nome host completo non può superare 255 ottetti. Si tratta di vincoli rigidi derivanti dal protocollo DNS stesso, definito decenni fa prima ancora che i nomi di dominio internazionali fossero un concetto. La codifica percentuale non può funzionare per i nomi host perché la stringa risultante probabilmente supererebbe i limiti di etichetta su parole più lunghe.
Ancora più importante, DNS è un sistema globale gestito da router e server in tutto il mondo. Non tutti capiscono UTF-8 o Unicode. Un carattere con codifica percentuale come %C3%A9 è comunque composto da tre caratteri ASCII, quindi rientra nei vincoli DNS. Ma questo approccio significa che ogni ricerca deve essere codificata in percentuale in entrata e decodificata in uscita, aggiungendo complessità allo stesso livello del protocollo. Era necessaria una soluzione migliore specificatamente per i nomi host.
IDNA e punycode in sintesi: il prefisso xn-- e l'algoritmo bootstring, descritti qualitativamente
IDNA, la specifica dei nomi di dominio internazionalizzati nelle applicazioni, risolve il problema del nome host codificando i nomi di dominio nonASCII in ASCII che DNS può gestire. La codifica utilizzata è chiamata punycode, un algoritmo di compressione che trasforma il testo Unicode in ASCII utilizzando il prefisso xn-- seguito da una rappresentazione con codifica bootstring. L'algoritmo è deterministico: münchen diventa sempre xn--mnchen-3ya ogni volta. Qualsiasi nome host nonASCII deve essere convertito in questo modo prima che possa avvenire la risoluzione di DNS.
Il prefisso xn-- segnala a DNS e al software IDNA-aware che i seguenti caratteri sono punycode, non lettere ASCII letterali. Un dominio come example.xn--mnchen-3ya.com viene inteso come example.münchen.com dal software IDNA. Punycode utilizza solo lettere, cifre e trattini ASCII, quindi si adatta perfettamente alle etichette DNS senza problemi. L'algoritmo comprime le informazioni nonASCII in questa rappresentazione ASCII.
Percorsi, query e frammenti rimangono codificati in percentuale: UTF-8 byte su %XX, come altrove
Tutto il resto in URL (il percorso, la stringa di query, il frammento) utilizza invece la codifica percentuale. Un carattere nonASCII viene prima convertito in UTF-8 byte, quindi ogni byte viene scritto come %HH dove HH è esadecimale. Il percorso /café/ diventa /caf%C3%A9/. La stringa di query ?name=josé diventa ?name=jos%C3%A9. La codifica percentuale è standard ovunque sul Web: negli URL di richiesta HTTP, nei moduli HTML, nelle API. Non necessita di una gestione speciale da parte di DNS o router.
La codifica percentuale consente inoltre di rappresentare in modo sicuro altri caratteri speciali. Uno spazio diventa %20, una barra (se deve apparire all'interno di un valore) diventa %2F e così via. Lo schema è coerente e universale. Non viene utilizzato per i nomi host perché DNS non comprende gli URL o la codifica percentuale; comprende solo le etichette ASCII.
Esempio funzionante: uno URL con entrambi: l'host convertito in punycode, il percorso codificato in percentuale, affiancati
Prendi il URL "https://münchen.example/café?city=münchen". Il nome host münchen deve essere convertito in punycode prima della ricerca DNS: https://xn--mnchen-3ya.example/café?city=münchen. Ma aspetta: il percorso e la query hanno anche non-ASCII. Converti anche quelli: https://xn--mnchen-3ya.example/caf%C3%A9?city=m%C3%BCnchen. Ora il nome host è punycode, il percorso e la query sono codificato in percentuale. Un browser visualizza la versione Unicode originale per la leggibilità; la richiesta HTTP trasporta la versione codificata.
Nello strumento di codifica e decodifica URL, incolla un percorso contenente testo nonASCII e confronta la modalità a valore singolo (solo il percorso) con la modalità a indirizzo intero (completo URL). Lo strumento mostra il risultato con codifica percentuale per il percorso. Il nome host, tuttavia, richiede una conversione punycode separata; la maggior parte degli strumenti di codifica non lo gestiscono in linea, quindi leggilo dalla documentazione dello strumento.
Attacchi omografi e perché i browser a volte mostrano punycode: il ragionamento di sicurezza dietro le regole di visualizzazione
Un utente malintenzionato potrebbe registrare un dominio utilizzando lettere cirilliche che sembrano visivamente identiche alle lettere latine, come "https://xn--80akhbyknj4f.example" (una versione cirillica di "example.example" in punycode). Se un browser lo visualizza decodificato come testo cirillico, gli utenti potrebbero non notare la differenza. Per prevenire attacchi omografi, i browser a volte mostrano la versione punycode invece di decodificarla. Viene visualizzato un avviso: questo dominio è tutto o principalmente nonASCII e potresti non riconoscere i caratteri.
Il codificatore e decodificatore URL è uno strumento per la codifica e la decodifica, non per la valutazione della sicurezza. Se lavori con nomi di dominio internazionali, tieni presente che la rappresentazione punycode è ciò che vede la rete.
Cosa non copre: esecuzione manuale dell'algoritmo punycode o differenze IDNA 2003 rispetto a 2008
IDNA ha attraversato più versioni nel tempo: IDNA 2003 e IDNA 2008 gestiscono alcuni casi limite in modo diverso, in particolare riguardo alla normalizzazione e ai caratteri Unicode consentiti dalle specifiche. Alcuni sistemi meno recenti utilizzano ancora IDNA 2003 mentre altri sono migrati a IDNA 2008 per una migliore conformità. Le differenze sono importanti se stai creando sistemi che devono essere compatibili tra più versioni. Controlla sempre attentamente i requisiti di sistema.
Punycode utilizza la compressione bootstring. Esistono implementazioni nei linguaggi comuni, ma verifica la policy IDNA con il tuo sistema di nomi host. Testare la risoluzione e il comportamento di visualizzazione anziché dare per scontato.
Conclusione: due codifiche per due lavori: come il codificatore e decodificatore URL gestisce le parti codificate in percentuale e perché un codificatore in percentuale è lo strumento sbagliato per il nome host
I nomi host necessitano di punycode perché DNS è un vecchio protocollo che comprende solo le etichette ASCII e presenta rigidi vincoli di lunghezza e caratteri. Percorsi, query e frammenti utilizzano la codifica percentuale perché è universale sul Web e non presenta tali vincoli. Sono due soluzioni separate per due problemi completamente diversi. Quando incontri un nonASCII URL, il nome host riceve prima la conversione punycode, quindi il resto utilizza la codifica percentuale.
Per la maggior parte del lavoro di sviluppo, il framework o la libreria gestiscono automaticamente questa conversione dietro le quinte. Ma capire perché esistono due codifiche diverse previene la confusione durante il debug di URL internazionali o l'implementazione corretta del proprio codice di gestione URL.