Codeur/Décodeur URL

L'encodage d'URL (également appelé encodage pourcent) est un mécanisme permettant de convertir des caractères dans un format pouvant être transmis en toute sécurité dans une URL. Les URL ne pouvant contenir que certains caractères ASCII, les autres caractères (comme les caractères accentués, les espaces et les symboles spéciaux) doivent être encodés au format %XX, où XX est la valeur hexadécimale du caractère. Par exemple : un espace est encodé en %20, et le caractère é est encodé en %C3%A9. L’encodage URL transforme des caractères en une forme transmissible dans les URLs. Espaces, texte non ASCII, caractères réservés et symboles peuvent être percent-encodés selon le contexte. Le point clé est de distinguer URL complète, segment de chemin, paramètre de query, corps de formulaire ou fragment, car chaque position a ses règles. Double encodage ou absence d’encodage peut casser liens, requêtes API, signatures, redirections et paramètres de recherche.

L'encodage URL (encodage pourcent) est défini par la RFC 3986 §2.1 et transforme les caractères au format %XX, où XX est la représentation hexadécimale majuscule à deux chiffres de la valeur de l'octet en UTF-8. La RFC définit deux classes de caractères : les caractères non réservés (A-Z a-z 0-9 - _ . ~) qui ne sont jamais encodés, et les caractères réservés (gen-delims : / ? # [ ] @ et sub-delims ! $ & ' ( ) * + , ; =) dont l'encodage dépend du contexte — ils portent un sens structurel dans certains composants d'URL mais sont des données littérales dans d'autres. JavaScript fournit deux fonctions intégrées avec des portées différentes. encodeURIComponent() encode chaque caractère sauf A-Z a-z 0-9 - _ . ! ~ * ' ( ) — c'est le choix correct pour encoder les valeurs individuelles de paramètres de requête, les segments de chemin et les identifiants de fragment. encodeURI() préserve en plus les caractères structurels : / ? # [ ] @ ! $ & ' ( ) * + , ; = et est conçu pour encoder des URI entiers tout en conservant leur structure syntaxique intacte. La distinction critique est que encodeURIComponent() encode / et &, ce qui casserait une URL si appliqué à la chaîne entière, tandis que encodeURI() les préserve. La gestion des espaces est le piège d'interopérabilité le plus courant. La RFC 3986 spécifie %20 comme encodage pourcent canonique du caractère espace (U+0020). Cependant, le type MIME application/x-www-form-urlencoded (utilisé par les soumissions de formulaires HTML depuis HTML 4.01) encode les espaces en +. Les deux ne sont pas interchangeables : un serveur attendant %20 interprétera + littéralement, et un serveur attendant + traitera %20 comme un signe pourcent suivi de 20. L'outil utilise encodeURIComponent() qui produit %20, conformément à la RFC 3986. Les utilisateurs décodant des payloads x-www-form-urlencoded (de corps POST ou de chaînes de requête parsées par des middlewares anciens) doivent être conscients de cette différence. La gestion des caractères multi-octets est automatique mais mérite d'être comprise : la chaîne d'abord encodée en octets UTF-8, puis chaque octet individuellement encodé en pourcent. Un caractère CJK comme « 你 » (U+4F60) occupe 3 octets UTF-8 (E4 BD A0), produisant %E4%BD%A0. Si le serveur analyse avec un jeu de caractères différent comme GBK, le même caractère s'encode en %C4%E3 (2 octets), et le résultat décodé sera corrompu à moins que les deux parties ne s'accordent sur UTF-8. Le double encodage est un autre bug courant : %2520 signifie un signe pourcent littéral (%25) suivi de 20, indiquant que l'entrée était déjà encodée en pourcent et a été encodée une seconde fois. Le mode décodage détecte les séquences malformées (%XX incomplet) et signale l'erreur plutôt que de produire silencieusement des données corrompues.

• encodeURIComponent vs encodeURI : encodeURIComponent encode / ? & # et est correct pour les valeurs de requête, segments de chemin et fragments ; encodeURI préserve ces caractères structurels et est correct pour les URL complètes — utiliser la mauvaise fonction est le bug d'encodage URL le plus courant.
• Ensembles de caractères réservés RFC 3986 : gen-delims (: / ? # [ ] @) portent la syntaxe URL ; sub-delims (! $ & ' ( ) * + , ; =) peuvent être des délimiteurs ou des données selon le composant URL — le contexte détermine si un caractère réservé est encodé en pourcent.
• Encodage des espaces : la forme canonique RFC 3986 est %20 (produite par encodeURIComponent) ; application/x-www-form-urlencoded utilise + (défaut des formulaires HTML) — les deux sont sémantiquement incompatibles et les mélanger casse les parseurs côté serveur.
• Encodage multi-octets UTF-8 : « 你 » (U+4F60) → octets UTF-8 E4 BD A0 → %E4%BD%A0 (3 octets encodés en pourcent) ; le même caractère sous GBK → %C4%E3 (2 octets) — l'accord sur le jeu de caractères entre client et serveur est obligatoire pour le texte non ASCII.
• Détection du double encodage : %2520 se décode d'abord en %20 puis en espace — la sortie du mode décodage révèle ce modèle ; les séquences malformées comme %ZZ ou %2 (incomplet) sont détectées et signalées comme erreurs.
• IRI (RFC 3987) : les identifiants de ressources internationalisés autorisent les caractères Unicode directement dans les URL ; les navigateurs affichent la forme décodée dans la barre d'adresse mais transmettent la forme UTF-8 encodée en pourcent sur le réseau — le mode encodage de l'outil montre ce qui transite réellement en HTTP.
• Gestion des erreurs de decodeURIComponent : passer une chaîne avec une séquence pourcent incomplète (% suivi de moins de 2 chiffres hexadécimaux) lance une URIError — l'outil enveloppe l'appel dans un try/catch et affiche le message d'erreur plutôt que de renvoyer silencieusement une chaîne vide.