A volte gli spazi ottengono l'URL codificato per il +segno, altre volte per %20. Qual è la differenza e perché dovrebbe accadere?
Risposte:
+indica uno spazio solo nel application/x-www-form-urlencodedcontenuto, ad esempio la parte della query di un URL:
http://www.example.com/path/foo+bar/path?query+name=query+value
In questo URL, il nome del parametro è query namecon uno spazio e il valore è query valuecon uno spazio, ma il nome della cartella nel percorso è letteralmente foo+bar, non è foo bar .
%20è un modo valido per codificare uno spazio in uno di questi contesti. Quindi, se è necessario codificare l'URL di una stringa per l'inclusione in parte di un URL, è sempre sicuro sostituire gli spazi con %20e i vantaggi con %2B. Questo è ciò che es. encodeURIComponent()fa in JavaScript. Sfortunatamente non è quello che fa urlencode in PHP ( rawurlencode è più sicuro).
Vedi anche HTML 4.01 Specifica application / x-www-form-urlencoded
query+name=query+valueparametro da un modulo con <input name="query name" value="query value">. Non verrà creato query%20nameda un modulo, ma è assolutamente sicuro utilizzarlo invece, ad es. se stai mettendo insieme un modulo per un XMLHttpRequest. Se hai un URL con uno spazio al suo interno, ad esempio <a href="http://www.example.com/foo bar/">, il browser lo codificherà per consentirti %20di correggere l'errore, ma probabilmente è meglio non fare affidamento.
foo bara foo+bar?
encodeURIComponent(s).replace(/%20/g, '+')se ne hai davvero bisogno+
http://www.example.com/some/path/to/resource?param1=value1
La parte prima del punto interrogativo deve utilizzare la codifica% (quindi %20per lo spazio), dopo il punto interrogativo è possibile utilizzare uno %20o +per uno spazio. Se hai bisogno di un effettivo +dopo il punto interrogativo, usa %2B.
decodeURIComponentnon lo decodifica.
+è un carattere riservato , verrà conservato dal browser.
+per impostazione predefinita ( { foo: 'bar bar'}.to_query=> foo=bar+bar)
Quindi, le risposte qui sono tutte un po 'incomplete. L'uso di '% 20' per codificare uno spazio negli URL è esplicitamente definito in RFC3986 , che definisce come viene costruito un URI. In questa specifica non viene menzionato l'utilizzo di un '+' per la codifica degli spazi: se si utilizza esclusivamente questa specifica, uno spazio deve essere codificato come '% 20'.
La menzione dell'uso di "+" per la codifica degli spazi deriva dalle varie incarnazioni della specifica HTML, in particolare nella sezione che descrive il tipo di contenuto "application / x-www-form-urlencoded". Viene utilizzato per la pubblicazione dei dati dei moduli.
Ora, la specifica HTML 2.0 (RFC1866) ha esplicitamente affermato, nella sezione 8.2.2, che la parte Query della stringa URL di una richiesta GET deve essere codificata come 'application / x-www-form-urlencoded'. Questo, in teoria, suggerisce che è legale usare un '+' nell'URL nella stringa di query (dopo il '?').
Ma ... lo fa davvero? Ricorda, l'HTML è esso stesso una specifica del contenuto e gli URL con stringhe di query possono essere utilizzati con contenuti diversi dall'HTML. Inoltre, mentre le versioni successive delle specifiche HTML continuano a definire '+' come legale nel contenuto 'application / x-www-form-urlencoded', omettono completamente la parte dicendo che le stringhe di query di richiesta GET sono definite come quel tipo. In effetti, non vi è alcun riferimento alla codifica della stringa di query in qualsiasi cosa dopo le specifiche HTML 2.0.
Ciò che ci lascia con la domanda: è valido? Certamente c'è MOLTO codice legacy che supporta '+' nelle stringhe di query e molto codice che lo genera anche. Quindi le probabilità sono buone che non si romperanno se si utilizza '+'. (E, di fatto, ho fatto tutte le ricerche su questo recentemente perché ho scoperto un sito principale che non è riuscito ad accettare '% 20' in una query GET come spazio. In realtà non sono riusciti a decodificare QUALSIASI carattere con codifica percentuale. Quindi il servizio anche il riutilizzo può essere rilevante.)
Ma da una pura lettura delle specifiche, senza il linguaggio dalla specifica HTML 2.0 trasferito nelle versioni successive, gli URL sono interamente coperti da RFC3986, il che significa che gli spazi dovrebbero essere convertiti in '% 20'. E sicuramente questo dovrebbe essere il caso se stai richiedendo qualcosa di diverso da un documento HTML.
%20( <a href="?q=a b">), ma quando si invia un modulo, utilizza il +segno. Puoi sovrascriverlo utilizzando esplicitamente il +segno ( <a href="?q=a+b">) o inviando il modulo utilizzando XMLHTTPRequest.
È meglio codificare sempre gli spazi come% 20, non come "+".
Era RFC-1866 (specifica HTML 2.0), che specificava che i caratteri dello spazio dovevano essere codificati come "+" nelle coppie chiave-valore del tipo di contenuto "application / x-www-form-urlencoded". (vedi paragrafo 8.2.1. comma 1.). Questo modo di codificare i dati dei moduli viene anche fornito nelle specifiche HTML successive, cerca i paragrafi pertinenti su application / x-www-form-urlencoded.
Ecco un esempio di tale stringa nell'URL in cui RFC-1866 consente la codifica di spazi come vantaggi: "http://example.com/over/there?name=foo+bar". Quindi, solo dopo "?", Gli spazi possono essere sostituiti da vantaggi, secondo RFC-1866. In altri casi, gli spazi devono essere codificati in% 20. Ma poiché è difficile determinare il contesto, è la migliore pratica non codificare mai gli spazi come "+".
Consiglierei di codificare in percentuale tutti i caratteri tranne "senza prenotazione" definito in RFC-3986, p. 2.3
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
Qual è la differenza: vedi altre risposte.
Quando usare +invece di %20? Utilizzare +se, per qualche motivo, si desidera rendere più leggibile la stringa di query dell'URL ( ?.....) o il frammento di hash ( #....). Esempio: puoi effettivamente leggere questo:
https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces
( %2B= +)
Ma è molto più difficile leggere quanto segue: (almeno per me)
Penso che +sia improbabile che rompa qualcosa, dal momento che Google utilizza +(vedi il primo link sopra) e probabilmente ci hanno pensato. Mi userò +solo perché leggibile + Google pensa che sia OK.