Encodage d'URL expliqué : pourquoi les espaces deviennent %20

Vous l'avez vu dans les adresses Web : %20 où un espace devrait être, ou %3D au lieu d'un signe égal. Il s'agit du codage d'URL (également appelé codage en pourcentage), et même si cela ressemble à du charabia, il résout un réel problème qui permet au Web de fonctionner. Voici ce qui se passe.

Pourquoi les URL doivent-elles être codées

Les URL ne peuvent contenir en toute sécurité qu'un ensemble limité de caractères : des lettres, des chiffres et quelques symboles. De nombreux caractères ont une signification particulière (? démarre une chaîne de requête, & sépare les paramètres, / sépare les segments de chemin) ou ne sont pas autorisés du tout (espaces). Si vous insérez ces caractères dans une URL tels quels, les navigateurs et les serveurs sont confus. L'encodage les remplace par une représentation sûre.

Comment ça marche

Le codage en pourcentage remplace un caractère non sécurisé par un % suivi de sa valeur d'octet hexadécimal à deux chiffres. Un espace est l'octet 32, qui est 20 en hexadécimal — donc %20. Un signe égal devient %3D, une esperluette %26, et ainsi de suite. Encodez ou décodez n'importe quelle chaîne instantanément avec notre encodeur d'URL et notre décodeur d'URL.

Un exemple pratique

Supposons que vous souhaitiez une URL de recherche pour "café et bar". L'espace et l'esperluette doivent être codés :

https://example.com/search?q=caf%C3%A9%20%26%20bar

L'avis "é" est devenu %C3%A9 — les caractères non-ASCII sont codés sous la forme de leurs octets UTF-8, qui peuvent être supérieurs à une paire de pour cent. La référence de codage en pourcentage MDN couvre les détails.

Là où cela compte

• Paramètres de requête : les entrées utilisateur dans la recherche et les formulaires doivent être codées afin que les caractères spéciaux ne brisent pas l'URL.
• API : la transmission de valeurs dans une URL nécessite un encodage pour rester valide.
• Liens avec suivi : les URL des campagnes contiennent souvent des valeurs codées.

Pièges courants

Deux grands : le double encodage (encodage d'une chaîne déjà encodée, transformant %20 en %2520) et l'oubli d'encoder les entrées de l'utilisateur, ce qui peut rompre des liens ou ouvrir des failles de sécurité. En cas de doute, décodez une URL pour vérifier ce qu'elle contient réellement.

Caractères réservés ou non réservés

Tous les caractères n'ont pas besoin d'être codés. La norme définit les caractères non réservés : lettres, chiffres et - _ . ~ — qui sont toujours sûrs tels quels. Caractères réservés comme / ? # & = ont une signification structurelle particulière dans une URL, ils doivent donc être codés lorsqu'ils sont utilisés comme données plutôt que comme séparateurs. C'est la raison pour laquelle vous encodez les entrées utilisateur : un terme de recherche contenant "&" doit devenir %26, sinon le "&" serait mal interprété comme le début d'un nouveau paramètre.

Les signes plus et la confusion spatiale

Un piège classique : dans la chaîne de requête des anciens formulaires soumis, un espace est parfois codé en + plutôt qu'en %20, car c'est ainsi que fonctionnaient historiquement les données de formulaire HTML (le format application/x-www-form-urlencoded). Dans le chemin d'une URL, un espace est toujours %20 et un + littéral signifie un plus. Cette division explique pourquoi le même « espace » peut apparaître de deux manières et pourquoi le décodage d'un mauvais contexte peut corrompre les données. En cas de doute, décodez et inspectez.

Encodage et sécurité

Un encodage approprié ne concerne pas seulement les liens valides : c'est une limite de sécurité. Ne pas encoder (ou valider) les entrées utilisateur qui aboutissent dans une URL peut permettre des attaques par injection et des redirections interrompues. Les frameworks fournissent généralement des fonctions d'encodage intégrées ; utilisez-les plutôt que de les lancer manuellement et ne faites jamais confiance aux entrées brutes de l'utilisateur dans une URL. Un encodage correct maintient à la fois vos liens valides et votre application plus sûre.

Résultat

L'encodage d'URL remplace les caractères dangereux par un % plus leur valeur d'octet hexadécimal, de sorte que les URL restent valides, quel que soit ce qu'elles contiennent. Les espaces deviennent %20, les symboles spéciaux obtiennent leurs propres codes et les caractères non-ASCII utilisent leurs octets UTF-8. Encodez les entrées de l'utilisateur, évitez le double encodage et utilisez un outil pour vérifier : ces signes de pourcentage énigmatiques cesseront d'être un mystère.