Dans une URL, les espaces doivent-ils être codés en utilisant %20 ou + ?

Question

Dans une URL, dois-je coder les espaces en utilisant la méthode suivante %20 ou + ? Par exemple, dans l'exemple suivant, lequel est correct ?

www.mydomain.com?type=xbox%20360
www.mydomain.com?type=xbox+360

Notre entreprise penche pour la première solution, mais utilise la méthode Java. URLEncoder.encode(String, String) con "xbox 360" (et "UTF-8" ) renvoie ce dernier .

Alors, quelle est la différence ?

Answer 1

Les données de formulaire (pour GET ou POST) sont généralement codées en tant que application/x-www-form-urlencoded : ceci précise + pour les espaces.

Les URL sont codées comme RFC 1738 qui précise %20 .

En théorie, je pense que vous devriez avoir %20 avant l'élément ? et + après :

example.com/foo%20bar?foo+bar

Answer 2

Selon le W3C (et ils sont la source officielle sur ces choses), un caractère d'espace dans la chaîne de requête (et dans la chaîne de requête seulement) peut être encodé soit comme " %20 " ou " + ". De la section "Chaînes de requête" sous "Recommandations" :

Dans la chaîne de requête, le signe plus est réservé à la notation abrégée d'un espace. Par conséquent, les vrais signes plus doivent être encodés. Cette méthode a été utilisée pour faciliter le passage des URI de requête dans les systèmes qui n'autorisent pas les espaces.

Selon la section 3.4 du RFC2396 qui est la spécification officielle sur les URI en général, le composant "query" est dépendant de l'URL :

3.4. Composant de la requête Le composant de la requête est une chaîne d'informations qui doit être interprétée par la ressource.

   query         = *uric

Dans un composant de requête, les caractères " ;", "/", " ?", " :", "@", "&", "=", "+", ",", et "$" sont réservés.

Il s'agit donc d'un bogue dans l'autre logiciel s'il n'accepte pas les URL avec des espaces dans la chaîne de requête encodée en " + " personnages.

Pour ce qui est de la troisième partie de votre question, il existe un moyen (bien qu'un peu laid) de corriger la sortie de l'application URLEncoder.encode() est alors de appelez replaceAll("\\+","%20") sur la valeur de retour.

Answer 3

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

Prendre " http://www.google.com " par exemple. Il s'agit d'une URL. UNE URL est un Localisateur de Ressources Uniformes 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 le " http://www.google.com " URL :

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

Si l'on considère un plus URL plus complexe comme " https://bob:bobby@www.lunatech.com:8080/file;p=1?q=2#troisième "nous pouvons extraire les informations suivantes :

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

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

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

Maintenant, dans la partie requête, les espaces peuvent être encodés soit en "+" (pour la compatibilité ascendante : 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é en "%2B". ambiguïté) doit être échappé en "%2B".

Cela signifie que la chaîne de caractères "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 l'encodage d'une URL entièrement construite est impossible sans une connaissance syntaxique de la structure de l'URL.

Ce qui revient à dire que

vous devriez avoir %20 avant le ? y + après

Source :

Answer 4

Il ne devrait pas pas plus que si vous encodiez la lettre A en %41.

Cependant, si vous avez affaire à un système qui ne reconnaît pas un formulaire, il semble que vous deviez lui donner ce qu'il attend, indépendamment de ce que dit la "spécification".

Answer 5

Vous pouvez utiliser l'un ou l'autre, mais la plupart des gens optent pour "+" car il est plus lisible pour l'homme.