Encodeur et Décodeur URL : Traitez les adresses Web en toute sécurité

Pourquoi les URL ont besoin d'encodage

Une URL est composée de caractères — et tous ne sont pas « sûrs » à utiliser directement. Les URL sont transmises sur Internet à travers des systèmes qui peuvent interpréter certains caractères comme ayant une signification particulière (comme ? pour les chaînes de requête, & pour séparer les paramètres, ou # pour les identifiants de fragment). D'autres caractères peuvent être non-ASCII (comme des lettres chinoises ou arabes), et certains peuvent être corrompus par une ancienne infrastructure HTTP.

L'encodage d'URL (officiellement appelé percent-encoding) résout ce problème en remplaçant les caractères non sûrs par un % suivi de la représentation hexadécimale à deux chiffres de la valeur d'octet du caractère.

Un espace (0x20) → %20
Un arobase (0x40) → %40
Un slash (0x2F) → %2F

---

La norme RFC

L'encodage d'URL est défini dans la RFC 3986 (Uniform Resource Identifiers). Selon cette norme :

Caractères non réservés — peuvent être utilisés en toute sécurité n'importe où dans une URL sans encodage :

• A–Z, a–z, 0–9
• -, _, ., ~

Caractères réservés — ont une signification particulière dans les URI et doivent être percent-encodés lorsqu'ils sont utilisés comme données :

• : / ? # [ ] @ ! $ & ' ( ) * + , ; =

Tout le reste — y compris les espaces, les caractères non-ASCII et les caractères comme ", <, >, {, } — doit être percent-encodé.

---

Le percent-encoding en pratique

Encoder un espace

Le caractère espace (U+0020) est encodé en %20. On voit aussi parfois + à la place de %20 dans les chaînes de requête — cela vient du standard d'encodage des formulaires HTML (application/x-www-form-urlencoded), où les espaces sont encodés en +. Les deux sont distincts :

• %20 — percent-encoding RFC 3986 (espaces dans les chemins et les en-têtes)
• + — encodage de formulaires HTML (espaces dans les chaînes de requête)

Lors du décodage, identifiez toujours quelle convention s'applique pour éviter les bugs.

Caractères non-ASCII

Les caractères non-ASCII sont d'abord encodés en UTF-8, puis chaque octet est percent-encodé :

Caractère chinois 中 (U+4E2D)
Octets UTF-8 : 0xE4 0xB8 0xAD
Percent-encodé : %E4%B8%AD

Ainsi, le mot français café contient le caractère é (U+00E9) qui sera encodé en %C3%A9 en UTF-8.

---

Fonctions d'encodage JavaScript

JavaScript fournit plusieurs fonctions intégrées pour l'encodage d'URL :

encodeURI()

Encode une URI complète — conçue pour encoder une URL entière tout en préservant sa structure. Elle n'encode pas les caractères qui font partie de la syntaxe URI : ; , / ? : @ & = + $ #.

encodeURI("https://example.com/search?q=bonjour monde&lang=français")
// "https://example.com/search?q=bonjour%20monde&lang=fran%C3%A7ais"

encodeURIComponent()

Encode un composant d'URI — conçue pour encoder des valeurs individuelles comme les valeurs de paramètres de requête. Elle encode tout sauf A–Z a–z 0–9 - _ . ! ~ * ' ( ).

encodeURIComponent("bonjour monde & plus")
// "bonjour%20monde%20%26%20plus"

encodeURIComponent("https://example.com")
// "https%3A%2F%2Fexample.com"

Quand utiliser laquelle

Scénario	Fonction
Encoder une URL complète	encodeURI()
Encoder une valeur de paramètre de requête	encodeURIComponent()
Encoder un segment de chemin	encodeURIComponent()
Encoder une URL à intégrer dans une autre URL	encodeURIComponent()

Les fonctions de décodage complémentaires

decodeURI(encodedURI)
decodeURIComponent(encodedComponent)

N'utilisez jamais les fonctions obsolètes escape() et unescape() — elles gèrent les caractères non-ASCII différemment et produisent des résultats incorrects.

---

Pièges courants et erreurs fréquentes

Double encodage

Un bug fréquent consiste à encoder une chaîne déjà encodée :

encodeURIComponent(encodeURIComponent("bonjour monde"))
// "bonjour%2520monde"
// %25 est l'encodage de %, donc %20 est devenu %2520

Vérifiez toujours si la valeur est déjà encodée avant de l'encoder.

Le piège + vs %20

Si vous décodez avec decodeURIComponent une chaîne de requête qui utilise + pour les espaces, le + ne sera pas décodé en espace — vous devez d'abord remplacer + par %20, ou utiliser l'API URLSearchParams :

new URLSearchParams("q=bonjour+monde").get("q")
// "bonjour monde" ✓

decodeURIComponent("bonjour+monde")
// "bonjour+monde" ✗ — toujours un signe plus littéral

Identifiants de fragment

Le caractère # dans les URL marque le début d'un identifiant de fragment (pour les ancres dans la page). Si vos données contiennent un #, il doit être encodé en %23, sinon le navigateur traitera tout ce qui suit comme un fragment.

Noms de domaine internationalisés (IDN)

Les noms de domaine avec des caractères non-ASCII (comme bücher.de) utilisent l'encodage Punycode, pas le percent-encoding. Les navigateurs convertissent les IDN en Punycode en interne : bücher.de → xn--bcher-kva.de.

---

Référence de structure d'URL

Une URL possède les composants suivants (selon RFC 3986) :

scheme://userinfo@host:port/path?query#fragment

Composant	Exemple	Règles d'encodage
Scheme	https	Lettres, chiffres, +, -, .
Host	example.com	Labels de domaine + points
Port	8080	Chiffres uniquement
Path	/search/results	Encodé avec %XX sauf non-réservés + :@!$&'()*+,;=
Query	q=bonjour+monde	+ pour les espaces dans les formulaires, %20 en général
Fragment	#section-2	Non envoyé au serveur ; navigateur uniquement

---

Considérations côté serveur

Normalisation des URL

Les serveurs doivent normaliser les URL avant de les traiter — par exemple, traiter %41 (qui se décode en A) de la même façon que A. Cependant, certains caractères ont des significations différentes encodés vs non encodés : / vs %2F dans les chemins — de nombreux serveurs web les traitent différemment pour des raisons de sécurité (protection contre le path traversal).

Injection SQL via les paramètres d'URL

Assainissez et validez toujours les paramètres d'URL avant de les utiliser dans des requêtes de base de données, même après le décodage d'URL. L'encodage d'URL n'est pas une frontière de sécurité.

---

Outils et API

L'API URL du navigateur

Les navigateurs modernes et Node.js fournissent l'API URL pour travailler avec les URL de manière structurée :

const url = new URL("https://example.com/search?q=bonjour monde&page=1");
console.log(url.searchParams.get("q")); // "bonjour monde" (décodé automatiquement)

url.searchParams.set("q", "nouvelle valeur & spéciale");
console.log(url.href);
// https://example.com/search?q=nouvelle+valeur+%26+sp%C3%A9ciale&page=1

L'API URL gère l'encodage/décodage de manière transparente, ce qui est généralement l'approche préférée par rapport aux appels manuels à encodeURIComponent.

---

Résumé

L'encodage d'URL est un concept fondamental que tout développeur web rencontre quotidiennement, souvent sans le remarquer. Les points clés à retenir :

1. Le percent-encoding (%XX) est le mécanisme standard pour encoder les caractères non sûrs dans les URI.
2. Utilisez encodeURIComponent() pour les valeurs individuelles et encodeURI() pour les URL complètes.
3. Soyez conscient de la distinction entre + et %20 dans les chaînes de requête.
4. Évitez le double encodage — vérifiez si une chaîne est déjà encodée avant de l'encoder.
5. Préférez les API modernes URL et URLSearchParams pour travailler avec les URL par programmation.