Punto e virgola come separatore di query URL

rimosso dead link Imageshack – e commerciale contro punto e virgola

Sebbene sia fortemente raccomandato ( fonte W3C , tramite Wikipedia ) che i server Web supportino il punto e virgola come separatore degli elementi di query URL (oltre alla e commerciale), non sembra essere generalmente seguito.

Ad esempio, confronta

http://www.google.com/search?q=nemo & oe = utf-8

http://www.google.com/search?q=nemo ; oe = utf-8

risultati. (In quest’ultimo caso, il punto e virgola è, o era al momento della scrittura di questo testo , trattato come carattere di stringa ordinario, come se l’URL fosse: http://www.google.com/search?q=nemo% 3B oe = utf-8 )

Sebbene la prima libreria di analisi degli URL che ho provato, si comporta bene:

>>> from urlparse import urlparse, query_qs >>> url = 'http://www.google.com/search?q=nemo;oe=utf-8' >>> parse_qs(urlparse(url).query) {'q': ['nemo'], 'oe': ['utf-8']} 

Qual è lo stato corrente dell’accettazione del punto e virgola come separatore e quali sono potenziali problemi o note interessanti? (dal punto di vista del server e del client)

La raccomandazione del W3C del 1999 è obsoleta. Lo stato attuale, secondo la Raccomandazione W3C 2014 , è che il punto e virgola è ora illegale come separatore di parametri:

Per decodificare i payload application / x-www-form-urlencoded, è necessario utilizzare il seguente algoritmo. […] L’output di questo algoritmo è un elenco ordinato di coppie nome-valore. […]

  1. Lascia che le stringhe siano il risultato della divisione rigorosa del payload della stringa su U + 0026 AMPERSAND caratteri (&).

In altre parole ?foo=bar;baz significa che il parametro foo avrà la bar;baz del valore bar;baz ; mentre ?foo=bar;baz=sna dovrebbe risultare in foo essere bar;baz=sna (anche se tecnicamente illegale dal secondo = dovrebbe essere sfuggito a %3D ).

Finché il tuo server HTTP e la tua applicazione lato server accettano il punto e virgola come separatori, dovresti essere pronto. Non riesco a vedere alcun inconveniente. Come hai detto, le specifiche del W3C sono dalla tua parte :

Raccomandiamo che implementatori di server HTTP e, in particolare, implementatori di CGI supportino l’uso di “;” al posto di “&” per salvare gli autori il problema di sfuggire a caratteri “&” in questo modo.

Sono d’accordo con Bob Aman. Le specifiche W3C sono progettate per semplificare l’uso di collegamenti ipertestuali di ancoraggio con URL che assomigliano a richieste GET (ad esempio, http://www.host.com/?x=1&y=2 ). In questo contesto, la e commerciale è in conflitto con il sistema per i riferimenti di quadro carattere, che iniziano tutti con una e commerciale (es. " ). Pertanto, W3C consiglia ai server Web di utilizzare un punto e virgola come separatore di campo anziché come e commerciale, per semplificare la scrittura di questi URL. Ma questa soluzione richiede che gli scrittori ricordino che la e commerciale deve essere sostituita da qualcosa, e che a ; è un delimitatore di campo altrettanto valido, anche se i browser Web utilizzano universalmente e commerciali nell’URL quando inviano moduli. Questo è probabilmente più difficile che ricordare di sostituire la e commerciale con un & in questi collegamenti, proprio come si farebbe altrove nel documento.

A peggiorare le cose, finché tutti i server Web non consentono il delimitazione dei punti e virgola, gli autori di URL possono utilizzare questo collegamento solo per alcuni host e devono utilizzare & per gli altri. Dovranno anche cambiare il loro codice in un secondo momento se un determinato host smette di consentire i delimitatori del punto e virgola. Questo è certamente più difficile del semplice utilizzo di & , che funzionerà per tutti i server per sempre. Ciò a sua volta rimuove qualsiasi incentivo per i server Web a consentire il punto e virgola come separatori di campo. Perché preoccuparsi, quando tutti stanno già cambiando la propria e commerciale in & invece di ; ?

In breve, l’HTML è un grande casino (a causa della sua clemenza), e l’uso del punto e virgola aiuta a semplificare questo LOT. Stimo che quando considero le complicazioni che ho trovato, l’uso di e commerciali come separatore rende l’intero processo tre volte più complicato rispetto all’uso del punto e virgola per i separatori!

Sono un programmatore .NET e, per quanto ne so , .NET non consente “;” separatori, quindi ho scritto i miei metodi di analisi e gestione perché ho visto un enorme valore nell’utilizzo del punto e virgola piuttosto che nel già problematico sistema di utilizzo di e commerciali come separatori. Sfortunatamente, persone di tutto rispetto (come @Bob Aman in un’altra risposta) non vedono il valore nel motivo per cui l’utilizzo del punto e virgola è di gran lunga superiore e molto più semplice dell’uso di e commerciali. Quindi ora condivido alcuni punti per persuadere forse altri sviluppatori rispettabili che non riconoscono il valore di usare il punto e virgola invece:

L’uso di una querystring come “? A = 1 & b = 2” in una pagina HTML è improprio (senza prima la codifica HTML), ma il più delle volte funziona. Ciò è dovuto al fatto che la maggior parte dei browser è tollerante e che la tolleranza può portare a bug difficili da trovare quando, ad esempio, il valore della coppia di valori chiave viene inserito in un URL della pagina HTML senza codifica appropriata (direttamente come ‘? a = 1 & b = 2 ‘nel codice sorgente HTML). Un QueryString come ‘? Who = me + e + te’ è anche problematico.

Noi persone possiamo avere pregiudizi e non essere d’accordo sui nostri pregiudizi per tutto il giorno, quindi riconoscere i nostri pregiudizi è molto importante. Ad esempio, sono d’accordo sul fatto che penso semplicemente di separarci con “;” sembra “più pulito”. Sono d’accordo sul fatto che la mia opinione “più pulita” è puramente un pregiudizio. E un altro sviluppatore può avere un pregiudizio altrettanto opposto e altrettanto valido. Quindi il mio pregiudizio su questo punto non è più corretto del pregiudizio opposto.

Ma dato il supporto imparziale del punto e virgola che rende la vita di tutti più facile a lungo termine, non può essere contestato correttamente quando viene presa in considerazione l’intera immagine. In breve, usare il punto e virgola rende la vita più semplice per tutti , con un’eccezione: un piccolo ostacolo per abituarsi a qualcosa di nuovo. È tutto. È sempre più difficile far cambiare idea. Ma la difficoltà di rendere il cambiamento impallidisce rispetto alla continua difficoltà di continuare a usare &.

Utilizzando; come separatore QueryString rende MOLTO più semplice. I separatori e commerciale sono più di due volte più difficili da codificare correttamente rispetto all’utilizzo di punti e virgola. (Penso che la maggior parte delle implementazioni non siano codificate correttamente, quindi molte implementazioni non sono due volte più complicate. Ma poi rintracciare e correggere gli errori porta alla perdita di produttività. Qui, indico 2 passaggi di codifica separati necessari per codificare correttamente una QueryString quando & è il separatore:

  • Passaggio 1: l’URL codifica sia le chiavi che i valori della querystring.
  • Passaggio 2: concatenare le chiavi e i valori come ‘a = 1 & b = 2’ dopo che sono codificati URL dal passaggio 1.
  • Passaggio 3: quindi HTML codifica l’intera QueryString nel codice sorgente HTML della pagina.

Quindi la codifica speciale deve essere eseguita due volte per una codifica URL corretta (senza bug), e non solo, ma le codifiche sono due tipi di codifica distinti e diversi. Il primo è una codifica URL e il secondo è una codifica HTML (per il codice sorgente HTML). Se qualcuno di questi non è corretto, allora posso trovarti un bug. Ma il passaggio 3 è diverso per XML. Per XML, è necessaria invece la codifica dell’entity framework carattere XML (che è quasi identica). Il mio punto è che l’ultima codifica dipende dal contesto dell’URL, sia che si trovi in ​​una pagina Web HTML, sia nella documentazione XML.

Ora con i separatori di punto e virgola molto più semplici, il processo è come ci si aspetterebbe:

  • 1: l’URL codifica le chiavi e i valori,
  • 2: concatenare i valori insieme. (Senza codifica per il passaggio 3.)

Penso che la maggior parte degli sviluppatori web salti il ​​passaggio 3 perché i browser sono così indulgenti. Ma questo porta a bug e altre complicazioni quando si cacciano quegli insetti o gli utenti che non sono in grado di fare cose se questi bug non erano presenti, o scrivendo segnalazioni di bug, ecc.

Un’altra complicazione in uso reale è quando si scrive il markup della documentazione XML nel mio codice sorgente sia in C # che in VB.NET. Poiché & deve essere codificato, è una vera resistenza, letteralmente, sulla mia produttività. Quel terzo passaggio in più rende più difficile leggere anche il codice sorgente. Quindi questo deficit più difficile da leggere si applica non solo a HTML e XML, ma anche ad altre applicazioni come C # e codice VB.NET perché la loro documentazione utilizza la documentazione XML. Quindi la complicazione di codificazione del passo 3 prolifera anche in altre applicazioni.

Quindi in sintesi, usando il; come separatore è semplice perché il processo (corretto) quando si utilizza il punto e virgola è come un wud normalmente si aspetta che il processo sia: solo un passaggio della codifica deve aver luogo.

Forse questo non era troppo confuso. Ma tutta la confusione o difficoltà è dovuta all’utilizzo di un carattere di separazione che shud essere codificato in HTML. Quindi ‘&’ è il colpevole. E il punto e virgola allevia tutta questa complicazione.