Quand un espace dans une URL +
est-il codé et quand est-il codé %20
?
Quand un espace dans une URL +
est-il codé et quand est-il codé %20
?
Réponses:
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 %20
alors 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 ?
.
multipart/form-data
utilise le codage MIME; application/x-www-form-urlencoded
utilise +
et utilise correctement les URI codés %20
.
http://www.bing.com/search?q=hello+world
et une ressource avec un espace dans le nomhttp://camera.phor.net/cameralife/folders/2012/2012-06%20Pool%20party/
mailto:support@example.org?subject=I%20need%20help
,. Si vous avez essayé avec +, l'e-mail s'ouvrira avec + es au lieu d'espaces.
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 %20
avant ?
et +
après.
key1=value1&key1=value2
où les clés et les valeurs sont encodées avec les règles qui encodeURIComponent
suivent, 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.
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+'
URLEncoder.encode()
méthode en Java le convertit +
également.
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.