Codec URL

Perché gli URL vanno codificati

Un URL è insieme un indirizzo leggibile e una stringa strutturata analizzata da browser, proxy e server. Certi caratteri separano i componenti: ? avvia la query, & separa i parametri, # inizia il frammento, / divide i segmenti di percorso, e gli spazi sono scomodi in molti contesti. Se il valore di un parametro contiene & o =, l’analizzatore leggerebbe male la struttura a meno che quei byte non siano scritti in forma sicura.

La codifica URL—più formalmente percent-encoding—sostituisce byte non sicuri o riservati con un % seguito da due cifre esadecimali. Il byte space diventa spesso %20 (o + nella variante application/x-www-form-urlencoded). Non è cifratura; è un’ortografia di trasporto affinché struttura e payload possano coesistere.

Provate a codificare una frase con lo strumento da testo a URL codificato.

Caratteri reserved versus unreserved

RFC 3986 definisce i caratteri unreserved che di solito compaiono così come sono: lettere, cifre e -._~. I caratteri reserved come :/?#[]@!$&'()*+,;= hanno ruoli nella grammatica URL. Se codificare un carattere reserved dipende da dove compare. Una / nel percorso è un separatore; una / nei dati di un singolo segmento può richiedere codifica se volete una barra letterale nel valore di quel segmento.

Regola pratica: codificate i dati che iniettate in un componente così che i caratteri reserved perdano il significato speciale per l’analizzatore circostante.

Meccanica del percent-encoding

1. Esprimere la stringa come byte (quasi sempre UTF-8 sul web moderno).
2. Per ogni byte da codificare, scrivere % più hex in maiuscolo o minuscolo (i decoder accettano entrambi; gli emitter usano spesso il maiuscolo).
3. Lasciare invariati i caratteri sicuri.

Esempio: lo spazio in hello world diventa hello%20world. La codifica UTF-8 di é è i byte C3 A9, quindi il carattere diventa %C3%A9.

La decodifica inverte la mappatura. Sequenze incomplete come %Z o un % finale vanno rifiutate o gestite secondo le regole della piattaforma—non indovinate in silenzio nel codice sensibile alla sicurezza.

Query string e application/x-www-form-urlencoded

I moduli HTML tradizionalmente codificano gli spazi come + e usano & / = come delimitatori. Le librerie chiamate encodeURIComponent versus URLSearchParams differiscono nei casi limite. In fase di debug:

• Confermare se + significa spazio o un più letterale.
• Codificare i valori prima di unirli con &.
• Non codificare l’intero URL alla cieca—schema e host hanno regole diverse.

encodeURI e encodeURIComponent in JavaScript codificano set di caratteri diversi; scegliere quello sbagliato è una causa frequente di link rotti.

Percorsi, matrici e frammenti

I segmenti di percorso devono codificare spazi e la maggior parte dei caratteri reserved non intesi come separatori. I frammenti (#...) sono gestiti dal client e non inviati ai server nella richiesta HTTP; la codifica resta importante per la correttezza lato client. Lo userinfo (user:pass@) è obsoleto per i segreti negli URL—evitate di mettere credenziali negli URL indipendentemente dalla codifica.

Doppia codifica e bug di decodifica

La doppia codifica avviene quando %20 viene codificato di nuovo in %2520. Sintomi: %20 letterale nel testo UI o file non trovati perché il server cerca il nome sbagliato. La sottocodifica lascia & dentro un valore e tronca i parametri successivi.

Una pipeline robusta codifica esattamente una volta al confine in cui una stringa grezza diventa parte di un componente URL, e decodifica una volta all’estrazione dei valori.

Nomi di dominio internazionalizzati e percorsi

Gli host usano IDNA (Punycode) per etichette di dominio non ASCII—un meccanismo diverso dal percent-encoding di percorso e query. Percorsi e query usano percent-encoding UTF-8. Mescolare codifiche di sistema legacy (Latin-1 da un lato, UTF-8 dall’altro) produce mojibake dopo la decodifica.

Documentate sempre UTF-8 come codifica dei byte per le nuove API.

Aspetti di sicurezza

La codifica URL non sostituisce l’escape HTML, la parametrizzazione SQL o la sicurezza degli argomenti di comando. Una stringa correttamente percent-codificata per un parametro di query può restare pericolosa se poi viene messa in HTML senza escape, o in una shell senza quoting adeguato.

Problemi di open-redirect e SSRF spesso coinvolgono URL come dati. Validate schemi e host dopo la decodifica—gli aggressori possono codificare punti, barre o credenziali per confondere filtri ingenui. Confrontate con cura le forme decodificate; meglio ancora, analizzate con una libreria URL standard e consentite proprietà in allowlist.

Logging e privacy

Le query string contengono spesso termini di ricerca, token o dati personali. La codifica non li nasconde ai log del server né alla cronologia del browser. Preferite corpi POST o header per valori sensibili, e rimuovete i segreti dai log di accesso.

Checklist di test

1. Codificare una stringa con spazi, &, = e caratteri non ASCII.
2. Decodificare e confrontare con i code point originali.
3. Mettere il valore codificato in una query reale e rileggerlo dall’API parametri del framework.
4. Verificare che il framework non doppia-decodifichi.
5. Verificare che il comportamento di + versus %20 corrisponda al media type usato.

Lo strumento di codifica URL aiuta con i passi 1–2 nell’esplorazione manuale.

Scenari comuni

Costruire link di ricerca. Codificare il valore della query utente; non codificare ?q= stesso. URI di redirect OAuth. Può essere richiesta una corrispondenza esatta di stringa; differenze di codifica rompono i redirect. Chiavi di object storage negli URL. Codificare i segmenti di percorso così che chiavi annidate con spazi funzionino. CSV di link. Attenzione al software fogli di calcolo che reinterpreta le sequenze %.

Codifiche correlate

Non confondete percent-encoding con Base64 o entità HTML. Base64 usa un alfabeto diverso e serve per byte arbitrari in contesti testuali; le entità HTML proteggono la struttura del documento nel markup. Usate l’encoder che corrisponde all’analizzatore ricevente.

Riepilogo

La codifica URL permette a testo arbitrario di viaggiare nei componenti URL senza rompere i delimitatori. Convertite in byte UTF-8, percent-codificate i valori non sicuri una volta e decodificate una volta in uscita. Scegliete con cura le API per query versus URI completo, validate gli URL dopo il parsing per sicurezza, e ricordate: la codifica è ortografia—non riservatezza.