Les erreurs d'encodage d'URL que les développeurs commettent encore (et corrigent)

URL sont subtils, persistants et souvent découverts en production. Un %20 égaré, une esperluette doublement codée ou un + confus par rapport à l'espace peut interrompre les appels d'API, corrompre les données de suivi et créer des failles de sécurité. Réparons les plus courants.

Testez votre encodage avec notre outil URL Encoder/Decoder — collez n'importe quelle chaîne et voyez instantanément le résultat encodé.

encodeURI contre encodeURIComponent

JavaScript a deux fonctions d'encodage intégrées, et l'utilisation de la mauvaise est la première source de bugs :

// WRONG — encodeURI préserve & dans les valeurs de requête
const url = 'https://api.example.com/search?q=' + encodeURI('tom & jerry');
// Résultat : https://api.example.com/search?q=tom%20&%20jerry
// Le & est conservé — il ressemble désormais à un paramètre distinct ! // CORRECT
const url = 'https://api.example.com/search?q=' + encodeURIComponent('tom & jerry');
// Résultat : https://api.example.com/search?q=tom%20%26%20jerry
Règle générale : Utilisez encodeURIComponent pour les valeurs individuelles. Utilisez encodeURI uniquement lorsque vous disposez d'une URL complète qui nécessite uniquement l'encodage de caractères non-ASCII.
Bogues de double encodage
Le double encodage se produit lorsqu'une chaîne déjà encodée est à nouveau encodée :
const nom = 'bonjour tout le monde' ;
const encodé = encodeURIComponent(nom); // bonjour%20monde
const doublé = encodeURIComponent (codé); // bonjour%2520world
// %25 est l'encodage de % lui-même !
Cela se produit généralement lorsque :
Un framework encode automatiquement les paramètres de requête, et vous les pré-encodez également
Une URL est codée avant d'être stockée, puis à nouveau codée une fois récupérée
Middleware traite l'URL sur plusieurs couches, chacune ajoutant un codage
Détection
Recherchez %25 dans les URL : c'est presque toujours le signe d'un double encodage. La séquence %2520 (espace doublement codé) est le témoin classique.
La confusion + vs %20
Dans les soumissions de formulaire HTML (application/x-www-form-urlencoded), les espaces deviennent +. Dans le codage en pourcentage standard (RFC 3986), les espaces deviennent %20.
C'est important car :
decodeURIComponent ne pas décode + dans l'espace - il le laisse comme un littéral +
Les frameworks backend peuvent ou non décoder automatiquement + en fonction de l'analyseur
Si votre API attend %20 mais reçoit +, la recherche de "red+car" renvoie les résultats pour "red+car" (avec un plus littéral) au lieu de "red car" 
// Décodage sécurisé qui gère à la fois + et %20
fonction safeDecodeParam(value) { return decodeURIComponent(value.replace(/\+/g, '%20'));
}
Cas Edge UTF-8
Caractères non ASCII comme é, ü, 日本語 et les emoji doivent être codés en pourcentage sous forme de séquences d'octets UTF-8 :
encodeURIComponent('café') // caf%C3%A9
encodeURIComponent('日本語') // %E6%97%A5%E6%9C%AC%E8%AA%9E
encodeURIComponent('🔒') // %F0%9F%94%92
Des problèmes surviennent lorsque :
Le serveur attend Latin-1 mais reçoit UTF-8 (mojibake — caractères tronqués)
Les colonnes de la base de données ne sont pas définies sur UTF-8, ce qui tronque silencieusement les caractères multi-octets
Les fichiers journaux interprètent les chaînes codées avec un mauvais jeu de caractères
Pièges des URL de redirection et de rappel
Les rappels OAuth et les URL de redirection sont particulièrement sujets aux bugs d'encodage :
// Création d'une redirection OAuth
const redirectUri = 'https://myapp.com/callback?source=oauth';
const authUrl = `https://provider.com/auth?redirect_uri=${encodeURIComponent(redirectUri)}`;
// Correct : l'intégralité de l'URL de rappel (y compris la sienne ?) est codée sous la forme d'un seul paramètre value
Erreurs courantes :
Ne pas encoder du tout le redirect_uri — le ? dans le rappel divise l'URL parent
Encodage partiel du redirect_uri — encodage du chemin mais pas de la requête
Encodage de l'intégralité de l'URL d'authentification au lieu de simplement la valeur du paramètre
Ces bogues créent souvent des vulnérabilités de redirection ouverte que les attaquants exploitent à des fins de phishing.
Liste de contrôle de débogage
Lorsqu'une URL ne fonctionne pas comme prévu, vérifiez-les dans l'ordre :
Recherchez %25 — indique un double encodage
Check + vs %20 — les espaces sont-ils traités de manière cohérente ?
Inspecter la demande brute — utilisez l'onglet Réseau DevTools du navigateur pour voir l'URL codée réelle envoyée
Test avec des caractères spéciaux — essayez & = ? # / dans les valeurs pour voir si elles cassent la structure de l'URL
Check Content-Type — le serveur est-il analysé comme application/x-www-form-urlencoded ou application/json?
Vérifiez le décodage sur le serveur — enregistrez les valeurs brutes et décodées côté serveur
Fonctions d'assistance sécurisées
// Créer une chaîne de requête en toute sécurité
fonction buildQueryString (params) { renvoyer Object.entries (params) .map(([clé, valeur]) => `${encodeURIComponent(key)}=${encodeURIComponent(value)}` ) .join('&');
} // Utiliser URLSearchParams (navigateurs modernes + Node.js)
const params = new URLSearchParams({ q: 'tom & jerry', page: '1' });
URL const = `https://api.example.com/search?${params}`;
// Correct : gère automatiquement l'encodage
Meilleure pratique : Utilisez le constructeur URLSearchParams ou URL au lieu de la concaténation manuelle des chaînes. Ils gèrent correctement l'encodage par défaut.
FAQ
Pourquoi + devient-il un espace ?
Il s'agit d'un héritage du codage de formulaire HTML (application/x-www-form-urlencoded), où les espaces sont codés comme +. Dans le codage en pourcentage standard (RFC 3986), les espaces sont %20. La convention + s'applique uniquement aux chaînes de requête dans les soumissions de formulaires, et non aux segments de chemin ou à d'autres parties d'URL.
Comment encoder correctement les URL imbriquées ?
Utilisez encodeURIComponent sur l'URL interne avant de la placer dans le paramètre de requête de l'URL externe. Cela code des caractères comme  :/? qui seraient autrement interprétés comme faisant partie de la structure de l'URL externe.
Pourquoi les signatures sont-elles rompues après le codage de l'URL ?
Les signatures sont calculées sur des séquences d'octets exactes. Si vous signez une chaîne avant l'encodage (ou après le décodage), mais que vous la vérifiez sous forme codée (ou vice versa), les octets diffèrent et la signature échoue. Normalisez toujours l'encodage avant de signer.
Outils et articles connexes
URL Encodeur/Décodeur — tester l'encodage en temps réel
Erreurs de sécurité JWT — l'encodage est également important pour la gestion des jetons
Correction d'incompatibilité de somme de contrôle — lors des modifications d'encodage, hachages de fichiers corrompus