Strumenti per sviluppatori · URL codificatore e decodificatore
Plus contro %20: la storia dell'applicazione/x-www-form-urlencoded
· Sfondo
codifica dell'URL moduli html standard http
I moduli codificano uno spazio come + mentre lo standard URI dice %20 e il motivo è storico. Questo post ripercorre la convenzione dai primi moduli HTML all'odierna definizione WHATWG e spiega perché non è mai scomparsa.
Inoltre rispetto a %20: perché i moduli e gli URI codificano gli spazi in modo diverso
I moduli HTML inviati come GET codificano gli spazi come segni più nella stringa di query. Lo stesso spazio diventa %20 negli URL che seguono RFC 3986. Entrambi sono corretti perché seguono standard diversi. I campi del modulo contenenti spazi diventano nome=valore+con+spazi nella codifica del modulo ma %20 in RFC 3986. La distinzione più percentuale venti indica quale standard si applica ai tuoi dati.
La codifica del modulo utilizza il segno più per gli spazi come convenzione storica da RFC 1866 (1995), la definizione di invio del modulo originale di HTML 2.0. GET richiede spazi codificati come segni più, riservando più per il letterale + codificato come %2B. Questa regola si applicava solo alla sintassi application/x-www-form-urlencoded, e non alla sintassi generale URI. Miliardi di strutture di server sono diventate dipendenti da questa convenzione. Testare entrambi mostra chiare differenze: la modalità modulo produce più; La modalità URI produce %20. Il codificatore e decodificatore URL offre entrambe le modalità per il confronto diretto.
Primi moduli HTML e invio GET: come è stata definita la codifica del modulo e perché è stato scelto +
RFC 1866 (1995) invio di moduli definiti in cui gli spazi diventano più e il più letterale diventa %2B. Ciò si applicava solo a application/x-www-form-urlencoded. RFC 3986 specificato %20 per la sintassi generale URI. Due standard coesistevano deliberatamente.
RFC 2396 ha chiarito i set di caratteri in modo più rigoroso rispetto agli standard precedenti. Ha formalizzato i caratteri riservati che servono la struttura URI rispetto a quelli non riservati come dati letterali. Gli organismi di standardizzazione codificano il comportamento del browser e del proxy man mano che si evolve. RFC 3986 è arrivato successivamente senza modificare il comportamento di codifica, solo chiarendo la notazione. Tutti i browser attuali standardizzano la codifica UTF-8. I moduli HTML tramite i pulsanti di invio invia la domanda in formato/x-www-form-urlencoded con più per gli spazi. La costruzione manuale URI utilizza %20. Comprendere entrambi gli standard previene sorprese nell'integrazione.
Specifiche RFC 1866 e successive HTML: dove è stata scritta la regola e come differiva dalla sintassi URI
WHATWG URL Lo standard specifica che URLSearchParams.toString() produce l'output application/x-www-form-urlencoded con segni più per gli spazi. Codifica percentuale del costruttore URL che segue RFC 3986. Il browser che naviga verso URL con la codifica degli spazi %20; il modulo inviato come GET codifica plus. Questi strumenti fondamentalmente diversi servono a scopi diversi. Codifica manualeURIComponent fornisce %20 per gli spazi: stile RFC 3986. Moduli inviati allo stesso URL send plus. I server che analizzano gli invii dei moduli si aspettano plus; la ricezione di %20 provoca errori dei parametri silenziosi.
Il test di entrambi rivela i presupposti lato server da cui dipendi. JavaScript URLSearchParams fornisce la codifica sicura in stile modulo nascondendo più complessità. Costruisci URLSearchParams, aggiungi voci, chiama toString() per ottenere application/x-www-form-urlencoded con il plus corretto. In alternativa, crea stringhe di query con encodeURIComponent; ottieni RFC 3986 %20. Non mescolare mai gli approcci. Le stringhe di query con manual plus ed encodeURIComponent creano ambiguità. I ricevitori non possono distinguere se più significa spazio o più letterale. Gli approcci standard vengono gestiti in modo coerente.
Lo standard URL oggi: application/x-www-form-urlencoded come serializzatore separato con regole proprie
Le API JSON in genere rifiutano il segno più come spazio, prevedendo %20 per RFC 3986. I client che inviano plus falliscono silenziosamente: i parametri svaniscono. Il test delle API con entrambe le codifiche rivela quale standard accettano. URLSearchParams in JavaScript gestisce la codifica dei moduli. URL codificatore e decodificatore produce RFC 3986 %20.
L'invio del modulo HTML gestisce automaticamente la codifica. La struttura del tuo server decide quali regole applicare. Rails, Django, PHP trattano tutti il plus come spazio automaticamente nei dati del modulo ricevuto. Ma la creazione manuale di stringhe di query per gli stessi endpoint è estremamente importante. Un plus caricato crea ambiguità. La conformità alle specifiche e il comportamento del server nel mondo reale divergono leggermente. Documenta lo standard previsto dai tuoi endpoint. Prova entrambi gli stili di codifica. Il codice difensivo gestisce entrambi con garbo.
Esempio funzionale: lo stesso campo del modulo visto come stringa di query e come corpo della richiesta, con + in un posto e %20 in un altro
JavaScript URLSearchParams applica la codifica del modulo: lo spazio diventa più, non %20. il nuovo URLSearchParams({q: "hello world"}) produce "q=hello+world", non "q=hello%20world". Questa è la regola storica dell'applicazione/x-www-form-urlencoded incorporata specificatamente in JavaScript. Ma passando questa stringa come query non elaborata al nuovo URL mantiene più come più; solo URLSearchParams lo decodifica come spazio. Il costruttore è fedele a ciò che vede. La differenza del segno più causa bug comuni quando si mescolano le funzioni in modo errato.
Il costruttore URL e encodeURIComponent sono strumenti diversi. encodeURIComponent codifica quasi tutto tranne lettere, cifre e - _ non riservate. ! ~ * '( ). Non presuppone alcun contesto. Il costruttore URL analizza l'attuale URL e applica le regole WHATWG per componente. encodeURIComponent trasforma "hello/world" in "hello%2Fworld"; il nuovo URL vede le barre come separatori di percorso. Stesso input, output diverso. Utilizza encodeURIComponent durante la creazione di URL concatenando parti. Utilizza URLSearchParams o il costruttore URL per URL completi o parziali.
Perché non è possibile risolverlo: decenni di server e client che dipendono dal comportamento attuale
Le regole di codifica percentuale si sono evolute da RFC 1738 (1994) a RFC 2396 (1998) a RFC 3986 (2005). Ogni generazione ha chiarito le ambiguità. RFC 1738 era conservatore, trattando i personaggi non sicuri perché il primo web aveva un supporto limitato per i caratteri. Distribuzioni standardizzate su UTF-8, le implementazioni sono diventate coerenti. Gli standard successivi hanno allentato le restrizioni sui personaggi che si sono dimostrati sicuri nei sistemi. Consenso moderno: UTF-8 ovunque. Gli organismi di standardizzazione mantengono fermamente la compatibilità con le versioni precedenti. La risoluzione richiederebbe un coordinamento a livello mondiale, impossibile dopo tre decenni. Due standard coesistono deliberatamente.
I test con plus e %20 rivelano i presupposti del server. I registri del server mostrano ciò che i client inviano. I moduli utilizzano più; gli URL manuali utilizzano %20. Scegli in base al contesto e segui la documentazione API.
Cosa non copre: corpi multipart/form-data e JSON
Il test di entrambe le codifiche rivela il comportamento del server. Invia a+b in entrambe le direzioni. Molti server di produzione si aspettano la codifica dei moduli; le API più recenti prevedono %20. La tua scelta dipende dalle aspettative del destinatario. URLSearchParams gestisce la codifica dei moduli; encodeURIComponent gestisce la codifica RFC.
Non combinare mai metodi di codifica. Il valore codificato con encodeURIComponent %2B quindi passato a URLSearchParams viene doppiamente codificato come %252B. La decodifica una volta restituisce %2B anziché più. Il carattere diventa una stringa percentuale due-sei letterale anziché un segno più. Controlla i passaggi intermedi nel processo di creazione. La codifica avviene esattamente una volta per valore. Documenta lo standard di codifica utilizzato dalla tua pipeline. Prova con caratteri speciali tra cui più, spazio, e commerciale.
Conclusione: due standard, entrambi corretti nel loro contesto: come il codificatore e decodificatore URL ti fornisce il modulo RFC 3986, con %20 per gli spazi, in modo da sapere quale stai guardando
La divisione più contro venti non è un bug da correggere. È un artefatto storico di standard che risolvono problemi distinti in modo diverso. La risoluzione richiederebbe un coordinamento a livello mondiale, impossibile dopo trent’anni. Gli organismi di normalizzazione non interrompono retroattivamente il web. RFC 3986, le regole del modulo, la costruzione del browser URL hanno ciascuno standard e ragioni. La codifica del modulo RFC 1866 e la codifica RFC 3986 URI servono livelli diversi. Codifica deliberatamente conoscendo il tuo standard. Testare contro carichi utili realistici.
Scegli la codifica in base al contesto. I moduli utilizzano plus secondo gli standard HTML. Gli URI manuali utilizzano %20 per RFC 3986. Le API specificano cosa aspettarsi; seguire la documentazione o testarli entrambi. URL codificatore e decodificatore mostra RFC 3986. Hai bisogno della codifica dei moduli? URLSearchParams lo fa. Lo strumento non mescola le codifiche; comprendere gli standard previene le sorprese. L'incoerenza della codifica tra i livelli causa una sottile perdita di parametri, troncamento e danneggiamento dei dati. Entrambi gli standard sono corretti nel loro ambito. Applicare deliberatamente e documentare.