URL codant le caractère espace: + ou% 20?


Réponses:


425

De Wikipédia (accentuation et lien ajoutés):

Lorsque des données entrées dans des formulaires HTML sont soumises, les noms et valeurs des champs de formulaire sont codés et envoyés au serveur dans un message de requête HTTP à l'aide de la méthode GET ou POST, ou, historiquement, par e-mail. Le codage utilisé par défaut est basé sur une toute première version des règles générales de codage en pourcentage de l'URI, avec un certain nombre de modifications telles que la normalisation de la nouvelle ligne et le remplacement des espaces par "+" au lieu de "% 20". Le type de données MIME codé de cette manière est application / x-www-form-urlencoded, et il est actuellement défini (toujours de manière très obsolète) dans les spécifications HTML et XForms.

Ainsi, le pourcentage réel d' encodage utilise %20alors que les données de formulaire dans les URL sont sous une forme modifiée qui utilise +. Il est donc très probable que vous ne voyiez que les +URL dans la chaîne de requête après un ?.


2
Ainsi, l'encodage + serait techniquement un encodage en plusieurs parties / données de formulaire, tandis que l'encodage en pourcentage est codé par application / x-www-form-url?
BC.

17
@BC: no - multipart/form-datautilise le codage MIME; application/x-www-form-urlencodedutilise +et utilise correctement les URI codés %20.
McDowell

8
"Donc, vous êtes le plus susceptible de ne voir + dans les URL de la chaîne de requête qu'après un?" Est un euphémisme. Vous ne devriez jamais voir "+" dans la partie chemin de l'URL car il ne fera pas ce que vous attendez (espace).
Adam Gent

34
Donc, fondamentalement: la cible de la soumission GET est http://www.bing.com/search?q=hello+worldet une ressource avec un espace dans le nomhttp://camera.phor.net/cameralife/folders/2012/2012-06%20Pool%20party/
William Entriken

8
Notez que pour les liens de messagerie, vous avez besoin de% 20 et non + après le?. Par exemple mailto:support@example.org?subject=I%20need%20help,. Si vous avez essayé avec +, l'e-mail s'ouvrira avec + es au lieu d'espaces.
Sygmoral

288

Cette confusion est due au fait que les URL sont toujours «cassées» à ce jour.

Prenez par exemple " http://www.google.com ". Ceci est une URL. Une URL est un localisateur de ressources uniforme et est en fait un pointeur vers une page Web (dans la plupart des cas). Les URL ont en fait une structure très bien définie depuis la première spécification en 1994.

Nous pouvons extraire des informations détaillées sur l' URL " http://www.google.com ":

+---------------+-------------------+
|      Part     |      Data         |
+---------------+-------------------+
|  Scheme       | http              |
|  Host         | www.google.com    |
+---------------+-------------------+

Si nous regardons une URL plus complexe telle que:

" https: // bob: bobby@www.lunatech.com: 8080 / fichier; p = 1? q = 2 # troisième "

nous pouvons extraire les informations suivantes:

+-------------------+---------------------+
|        Part       |       Data          |
+-------------------+---------------------+
|  Scheme           | https               |
|  User             | bob                 |
|  Password         | bobby               |
|  Host             | www.lunatech.com    |
|  Port             | 8080                |
|  Path             | /file;p=1           |
|  Path parameter   | p=1                 |
|  Query            | q=2                 |
|  Fragment         | third               |
+-------------------+---------------------+

https://bob:bobby@www.lunatech.com:8080/file;p=1?q=2#third
\___/   \_/ \___/ \______________/ \__/\_______/ \_/ \___/
  |      |    |          |          |      | \_/  |    |
Scheme User Password    Host       Port  Path |   | Fragment
        \_____________________________/       | Query
                       |               Path parameter
                   Authority

Les caractères réservés sont différents pour chaque partie.

Pour les URL HTTP, un espace dans une partie de fragment de chemin doit être codé en "% 20" (pas, absolument pas "+"), tandis que le caractère "+" dans la partie de fragment de chemin peut être laissé non codé.

