Strumenti per sviluppatori · URL codificatore e decodificatore
Da RFC 1738 allo standard URL: come si sono evolute le regole di codifica percentuale
· Sfondo
codifica dell'URL rfc-storia standard web
Le regole per i caratteri di escape negli URL sono state riscritte più volte da 1994. Questo post segue RFC 1738, RFC 2396, RFC 3986 e lo standard WHATWG URL e spiega cosa cambia ogni volta.
Da RFC 1738 allo standard URL: come si sono evolute le regole di codifica percentuale
La tilde (~) esemplifica il modo in cui le regole di codifica cambiano attraverso le generazioni e le distribuzioni degli standard. RFC 1738 (1994) richiesto %7E ovunque; RFC 2396 (1998) ha spostato la tilde su non riservato consentendo la non codificata. RFC 3986 (2005) ha confermato lo stato senza prenotazione. I vecchi URL con %7E rimangono validi; output dei nuovi costruttori ~. L'evoluzione riflette le lezioni di implementazione man mano che il web matura e l'infrastruttura standardizzata. RFC 1738 era conservativo perché le prime infrastrutture erano eterogenee e varie.
RFC 1738 ha codificato il comportamento del browser 1994. Distribuzioni standardizzate su UTF-8; le restrizioni si sono rivelate inutili. Gli standard successivi hanno allentato le restrizioni sui caratteri. RFC 3986 consente la decodifica sicura di caratteri non riservati.
RFC 1738 (1994): personaggi "non sicuri" e le prime regole di fuga: cosa era considerato pericoloso e perché
RFC 1738 ha definito i caratteri "non sicuri" come quelli in conflitto con la sintassi URI (spazio, barra), storicamente utilizzati nei protocolli (caratteri di controllo) o che i sistemi non potevano trasmettere in modo sicuro. Elenco conservatore codificato in percentuale molto più del necessario per Internet moderno. Molti dei primi sistemi erano antecedenti a RFC; ha codificato il loro comportamento. I caratteri di controllo erano veramente pericolosi nei protocolli; gli spazi erano problemi di trasmissione per i client HTTP che leggevano dalle righe di comando. I sistemi moderni gestiscono questi casi in modo più elegante attraverso la codifica esplicita.
I test con RFC 1738 rivelano cosa si aspettavano i vecchi sistemi. Codifica un carattere dalla specifica URL degli anni '90 e confrontalo con il moderno RFC 3986. Le differenze mostrano cosa si è rilassato. Set non prenotato ampliato nel tempo. Trattino, punto e carattere di sottolineatura erano sempre sicuri. Tilde aveva bisogno di RFC 2396 per diventare sicura. L’approccio conservatore significava compatibilità con le versioni precedenti. I vecchi URL creati secondo le regole RFC 1738 rimangono validi oggi. La normalizzazione nella sezione RFC 3986 sezione 6 consente di decodificare in modo sicuro i caratteri non riservati con codifica percentuale inutilmente.
RFC 2396 (1998) — riservato e non riservato, sintassi generica e tilde riabilitata
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 rispetto a quelli non riservati come dati letterali. Espansione senza riserva comprendente trattino, punto, carattere di sottolineatura e tilde. Riconosceva la sintassi generica URI separata dalle regole specifiche dello schema. RFC 2396 introdotta la distinzione tra gen-delim (:, /, ?, #, [, ], @) e sub-delim (!, $, &, ', (, ), *, +, ,, ;, =). La denominazione chiarisce la divisione dei caratteri riservati in due gruppi con ruoli strutturali diversi.
RFC 2396 ha introdotto le linee guida sulla normalizzazione che specificano quali caratteri con codifica percentuale potrebbero essere decodificati senza modifiche di significato. La decodifica dei caratteri senza riserve viene normalizzata. Stick di codifica dei caratteri riservati. RFC 3986 notazione ulteriormente semplificata. Gli standard mantengono fermamente la compatibilità con le versioni precedenti.
RFC 3986 (2005) — ! * ' ( ) passa ai sub-delim, i gen-delim vengono nominati e arriva la guida alla normalizzazione
RFC 3986 (2005) è il moderno standard di riferimento per la codifica percentuale. Ha mantenuto la distinzione riservato/unreserved ma ha semplificato la notazione e ha aggiunto indicazioni sulla normalizzazione. Tilde si mosse senza ambiguità e senza riserve. I caratteri non riservati con codifica percentuale standard chiarita possono essere decodificati senza modifiche di significato. La sezione RFC 3986 3 descrive la sintassi di URI con precisione. La sezione 2 definisce le categorie di caratteri. La sezione 6 dedica regole formali alla normalizzazione sintattica. La normalizzazione basata sul confronto considera gli URI identici se i moduli normalizzati corrispondono. La rimozione dei segmenti di punto dai percorsi si normalizza senza alcun cambiamento significativo.
La normalizzazione è importante per l'analisi, la memorizzazione nella cache, il seguito dei collegamenti. Gli URL che differiscono solo per le lettere esadecimali (RFC 3986 preferisce le maiuscole) dovrebbero essere identici nella pratica. La normalizzazione impedisce voci di registro duplicate e errori di cache. Le cache digitate su URL normalizzati forniscono contenuto indipendentemente dalla preferenza di codifica del richiedente. La guida alla normalizzazione RFC 3986 consente ai sistemi di prendere decisioni coerenti. Ma un'applicazione rigorosa impedisce agli URL di funzionare correttamente nell'attuale Internet.
Lo standard WHATWG URL: analisi di ciò che i browser ricevono effettivamente: set di codifica, schemi speciali e tolleranza agli errori
WHATWG URL Standard (2016–presente) è emerso dall'esperienza del browser con URL che non seguono perfettamente RFC 3986. I browser hanno dovuto affrontare spazi non codificati, codifiche miste e stranezze. WHATWG descrive l'analisi reale del browser, non la grammatica teorica. I browser del mondo reale avevano sviluppato regole pratiche per tollerare gli spazi, gestire i caratteri di escape e recuperare da input errati. RFC 3986 è arrivato in 2005 e ha definito la grammatica formale, ma i browser nella pratica si erano già leggermente discostati.
WHATWG definisce nove set di codifica con regole specifiche del contesto. Lo spazio nel percorso diventa %20; La barra nelle informazioni utente diventa %2F. Il browser applica uno standard più ristretto per il Web. RFC 3986 fornisce la linea di base; WHATWG si basa su di esso.
Esempio realizzato: un URL con una tilde, uno spazio e un carattere nonASCII: come ogni generazione di regole lo codifica
I domini internazionalizzati utilizzano la codifica punycode (München diventa xn--mnchen-3ya). Percorsi e query utilizzano ancora la codifica percentuale. La parte del dominio utilizza punycode; le parti del percorso e della query utilizzano la codifica percentuale. Gli strati non si mescolano né interferiscono.
IDNA (Nomi di dominio internazionalizzati nelle applicazioni) risolve il problema del nome host. Punycode codifica nonASCII in ASCII per la compatibilità con DNS. Il prefisso xn-- segnala la codifica punycode. L'algoritmo è deterministico: münchen diventa sempre xn--mnchen-3ya. I caratteri diversi da ASCII devono essere convertiti prima della risoluzione DNS. La codifica percentuale non funziona per i nomi host a causa dei vincoli DNS e dei limiti delle etichette. Ciascun approccio risolve correttamente problemi diversi. Gli standard si sono evoluti separatamente per buone ragioni.
Ciò che questo non copre sono gli IRI e i nomi di dominio internazionalizzati, che hanno una loro storia
La scelta degli standard dipende dal contesto. Creare URL per i browser? Segui RFC 3986; i browser applicano WHATWG. Sistemi più vecchi? Testare le implementazioni. Comprendere l’evoluzione previene la confusione.
I costruttori moderni dovrebbero seguire RFC 3986 o WHATWG contestualmente. URL vecchi e nuovi coesistono e richiedono un'attenta valutazione della compatibilità. Il codificatore e decodificatore URL segue RFC 3986 ovunque, offrendo riferimenti fissi separati dal comportamento del browser. WHATWG aggiunge set di codifica specifici del componente oltre le basi di RFC. Sapere cosa è cambiato e quando aiuta a capire perché i sistemi non sono d’accordo. Testare il tuo URL con entrambi gli standard rivela quali controlli standard sono presenti nel tuo ambiente. Entrambi gli standard sono corretti.
Conclusione: scopri quale regolamento segue il tuo codice: in che modo il codificatore e decodificatore URL ti offre il comportamento RFC 3986 come punto di riferimento fisso
La normalizzazione RFC 3986 consente di decodificare in modo sicuro i caratteri non riservati con codifica percentuale inutilmente. %41 normalizza in A. I caratteri riservati codificati come %2F non vengono mai decodificati; il cambiamento del significato rompe la struttura. Gli organismi di standardizzazione mantengono fermamente la compatibilità con le versioni precedenti. La risoluzione richiederebbe un coordinamento mondiale impossibile dopo decenni. I libri sugli standard non interrompono retroattivamente il web. La modifica delle decisioni di codifica distrugge simultaneamente miliardi di sistemi esistenti.
La codifica percentuale abbraccia tre decenni di attenta evoluzione: da RFC 1738 attraverso RFC 2396 e RFC 3986 fino al moderno WHATWG URL Standard. Il codice moderno dovrebbe seguire la linea di base RFC 3986. I vecchi URL con codifica precedente rimangono validi. Il test dei viaggi di andata e ritorno garantisce la correttezza e la compatibilità.