Codificatore / Decodificatore URL gratuito

Codifica o decodifica URL e componenti URI istantaneamente.

Nessun dato lascia il tuo dispositivo

encodeURIComponent encodeURI

Input

Output

Informazioni sulla codifica URL

La codifica URL (chiamata anche percent-encoding) converte i caratteri non consentiti in un URL in un formato che può essere trasmesso in modo sicuro. I caratteri speciali vengono sostituiti con un segno di percentuale (%) seguito da due cifre esadecimali che rappresentano il valore in byte del carattere.

Una breve storia della regola di codifica

La convenzione di percent-encoding risale a RFC 1738 ("Uniform Resource Locators (URL)", Tim Berners-Lee, Larry Masinter e Mark McCahill, dicembre 1994), la prima specifica formale degli URL pubblicata dall'IETF. RFC 1738 definì il set originale di caratteri "riservati" (caratteri con significato strutturale negli URL che devono essere codificati quando usati come dati) e il set "non riservato" originale (caratteri che non hanno mai bisogno di codifica). La specifica è stata sostanzialmente rivista in RFC 2396 (Berners-Lee, Fielding, Masinter, agosto 1998) e di nuovo, definitivamente, in RFC 3986 ("Uniform Resource Identifier (URI): Generic Syntax", Berners-Lee, Fielding, Masinter, gennaio 2005), che è ancora oggi la specifica formale degli URI. RFC 3986 ha esteso il set non riservato per includere il carattere tilde (~), ha formalizzato UTF-8 come codifica per i caratteri non ASCII negli IRI e ha stretto le regole su quando i caratteri riservati devono essere percent-encoded contro lasciati così come sono. Per URI non ASCII, RFC 3987 ("Internationalized Resource Identifiers", Duerst e Suignard, gennaio 2005) ha definito l'estensione IRI che permette agli URL di contenere caratteri Unicode nativi, mappando la forma IRI alla forma URI standard tramite UTF-8 più percent-encoding. Per i nomi di dominio specificamente, RFC 3492 ha definito Punycode (Costello, marzo 2003), la codifica usata per rappresentare etichette di dominio Unicode (xn--exmpla-...) nel DNS, che è strutturalmente simile ma usa un algoritmo diverso. La specifica URL de facto del web moderno è il WHATWG URL Living Standard, curato da Anne van Kesteren, che codifica il comportamento effettivo dei browser, talvolta divergendo da RFC 3986 per la retrocompatibilità con come gli URL funzionano in pratica.

Riservati, non riservati e i caratteri che si codificano sempre

Gli spazi diventano %20, le e commerciali diventano %26, i segni di uguale diventano %3D, e i caratteri non ASCII come lettere accentate o emoji vengono codificati nelle loro sequenze di byte UTF-8. Lettere, cifre e i caratteri - _ . ~ non vengono mai codificati (caratteri non riservati).

encodeURI contro encodeURIComponent: quale usare quando

JavaScript spedisce due encoder integrati, entrambi standardizzati in ECMAScript dal 1999 (ES3). La scelta tra di loro è la decisione di URL-encoding singolarmente più comune nel codice web, e sbagliarla produce bug sottili che superano i test su input semplici ma si rompono sui dati utente reali contenenti commerciali, cancelletti o slash.

encodeURIComponent, codifica tutto tranne il set non riservato. Usalo quando stai codificando un singolo pezzo di dato che verrà incorporato in un URL, un valore di parametro di query, un segmento di percorso, un identificatore di frammento, un valore di campo modulo. La stringa hello world&more diventa hello%20world%26more, l'e-commerciale interno è codificato, così non viene analizzato come separatore di parametri di query quando l'URL viene letto in seguito. Questo è lo strumento giusto per "ho input dell'utente, voglio metterlo in un URL in modo sicuro".
encodeURI, codifica solo i caratteri che sono illegali ovunque in un URL. Lascia deliberatamente intatti i caratteri riservati (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) perché quei caratteri potrebbero star facendo lavoro strutturale. Usalo quando stai codificando un intero URL che è stato assemblato con la sua struttura già a posto, un URL che contiene i propri separatori ? e &, un URL con caratteri non ASCII nel percorso o nella query che hanno bisogno di codifica senza disturbare la grammatica dell'URL. La stringa https://example.com/search?q=hello world diventa https://example.com/search?q=hello%20world, gli slash e il punto di domanda sono preservati, solo lo spazio viene codificato.

