Ce qu’est vraiment l’encodage d’URL
L’encodage d’URL, aussi appelé encodage pourcent, permet à une URL de transporter des caractères qu’elle n’a pas le droit de contenir. Une URL n’accepte qu’un petit ensemble de lettres ASCII, de chiffres et de signes. Tout le reste — une espace, une lettre accentuée, un emoji, un mot en cyrillique ou en arabe — doit s’écrire % suivi de deux chiffres hexadécimaux pour chaque octet.
La même astuce sert pour les caractères autorisés mais porteurs de sens. Un ? ouvre la requête et un & sépare les paramètres : une recherche sur pain & fromage doit donc envoyer l’esperluette sous la forme %26, sinon le serveur voit deux paramètres au lieu d’un.
C’est tout son rôle : rendre une valeur sûre dans une URL sans en changer le sens. Ce n’est ni une compression, ni un chiffrement, ni un filtre de sécurité.
Comment un caractère devient %XX
L’encodage travaille sur des octets, pas sur des caractères. Le texte est d’abord converti en octets UTF-8, puis chaque octet à encoder s’écrit % suivi de sa valeur hexadécimale.
Un caractère ASCII tient sur un octet : une espace (octet 32, hex 20) devient %20. Les caractères hors ASCII occupent de deux à quatre octets en UTF-8, et chaque octet reçoit son propre échappement :
é→ octets C3 A9 →%C3%A9€→ octets E2 82 AC →%E2%82%AC😀→ octets F0 9F 98 80 →%F0%9F%98%80
Le décodage fait l’inverse : il rassemble les octets puis les lit en UTF-8. Si les octets ont été produits avec un autre jeu de caractères, comme Latin-1, on obtient du charabia — café au lieu de café. Tous les navigateurs et frameworks modernes utilisent l’UTF-8, et vous devriez faire de même.
Réservés, non réservés et l’importance du contexte
La RFC 3986 répartit les caractères d’une URL en deux groupes.
Les caractères non réservés — A–Z a–z 0–9 - . _ ~ — n’ont jamais besoin d’être encodés. C’est permis mais inutile, et un bon encodeur les laisse intacts.
Les caractères réservés — : / ? # [ ] @ ! $ & ' ( ) * + , ; = — structurent l’URL. Faut-il les encoder ? Tout dépend de l’endroit. La / entre deux segments du chemin doit rester une barre ; une / dans un nom de fichier passé en paramètre doit devenir %2F. C’est pourquoi il n’existe pas une seule bonne façon d’« encoder une URL » : on encode chaque morceau selon sa destination.
encodeURIComponent ou encodeURI
JavaScript propose deux fonctions natives, et choisir la mauvaise est le bug d’URL le plus courant.
| Fonction | À utiliser pour | Laisse intacts |
|---|---|---|
encodeURIComponent | Une valeur : un paramètre, un segment de chemin | Seulement les non réservés |
encodeURI | Une adresse complète qui doit rester valide | Aussi les réservés |
Appliquez encodeURI à une valeur comme a&b=c : le & et le = survivent et votre paramètre se transforme en deux. Appliquez encodeURIComponent à une URL entière : chaque / et chaque : sont échappés et le lien n’en est plus un. La règle : construisez l’URL par morceaux et encodez chaque valeur avec encodeURIComponent — ou mieux, laissez URLSearchParams s’en charger.
Les autres langages ont la même séparation : quote et quote_plus en Python, rawurlencode et urlencode en PHP. Notre encodeur et décodeur d’URL propose les deux modes pour voir la différence sur votre propre texte.
+ ou %20 : l’exception des formulaires
Dans un chemin, une espace s’écrit %20 et un + n’est qu’un signe plus. Mais les formulaires HTML envoyés avec le type par défaut application/x-www-form-urlencoded encodent l’espace en + dans la requête, et les serveurs le décodent ensuite.
Les ennuis commencent quand les deux conventions se croisent. Un numéro comme +33 1 23 45 67 89 placé sans encodage dans une requête arrive sous la forme 33 1 23 45 67 89, car le serveur a lu le + comme une espace. La solution : encoder le plus en %2B, ce que fait tout encodeur qui respecte les règles des formulaires. En cas de doute sur la convention attendue, %20 pour l’espace et %2B pour le plus sont toujours sûrs.
Le double encodage et le bug %2520
%25 est la forme encodée du signe pourcent lui-même. Quand vous voyez %2520 dans une URL, c’est donc un %20 encodé une seconde fois : une valeur est passée dans un encodeur alors qu’elle l’était déjà.
Cela se produit généralement à une frontière — un framework encode un paramètre que le code appelant avait déjà encodé, ou une URL de redirection est encodée une fois pour tenir dans une autre URL, puis à nouveau par une bibliothèque. Le symptôme visible : une 404, une recherche du texte littéral %20, ou un nom de fichier truffé de signes pourcent.
Décoder deux fois rend l’original, mais la vraie correction consiste à trouver le second encodeur et à le supprimer. Encodez une seule fois, au moment où la valeur entre dans l’URL.
Encoder n’est ni échapper, ni chiffrer
L’encodage pourcent rend une valeur sûre dans une URL. Il ne protège ni le HTML, ni le JavaScript, ni le SQL. Dès que le serveur décode %3Cscript%3E, il retrouve un <script> tout à fait ordinaire : la sortie doit toujours être échappée selon sa destination, et les requêtes en base doivent toujours utiliser des paramètres.
Ce n’est pas non plus un secret. N’importe qui peut décoder une URL, et les URL finissent dans les journaux du serveur, l’historique, les outils d’analyse et l’en-tête Referer de la page suivante. Ne mettez jamais un mot de passe, un jeton ou des données personnelles dans une requête parce que cela « a l’air brouillé ». C’est vrai aussi de Base64, comme l’explique notre guide Base64.
Quand le décodage échoue
La plupart des problèmes d’URL se ramènent à l’un de ceux-ci :
- « URIError: malformed URI sequence ». Un
%n’est pas suivi de deux chiffres hexadécimaux, ou les octets ne sont pas de l’UTF-8 valide. Un signe pourcent littéral doit lui-même s’envoyer en%25. - Les accents deviennent é ou �. Les octets ont été écrits dans un jeu de caractères et lus dans un autre. Vérifiez que les deux côtés utilisent l’UTF-8.
- Un paramètre est coupé à un &. La valeur n’a pas été encodée, ou l’a été avec
encodeURIau lieu deencodeURIComponent. - Les signes plus deviennent des espaces. Le décodage de formulaire a traité le
+comme une espace. Encodez un vrai plus en%2B. - %2520, %253D et consorts. Double encodage : trouvez le second encodeur.
Collez l’URL dans un décodeur et examinez chaque paramètre séparément : la décomposition rend généralement le problème évident en quelques secondes.
Outils et guides associés :
- Encodeur et décodeur d’URL - Encodez du texte ou une URL entière, décodez les %XX en texte et voyez chaque paramètre.
- Encodeur et décodeur Base64 - Encodez du texte en Base64 ou décodez-le, avec sortie URL-safe et UTF-8 géré.
- Base64 expliqué : comment l’encodage et le décodage fonctionnent
Questions fréquentes
Qu’est-ce que l’encodage d’URL ?⌄
L’encodage d’URL, ou encodage pourcent, écrit les caractères interdits dans une URL sous la forme d’un % suivi de deux chiffres hexadécimaux pour chaque octet UTF-8. Une espace devient %20 et é devient %C3%A9. N’importe quel texte peut ainsi voyager dans une URL sans en changer le sens.
Pourquoi une espace est-elle tantôt + et tantôt %20 ?⌄
Les formulaires HTML envoyés en application/x-www-form-urlencoded encodent l’espace en + dans la requête. Partout ailleurs, y compris dans les chemins et la plupart des API, une espace est %20 et + est un plus littéral. %20 est toujours sûr.
Faut-il utiliser encodeURI ou encodeURIComponent ?⌄
Utilisez encodeURIComponent pour une seule valeur, comme un paramètre ou un segment de chemin, car il encode &, =, / et ?. Réservez encodeURI à une URL complète qui doit garder sa structure.
Que signifie %2520 ?⌄
C’est une espace encodée deux fois : %25 est le signe pourcent, donc %2520 est %20 encodé une seconde fois. Décodez deux fois pour le lire, puis corrigez le code qui encode la valeur deux fois.
L’encodage d’URL est-il sûr ?⌄
Non. N’importe qui peut l’inverser, il n’apporte aucun secret, et une entrée décodée peut encore porter une injection. Échappez la sortie pour le HTML, utilisez des requêtes paramétrées pour les bases de données et ne mettez jamais de secret dans une URL.
Plus de 15 ans d'expérience pratique en développement web et en sécurité. Spécialisé dans la sécurité web concrète : garder les sites sûrs, fiables et faciles à diagnostiquer. BuildToolForge existe pour rendre ces vérifications gratuites, privées et compréhensibles. Les outils s'exécutent dans votre navigateur dès que possible, et rien de ce que vous saisissez dans un outil n'est conservé.
Comment nous rédigeons nos guides : Chaque guide s'appuie sur une expérience de terrain, est vérifié par rapport aux normes officielles et testé avec nos propres outils sur de vrais domaines. Nous mettons les guides à jour quand les normes ou les outils évoluent. Une erreur ? Écrivez-nous à contact@buildtoolforge.com.