Quand coder l'espace en plus (+) ou% 20?

Question

Parfois, les espaces sont codés en URL au signe +, d'autres fois en %20. Quelle est la différence et pourquoi cela devrait-il se produire?

Answer 1

+ signifie un espace seulement contenu application/x-www-form-urlencoded, comme la partie de la requête d'une URL:

http://www.example.com/path/foo+bar/path?query+name=query+value 

Dans cette URL, le nom du paramètre est query name avec un espace et la valeur est query value avec un espace, mais le nom du dossier dans le chemin est littéralement , pasfoo bar.

%20 est un moyen valide de coder un espace dans l'un de ces contextes. Donc, si vous avez besoin de coder une URL pour l'inclure dans une partie d'une URL, il est toujours sûr de remplacer les espaces par %20 et les plus par %2B. C'est ce que par exemple. encodeURIComponent() fait en JavaScript. Malheureusement, ce n'est pas ce que fait urlencode en PHP (rawurlencode est plus sûr).

Voir aussi HTML 4.01 Specification application/x-www-form-urlencoded

Answer 2

http://www.example.com/some/path/to/resource?param1=value1

La partie avant le point d'interrogation doit utiliser% le codage (donc %20 pour l'espace), après le point d'interrogation que vous pouvez utiliser %20 ou + pour un espace. Si vous avez besoin d'un + réel après le point d'interrogation, utilisez.

Answer 3

Quelle est la différence? Voir les autres réponses. Si vous utilisez + au lieu de %20 Utilisez + si, pour une raison quelconque, vous voulez rendre la chaîne de requête d'URL (?.....) ou le fragment de hachage (#....) plus lisible. Exemple: Vous pouvez lire en fait ceci:

https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces (%2B = +)

Mais ce qui suit est beaucoup plus difficile à lire: (au moins pour moi)

https://www.google.se/#q=google%20doesn%27t%20oops%20:%20%20this%20text%20%2B%20is%20different%20spaces

Je pense + est peu susceptible de briser quoi que ce soit, puisque Google utilise + (voir le 1er lien ci-dessus) et ils ont probablement pensé à ce sujet. Je vais utiliser + moi-même juste parce que lisible + Google pense que c'est OK.

Answer 4

Il est préférable de toujours coder les espaces comme% 20, pas comme "+". C'était RFC-1866 (spécification HTML 2.0), qui spécifiait que les caractères d'espace devraient être codés comme "+" dans les paires valeur/clé "type application/x-www-form-urlencoded". (voir le paragraphe 8.2.1, sous-paragraphe 1). Cette façon de coder les données de formulaire est également donnée dans les spécifications HTML ultérieures, recherchez les paragraphes pertinents sur l'application/x-www-form-urlencoded.

Voici un exemple d'une telle chaîne dans l'URL où RFC-1866 permet d'encoder des espaces comme des plus: "http://example.com/over/there?name=foo+bar".Ainsi, seulement après "?", Les espaces peuvent être remplacés par des plus, selon RFC-1866. Dans d'autres cas, les espaces doivent être codés sur% 20. Mais comme il est difficile de déterminer le contexte, il est préférable de ne jamais encoder les espaces comme "+".

Je recommande à tout pour cent encode caractère sauf « sans réserves » défini dans la RFC-3986, P.2.3

unreserved = ALPHA/DIGIT/"-"/"."/"_"/"~" 

Answer 5

Ainsi, les réponses ici sont tous un peu incomplet. L'utilisation d'un «% 20» pour coder un espace dans les URL est explicitement définie dans RFC3986, qui définit la manière dont un URI est généré. Il n'y a aucune mention dans cette spécification de l'utilisation d'un '+' pour les espaces de codage - si vous utilisez uniquement cette spécification, un espace doit être codé comme '% 20'. La mention d'utilisation de '+' pour coder les espaces provient des diverses incarnations de la spécification HTML - en particulier dans la section décrivant le type de contenu 'application/x-www-form-urlencoded'. Ceci est utilisé pour l'affichage des données de formulaire. Maintenant, la spécification HTML 2.0 (RFC1866) indique explicitement, dans la section 8.2.2, que la partie Query d'une chaîne d'URL de requête GET doit être codée comme 'application/x-www-form-urlencoded'. Ceci, en théorie, suggère qu'il est légal d'utiliser un '+' dans l'URL de la chaîne de requête (après le '?').

Mais ... le fait-il vraiment? Souvenez-vous que HTML est lui-même une spécification de contenu et que les URL avec des chaînes de requête peuvent être utilisées avec du contenu autre que HTML. De plus, alors que les versions ultérieures de la spécification HTML continuent de définir '+' comme légal dans le contenu 'application/x-www-form-urlencoded', elles omettent complètement la partie disant que les chaînes de requête GET sont définies comme type. Il n'y a, en fait, aucune mention à propos de la chaîne de requête encodant quelque chose après la spécification HTML 2.0.

Ce qui nous laisse avec la question - est-il valide? Certes, il y a beaucoup de code hérité qui supporte le '+' dans les chaînes de requête, et beaucoup de code qui le génère aussi. Donc, les chances sont bonnes que vous ne casserez pas si vous utilisez «+». (Et, en fait, j'ai fait toutes les recherches sur ce sujet récemment parce que j'ai découvert un site majeur qui n'a pas accepté '% 20' dans une requête GET comme un espace.En fait, ils ont échoué à décoder tout caractère codé pour cent. Mais à partir d'une lecture pure des spécifications, sans le langage de la spécification HTML 2.0 reportée dans les versions ultérieures, les URL sont entièrement couvertes par RFC3986, ce qui signifie que les espaces doivent être converti en '% 20'. Et cela devrait certainement être le cas si vous demandez autre chose qu'un document HTML.