Strumenti per sviluppatori · URL codificatore e decodificatore
Come funziona la codifica percentuale: dai caratteri ai byte UTF-8 alle sequenze %XX
· Come funziona
codifica dell'URL utf-8 codifica percentuale sviluppatore
La codifica percentuale non codifica i caratteri; codifica i byte. Questo post mostra come un carattere diventa UTF-8 byte e poi si accoppia esadecimale, e perché una lettera accentata richiede due gruppi %XX mentre un'emoji ne richiede quattro.
Perché "é" diventa %C3%A9 anziché %E9: l'osservazione che rivela lo strato di byte sottostante
Quando uno sviluppatore junior vede %C3%A9 in un URL, la codifica percentuale opera sui byte, non sui caratteri. Il carattere é non è un byte; UTF-8 lo codifica come due: C3 A9. La regola di codifica percentuale di RFC 3986 è semplice: codifica ogni byte come segno di percentuale seguito da due cifre esadecimali. Questa distinzione trasforma la spiegazione da misteriosa a logica.
Per comprendere la codifica percentuale è necessario comprendere UTF-8. Il testo deve essere convertito in byte utilizzando la codifica dei caratteri. UTF-8 è lo standard per URL e web. Esprime i caratteri come sequenze di byte di lunghezza variabile: ASCII utilizza un byte, le lettere accentate ne utilizzano due, le emoji ne utilizzano quattro. Ogni fase è distinta: carattere, punto di codice Unicode, UTF-8 byte, quindi %XX coppie. Saltare a esadecimale senza comprendere i byte non coglie il punto.
La regola di codifica percentuale da RFC 3986: un % seguito da due cifre esadecimali per byte, preferibilmente maiuscolo
RFC 3986 definisce una regola: codificare ogni byte come percentuale seguita da due cifre esadecimali maiuscole. I caratteri non riservati che non necessitano di codifica sono lettere, cifre, trattino, carattere di sottolineatura, punto e tilde. Tutto il resto deve essere codificato. Gli spazi diventano %20, le barre diventano %2F e il segno di percentuale diventa %25. Ciò impedisce ai caratteri speciali nei valori della query di interrompere la struttura URL.
Uno spazio codifica come byte 0x20, diventando %20. Una barra è 0x2F, che diventa %2F. Questi sono i caratteri ASCII che necessitano di un byte. Le lettere accentate e le emoji differiscono. Il segno di percentuale diventa %25. I delimitatori riservati come i due punti vengono codificati per preservare la struttura. Ciò impedisce che una e commerciale incorporata o un valore uguale a un parametro di query interrompa l'analisi. Ogni byte diventa %HH.
UTF-8 come set di caratteri presunto: perché gli URL moderni sono UTF-8 e dove si trovano le eccezioni legacy
UTF-8 utilizza la codifica a lunghezza variabile. ASCII dai punti di codice 0 a 127 è un byte. I caratteri da 128 a 2047, comprese le lettere latine accentate, sono due byte. I caratteri da 2048 a 65535, comuni nelle scritture dell'Asia orientale, sono tre byte. I caratteri sopra 65535, inclusa la maggior parte delle emoji, sono quattro byte. Ogni byte è preceduto da bit che segnalano quanti byte seguono.
La lettera accentata é è il punto di codice Unicode U+00E9. UTF-8 lo codifica come due byte: 0xC3 e 0xA9. La codifica percentuale produce %C3%A9. Il tedesco ü (U+00FC) codifica come 0xC3 0xBC, diventando %C3%BC. Lo spagnolo ñ (U+00F1) codifica come 0xC3 0xB1, diventando %C3%B1. Lo schema è coerente: il primo byte segnala una sequenza di due byte. Una lettera accentata si espande di sei caratteri nella codifica.
Esempio realizzato: codifica 'café 😀' byte per byte: i punti di codice, i byte UTF-8 e la stringa risultante
Emoji rende evidente il livello di byte. L'emoji del pollice in su 👍 è il punto codice U+1F44D. UTF-8 lo codifica come quattro byte: F0 9F 91 8D. La codifica percentuale produce %F0%9F%918D: dodici caratteri per un simbolo. Lo smiley 😀 (U+1F600) codifica come F0 9F 98 80, diventando %F0%9F%9880. Le sequenze di quattro byte diventano caratteri codificati al dodici percento.
Il testo misto mostra perché è importante comprendere i byte. La frase "café 😀" contiene semplicemente ASCII, un accento e un emoji. Le lettere c, a, f codificano come 63, 61, 66. La é codifica come C3 A9. Lo spazio codifica come 20. L'emoji codifica come F0 9F 98 80. Il risultato è "caf%C3%A9%20%F0%9F%9880". Comprendere quali byte necessitano di codifica rende l'output prevedibile.
Decodifica al contrario: raccogliendo i gruppi %XX in byte e solo successivamente interpretandoli come UTF-8
La decodifica inverte il processo. Un decodificatore esegue la scansione delle coppie %XX e le raccoglie in valori di byte. Vedendo %C3%A9, estrae i byte C3 e A9. La decodifica UTF-8 li interpreta come il carattere é. Se una sequenza è incompleta, come solo %C3, il risultato è un errore. Il decodificatore sa dai bit del prefisso UTF-8 che C3 richiede un secondo byte.
Le maiuscole e minuscole non hanno importanza nelle cifre esadecimali; %C3%A9 e %c3%a9 decodificano in modo identico. RFC consente l'uso del maiuscolo o del minuscolo, anche se è preferibile il maiuscolo. Ma per i caratteri conta il maiuscolo e il minuscolo: é (come %C3%A9) non è la stessa cosa di É (come %C3%89). Il confronto URL deve normalizzare la codifica percentuale o rischiare di trattare risorse identiche come diverse. I framework si normalizzano prima della memorizzazione nella cache.
Perché le maiuscole e minuscole non contano nelle cifre esadecimali ma lo fanno altrove: regole di normalizzazione e confronto URL
RFC 3986 menziona punycode per i nomi di dominio e la codifica dei moduli per gli invii come regole separate. Punycode codifica i nomi di dominio nonASCII senza segni di percentuale per la compatibilità DNS. Il dominio 😀.example diventa "xn--js8h.example". La codifica del modulo modifica la codifica percentuale con un'eccezione: gli spazi diventano segni più invece di %20. I moduli inviati come application/x-www-form-urlencoded utilizzano plus per gli spazi.
Lo strumento di codifica URL mostra tutte e tre le modalità: codifica del componente, codifica dell'interoURL e codifica del modulo. Codifica del componente con encodeURIComponent codifica ogni carattere speciale inclusi i delimitatori, adatti per i valori della query. La codifica Whole-URL con encodeURI preserva i caratteri strutturali per gli URL completi. La codifica del modulo è per i corpi POST. Ciascuno utilizza UTF-8; differiscono solo per i byte che rimangono non codificati.
Punycode e codifica dei moduli: standard fratelli, non estensioni con codifica percentuale
La prospettiva dei byte risolve i misteri URL. Perché un emoji ha bisogno di dodici caratteri? Poiché UTF-8 utilizza quattro byte, ciascuno dei quali diventa %HH. Perché alcuni URL hanno %2F per le barre mentre altri hanno barre semplici? Perché la modalità di codifica decide: una barra in un segmento di percorso rimane non codificata, ma all'interno di un valore di query deve essere %2F per evitare errori di lettura.
Pensa in byte per una codifica percentuale prevedibile. Un carattere è un punto di codice Unicode. UTF-8 è la sua rappresentazione in byte. La codifica percentuale è il formato di trasmissione. L'espansione dei caratteri avviene al livello UTF-8. Il caso esadecimale non influisce sulla decodifica, ma il caso dei caratteri sì. Le sequenze di byte non valide falliscono in UTF-8 a causa di rigide regole di prefisso. Lo strumento di codifica URL mostra questa progressione.
In conclusione: pensa in byte: come il codificatore e decodificatore URL mostra l'esatto output %XX per qualsiasi testo che incolli, nel browser
Esempio realizzato: codifica "café 😀". La parola café ha le lettere c, a, f come ASCII byte singoli: 63, 61, 66. La é è UTF-8 due byte: C3 A9. Lo spazio è 20. L'emoji 😀 è di quattro byte: F0 9F 98 80. Le lettere ASCII non riservate rimangono visibili. Risultato: "caf%C3%A9%20%F0%9F%9880". Questo mostra perché un emoji si espande fino a dodici caratteri.
Da asporto: pensa in byte, non in caratteri. La codifica percentuale viene applicata dopo la codifica UTF-8. Ogni byte diventa %HH. La lunghezza variabile UTF-8 significa che i caratteri si espandono in modo diverso: ASCII diventa %XX (due caratteri), gli accenti a due byte diventano %XX%XX (sei caratteri), gli emoji a quattro byte diventano %XX%XX%XX%XX (dodici caratteri). Incolla il testo nello strumento di codifica URL e osserva la progressione.