Qu'est-ce que l'encodage d'URL (et pourquoi les espaces deviennent %20) ?

Vous tombez sur une adresse web parsemée de %20, ou sur un lien de recherche où chaque espace s’est transformé en signe pourcent suivi de deux chiffres, et vous avez l’impression que l’URL est cassée. Ce n’est pas le cas. C’est l’encodage d’URL qui fait son travail, et une fois que vous connaissez la règle qui se cache derrière, cette adresse en apparence cryptique se lit aussi clairement que les mots que vous avez tapés. L’enjeu est réel, car un seul caractère non encodé peut discrètement envoyer un lien au mauvais endroit.

En bref : l’encodage d’URL, aussi appelé encodage pourcent, remplace les caractères dangereux ou ayant une signification particulière dans une adresse web par un signe pourcent suivi de la valeur hexadécimale de leur octet. C’est pourquoi un espace devient %20 et une esperluette à l’intérieur d’une valeur devient %26. C’est entièrement réversible et ce n’est pas du chiffrement, donc n’importe qui peut le décoder.

Pourquoi les URL n’autorisent qu’un ensemble limité de caractères

Une URL a été conçue pour pouvoir être imprimée, saisie et transmise entre des systèmes très différents en toute fiabilité, elle ne peut donc utiliser qu’un petit ensemble de caractères. L’ensemble sûr regroupe les lettres de A à Z et de a à z, les chiffres de 0 à 9, et une poignée de signes comme le trait d’union, le point, le tiret bas et le tilde. Tout le reste risque d’être mal interprété en chemin.

Le problème, c’est que le texte que vous voulez glisser dans une URL reste rarement dans cet ensemble. Les termes de recherche contiennent des espaces. Les noms portent des accents. Les valeurs comportent de la ponctuation. L’espace, en particulier, n’a tout simplement pas sa place dans une URL : s’il passe tel quel, certains systèmes le suppriment, d’autres cassent le lien, et d’autres encore coupent l’adresse en deux. Plutôt que d’espérer que chaque système traite les caractères bizarres de la même façon, l’encodage d’URL convertit les caractères à risque dans une forme que tous les systèmes comprennent déjà.

Comment l’encodage pourcent transforme un espace en %20

L’encodage pourcent suit une seule règle. Prenez le caractère dangereux, cherchez la valeur hexadécimale de son octet, et écrivez un signe pourcent suivi de ces deux chiffres hexadécimaux. Le signe pourcent est le drapeau qui annonce « un caractère encodé suit », et les deux chiffres sont la valeur. Un espace correspond à l’octet 32, soit 20 en hexadécimal, donc un espace devient %20. Une esperluette devient %26. Un dièse devient %23.

Comme la règle est mécanique et fixe, elle fonctionne dans les deux sens. L’encodage parcourt le texte et remplace chaque caractère dangereux par son code pourcent. Le décodage repère chaque signe pourcent, lit les deux chiffres suivants et restitue le caractère d’origine. Il n’y a ni devinette ni clé, c’est pourquoi un encodeur et décodeur d’URL sur dev.hivly.net peut convertir une chaîne dans un sens comme dans l’autre en une seule étape et vous rendre une copie exacte de l’original.

Caractères réservés et caractères à simplement échapper

Voici le point qui embrouille tout le monde : certains caractères ne sont pas interdits, ils sont réservés, c’est-à-dire qu’ils portent une signification structurelle dans une URL. Le point d’interrogation marque le début de la chaîne de requête. L’esperluette sépare un paramètre du suivant. Le signe égal relie un nom à sa valeur. La barre oblique découpe le chemin, et le dièse marque un fragment. Ces caractères sont autorisés précisément parce que l’URL en a besoin pour délimiter ses propres parties.

Un caractère peut donc figurer dans une URL pour deux raisons différentes, et cela change la décision de l’encoder ou non. Quand une barre oblique sépare des dossiers dans le chemin, elle reste une barre oblique. Quand une esperluette sépare deux paramètres de requête, elle reste une esperluette. Vous n’encodez ces caractères réservés que lorsqu’ils apparaissent à l’intérieur d’une valeur et que vous voulez les traiter comme du texte ordinaire plutôt que comme de la structure. Tout ce qui se trouve en dehors de l’ensemble sûr, comme les espaces et les accents, est toujours encodé, quel que soit l’endroit où il se situe.

Pourquoi on encode les valeurs mais pas les séparateurs

Voyez une URL comme un formulaire avec des cases étiquetées, et les caractères réservés comme les étiquettes. La structure d’une chaîne de requête est ?name=value&name=value, où le point d’interrogation, les signes égal et les esperluettes tiennent la forme en place. Ces séparateurs doivent rester bruts, car ce sont eux qui indiquent au système destinataire où finit un morceau et où commence le suivant. Encodez-les et vous effacez la structure.

Les données que vous déposez dans chaque case sont une autre histoire. Supposons qu’une valeur de recherche soit tom & jerry. Si vous la collez telle quelle, l’esperluette est lue comme un séparateur et le système croit que vous avez envoyé deux paramètres, coupant votre valeur en deux. Encodez cette esperluette interne en %26 et elle reste une partie de la valeur, une esperluette littérale et non un séparateur. Il en va de même pour un signe égal ou une barre oblique qui appartiennent à la valeur. La règle en pratique : laissez tranquilles les séparateurs qui construisent l’URL, et encodez le contenu que vous y versez.

La particularité du signe plus dans l’encodage de formulaire

Il existe deux traditions légèrement différentes pour gérer un espace, et l’écart entre les deux provoque une vraie confusion. L’encodage pourcent standard utilise toujours %20 pour un espace, n’importe où dans l’URL. Mais une convention plus ancienne, utilisée quand les navigateurs envoient des formulaires HTML, encode un espace dans la chaîne de requête par un signe plus. Vous verrez donc à la fois a%20b et a+b désigner la même chose, selon la façon dont l’URL a été construite.

Cela compte quand un signe plus est une vraie donnée. Dans le style d’encodage de formulaire, un plus réel que vous voulez conserver doit être écrit %2B, car un simple plus serait lu comme un espace et perdu. La plupart des outils et bibliothèques modernes gèrent correctement les deux styles d’eux-mêmes, vous avez donc rarement à choisir à la main. L’essentiel à retenir est simple : un plus dans une chaîne de requête peut être un espace déguisé, et un plus littéral doit être encodé pour survivre.

L’encodage d’URL est réversible, ce n’est pas du chiffrement

L’encodage d’URL a l’air technique, alors on imagine parfois que les codes pourcent cachent quelque chose. Ce n’est pas le cas. La correspondance est une norme publiée, identique pour tout le monde, sans aucune clé ni aucun secret. Quiconque lit %26 sait qu’il s’agit d’une esperluette, et n’importe quel décodeur retransforme la chaîne entière en texte clair en une seule passe.

Cela fait de l’encodage d’URL un format de transport, de la même famille que le Base64 : un moyen de faire transiter du texte en toute sécurité dans un canal aux règles strictes, et non un moyen de le rendre confidentiel. Si une URL transporte une donnée sensible, l’encoder ne change rien à la question de savoir qui peut la lire, car le décodage est gratuit et instantané. Considérez les codes pourcent comme une autre orthographe des mêmes mots, lisible par tous, et vous les utiliserez correctement. Ils permettent à votre lien de survivre au trajet ; ils n’ont jamais été un cadenas sur le contenu.