URL Errori di codifica che gli sviluppatori continuano a commettere (e correzioni)

Q: Perché + diventa uno spazio negli URL?

Si tratta di un'eredità della codifica dei moduli HTML (application/x-www-form-urlencoded), dove gli spazi sono codificati come +. Nella codifica percentuale standard (RFC 3986), gli spazi sono %20. La convenzione + si applica solo alle stringhe di query negli invii dei moduli, non ai segmenti di percorso o ad altre parti dell'URL.

Q: Come posso codificare correttamente gli URL nidificati?

Utilizza encodeURIComponent sull'URL interno prima di inserirlo nel parametro di query dell'URL esterno. Questo codifica caratteri come :/? che altrimenti verrebbe interpretato come parte della struttura dell'URL esterno.

Q: Perché le firme si interrompono dopo la codifica dell'URL?

Le firme vengono calcolate su sequenze di byte esatte. Se si firma una stringa prima della codifica (o dopo la decodifica), ma la si verifica in forma codificata (o viceversa), i byte differiscono e la firma fallisce. Normalizza sempre la codifica prima di firmare.

__Strumenti per sviluppatori29 marzo 2026·7 minuti di lettura

I bug di codifica di

URL sono subdoli, persistenti e spesso scoperti in produzione. Un %20 fuori posto, una e commerciale con doppia codifica o un + confuso rispetto allo spazio possono interrompere le chiamate API, corrompere i dati di tracciamento e creare vulnerabilità di sicurezza. Risolviamo quelli più comuni.

Testa la tua codifica con il nostro strumento URL Codificatore/Decodificatore: incolla qualsiasi stringa e visualizza immediatamente il risultato codificato.

encodeURI vs encodeURIComponent

JavaScript ha due funzioni di codifica integrate e l'utilizzo di quella sbagliata è la principale fonte di bug:

FunzioneCodiciConservaUtilizzo percodificaURISpazi, non ASCII: / ? #[]@! $ & ' ( ) * + , ; =Codifica di un URL completoencodeURIComponentTutto sopra + : / ? #@! $ & ' ( ) * + , ; =Solo - _ . ~ e caratteri alfanumericiCodifica del valore di un parametro di query

