Quand encoder space to plus ( + ) ou %20?
parfois, les espaces sont encodés en URL vers le signe + , parfois vers %20 . Quelle est la différence et pourquoi devrait-il se produire?
5 réponses
+ désigne un espace seulement dans application/x-www-form-urlencoded de contenu, comme la partie requête de l'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 foo+bar , pas foo bar .
%20 est une façon valide de coder un espace dans ces contextes. Ainsi, si vous avez besoin D'encoder une chaîne de caractères pour l'inclure dans une partie D'une URL, il est toujours prudent 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 urlencode fait en PHP ( rawurlencode est plus sûr).
Voir Aussi HTML 4.01 Specification application / x-www-form-urlencoded
http://www.example.com/some/path/to/resource?param1=value1
La partie avant le point d'interrogation doit utiliser le % de l'encodage (donc %20 pour l'espace), après le point d'interrogation, vous pouvez utiliser %20 ou + un espace. Si vous avez besoin d'un + après le point d'interrogation, utilisez %2B .
donc, les réponses ici sont toutes un peu incomplètes. L'utilisation d'un' %20 ' pour encoder un espace dans les URLs est explicitement définie dans RFC3986 , qui définit comment un URI est construit. Il n'est pas mentionné dans cette spécification d'utiliser un " + "pour encoder les espaces - si vous utilisez uniquement cette spécification, un espace doit être encodé comme "%20".
la mention d'utiliser " + " pour encoder les espaces provient des différentes incarnations de la spécification HTML - spécifiquement dans la section décrivant le type de contenu "application/x-www-form-urlencoded". Ce est utilisé pour l'affichage des données de formulaire.
maintenant, la spécification HTML 2.0 (RFC1866) dit explicitement, dans la section 8.2.2, que la partie requête de la chaîne D'URL D'une requête GET doit être encodé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... est-il vraiment? Rappelez-vous, HTML est lui-même une spécification de contenu, et des URLs avec des chaînes de requête peuvent être utilisés avec du contenu autre que HTML. De plus, alors que les versions ultérieures des spécifications HTML continuent de définir '+' comme étant 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 request sont définies comme ce type. Il n'y a, en fait, aucune mention que ce soit sur la chaîne de requête encodant dans quoi que ce soit après la spécification HTML 2.0.
Qui nous laisse avec la question - est-il valide? Il y a certainement beaucoup de code d'héritage qui supporte '+' dans les chaînes de requête, et beaucoup de code qui le génère aussi. Alors les chances sont bonnes que vous ne cassera pas si vous utilisez"+". (Et, en fait, j'ai fait toutes les recherches sur cette 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. Ils n'ont pas réussi à décoder un pourcentage de caractères codés. Donc le service que vous utilisez peut être pertinent bien.)
mais d'une lecture pure des spécifications, sans le langage de la spécification HTML 2.0 repris dans les versions ultérieures, les URLs sont entièrement couverts par RFC3986, ce qui signifie que les espaces doivent être convertis en '%20'. Et ce devrait certainement être le cas si vous demandez autre chose qu'un document HTML.
il est préférable de toujours encoder les espaces en %20, et non en"+".
C'était la RFC 1866 (HTML 2.0), qui a précisé que les caractères d'espace doit être codé comme "+" dans "application/x-www-form-urlencoded" content-type de paires clé-valeur. (voir le paragraphe 8.2.1. le sous-alinéa 1.). Ce mode d'encodage des données de forme est également donné dans les spécifications HTML ultérieures, cherchez les paragraphes pertinents sur application / x-www-form-urlencoded.
voici un exemple d'une telle chaîne dans L'URL où RFC-1866 permet d'encoder des espaces en plus: "http://example.com/over/there?name=foo + bar". Donc, seulement après "?", les espaces peuvent être remplacés par des plus, selon RFC-1866. Dans d'autres cas, les espaces devraient être encodés à %20. Mais comme il est difficile de déterminer le contexte, il est préférable de ne jamais encoder les espaces en "+".
je vous recommande de le pour-cent-encoder tous les caractères sauf "sans réserve", défini dans la RFC 3986, p.2.3
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
Quelle est la différence: voir d'autres réponses.
quand utiliser + au lieu de %20 ? Utilisez + si, pour une raison quelconque, vous voulez rendre la chaîne de requête URL ( ?..... ) ou le fragment de hachage ( #.... ) plus lisible. Exemple: vous pouvez effectivement lire ceci:
https://www.google.se/#q=google+n'%27t+encoder+:+et+utilise+%2B+lieu+de+espaces
( %2B =+)
Mais la suite est beaucoup plus difficile à lire (au moins pour moi)
je pense que + est peu susceptible de casser quoi que ce soit, puisque Google utilise + (voir le 1er lien ci-dessus) et ils ont probablement pensé à cela. Je vais utiliser + moi-même juste parce que lisible + Google pense que c'est OK.