Encodeur/Décodeur URL

Science et Histoire de l'Encodage en Pourcentage

L'encodage en pourcentage est ne d'une contrainte fondamentale des debuts d'internet : la limitation ASCII. Lorsque Tim Berners-Lee a concu la syntaxe URL en 1994, la spécification du Localisateur Uniforme de Ressources (RFC 1738) restreignait les adresses web à un petit sous-ensemble de caractères ASCII. Cela avait du sens pour l'internet predominamment anglophone du debut des années 90, mais signifiait que tout caractère en dehors de cet ensemble sur necessitait un mecanisme de représentation. La solution etait d'une elegante simplicite : représenter chaque octet non sur par un signe de pourcentage suivi de sa valeur hexadecimale a deux chiffres. Un espace (valeur d'octet 32, hex 20) devient %20, un point d'interrogation (valeur 63, hex 3F) devient %3F. Ce schéma pouvait représenter toute valeur d'octet de 00 a FF, le rendant capable d'encoder tout caractère dans tout jeu de caractères. L'introduction d'UTF-8 comme encodage standard du web a transforme l'encodage en pourcentage d'un simple schéma de mappage d'octets en un système d'encodage multi-octets. Un seul caractère chinois peut necessiter trois octets en UTF-8, produisant trois triplets consecutifs. Le signe euro, par exemple, occupe trois octets (E2, 82, AC) et devient la sequence de six caractères %E2%82%AC. C'est pourquoi les URLs encodees contenant du texte non-latin peuvent paraitre considerablement plus longues. RFC 3986, publie en 2005, a affine la spécification URL originale et formalise les règles modernes de l'encodage en pourcentage. Il a etabli le concept d'ensembles de caractères reserves et non reserves, clarifiant lesquels servent de delimiteurs structurels dans les URLs. Cette distinction explique pourquoi deux fonctions d'encodage existent en JavaScript : encodeURI preserve les caractères structurels pour les URLs complétés, tandis qu'encodeURIComponent encode tout pour une integration sure dans les composants d'URL. La spécification a égalementt introduit le principe de normalisation, définissant quand deux URLs differemment encodees doivent être considerees équivalentes.

Méthodologie

L'encodage URL remplace les caractères ASCII non surs par un signe de pourcentage (%) suivi de deux chiffres hexadecimaux représentant la valeur en octets du caractère. Par exemple, un espace devient %20 (hex 20 = decimal 32), une esperluette devient %26 et un signe plus devient %2B. L'encodage suit le RFC 3986, qui définit l'ensemble des caractères non reserves ne necessitant jamais d'encodage : lettres majuscules et minuscules (A-Z, a-z), chiffres (0-9) et quatre caractères speciaux (tiret, point, underscore, tilde). Cet outil propose deux modes d'encodage correspondant directement aux fonctions natives de JavaScript. Le mode Composant utilise encodeURIComponent(), qui encode tous les caractères sauf l'ensemble non reserve, le rendant idéal pour les valeurs de paramètrès de requête ou des caractères comme & et = doivent être echappes. Le mode URL Complete utilise encodeURI(), qui preserve en plus les caractères structurels d'URL comme : / ? # [ ] @ ! $ & ' ( ) * + , ; = pour qu'une URL complété reste fonctionnelle après l'encodage. Pour les caractères internationaux et les emojis, l'outil convertit d'abord le texte en sa représentation d'octets UTF-8, puis encode chaque octet individuellement. Un seul caractère Unicode comme le signe euro peut produire plusieurs triplets encodes (%E2%82%AC) car UTF-8 utilise un encodage de longueur variable d'un a quatre octets par caractère.

Comprendre vos Résultats

Utilisez le mode Composant (encodeURIComponent) chaque fois que vous encodez une valeur qui sera placee après un signe égal dans une chaine de requête. Cela garantit que les caractères comme &, = et # dans votre valeur ne brisent pas accidentellement la structure de l'URL. Utilisez le mode URL Complete (encodeURI) lorsque vous avez une URL complété et souhaitez uniquement encoder les espaces et les caractères non-ASCII tout en gardant les delimiteurs structurels intacts. Si vous voyez %25 dans votre sortie, cela signifie que le signe de pourcentage lui-même a ete encode, ce qui indique généralement un double encodage—l'entrée etait déjà encodee avant votre traitement. Decoder ces chaines deux fois récupérera le texte original. C'est l'une des erreurs d'encodage URL les plus courantes dans les applications web et APIs. Le decodage est utile pour rendre les URLs lisibles lors du debogage, analyser les journaux serveur ou inspecter les paramètrès de requête contenant des valeurs encodees. Les noms de domaine internationaux (IDN) utilisent un encodage différent appele Punycode plutot que l'encodage en pourcentage, donc les noms de domaine avec des caractères non-latins necessitent un traitement séparé. Encodez toujours les saisies utilisateur avant de les inserer dans les URLs pour prevenir les attaques par injection.

Exemples Pratiques

Paramètre de requête de recherche : encoder 'coffee & tea' en mode Composant produit 'coffee%20%26%20tea', echappant en sécurité les espaces et l'esperluette pour que le serveur recoive le texte litteral. Soumission de formulaire : un utilisateur entre 'price=50$', qui doit être encode en 'price%3D50%24' pour empecher le signe égal d'être interpréete comme séparateur clé-valeur. URLs de redirection API : lors du passage d'une URL de callback comme 'https://app.com/auth?token=abc' en paramètre à une autre URL, le mode Composant encode l'ensemble du callback y compris sa propre chaine de requête. Contenu multilingue : l'encodage de texte japonais produit des sequences d'octets UTF-8 sous forme de triplets en pourcentage. Decodage de debogage : collez une URL complété depuis les journaux serveur et decodez-la pour voir instantanement la requête originale pour un depannage rapide.

Conseils et Bonnes Pratiques

Utilisez toujours le mode Composant lors de l'encodage de valeurs individuelles de paramètrès de requête. Le mode URL Complete laisse les caractères structurels comme & et = non encodes, ce qui cassera votre URL si ces caractères apparaissent dans les données elles-memes plutot que comme delimiteurs. Evitez le double encodage en vérifiant si votre entrée est déjà encodee. Si vous voyez des sequences comme %20 ou %26 dans l'entrée, decodez d'abord avant de re-encoder pour eviter l'empilement (ou %20 devient %2520). Lors de la construction programmatique d'URLs, encodez chaque valeur de paramètre séparément puis assemblez l'URL complété. N'encodez jamais la chaine URL entière en une fois, car cela corromprait les caractères structurels separant le schéma, l'hote, le chemin et les composants de requête. Pour deboguer les appels API, collez l'URL encodee complété en mode decodage pour lire rapidement toutes les valeurs de paramètrès sous forme lisible. Cela est particulièrement utile pour resoudre les URLs de webhooks ou les redirections OAuth contenant des valeurs encodees imbriquees.

Encodages URL Courants

Sources

• RFC 3986 – Syntaxe Générique d'URI
• MDN – encodeURIComponent