Strumenti per sviluppatori · URL codificatore e decodificatore
RFC 3986 caratteri riservati e non riservati: cosa dice lo standard URI
· Sfondo
codifica dell'URL rfc3986 codifica percentuale
RFC 3986 divide i caratteri in riservati, non riservati e tutto il resto, e questa suddivisione spiega ogni regola di codifica percentuale che hai soddisfatto. Questo post legge chiaramente le sezioni pertinenti.
RFC 3986 caratteri riservati e non riservati: cosa conta quando crei URL
RFC 3986 divide i caratteri in tre categorie: non riservati, riservati e tutto il resto che deve essere codificato. I caratteri non riservati non necessitano mai di codifica: si tratta di lettere, cifre, trattini, punti, trattini bassi e tilde. RFC li elenca esplicitamente nella sezione 2.3, affermando che è sicuro lasciarli non codificati in qualsiasi contesto URI. I test nel codificatore e decodificatore URL con questi caratteri mostrano che passano invariati. I caratteri riservati si suddividono in gen-delim (: / ? # [ ] @) e sub-delim (! $ & ' ( ) * + , ; =), ciascuno con significato strutturale in diversi componenti URL.
Quando è necessario codificare un carattere? I caratteri riservati devono essere codificati in percentuale solo laddove creano ambiguità. Una barra contrassegna i segmenti del percorso; in un valore di query deve essere %2F. Una e commerciale separa i parametri; & in un valore richiede %26. I caratteri non riservati non necessitano mai di codifica: un trattino rimane un trattino. Lo standard URL garantisce un'analisi corretta. Test con codificatore e decodificatore URL: inserendo "hello/world" con encodeURIComponent si produce "hello%2Fworld"; con encodeURI preserva la barra.
Senza riserva: lettere, cifre, trattino, punto, carattere di sottolineatura e tilde: i caratteri che non necessitano mai di codifica e non dovrebbero mai essere codificati
La codifica percentuale utilizza %HH dove HH è la notazione esadecimale. ASCII la lettera A (codice 65) diventa %41. Non-ASCII é richiede la codifica UTF-8: é (U+00E9) diventa %C3%A9. Gli standard moderni specificano UTF-8 in modo uniforme su tutti i browser.
Gli URL completi necessitano di una sintassi strutturale intatta; i valori delle query necessitano di caratteri riservati interni innocui. Il parametro di query ?q=R&D deve codificare & come %26 se manuale, altrimenti la e commerciale diventa il separatore. I valori con barre diventano %2F in modalità componente. La codifica del componente (encodeURIComponent) gestisce questa operazione codificando tutto tranne lettere, cifre e - _ non riservate. ! ~ * '( ). I test mostrano chiaramente la differenza tra i metodi.
Riservato: gen-delim e sub-delim: i due gruppi, i loro membri e i loro ruoli strutturali
Le stringhe di query dimostrano perché i caratteri riservati sono importanti. La e commerciale separa le coppie chiave=valore: ?utm_source=email&utm_campaign=sale indica due parametri. All'interno di un valore, la e commerciale senza caratteri di escape termina la coppia. Uguale separa le chiavi dai valori. L'analisi avviene su più livelli; ognuno applica le stesse regole.
I caratteri che richiedono la codifica nei valori della query includono la e commerciale, l'uguale, il cancelletto, il punto interrogativo, gli spazi e le lettere nonASCII. L'hash è il più subdolo: #qualsiasi cosa diventa identificatore di frammento, mai inviato al server. I nomi delle campagne che terminano con hash perdono tutto ciò che segue prima che la richiesta lasci il browser. Gli spazi devono diventare %20. I test con il codificatore e decodificatore URL mostrano le modalità del componente e del modulo. La comprensione della posizione determina la necessità di codifica.
Quando i caratteri riservati devono essere codificati, solo dove verrebbero scambiati per un delimitatore, componente per componente
La codifica percentuale persiste in RFC 3986. Il set senza prenotazione rimane piccolo garantendo la portabilità. I caratteri non riservati con codifica percentuale possono essere decodificati senza modifiche di significato. La decodifica di %41 in A è corretta perché A non è prenotato. La decodifica di %2F in / cambia significato quando la barra è dati, non separatore. RFC 3986 sezione di normalizzazione 6 copre gli approcci sintattici.
I personaggi riservati in posizioni diverse hanno ruoli diversi. I due punti nello schema indicano lo schema: confine dell'autorità; i due punti in userinfo sono dati. Il punto interrogativo apre la sezione delle query; La barra nel valore della query è letterale. L'hash contrassegna l'inizio del frammento. La posizione determina la necessità di codifica. Le stringhe di query trasportano valori che sono essi stessi URI. La codifica di un reindirizzamento URL come https://example.com/page?param=value come parametro richiede la codifica di barre e due punti in %2F e %3A. Il contesto definisce sempre i caratteri sicuri.
Esempio pratico: classificare ogni carattere di un URL reale: non riservato, riservato come delimitatore, riservato come dati
RFC 1738 (1994) ha considerato molti caratteri non sicuri. Poiché le distribuzioni sono state standardizzate su UTF-8, gli standard successivi hanno allentato le restrizioni. La tilde (~) esemplifica l'evoluzione: RFC 1738 richiesto %7E, RFC 2396 (1998) ha spostato la tilde su non riservato, RFC 3986 confermato stato non riservato. L’evoluzione riflette le lezioni di implementazione. Gli standard preservano la compatibilità con le versioni precedenti.
La normalizzazione RFC consente la decodifica di caratteri non riservati con codifica percentuale inutilmente. %41 normalizza in modo sicuro in A. I caratteri riservati codificati come %2F non vengono mai decodificati; il cambiamento del significato rompe la struttura. Il consenso moderno utilizza RFC 3986 come base di riferimento. Il codificatore e decodificatore URL segue RFC 3986 ovunque, offrendo riferimenti fissi separati dal comportamento del browser. WHATWG URL Standard aggiunge set di codifica specifici del componente oltre RFC. Coesistono standard: RFC 3986 per l'analisi generale URL, WHATWG per i browser Web. Le biblioteche differiscono; controllare la documentazione.
Linee guida sulla normalizzazione nella sezione 6: caso esadecimale, decodifica senza riserve e regole del segmento di percorso
I test con RFC 3986 garantiscono che gli URL funzionino su software nell'arco di decenni. Il codificatore e decodificatore URL fornisce la linea di base della codifica RFC 3986 da applicare ai componenti costruiti. Leggi la documentazione standard che spiega ogni decisione di codifica nelle librerie URL. WHATWG URL si basa su RFC 3986 anziché sostituirlo completamente. Creare URL per browser generici? Segui RFC 3986; i browser applicano le regole WHATWG in alto. Sistemi più vecchi? Testare le implementazioni effettive. Normalizzazione per l'archiviazione? Applica RFC 3986 in modo coerente. Comprendere la distinzione riservato/unreserved ti dice che i caratteri sono sicuri.
La codifica URL non è una sanificazione della sicurezza. Ogni contesto, SQL, HTML, JavaScript, URI, necessita della propria codifica di output. La codifica percentuale protegge solo la struttura URL. Applica la difesa giusta al livello giusto.
Cosa non copre: i diversi set di codifica dello standard WHATWG URL e la gestione di IRI
RFC 2396 (1998) ha chiarito i set di caratteri in modo più rigoroso rispetto a RFC 1738. Ha formalizzato i caratteri riservati che servono la struttura URI e non riservati come dati letterali. Espansione senza riserve che include trattino, punto, carattere di sottolineatura e tilde sulle definizioni originali. RFC 2396 introdotta la distinzione tra gen-delim (:, /, ?, #, [, ], @) e sub-delim (!, $, &, ', (, ), *, +, ,, ;, =). Ogni gruppo ha ruoli strutturali diversi negli URL. La denominazione chiarisce la divisione dei caratteri riservati in due gruppi. Conoscere i nomi aiuta le discussioni tecniche.
RFC 3986 (2005) è un riferimento moderno. Ha mantenuto la distinzione riservato/unreserved ma la notazione semplificata. Gli organismi di normalizzazione non interrompono retroattivamente il web. Codifica deliberatamente conoscendo il tuo standard. Il codificatore e decodificatore URL fornisce il riferimento RFC 3986.
Conclusione: lo standard è breve e preciso: in che modo le due modalità del codificatore e decodificatore URL corrispondono alla codifica dei dati rispetto alla conservazione dei delimitatori
La scelta degli standard dipende dal contesto. Creare URL per browser generici? Segui RFC 3986; i browser applicano le regole WHATWG. Sistemi più vecchi? Testare le implementazioni effettive. Normalizzazione per l'archiviazione? Applica RFC 3986 in modo coerente. Le regole di codifica percentuale si sono evolute dal conservatore RFC 1738 attraverso il chiarimento RFC 2396 e RFC 3986 allo standard a più livelli WHATWG URL Standard. Ogni generazione rifletteva l'esperienza. I costruttori moderni seguono RFC 3986 o WHATWG contestualmente. URL vecchi e nuovi coesistono e richiedono un approccio compatibile. Comprendere le categorie previene errori di codifica.
Verificare che gli URL vengano codificati correttamente prima della distribuzione. Il codificatore e decodificatore URL dimostra le regole di RFC 3986 end-to-end. Visualizza i valori esadecimali esatti e capisci quali caratteri codificano. Utilizza questo strumento quando crei URL concatenando pezzi. RFC 3986 categorie riservate e non riservate set di caratteri di partizione per un'analisi URI coerente.