La regola mentale: encodeURIComponent per i dati, encodeURI per gli URL. Usa quello sbagliato e o spezzerai la struttura dell'URL (encodeURIComponent su un intero URL fa l'escape degli slash e degli ampersand di cui avevi bisogno) o non riuscirai a fare l'escape dell'input dell'utente (encodeURI su un valore di query lascia passare gli ampersand e i tuoi dati vengono analizzati come parametri multipli).

application/x-www-form-urlencoded, l'altra codifica

C'è una seconda codifica correlata usata specificamente per le sottomissioni di form HTML: application/x-www-form-urlencoded. Sembra quasi identica al percent-encoding URL eccetto per un dettaglio, gli spazi sono codificati come + invece che %20. Questa convenzione risale alla specifica HTML originale dei form ed è preservata nel URL Living Standard per il serializzatore application/x-www-form-urlencoded specificamente. I decoder per dati form-encoded devono invertire la convenzione: un + letterale nei dati form è codificato come %2B e + nella stringa codificata si decodifica di nuovo a uno spazio. L'API URLSearchParams di JavaScript gestisce questa convenzione automaticamente; encodeURIComponent no, codifica sempre gli spazi come %20. Per query string assemblate a mano per un'azione di form HTML, usa URLSearchParams invece di chiamare encodeURIComponent su ogni valore individualmente.

Quando ti serve davvero questo strumento

