Strumenti per sviluppatori · URL codificatore e decodificatore
Spazi nei collegamenti per il download dei file: perché %20, + e uno spazio non elaborato non sono la stessa cosa
· Perché è importante
codifica dell'URL http flusso di lavoro dello sviluppatore
Un file chiamato "Q3 report (final).pdf" può essere collegato in tre modi diversi e solo uno è corretto in modo affidabile. Questo post spiega perché i nomi dei file interrompono i collegamenti di download e come codificarli in modo che ogni cliente sia d'accordo.
Il download che fallisce per alcuni utenti e funziona per altri: un nome file con spazi e un segno più
File come "Q3 report.pdf" funzionano correttamente se archiviati localmente ma non riescono tramite i collegamenti di download per alcuni utenti mentre altri riescono senza problemi. Gli spazi non elaborati non sono validi negli URL secondo la specifica RFC 3986. I browser li tollerano nelle barre degli indirizzi ma i client HTTP li rifiutano rigorosamente. Comprendere %20, i segni più e gli spazi grezzi è assolutamente essenziale per una distribuzione affidabile. La distinzione tra i metodi di codifica influisce direttamente sulle percentuali di successo dei download su diverse piattaforme, vari strumenti di automazione e implementazioni client HTTP in tutto il mondo. Gli sviluppatori devono comprendere questa distinzione quando creano sistemi di download. Il contesto è importante per le scelte di codifica e la compatibilità del sistema.
Gli sviluppatori devono scegliere tra spazi non elaborati, %20 o segni più durante la creazione di collegamenti per il download. I test con curl, wget e Python rivelano quali client applicano la conformità RFC. I download del browser riescono a causa del ripristino degli errori, ma le integrazioni API falliscono quando incontrano spazi non codificati.
Perché uno spazio non elaborato non è valido in URL e perché i browser lo tollerano nella barra degli indirizzi ma i client HTTP no
Gli spazi grezzi negli URL hanno radici storiche nella progettazione del protocollo. Gli URL attraversano i sistemi che trattano gli spazi come delimitatori tra i token. Uno spazio in URL potrebbe essere interpretato erroneamente come terminatore. I client HTTP che leggono dalle righe di comando troncano ai primi spazi. Questo progetto fondamentale rimane nelle implementazioni del protocollo ed è improbabile che cambi.
I browser tollerano gli spazi grezzi attraverso la conversione silenziosa in %20 prima di inviare richieste HTTP. Questo comportamento intuitivo nasconde i requisiti del protocollo agli utenti finali che incollano gli URL nelle barre degli indirizzi. I sistemi automatizzati non dispongono di questo livello di ripristino. Gli script falliscono sugli URL con spazi non elaborati. I client di posta riscontrano errori nell'apertura di tali collegamenti.
%20 rispetto a + in un segmento di percorso: la convenzione di codifica del modulo che non si applica ai percorsi
%20 rispetto ai segni più rappresenta una distinzione fondamentale nei contesti di codifica URL. Nei segmenti del percorso, gli spazi devono essere codificati come %20 per RFC 3986. Il segno più non è uno spazio codificato in percorsi. Questa convenzione ha avuto origine nella codifica del modulo HTML dove funge da codifica dello spazio nelle stringhe di query. Gli sviluppatori spesso applicano in modo errato le regole del modulo ai percorsi.
Le convenzioni di codifica dei moduli che consentono i segni più non si applicano ai percorsi con requisiti strutturali diversi. Nelle stringhe di query, la e commerciale e l'uguale delimitano i parametri. L'utilizzo del segno più per gli spazi nei valori della query non crea ambiguità poiché il segno più non è un delimitatore. Nei percorsi, più non ha alcun significato speciale. Le convenzioni di mixaggio creano collegamenti di download interrotti.
Nomi di file nonASCII: chiavi di codifica percentuale UTF-8 e chiavi di archiviazione di oggetti che memorizzano il nome non elaborato
I nomi di file nonASCII richiedono la codifica percentuale UTF-8 prima della trasmissione sicura negli URL. Un nome file come "Über report.pdf" contiene "Ü" (U+00DC) fuori dall'intervallo ASCII. La codifica UTF-8 lo converte in byte C3 9C. Questi byte vengono codificati in percentuale come %C3%9C negli URL. Ogni UTF-8 byte ottiene la propria tripletta, producendo nomi di file codificati più lunghi.
I servizi di storage di oggetti come Amazon S3 presentano casi interessanti per nomi di file nonASCII. Alcuni sistemi consentono UTF-8 byte non elaborati nelle chiavi mentre altri richiedono la codifica percentuale. La strategia di codifica dipende dai provider di archiviazione e dall'utilizzo di URL. L'accesso basato su URL richiede UTF-8 con codifica percentuale. Gli sviluppatori devono coordinare i livelli di archiviazione e di generazione URL.
Esempio realizzato: codifica 'Über Q3 report (final)+notes.pdf' per un percorso: l'output esatto e il motivo per cui + deve diventare %2B
Esempio realizzato: la codifica "Über report (final)+notes.pdf" dimostra la codifica completa. Il nome file contiene spazi, caratteri nonASCII e un segno più letterale. La codifica UTF-8 di "Ü" produce %C3%9C. Nella codifica del percorso, gli spazi diventano %20 (a differenza della codifica del modulo che utilizza più). Il più letterale diventa %2B. Le parentesi codificano come %28 e %29. Risultato: %C3%9CberQ3%20report%20%28final%29%2Bnotes.pdf.
I test con il codificatore e decodificatore URL mostrano la trasformazione esatta. Incollare il nome file in modalità a valore singolo produce segmenti corretti con codifica percentuale utilizzando le regole del percorso. Lo strumento preserva i delimitatori del percorso codificando solo i componenti del nome file. Il confronto visivo tra input e output rende le regole chiare e verificabili prima della produzione. Confrontalo con la modalità modulo per vedere le differenze di contesto.
Content-Disposition e il parametro filename*: una codifica separata per la richiesta di download, menzionata per completezza
I parametri Content-Disposition e filename* rappresentano livelli di codifica alternativi per le richieste di download. I server includono intestazioni Content-Disposition che specificano i nomi dei file per le finestre di dialogo di download. Il parametro filename utilizza RFC 2183 mentre filename* utilizza RFC 5987 con codifica percentuale. I browser interpretano queste intestazioni per decidere i nomi dei file di salvataggio. Lo stesso nome file viene codificato due volte con schemi diversi.
Due livelli di codifica creano opportunità per errori di transcodifica. I nomi di file con codifica URL e con codifica dell'intestazione potrebbero non eseguire correttamente il round trip se server e client non sono d'accordo. Per la massima compatibilità, gli sviluppatori devono codificare i nomi dei file nei percorsi URL utilizzando la codifica percentuale %20 e UTF-8 e impostare le intestazioni Content-Disposition con nomi di file decodificati. Ciò garantisce che tutti i client e i browser HTTP funzionino correttamente.
Ciò che questo non copre: nomi di file riservati su sistemi operativi specifici e peculiarità del provider di archiviazione
I nomi di file riservati su sistemi operativi specifici aggiungono complessità alla codifica URL. Windows riserva nomi come CON, PRN e AUX per i dispositivi. I file denominati letteralmente "CON.pdf" non possono esistere su NTFS. macOS dispone di convenzioni di denominazione e regole di attributi estesi. Linux fa distinzione tra maiuscole e minuscole. I nomi di file con codifica URL validi potrebbero non essere validi per l'archiviazione su alcuni sistemi.
Le peculiarità del provider di archiviazione aggiungono complessità alla distribuzione multipiattaforma. Amazon S3 accetta chiavi UTF-8 e fa distinzione tra maiuscole e minuscole. Google Cloud Storage si comporta in modo simile con restrizioni aggiuntive. L'archiviazione BLOB di Azure prevede regole di carattere diverse. I nomi di file che funzionano su S3 potrebbero non riuscire in Azure. Gli architetti devono controllare la documentazione del fornitore ed eseguire test con nomi di file reali nonASCII.
Conclusione: codifica il segmento, non URL: come la modalità a valore singolo del codificatore e decodificatore URL produce un nome file sicuro per il percorso
Conclusione: codifica il segmento, non URL: la modalità a valore singolo del codificatore e decodificatore URL produce nomi di file sicuri per il percorso. Lo strumento accetta nomi di file non elaborati e produce segmenti con codifica percentuale. Ciò impedisce la doppia codifica e il mixaggio dei contesti. L'utilizzo della modalità a valore singolo evita il bilanciamento delle regole di codifica di percorso, query e frammento. I segmenti generati possono essere inseriti in sicurezza negli URL.
Le migliori pratiche codificano i nomi dei file nel punto in cui entrano nella costruzione URL. Non dare per scontato che i browser risolvano i problemi di codifica. Testare con client HTTP effettivi utilizzati dagli utenti di destinazione: API curl, wget, Python, Java httplib e browser fetch. Verifica che i nomi dei file sopravvivano al viaggio di andata e ritorno attraverso interi sistemi. URL codificatore e decodificatore è il punto di partenza per garantire la correttezza.