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


Quand un espace dans une URL est-il codé +, et quand est-il codé %20?


568
2017-10-27 23:23


origine


Réponses:


De Wikipédia (emphase et lien ajouté):

Lorsque des données qui ont été entrées dans des formulaires HTML sont soumises, les noms et les 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 courrier électronique. Le codage utilisé par défaut est basé sur une version très ancienne des règles générales de codage URI, avec une nombre de modifications comme la normalisation de la nouvelle ligne et le remplacement des espaces par "+" au lieu de "% 20". Le type de données MIME encodé de cette manière est application / x-www-form-urlencoded, et il est actuellement défini (toujours de manière très désuète) dans les spécifications HTML et XForms.

Alors le réal pourcentage d'utilisation de l'encodage %20 tandis que les données de formulaire dans les URL sont sous une forme modifiée qui utilise +. Donc, vous êtes le plus susceptible de ne voir que + dans les URL de la chaîne de requête après un ?.


335
2017-10-27 23:26



Cette confusion est due au fait que l'URL est encore "cassée" à ce jour.

Prenez "http://www.google.com"par exemple, il s'agit d'une URL.Une URL est un localisateur de ressources uniforme et est vraiment un pointeur sur 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 le "http://www.google.com"URL:

+---------------+-------------------+   
|      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é sur "% 20" (pas, absolument pas "+"), tandis que le caractère "+" dans la partie fragment de chemin peut être laissé non codé.

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

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

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

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

Cela se résume à:

Tu aurais dû %20 avant le ? et + après.

La source


204
2018-04-29 15:36



je recommanderais %20.

Êtes-vous en train de les coder en dur?

Ce n'est pas très cohérent dans toutes les langues, cependant. Si je ne me trompe pas, en PHP urlencode() traite les espaces comme + alors que Python urlencode() les traite comme %20.

MODIFIER:

Il semble que je me trompe. Python urlencode() (au moins en 2.7.2) utilise quote_plus() au lieu de quote() et encode ainsi les espaces comme "+". Il semble aussi 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 traqueur de problèmes de Python sur ce qu'il faut utiliser pour encoder des espaces: http://bugs.python.org/issue13866.

EDIT # 2:

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

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

>>> '+=%2B+'

20
2017-10-27 23:31



Un espace peut uniquement être codé à "+" dans la partie de requêtes "paires de valeurs-clés" de type de contenu "application / x-www-form-urlencoded" d'une URL. C'est un MAI, pas un MUST. Dans le reste des URL, il est codé en% 20.

À mon avis, il vaut mieux toujours coder les espaces comme% 20, pas comme "+", 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 encodés comme " + Application "in" / x-www-form-urlencoded "paire valeur-clé de type contenu. (voir 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, par exemple, recherchez les paragraphes pertinents sur application / x-www-form-urlencoded dans HTML 4.01 Specification, et ainsi de suite .

Voici un exemple de chaîne dans l'URL où la spécification HTML permet d'encoder les espaces comme des plus: "http://example.com/over/there?name=foo+barAinsi, seulement après "?", Les espaces peuvent être remplacés par des plus, selon la spécification HTML Dans d'autres cas, les espaces devraient être codés en% 20. Mais comme il est difficile de déterminer correctement le contexte, c'est la meilleure pratique. ne codez jamais les espaces comme "+".

Je recommande de coder en pourcentage tous les caractères sauf "non réservé" défini dans la 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 encoder en UTF-8, puis encodez le résultat.


7
2017-10-27 19:29