URL Encoder/Decoder

La Scienza e la Storia della Codifica Percentuale

La codifica percentuale emerse da un vincolo fondamentale dei primi tempi di internet: la limitazione ASCII. Quando Tim Berners-Lee progettò la sintassi URL nel 1994, la specifica dell'Uniform Resource Locator (RFC 1738) limitava gli indirizzi web a un piccolo sottoinsieme di caratteri ASCII. Questo aveva senso per l'internet prevalentemente anglofono dei primi anni '90, ma significava che qualsiasi carattere al di fuori di questo insieme sicuro necessitava di un meccanismo di rappresentazione. La soluzione fu elegantemente semplice: rappresentare ogni byte non sicuro come un segno di percentuale seguito dal suo valore esadecimale a due cifre. Uno spazio (valore byte 32, hex 20) diventa %20, un punto interrogativo (valore 63, hex 3F) diventa %3F. Questo schema poteva rappresentare qualsiasi valore byte da 00 a FF, rendendolo capace di codificare qualsiasi carattere in qualsiasi set di caratteri. L'introduzione di UTF-8 come codifica standard dei caratteri del web trasformò la codifica percentuale da un semplice schema di mappatura byte a un sistema di codifica multi-byte. Un singolo carattere cinese può richiedere tre byte in UTF-8, producendo tre triplette consecutive. Il simbolo dell'euro, ad esempio, occupa tre byte (E2, 82, AC) e diventa la sequenza di sei caratteri %E2%82%AC. Ecco perché gli URL codificati contenenti testo non latino possono apparire notevolmente più lunghi. RFC 3986, pubblicato nel 2005, perfezionò la specifica URL originale e formalizzò le regole moderne per la codifica percentuale. Stabilì il concetto di insiemi di caratteri riservati e non riservati, chiarendo quali servono come delimitatori strutturali negli URL. Questa distinzione spiega perché esistono due funzioni di codifica in JavaScript: encodeURI preserva i caratteri strutturali per URL completi, mentre encodeURIComponent codifica tutto per un inserimento sicuro nei componenti URL. La specifica introdusse anche il principio della normalizzazione, definendo quando due URL codificati diversamente devono essere considerati equivalenti.

Metodologia

La codifica URL sostituisce i caratteri ASCII non sicuri con un segno di percentuale (%) seguito da due cifre esadecimali che rappresentano il valore in byte del carattere. Ad esempio, uno spazio diventa %20 (hex 20 = decimale 32), una e commerciale diventa %26 è un segno più diventa %2B. La codifica segue RFC 3986, che definisce l'insieme dei caratteri non riservati che non necessitano mai di codifica: lettere maiuscole e minuscole (A-Z, a-z), cifre (0-9) e quattro caratteri speciali (trattino, punto, underscore, tilde). Questo strumento fornisce due modalità di codifica che corrispondono direttamente alle funzioni native di JavaScript. La modalità Componente usa encodeURIComponent(), che codifica ogni carattere tranne l'insieme non riservato, rendendola ideale per i valori dei parametri di query dove caratteri come & e = devono essere sottoposti a escape. La modalità URL Completo usa encodeURI(), che preserva inoltre i caratteri strutturali dell'URL come : / ? # [ ] @ ! $ & ' ( ) * + , ; = affinché un URL completo rimanga funzionale dopo la codifica. Per i caratteri internazionali e gli emoji, lo strumento converte prima il testo nella sua rappresentazione in byte UTF-8, poi codifica ogni byte individualmente. Un singolo carattere Unicode come il simbolo dell'euro può produrre più triplette codificate (%E2%82%AC) perché UTF-8 usa una codifica a lunghezza variabile da uno a quattro byte per carattere.

Capire i tuoi risultati

Usare la modalità Componente (encodeURIComponent) ogni volta che si codifica un valore che sarà posizionato dopo un segno di uguale in una stringa di query. Questo assicura che caratteri come &, = e # all'interno del valore non rompano accidentalmente la struttura dell'URL. Usare la modalità URL Completo (encodeURI) quando si ha un URL completo e si vogliono codificare solo spazi e caratteri non-ASCII mantenendo intatti i delimitatori strutturali. Se si vede %25 nell'output, significa che il segno di percentuale stesso è stato codificato, il che tipicamente indica una doppia codifica—l'input era già codificato prima dell'elaborazione. Decodificare tali stringhe due volte recupererà il testo originale. Questo è uno degli errori di codifica URL più comuni nelle applicazioni web e nelle API. La decodifica è utile per rendere gli URL leggibili durante il debugging, analizzare i log del server o ispezionare i parametri di query che contengono valori codificati. I nomi di dominio internazionali (IDN) usano una codifica diversa chiamata Punycode invece della codifica percentuale, quindi i nomi di dominio con caratteri non latini richiedono una gestione separata. Codificare sempre l'input dell'utente prima di inserirlo negli URL per prevenire attacchi di iniezione.

Esempi pratici

Parametro di query di ricerca: codificare 'coffee & tea' in modalità Componente produce 'coffee%20%26%20tea', facendo escape in sicurezza sia degli spazi che della e commerciale affinché il server riceva il testo letterale. Invio di modulo: un utente inserisce 'price=50$', che deve essere codificato come 'price%3D50%24' per impedire che il segno di uguale venga interpretato come separatore chiave-valore. URL di redirect API: quando si passa un URL di callback come 'https://app.com/auth?token=abc' come parametro a un altro URL, la modalità Componente codifica l'intero callback inclusa la propria stringa di query. Contenuto multilingue: la codifica di testo giapponese produce sequenze di byte UTF-8 come triplette percentuali. Decodifica di debug: incollare un URL completo dai log del server e decodificarlo per vedere istantaneamente la query originale per una rapida risoluzione dei problemi.

Consigli e Buone Pratiche

Usare sempre la modalità Componente quando si codificano singoli valori di parametri di query. La modalità URL Completo lascia i caratteri strutturali come & e = non codificati, il che romperà l'URL se quei caratteri appaiono nei dati stessi invece che come delimitatori. Evitare la doppia codifica controllando se l'input è già percent-encoded. Se si vedono sequenze come %20 o %26 nell'input, decodificare prima di ricodificare per prevenire l'impilamento (dove %20 diventa %2520). Quando si costruiscono URL programmaticamente, codificare ogni valore di parametro separatamente e poi assemblare l'URL completo. Non codificare mai l'intera stringa URL in una volta, poiché questo corromperebbe i caratteri strutturali che separano schema, host, percorso e componenti di query. Per il debugging delle chiamate API, incollare l'URL codificato completo in modalità decodifica per leggere rapidamente tutti i valori dei parametri in forma leggibile. Questo è particolarmente utile quando si risolvono problemi con URL di webhook o redirect OAuth che contengono valori codificati annidati.

Codifiche URL Comuni

Fonti

• RFC 3986 – Sintassi Generica URI
• MDN – encodeURIComponent