Strumenti per sviluppatori · URL codificatore e decodificatore
URIErrore: URI malformato: perché decodificaURIComponent genera e come risolverlo
· Come funziona
codifica dell'URL javascript gestione degli errori
decodeURIComponent genera un'eccezione quando un segno di percentuale non è seguito da due cifre esadecimali o quando i byte decodificati non sono validi UTF-8. Questo post mostra gli input che lo attivano e come decodificarlo in modo difensivo.
Il segno di percentuale che si è bloccato: perché "100% off" interrompe decodeURIComponent
Un modulo raccoglie il codice sconto "100% di sconto". JavaScript lo passa al decodificatoreURIComponent in un decoder URL. La funzione genera URIError: URI non valido. Il segno di percentuale non è seguito da due cifre esadecimali. Ciò viola completamente le regole di codifica percentuale. decodeURIComponent si aspetta che ogni % inizi una tripletta come %20 o %C3. Un % solitario è un errore di sintassi che interrompe immediatamente l'esecuzione e genera un errore.
Rilevare questo errore in modo sicuro previene completamente l'arresto anomalo dell'applicazione. Gli URL arrivano dall'input dell'utente, reindirizzamenti, codici QR ed e-mail. Gli errori di battitura si verificano frequentemente. Un rapporto di arresto anomalo con URIError ti dice dove indagare rapidamente. La decodifica difensiva mantiene le applicazioni in esecuzione e i log degli errori diventano utili per il debug.
Due tipi di errore: escape esadecimali non validi e sequenze di byte UTF-8 non valide
decodeURIComponent genera esattamente due situazioni. Primo: sequenza di escape non valida. Una percentuale non seguita da due cifre esadecimali (0-9, A-F, a-f). Esempi: %ZZ, %2, %2g. Secondo: tripletta valida come %E9 decodifica in UTF-8 byte non validi. Il primo è l'errore di formato. Il secondo è l'errore semantico. Entrambi lanciano e interrompono immediatamente l'esecuzione.
UTF-8 ha regole rigide sulle sequenze di byte. I byte 0x80–0xFF vengono visualizzati solo nelle sequenze multibyte. Un singolo %E9 non può essere valido UTF-8 da solo. Questo byte orfano genera un errore. Gli errori di formato sono evidenti. Gli errori semantici sono sottili ma ugualmente reali. Entrambi i casi richiedono la gestione try/catch nel codice di produzione.
Codifica legacy a byte singolo: quando %E9 da solo genera un'eccezione ma %C3%A9 sopravvive
La confusione deriva dalla storia degli standard web. Le vecchie pagine utilizzavano il latino-1 invece di UTF-8. In latino-1, %E9 rappresentava é. I browser moderni utilizzano esclusivamente UTF-8. UTF-8 codifica é come %C3%A9. I decoder moderni si aspettano UTF-8 e rifiutano %E9 come non valido. Questo è un comportamento corretto. L'errore segnala un problema con i dati di origine.
Consenso moderno: UTF-8 ovunque. Lo standard URL specifica UTF-8. Tutti i browser attuali utilizzano UTF-8. Se riscontri %E9 da vecchi sistemi, rileva l'errore e fallback sulla stringa non elaborata. Non decodificare come Latin-1 nel codice moderno. Investigare da dove hanno avuto origine i dati.
Tre input, tre messaggi di errore: in che modo i motori differiscono sulla stessa stringa interrotta
I motori del browser rifiutano costantemente l'input non corretto, ma gli errori di parola in modo diverso. Chrome segnala "URI formato non valido". Firefox segnala "sequenza URI non valida". Safari segnala "impossibile convertire undefinito in oggetto". Tutti e tre i motori rifiutano input identici. Il testo esatto del messaggio non è standardizzato tra diversi motori o versioni. Non fare mai affidamento sul testo dell'errore per guidare la logica del codice.
Non effettuare mai una corrispondenza di stringa con un messaggio di errore per le decisioni del programma. Cattura sempre URIError per tipo. La funzione decodeUrl racchiude decodeURIComponent e fornisce codice coerente INVALID_PERCENT_ENCODING. Questo nomina l'esatta posizione del problema. Funziona in tutti i tempi di esecuzione perché non dipende dalle variazioni di formulazione del motore. Questo approccio è più affidabile e manutenibile.
Lettura sicura dell'eccezione: convalida try/catch, e modelli di fallback
Modello difensivo più semplice: avvolgi decodeURIComponent in try/catch. Se solleva un'eccezione, utilizza una stringa non elaborata o un carattere sostitutivo. Ciò impedisce l'arresto anomalo dell'input non valido. Per i valori della query, mostra il modulo con codifica URL. Per il testo rivolto all'utente, inserisci il carattere sostitutivo. Ciò impedisce agli input errati di interrompere le applicazioni e mantiene la stabilità.
Preconvalida con espressioni regolari per velocità e sicurezza. Verificare che l'input contenga solo triplette %XX valide prima della decodifica. Il modello /%[0-9A-Fa-f]{2}/g rileva escape validi; qualsiasi cosa senza corrispondenza non è valida. Gli errori di formato falliscono rapidamente in caso di spazzatura evidente. UTF-8 gli errori devono ancora essere provati/catch. Insieme, questo fornisce una protezione difensiva completa contro gli errori.
Gli errori silenziosi nascondono bug: perché la decodifica cieca è rischiosa quanto la codifica errata
Rischio sottile: il decoder non lancia ma produce silenziosamente il testo sbagliato. Il vecchio codice che utilizza unescape deprecato lascia UTF-8 non validi in memoria. Il testo appare correttamente sullo schermo finché non raggiunge i sistemi che convalidano rigorosamente UTF-8. Il codice moderno genera invece di corrompersi silenziosamente. Un’eccezione è più chiara e sicura della corruzione silenziosa dei dati che si diffonde a valle.
Supponiamo che l'input dell'utente non sia corretto. Avvolgi sempre le chiamate. Registra gli errori con l'input originale per il debug. Non dare mai per scontato che ogni% sia valido. Errori di battitura e troncamenti creano fughe incomplete. Trattarli come errori di dati, non come errori logici. Il codice difensivo sopravvive con grazia agli input errati e mantiene i sistemi affidabili.
Quali strumenti reali saltano: comportamento del framework lato server e ripristino degli errori
I framework server gestiscono la codifica non corretta con maggiore indulgenza rispetto ai browser. Ruby, Python e PHP offrono la configurazione per la gestione degli escape non validi negli URL. Alcuni sostituiscono automaticamente i caratteri sostitutivi. Altri rilasciano byte silenziosamente. Alcuni lanciano eccezioni come fa JavaScript. Il comportamento effettivo varia in base al framework e alle impostazioni di configurazione scelte dagli sviluppatori.
Questo articolo riguarda solo il comportamento JavaScript del browser. Se i valori arrivano dalle API del server, il server ha già decodificato o ignorato gli errori prima dell'invio. I server possono essere più indulgenti dei client. Quando si scrivono contratti API, specificare se i valori sono grezzi o pre-decodificati. Le stringhe di query URL dovrebbero arrivare con codifica percentuale; JSON può arrivare pre-decodificato.
Convalida anticipatamente: utilizzando il codificatore e decodificatore URL per controllare prima le stringhe sospette
Prima di passare URL sospetti a decodeURIComponent, incollali nel codificatore e decodificatore URL. Lo strumento mostra la codifica esatta, individua gli escape non validi e spiega gli errori senza arrestare in modo anomalo l'applicazione. Prova con %ZZ, %E9 e 100% per visualizzare diversi errori e i relativi messaggi di errore esatti. Questo richiede pochi secondi e crea fiducia.
Convalida tempestivamente, rileva gli errori con garbo e registra ciò che si è rotto. Il decodificatore difensivo e lo strumento di test mantengono le applicazioni in esecuzione e debuggabili. Il codificatore e decodificatore URL trasforma "URI formato non valido" in informazioni utilizzabili che puoi utilizzare immediatamente. Applica questo modello ai tuoi decodificatori per garantire resilienza e manutenibilità negli ambienti di produzione.