Maintenant, dans la partie requête, les espaces peuvent être encodés en "+" (pour la compatibilité descendante: n'essayez pas de le rechercher dans la norme URI) ou "% 20" tandis que le caractère "+" (en raison de cette ambiguïté ) doit être échappé vers "% 2B".

Cela signifie que la chaîne "bleu + bleu clair" doit être codée différemment dans les parties chemin et requête:

" http://example.com/blue+light%20blue?blue%2Blight+blue ".

De là, vous pouvez déduire que le codage d'une URL entièrement construite est impossible sans une connaissance syntaxique de la structure de l'URL.

Cela se résume à:

Vous devriez avoir %20avant ?et +après.

La source


>> vous devriez avoir% 20 avant le? et + après Désolé pour la question idiote. Je sais un peu que le paramètre hashtag est utilisé après "?" paramètre de point d'interrogation. Bien que ce soit différent, l'utilisation de "#" ne recharge pas la page. Mais j'ai essayé d'utiliser le signe% 20 et + après le hashtag "#", et cela ne semble pas fonctionner. Lequel doit être utilisé après "#"?
Philcyb

@Philcyb Vous voudrez peut-être lire ceci en.wikipedia.org/wiki/Percent-encoding
Matas Vaitkevicius

La partie requête a-t-elle réellement une norme "officielle"? J'ai pensé que cette partie est spécifique à l'application. 99,99% des applications utilisent key1=value1&key1=value2où les clés et les valeurs sont encodées avec les règles qui encodeURIComponentsuivent, mais AFAIK le contenu de la partie de la requête est entièrement à 100% jusqu'à l'application. À part cela, cela ne va qu'au premier, #il n'y a pas d'encodage officiel.
gman

Une réponse en double pour la question en double! Mais hmm, ok, j'ai renoncé aux deux.
Vladimir Vukanac

3
L'étiquetage des composants ASCII est épique.
jsejcksn

25

Je recommanderais %20.

Les codez-vous en dur?

Cependant, ce n'est pas très cohérent entre les langues. Si je ne me trompe pas, en PHP urlencode()traite les espaces comme +tandis que Python les urlencode()traite comme %20.

ÉDITER:

Il semble que je me trompe. Python urlencode()(au moins en 2.7.2) utilise à la quote_plus()place de quote()et encode donc les espaces en "+". Il semble également que la recommandation du W3C soit le "+" comme ici: http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1

Et en fait, vous pouvez suivre ce débat intéressant sur le propre tracker de problème de Python sur ce qu'il faut utiliser pour encoder les espaces: http://bugs.python.org/issue13866 .

EDIT # 2:

Je comprends que la façon la plus courante d'encoder "" est comme "+", mais juste une note, c'est peut-être juste moi, mais je trouve cela un peu déroutant:

import urllib
print(urllib.urlencode({' ' : '+ '})

>>> '+=%2B+'

Pas de codage en dur. Essayer de déterminer d'un point de vue esthétique à quoi ressembleront mes URL contenant des espaces.
BC.

Salut, je suis confus aussi, Lorsque l'utilisateur soumet le formulaire html, comment le formulaire code-t-il l'espace? avec quel personnage? Le résultat dépend-il du navigateur?
GMsoF

1
Et la URLEncoder.encode()méthode en Java le convertit +également.
2014

Et puis la question se pose de savoir comment traiter l'encodage dans le corps d'une requête POST: "Content-Type: application / x-www-form-urlencoded" où les paramètres sont sous la forme de "a = b & c = d", mais ne sont pas du tout dans une URL, juste le corps du "document". Ils ont vraiment gâché ce problème, et il est sacrément difficile de trouver des réponses définitives.
fyngyrz

Perls uri_escape () les traite comme% 20
someuser

16

Un espace ne peut être codé qu'en "+" dans la partie de requête de paires clé-valeur de type de contenu "application / x-www-form-urlencoded". À mon avis, c'est un MAI, pas un MUST. Dans le reste des URL, il est codé en% 20.

À mon avis, il est préférable de toujours coder les espaces en% 20, pas en "+", même dans la partie requête d'une URL, car c'est la spécification HTML (RFC-1866) qui spécifie que les caractères d'espace doivent être codés en " + paires "clé-valeur" de type de contenu "application" / x-www-form-urlencoded "(voir paragraphe 8.2.1. alinéa 1)

Cette façon d'encoder les données du formulaire est également donnée dans les spécifications HTML ultérieures. Par exemple, recherchez les paragraphes pertinents sur application / x-www-form-urlencoded dans la spécification HTML 4.01, etc.

Voici un exemple de chaîne dans l'URL où la spécification HTML autorise le codage des espaces comme avantages: " http://example.com/over/there?name=foo+bar ". Ainsi, seulement après "?", Les espaces peuvent être remplacés par des points positifs . Dans d'autres cas, les espaces doivent être codés en% 20. Mais comme il est difficile de déterminer correctement le contexte, il est préférable de ne jamais coder les espaces en "+".

Je recommanderais de coder en pourcentage tous les caractères sauf "non réservé" défini dans RFC-3986, p.2.3

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

L'implémentation dépend du langage de programmation que vous avez choisi.

Si votre URL contient des caractères nationaux, commencez par les coder en UTF-8, puis codez en pourcentage le résultat.


1
Pourquoi quelqu'un devrait-il se soucier des spécifications HTML si la ressource demandée n'est pas HTML? J'ai vu "+" dans certaines API Web qui ne répondent pas avec HTML, par exemple, vous demandez un pdf. Je considère qu'il est faux de ne pas utiliser "% 20".
L'incroyable

@TheincredibleJan, je suis d'accord avec vous. C'est de cela que je parle.
Maxim Masiutin

1
@MaximMasiutin Lorsque votre réponse dit "C'est un MAI, pas un MUST", à quelle spécification faites-vous référence? J'ai du mal à trouver une spécification qui l'a comme mai. Dans w3.org/TR/1999/REC-html401-19991224/interact/…, l' utilisation de '+' (dans la section de requête) se trouve dans une section 'must' de la spécification.
JosephH

2
@JosephH - merci pour votre note. C'est mon opinion personnelle sur MAI. J'ai édité le post. Ce que je voulais dire, c'est que la spécification HTML que vous avez définie définit "+", mais dans le contexte de l'URL, d'autres règles s'appliquent, qui permettent également de coder les espaces en tant que% 20.
Maxim Masiutin
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.