// SBAGLIATO: la codifica URI preserva & nei valori della query
const url = 'https://api.example.com/search?q=' + encodeURI('tom & jerry');
// Risultato: https://api.example.com/search?q=tom%20&%20jerry
// Il & viene conservato: ora sembra un parametro separato! // CORRETTO
const url = 'https://api.example.com/search?q=' + encodeURIComponent('tom & jerry');
// Risultato: https://api.example.com/search?q=tom%20%26%20jerry
Regola pratica: Utilizzare encodeURIComponent per i singoli valori. Utilizza encodeURI solo quando disponi di un URL completo che richiede solo la codifica di caratteri non ASCII.
Bug della doppia codifica
La doppia codifica avviene quando una stringa già codificata viene nuovamente codificata:
const nome = 'ciao mondo';
const codificato = codificaURIComponent(nome); // ciao%20mondo
const raddoppiato = encodeURIComponent(codificato); // ciao%2520mondo
// %25 è la codifica di % stesso!
Ciò si verifica in genere quando:
Un framework codifica automaticamente i parametri di query e anche tu li precodifichi
Un URL viene codificato prima di essere archiviato, quindi codificato nuovamente una volta recuperato
Il Middleware elabora l'URL su più livelli, ciascuno aggiungendo la codifica
Rilevamento
Cerca %25 negli URL: è quasi sempre un segno di doppia codifica. La sequenza %2520 (spazio a doppia codifica) è la classica spia.
La confusione + vs %20
Negli invii di moduli HTML (application/x-www-form-urlencoded), gli spazi diventano +. Nella codifica percentuale standard (RFC 3986), gli spazi diventano %20.
Questo è importante perché:
decodeURIComponent fa not decodifica + torna nello spazio: lo lascia letterale +
I framework backend possono o meno decodificare automaticamente + a seconda del parser
Se la tua API prevede %20 ma riceve +, le ricerche per "red+car" restituiscono risultati per "red+car" (con un più letterale) invece di "red car"
// Decodifica sicura che gestisce sia + che %20
funzione safeDecodeParam(valore) { return decodeURIComponent(value.replace(/\+/g, '%20'));
}
Custodie Edge UTF-8
Caratteri non ASCII come é, ü, 日本語 e le emoji devono essere codificate in percentuale come byte UTF-8 sequenze:
encodeURIComponent('café') // caf%C3%A9
codificaURIComponent('日本語') // %E6%97%A5%E6%9C%AC%E8%AA%9E
codificaURIComponent('🔒') // %F0%9F%94%92
I problemi sorgono quando:
Il server si aspetta Latin-1 ma riceve UTF-8 (mojibake - caratteri confusi)
Le colonne del database non sono impostate su UTF-8, troncando automaticamente i caratteri multibyte
I file di registro interpretano stringhe codificate con set di caratteri errato
Insidie degli URL di reindirizzamento e richiamata
I callback OAuth e gli URL di reindirizzamento sono particolarmente inclini a codificare bug:
// Creazione di un reindirizzamento OAuth
const reindirizzamentoUri = 'https://myapp.com/callback?source=oauth';
constauthUrl = `https://provider.com/auth?redirect_uri=${encodeURIComponent(redirectUri)}`;
// Corretto: l'intero URL di callback (incluso il proprio ?) è codificato come un singolo parametro value
Errori comuni:
Non codifica affatto redirect_uri: ? nel callback divide l'URL principale
Codifica parzialmente redirect_uri: codifica il percorso ma non la query
Codifica dell'intero URL di autenticazione anziché solo del valore del parametro
Questi bug creano spesso vulnerabilità di reindirizzamento aperte che gli aggressori sfruttano per il phishing.
Elenco di controllo del debug
Quando un URL non funziona come previsto, controlla questi in ordine:
Cerca %25 — indica doppia codifica
Controlla + vs %20 — gli spazi vengono gestiti in modo coerente?
__Ispeziona la richiesta non elaborata: utilizza la scheda Rete di DevTools del browser per vedere l'URL codificato effettivo inviato
__Test con caratteri speciali — prova & = ? # / in valori per vedere se interrompono la struttura dell'URL
Controlla Content-Type: il server esegue l'analisi come application/x-www-form-urlencoded o application/json?
__Verifica la decodifica sul server: registra i valori grezzi e decodificati sul lato server
Funzioni di supporto sicure
// Crea una stringa di query in modo sicuro
funzione buildQueryString(parametri) { return Object.entries(parametri) .map(([chiave, valore]) => `${encodeURIComponent(key)}=${encodeURIComponent(value)}` ) .join('&');
} // Utilizza URLSearchParams (browser moderni + Node.js)
const params = nuovo URLSearchParams({ q: 'tom & jerry', page: '1' });
URL const = `https://api.example.com/search?${params}`;
// Corretto: gestisce la codifica automaticamente
Best practice: Utilizzare il costruttore URLSearchParams o URL invece della concatenazione manuale di stringhe. Gestiscono la codifica correttamente per impostazione predefinita.
FAQ
Perché + diventa uno spazio?
Questa è un'eredità della codifica dei moduli HTML (application/x-www-form-urlencoded), dove gli spazi sono codificati come +. Nella codifica percentuale standard (RFC 3986), gli spazi sono %20. La convenzione + si applica solo alle stringhe di query negli invii di moduli, non ai segmenti di percorso o ad altre parti di URL.
Come faccio a codificare correttamente gli URL nidificati?
Utilizza encodeURIComponent sull'URL interno prima di inserirlo nel parametro di query dell'URL esterno. Questo codifica caratteri come :/? che verrebbero altrimenti interpretati come parte della struttura dell'URL esterno.
Perché le firme si interrompono dopo la codifica dell'URL?
Le firme vengono calcolate su sequenze di byte esatte. Se si firma una stringa prima della codifica (o dopo la decodifica), ma la si verifica in forma codificata (o viceversa), i byte differiscono e la firma fallisce. Normalizza sempre la codifica prima di firmare.
Strumenti e articoli correlati
URL Codificatore/Decodificatore: prova la codifica in tempo reale
__JWT Security Errori: la codifica è importante anche per la gestione dei token
Correzione mancata corrispondenza checksum: quando la codifica modifica gli hash dei file corrotti