Guide de l'encodage URL (encodage pourcent) : pourquoi le texte devient %20 et %C3%A9
Copiez un lien contenant un mot accentué et vous obtenez des chaînes comme %C3%A9t%C3%A9. C'est l'encodage URL. Ce guide explique les règles qui le régissent et les problèmes qu'il pose en développement web, dans les liens marketing et les intégrations d'API.
Seuls certains caractères sont autorisés dans une URL
La syntaxe des URL est définie par la RFC 3986. Seuls les lettres, les chiffres et quatre symboles — le tiret (-), le point (.), le tiret bas (_) et le tilde (~) — peuvent figurer tels quels dans une URL. On les appelle caractères non réservés.
Les symboles tels que :, /, ?, #, & et = sont réservés : ils donnent sa structure à l'URL. ? ouvre la chaîne de requête, & sépare les paramètres et # désigne un fragment. Si un terme de recherche contient lui-même & ou #, l'insérer sans l'encoder change le sens de toute l'URL.
Comment fonctionne l'encodage pourcent
Les caractères qui ne peuvent pas apparaître directement sont décomposés en octets, et chaque octet s'écrit % suivi de deux chiffres hexadécimaux. Une espace (octet 0x20) devient %20, une esperluette (0x26) devient %26 et un signe égal (0x3D) devient %3D.
Le texte non ASCII est d'abord converti en octets UTF-8, puis encodé de la même façon. La syllabe coréenne 안 occupe trois octets en UTF-8 (EC 95 88) et devient donc %EC%95%88 : un caractère en devient neuf. Le é français, sur deux octets, devient %C3%A9.
안녕 하세요? → %EC%95%88%EB%85%95%20%ED%95%98%EC%84%B8%EC%9A%94%3F
a b&c=d → a%20b%26c%3DdLe décodage inverse le processus : %EC%95%88 redevient les octets EC 95 88, interprétés en UTF-8. Si un serveur interprète ces octets dans un ancien encodage, le texte devient illisible — une cause fréquente de termes de recherche cassés sur les sites anciens.
Une espace : %20 ou + ?
Les espaces sont la principale source de confusion. Selon la RFC 3986, une espace s'écrit %20. Mais le format application/x-www-form-urlencoded des formulaires HTML écrit les espaces des chaînes de requête sous forme de +. Le même texte a b peut donc apparaître comme a%20b dans un chemin et comme a+b dans une requête de formulaire.
Les ennuis commencent quand il faut un vrai signe plus. Un numéro comme +33 ou une expression comme 1+1 placés sans encodage dans une requête peuvent être lus comme une espace. Encodez ces valeurs en %2B. Les bibliothèques diffèrent — encodeURIComponent en JavaScript produit %20, alors que certaines bibliothèques serveur produisent + — assurez-vous donc que les deux côtés suivent la même convention.
Encodez les composants, pas l'URL entière
N'encodez jamais une URL entière d'un seul coup. Encoder https://example.com/search?q=... transforme : et / en %3A et %2F, et le résultat ne fonctionne plus comme adresse. N'appliquez l'encodage qu'aux parties qui sont des données, comme les valeurs de paramètres.
JavaScript reflète cette distinction avec deux fonctions. encodeURI laisse intacts les caractères structurels, tandis qu'encodeURIComponent encode aussi /, ?, & et =. Pour les valeurs de paramètres de requête, encodeURIComponent est le choix sûr.
Double encodage : méfiez-vous de %2520
Encoder une chaîne déjà encodée transforme % en %25. Si une espace apparaît sous la forme %2520 au lieu de %20, elle a été encodée deux fois. Cela arrive souvent avec des liens de suivi qui passent par plusieurs redirections, ou avec des URL de retour après connexion qui transportent une autre URL en paramètre.
Décoder deux fois est tout aussi nuisible : un véritable %25 présent dans les données devient % et la valeur change. La règle est simple : encodez une seule fois, au dernier moment, lorsqu'une valeur entre dans une URL, et décodez une seule fois, au premier moment, lorsque vous la lisez.
Liste de contrôle pratique
Testez des valeurs dans l'encodeur/décodeur URL d'AIBIZAP pour voir exactement quels caractères changent et comment.
- Encodez les noms de campagne des liens UTM s'ils contiennent des espaces ou des accents.
- Encodez au niveau du composant les valeurs d'API comme les termes de recherche, les adresses e-mail (avec @) et les horodatages (avec :).
- Si un lien est cassé, cherchez %25 pour détecter un double encodage.
- Si les journaux du serveur affichent du texte illisible, vérifiez que les valeurs ont été décodées et interprétées en UTF-8.
- Lorsqu'une valeur Base64 doit aller dans une URL, utilisez Base64URL ou encodez le résultat en pourcent.