URL encoder decoder : maîtriser le percent-encoding et la RFC 3986
Pourquoi les URLs doivent être encodées
Les URLs (Uniform Resource Locators) ne peuvent contenir qu'un sous-ensemble restreint de caractères ASCII. La RFC 3986 (IETF, 2005) définit précisément quels caractères sont autorisés dans chaque composant d'une URI : les lettres non accentuées (a-z, A-Z), les chiffres (0-9) et quelques caractères spéciaux (-, _, ., ~). Tous les autres caractères, y compris les espaces, les accents, les symboles et les caractères Unicode, doivent être convertis en percent-encoding.
Sans encodage correct, les URLs contenant des caractères spéciaux peuvent provoquer des erreurs HTTP 400, des problèmes d'interopérabilité entre systèmes, ou pire, des failles de sécurité (injection de paramètres, open redirect). Le percent-encoding est donc un pilier fondamental du fonctionnement du web.
Percent-encoding : caractère → % + valeur hexadécimale de l'octet UTF-8
Le percent-encoding expliqué
Le percent-encoding remplace chaque caractère non autorisé par un signe % suivi de deux chiffres hexadécimaux représentant la valeur de l'octet. Pour les caractères multi-octets (UTF-8), chaque octet est encodé séparément. Par exemple, le caractère "é" (U+00E9) s'encode en UTF-8 sur deux octets (0xC3 0xA9), ce qui donne %C3%A9.
Catégories de caractères dans les URLs (RFC 3986)
Source : RFC 3986, Section 2
encodeURI vs encodeURIComponent : quelle fonction utiliser ?
JavaScript propose deux fonctions d'encodage qui servent des objectifs différents. Le choix entre les deux est une source fréquente de bugs.
encodeURI()
URL complète
Préserve :, /, ?, #, &, = (structure de l'URL)
encodeURIComponent()
Composant seul
Encode tout sauf a-z, 0-9, -, _, ., ~
encodeURI() est conçu pour encoder une URL complète en préservant sa structure. Il n'encode pas les caractères ayant un rôle syntaxique dans les URLs (/, ?, #, &, =). encodeURIComponent() encode un composant individuel d'URL (une valeur de paramètre, un segment de chemin) et encode tous les caractères réservés. En règle générale, utilisez encodeURIComponent() pour les valeurs de query string.
Exemple illustré : construire une URL avec des paramètres
Prenons le cas d'une recherche sur un site francophone avec des paramètres contenant des espaces et des accents.
Recherche : "café crème", catégorie : "boissons chaudes"
q=café crème&cat=boissons chaudes encodeURIComponent() sur chaque paramètre individuellement
q=caf%C3%A9%20cr%C3%A8me&cat=boissons%20chaudes Assembler avec la base URL et les séparateurs
https://exemple.fr/recherche?q=caf%C3%A9%20cr%C3%A8me&cat=boissons%20chaudes RFC 3986
Standard IETF définissant la syntaxe des URIs et les règles de percent-encoding (2005)
Espaces dans les URLs : %20 ou + ?
Les espaces dans les URLs sont une source de confusion récurrente. Dans les chemins d'URL et les fragments, les espaces s'encodent en %20 conformément à la RFC 3986. Dans les corps de formulaires HTML (content-type application/x-www-form-urlencoded), les espaces s'encodent en +, conformément au standard HTML (anciennement RFC 1738). Les deux sont techniquement valides dans leur contexte respectif, mais %20 est le plus universel et recommandé pour les APIs REST modernes.
API moderne
URL et URLSearchParams gèrent automatiquement l'encodage des paramètres. Préférez new URLSearchParams({q: 'café crème'}) à une concaténation manuelle pour éviter les erreurs d'encodage. Pour tester vos données CSV exportées avec des URLs, utilisez notre convertisseur CSV vers JSON.Sécurité et encodage URL
Un encodage URL incorrect peut créer des vulnérabilités. Les attaques par injection de paramètres exploitent les valeurs non encodées pour injecter des séparateurs (&, =) supplémentaires. Les attaques open redirect manipulent des URLs dans les paramètres pour rediriger vers des sites malveillants. Un double encodage (%2520 au lieu de %20) peut contourner les filtres de validation. Vérifiez l'intégrité de vos données avec notre générateur de hash SHA.
Double encodage
%20 est encodé une seconde fois, il devient %2520, ce qui sera interprété comme le texte littéral "%20" au lieu d'un espace. Vérifiez toujours si votre framework n'encode pas déjà automatiquement les paramètres.Erreurs fréquentes à éviter
- Utiliser encodeURI() pour les valeurs de paramètres.
encodeURI()ne encode pas &, =, #, ce qui casse la structure de la query string. UtilisezencodeURIComponent()pour chaque valeur individuelle. - Encoder manuellement au lieu d'utiliser URLSearchParams. La construction manuelle de query strings (
'?q=' + value) est fragile.URLSearchParamsgère automatiquement l'encodage, les caractères spéciaux et la sérialisation. - Oublier d'encoder les accents dans les URLs. Les navigateurs modernes affichent les URLs avec accents dans la barre d'adresse (IDN), mais la requête HTTP sous-jacente utilise toujours le percent-encoding. Un serveur qui ne décode pas correctement l'UTF-8 retournera une erreur 404.
- Confondre URL encoding et HTML encoding. L'encodage URL (%C3%A9) et l'encodage HTML (é) sont deux mécanismes distincts. Appliquer le mauvais encodage au mauvais contexte produit des résultats corrompus.
- Ne pas gérer l'erreur URIError en décodage.
decodeURIComponent()lève une exception si la séquence percent-encoded est invalide (ex : %ZZ). Encapsulez toujours l'appel dans un try/catch.
Sources et références
- RFC 3986 (IETF, 2005) : Uniform Resource Identifier (URI): Generic Syntax.
- MDN Web Docs, encodeURIComponent() : documentation JavaScript.
- URL Standard (WHATWG) : spécification vivante de l'API URL.
- W3C HTML 5.2, URL-encoded form data : encodage des formulaires.