Debug di una chiamata API. Stai colpendo un endpoint REST con un parametro di query che contiene spazi o caratteri speciali e ricevi indietro errori 400 o risultati inaspettati. Codifica il valore del parametro qui, incolla il risultato nella tua richiesta e conferma che l'API tratti l'input correttamente.
Costruire un URL condivisibile a mano. Costruzione di un deep-link a una pagina di risultati di ricerca, una vista filtrata di una dashboard SaaS o un modulo precompilato, ovunque tu debba incorporare una query di ricerca o uno stato di selezione nell'URL.
Decodificare un URL catturato per leggere cosa c'è davvero dentro. Un URL nel log contiene %E2%9C%93%20done, a cosa corrisponde? Incolla, premi Decodifica, vedi ✓ done.
URL OAuth e webhook. Il parametro redirect_uri nei flussi OAuth deve essere percent-encoded con precisione; sbagliare produce errori opachi "redirect_uri mismatch". Gli URL webhook che contengono parametri di query con dati utente hanno bisogno di codifica attenta.
Nomi di file con caratteri non ASCII nei link di download. Un link diretto a un file chiamato café-menu.pdf ha bisogno che la é sia percent-encoded perché il link funzioni in tutti i browser e gli strumenti shell.
Stringhe di connessione al database. Gli URL di database PostgreSQL, MySQL e simili (postgres://user:p@ssw0rd@host/db) hanno bisogno che la password sia percent-encoded se contiene @, :, / o altri caratteri riservati che confonderebbero il parser dell'URL.

Sicurezza: perché la codifica conta oltre l'estetica

L'URL-encoding errato è una fonte di lunga data di vulnerabilità web. L'HTTP response splitting sfrutta interruzioni di riga non codificate (CR, LF, %0D%0A) nei parametri URL che vengono riflessi negli header HTTP, permettendo a un attaccante di iniettare header arbitrari o anche una risposta completa. I redirect aperti sfruttano la gestione URL ingenua che non decodifica e valida correttamente gli URL forniti dall'utente prima del redirect. Il server-side request forgery (SSRF) può abusare di caratteri codificati per bypassare le allowlist URL, una regex che blocca "http://internal" manca "http://%69nternal" se il server decodifica dopo il controllo regex. L'SQL injection tramite parametri URL non è un problema di URL-encoding di per sé ma è esacerbato quando apici singoli e altri meta-caratteri SQL sopravvivono fino alla query del database. La raccomandazione OWASP dai primi anni 2000 è stata: codifica al confine in entrata, decodifica al confine in uscita, non mischiare mai forme codificate e decodificate nello stesso buffer. Questo strumento fa esattamente il passo encode/decode, cosa fai con il risultato dipende da te e la responsabilità di sicurezza è al livello applicativo.

Doppia codifica, il bug più comune

La doppia codifica avviene quando una stringa già codificata viene codificata di nuovo. Il carattere spazio in un URL già codificato è %20; codificalo di nuovo e ottieni %2520 (perché % si codifica in %25). Quando il ricevente decodifica una volta, ottiene %20 indietro invece di uno spazio. Quando decodifica due volte (nei rari casi in cui la doppia decodifica è supportata), ottiene lo spazio, ma la maggior parte dei parser non lo fa, e l'URL contiene silenziosamente %20 visibile nella barra degli indirizzi. La correzione è sempre: decodifica prima se non sai se l'input è già codificato, poi codifica esattamente una volta. Lo stesso schema si applica nel codice, non chiamare mai encodeURIComponent due volte sulla stessa stringa. Se devi fare round-trip di un valore, decodifica la codifica precedente prima di ricodificare per il nuovo contesto. Il pulsante Swap di questo strumento aiuta con il ciclo diagnostico: incolla un URL sospetto, clicca Decodifica per vedere cosa c'è dentro, clicca Swap, clicca Codifica per ottenere di nuovo la forma codificata canonica.

Privacy: esecuzione solo nel browser

Gli URL incorporano frequentemente dati sensibili, token di autenticazione nei parametri di query, identificatori utente nei segmenti di percorso, query di ricerca contenenti contesto personale, valori state OAuth, URL di webhook che includono chiavi API. Gli URL-encoder lato server prendono una copia di ogni URL che incolli nei loro log. Questo strumento usa le funzioni integrate di JavaScript encodeURIComponent, encodeURI, decodeURIComponent e decodeURI in esecuzione localmente nella tua scheda del browser. Nessun upload, nessuna telemetria, nessun log, verifica nel pannello Network di DevTools mentre clicchi Codifica (nessuna richiesta parte) o metti la pagina offline (modalità aereo) dopo il caricamento e l'encoder continua a funzionare. Sicuro per URL contenenti token, chiavi API, endpoint interni o qualsiasi URL che non vorresti vedere copiato sul disco rigido di uno sconosciuto.

Domande frequenti

Quando dovrei codificare il testo in URL?

Dovresti codificare in URL il testo ogni volta che includi input dell'utente in un URL, per esempio, query di ricerca in una stringa di query, nomi di file in un percorso o dati nei parametri di richiesta API. Senza codifica, i caratteri speciali possono rompere la struttura dell'URL o introdurre vulnerabilità di sicurezza.

Cos'è la doppia codifica e come posso evitarla?

La doppia codifica si verifica quando un testo già codificato viene codificato di nuovo, trasformando %20 in %2520. Questo di solito si verifica quando il codice codifica una stringa che era già codificata. Decodifica sempre prima se non sei sicuro se il testo sia già codificato, poi codifica una volta.

Questo strumento è sicuro per URL sensibili?

Sì. Questo strumento viene eseguito interamente nel tuo browser utilizzando le funzioni di codifica integrate di JavaScript. Nessun dato viene inviato a nessun server. Puoi verificarlo disconnettendoti da Internet, lo strumento continuerà a funzionare.

Perché i miei dati di form hanno il segno più invece di %20?

Le sottomissioni di form HTML usano una codifica separata ma correlata chiamata application/x-www-form-urlencoded, che codifica gli spazi come + invece che %20 come convenzione storica. Entrambe le forme sono valide nelle query string degli URL; i parser moderni accettano entrambe. L'API URLSearchParams di JavaScript usa la convenzione form-encoded; encodeURIComponent usa sempre %20. Se i tuoi dati devono interoperare con vecchio codice di gestione form, usa URLSearchParams; se va da qualche altra parte, qualsiasi forma funziona.

E i caratteri non ASCII e gli emoji?

L'URL-encoding moderno usa UTF-8: ogni carattere non ASCII viene convertito nella sua rappresentazione UTF-8 multi-byte, poi ogni byte viene percent-encoded. Il segno dell'euro (€, tre byte UTF-8) diventa %E2%82%AC; un emoji come il razzo 🚀 (quattro byte) diventa %F0%9F%9A%80. RFC 3987 (IRI) e il WHATWG URL Standard formalizzano entrambi questa convenzione UTF-8-first. I sistemi più vecchi a volte usavano Latin-1 o altre codifiche; se stai decodificando URL antichi e il risultato sembra confuso, la sorgente potrebbe aver usato una codifica di caratteri diversa prima del percent-encoding.