Encodeur/Décodeur URL

Science et Histoire de l'Encodage en Pourcentage

L'encodage en pourcentage est ne d'une contrainte fondamentale des débuts d'internet : la limitation ASCII. Lorsque Tim Berners-Lee a conçu 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 début des années 90, mais signifiait que tout caractère en dehors de cet ensemble sur nécessitait un mécanisme de représentation. La solution était d'une élégante simplicité : représenter chaque octet non sur par un signe de pourcentage suivi de sa valeur hexadécimale 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 nécessiter trois octets en UTF-8, produisant trois triplets consécutifs. Le signe euro, par exemple, occupe trois octets (E2, 82, AC) et devient la séquence de six caractères %E2%82%AC. C'est pourquoi les URLs encodees contenant du texte non-latin peuvent paraître considérablement 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 établi 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 intégration sure dans les composants d'URL. La spécification a égalementt introduit le principe de normalisation, définissant quand deux URLs différemment encodees doivent être considérées équivalentes.

Méthodologie

L'encodage URL remplace les caractères ASCII non sûrs par un signe de pourcentage (%) suivi de deux chiffres hexadécimaux représentant la valeur en octets du caractère. Par exemple, un espace devient %20 (hex 20 = décimal 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 réservés ne nécessitant jamais d'encodage : lettres majuscules et minuscules (A-Z, a-z), chiffres (0-9) et quatre caractères spéciaux (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 réservé, le rendant idéal pour les valeurs de paramètres de requête où des caractères comme & et = doivent être échappés. Le mode URL Complete utilise encodeURI(), qui préserve 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 encodés (%E2%82%AC) car UTF-8 utilise un encodage de longueur variable d'un à quatre octets par caractère.

Comprendre vos Résultats

Utilisez le mode Composant (encodeURIComponent) chaque fois que vous encodez une valeur qui sera placée après un signe égal dans une chaîne 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 Complète (encodeURI) lorsque vous avez une URL complète et souhaitez uniquement encoder les espaces et les caractères non-ASCII tout en gardant les délimiteurs structurels intacts. Si vous voyez %25 dans votre sortie, cela signifie que le signe de pourcentage lui-même a été encodé, ce qui indique généralement un double encodage—l'entrée était déjà encodée avant votre traitement. Décoder ces chaînes 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 décodage est utile pour rendre les URLs lisibles lors du débogage, analyser les journaux serveur ou inspecter les paramètres de requête contenant des valeurs encodées. Les noms de domaine internationaux (IDN) utilisent un encodage différent appelé Punycode plutôt que l'encodage en pourcentage, donc les noms de domaine avec des caractères non-latins nécessitent un traitement séparé. Encodez toujours les saisies utilisateur avant de les insérer dans les URLs pour prévenir les attaques par injection.

Exemples Pratiques

Paramètre de requête de recherche : encoder 'coffee & tea' en mode Composant produit 'coffee%20%26%20tea', échappant en sécurité les espaces et l'esperluette pour que le serveur reçoive le texte littéral. Soumission de formulaire : un utilisateur entre 'price=50$', qui doit être encode en 'price%3D50%24' pour empêcher 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 chaîne de requête. Contenu multilingue : l'encodage de texte japonais produit des séquences d'octets UTF-8 sous forme de triplets en pourcentage. Décodage de débogage : collez une URL complété depuis les journaux serveur et décodez-la pour voir instantanément la requête originale pour un dépannage rapide.

Conseils et Bonnes Pratiques

Utilisez toujours le mode Composant lors de l'encodage de valeurs individuelles de paramètres de requête. Le mode URL Complete laisse les caractères structurels comme & et = non encodés, ce qui cassera votre URL si ces caractères apparaissent dans les données elles-mêmes plutôt que comme délimiteurs. Évitez le double encodage en vérifiant si votre entrée est déjà encodée. Si vous voyez des séquences comme %20 ou %26 dans l'entrée, décodez d'abord avant de re-encoder pour éviter l'empilement (où %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 chaîne URL entière en une fois, car cela corromprait les caractères structurels séparant le schéma, l'hôte, le chemin et les composants de requête. Pour déboguer les appels API, collez l'URL encodée complété en mode décodage pour lire rapidement toutes les valeurs de paramètres sous forme lisible. Cela est particulièrement utile pour résoudre les URLs de webhooks ou les redirections OAuth contenant des valeurs encodées imbriquées.

Encodages URL Courants

Sources

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