Encoder les caractères spéciaux dans les URL : la référence du développeur

Les caractères spéciaux dans les URL

Les URL obéissent à une syntaxe stricte définie par la RFC 3986. De nombreux caractères ont une signification particulière ou sont interdits dans certaines parties d'une URL. Comprendre comment encoder correctement ces caractères est essentiel pour construire des applications web et des API fiables.

Le caractère espace

L'espace est le caractère que l'on encode le plus souvent. Toutefois, il peut être encodé de deux manières selon le contexte :

• %20 - l'encodage pourcent de la RFC 3986, utilisé dans les chemins d'URL et la plupart des contextes
• + - utilisé dans le format application/x-www-form-urlencoded (soumission de formulaires HTML)

Lorsque vous construisez des URL par programmation, privilégiez %20 pour rester cohérent. Lorsque vous constituez les données d'un formulaire, la notation + est la norme.

Les caractères réservés en détail

L'esperluette (&)

L'esperluette sépare les paramètres de requête. Lorsqu'une esperluette apparaît dans la valeur d'un paramètre, elle doit être encodée en %26 afin qu'elle ne soit pas interprétée comme un séparateur. Dans un contexte HTML, elle doit également être encodée sous forme d'entité, à savoir &.

Le point d'interrogation (?)

Le point d'interrogation sépare le chemin de la chaîne de requête. Si un point d'interrogation apparaît dans la valeur d'un paramètre, il doit être encodé en %3F. Notez que encodeURI() n'encode PAS les points d'interrogation, contrairement à encodeURIComponent().

Le dièse (#)

Le dièse marque le début de l'identifiant de fragment. Dans une URL, tout # présent dans la valeur d'un paramètre de requête doit être encodé en %23, faute de quoi le navigateur interprétera tout ce qui suit comme un identifiant de fragment et ne l'enverra pas au serveur.

La barre oblique (/)

Les barres obliques séparent les segments d'un chemin. Lorsqu'une barre oblique apparaît dans la valeur d'un segment de chemin (par exemple un nom de fichier contenant une barre oblique), elle doit être encodée en %2F. Notez que certains serveurs peuvent décoder %2F et continuer à le traiter comme un séparateur de chemin.

Les caractères Unicode

Les caractères non-ASCII sont encodés en les convertissant d'abord en leur séquence d'octets UTF-8, puis en appliquant l'encodage pourcent à chaque octet. Voici quelques exemples :

• Le e accent aigu (é) → UTF-8 : 0xC3 0xA9 → %C3%A9
• Le caractère chinois (中) → UTF-8 : 0xE4 0xB8 0xAD → %E4%B8%AD
• L'émoji (globe) → UTF-8 : 0xF0 0x9F 0x8C 0x8D → %F0%9F%8C%8D

L'encodage selon les composants de l'URL

Composant	À encoder	Exemple
Segment de chemin	Espaces, ?, # et non-ASCII	/path/my%20file
Clé de requête	=, &, #, +, espaces	my%20key=value
Valeur de requête	&, #, +, espaces, =	key=hello%20world
Fragment	Espaces et non-ASCII	#section%20one

Les pièges courants

• Oublier d'encoder # dans les valeurs de requête (le reste de l'URL est alors ignoré sans avertissement)
• Encoder deux fois une chaîne déjà encodée (ce qui produit %2520 au lieu de %20)
• Utiliser encodeURI() au lieu de encodeURIComponent() pour les valeurs de paramètres
• Ne pas encoder + dans les valeurs de requête (il est alors décodé comme un espace)
• Supposer que tous les serveurs traitent %2F de la même façon dans les chemins