Une URL est-elle autorisée à contenir un espace?

Un URI (en particulier une URL HTTP) est-il autorisé à contenir un ou plusieurs espaces? Si une URL doit être encodée, est-ce +juste une convention couramment suivie ou une alternative légitime?

En particulier, quelqu'un peut-il pointer vers une RFC qui indique qu'une URL avec un espace doit être encodée?

Motivation pour la question: lors du test bêta d'un site Web, j'ai noté que certaines URL étaient construites avec des espaces. Firefox semblait faire la bonne chose, ce qui m'a surpris! Mais je voulais pouvoir diriger les développeurs vers une RFC afin qu'ils ressentent le besoin de corriger ces URL.

Selon RFC 1738 :

Peu sûr:

Les caractères peuvent être dangereux pour un certain nombre de raisons. Le caractère espace n'est pas sûr car des espaces importants peuvent disparaître et des espaces insignifiants peuvent être introduits lorsque les URL sont transcrites ou composées ou soumises au traitement de programmes de traitement de texte. Les caractères "<"et ne ">"sont pas sûrs car ils sont utilisés comme délimiteurs autour des URL en texte libre; le guillemet ( """) est utilisé pour délimiter les URL dans certains systèmes. Le caractère "#"n'est pas sûr et doit toujours être codé car il est utilisé dans le World Wide Web et dans d'autres systèmes pour délimiter une URL d'un identifiant de fragment / d'ancrage qui pourrait le suivre. Le personnage"%"est dangereux car il est utilisé pour les encodages d'autres caractères. D'autres caractères ne sont pas sûrs car les passerelles et autres agents de transport sont connus pour modifier parfois ces caractères. Ces personnages sont "{", "}", "|", "\", "^", "~", "[", "]"et "`".

Tous les caractères non sécurisés doivent toujours être encodés dans une URL . Par exemple, le caractère "#"doit être codé dans les URL, même dans les systèmes qui ne traitent normalement pas les identificateurs de fragment ou d'ancrage, de sorte que si l'URL est copiée dans un autre système qui les utilise, il ne sera pas nécessaire de modifier le codage de l'URL.

Pourquoi doit-il être encodé? Une demande ressemble à ceci:

GET /url HTTP/1.1
(Ignoring headers)

Il y a 3 champs séparés par un espace blanc. Si vous mettez un espace dans votre URL:

GET /url end_url HTTP/1.1

Vous savez que vous avez 4 champs, le serveur HTTP vous dira que c'est une requête invalide.

GET /url%20end_url HTTP/1.1

3 champs => valide

Remarque: dans la chaîne de requête (après?), Un espace est généralement encodé en +

GET /url?var=foo+bar HTTP/1.1 

plutôt que

GET /url?var=foo%20bar HTTP/1.1 

Réponse plus courte: non, vous devez encoder un espace; il est correct d'encoder un espace comme +, mais uniquement dans la chaîne de requête; dans le chemin que vous devez utiliser %20.

Les URL sont définies dans la RFC 3986 , bien que d'autres RFC soient également pertinentes, mais la RFC 1738 est obsolète.

Ils peuvent ne pas avoir d'espaces, ainsi que de nombreux autres caractères. Puisque ces caractères interdits doivent souvent être représentés d'une manière ou d'une autre, il existe un schéma pour les encoder dans une URL en les traduisant en leur équivalent hexadécimal ASCII avec un préfixe «%».

La plupart des langages / plates-formes de programmation fournissent des fonctions d'encodage et de décodage d'URL, même s'ils ne respectent pas correctement les normes RFC. Par exemple, je sais que PHP ne le fait pas.

Oui, cependant, l'espace est généralement codé en "% 20". Tous les paramètres qui passent à une URL doivent être encodés, simplement pour des raisons de sécurité.

L'URL peut contenir un caractère d'espace et elle sera affichée sous la forme% 20 dans la plupart des navigateurs, mais les règles de codage du navigateur changent assez souvent et nous ne pouvons pas dépendre de la façon dont un navigateur affichera l'URL.

Donc, à la place, vous pouvez remplacer le caractère d'espace dans l'URL par n'importe quel caractère qui, selon vous, rendra l'URL plus lisible et "Jolie";) ..... O les caractères généraux qui sont préférés sont "-", "_", "+" .... mais ce ne sont pas les compulsions donc vous pouvez utiliser n'importe quel caractère qui n'est pas censé être déjà dans l'URL.

Veuillez éviter les%, &,}, {,], [, /,>, <comme remplacement du caractère de l'espace URL car ils peuvent générer une erreur sur certains navigateurs et plates-formes.

Comme vous pouvez le voir, le débordement Stak lui-même utilise le caractère «-» comme espace de remplacement (% 20).

Ayez un bon questionnement.

Les URL ne doivent pas contenir d'espaces. Si vous devez en résoudre un qui le fait, utilisez sa valeur codée de%20

Quelqu'un peut-il pointer vers un RFC indiquant qu'une URL avec un espace doit être encodée?

Les URI, et donc les URL, sont définis dans la RFC 3986.

Si vous regardez la grammaire définie là-bas, vous remarquerez finalement qu'un caractère espace ne peut jamais faire partie d'une URL syntaxiquement légale, donc le terme «URL avec un espace» est une contradiction en soi.

Pour répondre à ta question. Je dirais qu'il est assez courant pour les applications de remplacer les espaces dans les valeurs qui seront utilisées dans les URL. La raison en est généralement d'éviter le codage en pourcentage (URI) plus difficile à lire.

Consultez cet article de wikipedia sur l' encodage en pourcentage .

Firefox 3 affichera les %20s dans les URL sous forme d'espaces dans la barre d'adresse.