URI, URL e componenti
URI è il termine generale per identificatori di risorse; URL indica gli URI che esprimono anche un meccanismo o luogo di accesso. Nella pratica web un URL è composto da schema, authority, path, query e fragment, ciascuno con regole proprie.
Interpretare correttamente i componenti è essenziale perché lo stesso carattere può essere sintassi in una posizione e dato in un'altra. Codificare indiscriminatamente l'intero URL può quindi distruggere delimitatori necessari.
Reserved e unreserved
RFC 3986 distingue caratteri unreserved, che possono normalmente comparire senza codifica, e reserved, che possono avere funzione delimitatrice. Lettere ASCII, cifre, trattino, punto, underscore e tilde appartengono al gruppo unreserved.
Caratteri come :, /, ?, #, [, ], @ e alcuni sub-delims possono avere significato strutturale. Se devono rappresentare dati letterali all'interno di un componente, la scelta di codificarli dipende dal ruolo concreto di quel componente.
Dal testo Unicode ai byte UTF-8
Il percent-encoding opera su byte: ogni byte viene rappresentato come % seguito da due cifre esadecimali. Un carattere Unicode non ASCII viene prima trasformato nella sua sequenza UTF-8, che può richiedere più byte e quindi più triplette %HH.
Questo spiega perché un singolo carattere visibile può diventare una sequenza molto più lunga. Decodificare correttamente significa ricostruire prima i byte e poi interpretarli con l'encoding concordato, tipicamente UTF-8.
Path, query e form encoding
Nel path, slash e segmenti hanno semantica strutturale. Nella query, ampersand ed uguale sono spesso usati dalle convenzioni applicative per separare coppie nome-valore, pur non definendo da soli un unico modello universale di query string.
application/x-www-form-urlencoded aggiunge una convenzione distinta: lo spazio è spesso rappresentato con + e il segno + letterale deve essere codificato. Non va confusa questa convenzione con il percent-encoding generico di un URI.
Normalizzazione ed equivalenza
La percent-encoding è case-insensitive nelle cifre esadecimali e alcuni caratteri unreserved codificati possono essere normalizzati nella forma letterale. Tuttavia due URL testualmente diversi non sono automaticamente equivalenti in ogni applicazione.
Normalizzazione di host, porte di default, path e query può dipendere dal protocollo e dal server. Evita trasformazioni aggressive quando l'identità esatta della risorsa o una firma crittografica dipendono dalla rappresentazione originale.
Errori di decodifica e sicurezza
Sequenze con percentuale incompleta, cifre non esadecimali o byte che non formano UTF-8 valido devono essere gestite esplicitamente. Decoder troppo permissivi possono produrre interpretazioni divergenti tra proxy, framework e applicazione.
Le differenze di canonicalizzazione possono contribuire a bypass di routing, cache o controlli di sicurezza. È buona pratica decodificare nel livello corretto una sola volta e validare il componente risultante secondo la sua semantica.
