Skip to main content

Codifica o decodifica stringhe URL.

Tutti i calcoli sono eseguiti localmente nel tuo browser. Nessun dato viene inviato al server.

I risultati hanno carattere informativo. Verificali con altre fonti.

Una frase polacca di 17 caratteri ne diventa 66 dentro un URL

La codifica percentuale lavora sui byte, non sui caratteri, e UTF-8 spende più di un byte per tutto ciò che sta fuori dall'ASCII. Ogni byte diventa tre caratteri, quindi il testo accentato si gonfia violentemente: zażółć gęślą jaźń è 17 caratteri, 26 byte e 66 caratteri una volta codificato — un fattore 3,88.

Come funziona

  • Codifica il testo in percentuale per un uso sicuro negli URL e lo decodifica.
  • Codifica prima in UTF-8, ed è da lì che viene l'espansione di dimensione.
  • Distingue la codifica di un URL intero da quella di un singolo componente: compiti diversi con insiemi sicuri diversi.
ogni byte non sicuro → % seguito da due cifre esadecimali

byte in UTF-8:
  ASCII        1 byte  → 1 carattere non codificato
  ł, ü         2 byte  → 6 caratteri   (%C5%82)
  €, 日        3 byte  → 9 caratteri   (%E2%82%AC)
  emoji        4 byte  → 12 caratteri  (%F0%9F%98%80)

71 dei 95 caratteri ASCII stampabili passano intatti

Esempio pratico

Gli stessi caratteri codificati e poi il classico guasto da doppia codifica.

  1. a → a (1 carattere, invariato)
  2. ł → %C5%82 (6 caratteri)
  3. 😀 → %F0%9F%98%80 (12 caratteri)
  4. "a b" → "a%20b"
  5. codificato di nuovo → "a%2520b"

La seconda codifica trasforma il % di %20 in %25 e produce %2520. Decodificare una volta restituisce a%20b, non a b: la stringa sembra decodificata ed è ancora sbagliata, ed è per questo che i bug da doppia codifica sopravvivono a lungo prima che qualcuno se ne accorga.

Come leggere il risultato

  • Lo spazio è %20 in un percorso e + nei dati di query codificati come form, e i due non sono intercambiabili. Decodificare un + come un più letterale dove si intendeva uno spazio, o viceversa, è il secondo bug di codifica più comune dopo la doppia codifica.
  • Codifica i componenti, non gli URL interi. Far passare un URL completo per la codifica di componente distrugge il :// e i separatori; far passare un componente per la codifica dell'URL completo lascia & e = intatti, il che consente all'input dell'utente di iniettare parametri aggiuntivi.
  • All'espansione sono attaccati limiti pratici. Server e proxy tagliano spesso gli URL intorno ai 2.000 caratteri, quindi una stringa di query che porta testo accentato tocca quel tetto molto prima di quanto suggerisca il conteggio dei caratteri.
  • Codificare non è fare escaping per altri contesti. Una stringa codificata in percentuale è sicura in un URL e non dice nulla sulla sicurezza in HTML, SQL o in una shell: ogni destinazione richiede la propria codifica, applicata nel punto d'uso.

Domande frequenti

Perché il mio testo è diventato %2520?
È stato codificato due volte. Il primo passaggio ha trasformato uno spazio in %20; il secondo ha visto il % come un carattere ordinario e l'ha codificato come %25, lasciando %2520. Decodifica due volte per recuperare l'originale, poi correggi lo strato che codifica in eccesso.
Lo spazio va scritto %20 o +?
%20 ovunque tranne nelle stringhe di query codificate come form, dove + è la convenzione storica ed è ancora ampiamente prodotta. In quel contesto entrambi si decodificano come spazio, ma solo %20 è corretto in un segmento di percorso.