Encodeur et décodeur URL

La structure d'une URL dépend de ce que des caractères précis — `/` pour séparer les segments de chemin, `?` pour introduire la chaîne de requête, `&` pour séparer les paramètres, `#` pour un fragment — portent une signification structurelle fixe partout où ils apparaissent. Si une valeur placée dans une URL, comme un terme de recherche ou le nom d'un utilisateur, contient littéralement l'un de ces mêmes caractères, il doit y avoir un moyen de distinguer « cette esperluette fait partie de la vraie valeur » de « cette esperluette sépare deux paramètres de requête ». L'encodage pourcent est ce mécanisme : tout caractère à signification structurelle, quand il doit apparaître comme donnée littérale plutôt que comme structure, est remplacé par un `%` suivi de sa valeur d'octet hexadécimale, donc `&` devient `%26` et se lit sans ambiguïté comme donnée plutôt que comme séparateur de paramètres.

L'erreur d'encodage d'URL la plus courante, de loin, est d'encoder une URL complète assemblée avec la mauvaise fonction — utiliser `encodeURIComponent`, qui échappe chaque caractère réservé y compris `/`, `:`, `&` et `?`, sur une adresse entière plutôt que sur une seule valeur individuelle. Le `://` après le protocole devient `%3A%2F%2F`, chaque `&` séparant des paramètres de requête devient `%26`, et l'URL cesse complètement d'être une URL — elle devient une longue chaîne encodée sans aucune structure qu'un serveur puisse analyser. La bonne approche est l'ordre inverse : encoder d'abord chaque valeur individuelle — le terme de recherche, la destination de redirection, quelle que soit la vraie donnée — et seulement ensuite insérer ces valeurs déjà encodées dans la structure d'URL environnante, sans jamais réencoder l'ensemble assemblé après coup.

C'est précisément pourquoi cet outil propose deux modes distincts plutôt qu'un bouton générique « encoder » : le mode composant pour encoder une seule valeur sur le point de devenir partie d'une URL, et le mode URL complète pour le cas plus rare d'encoder une adresse entière tout en préservant délibérément ses caractères structurels.

Deux conventions d'encodage distinctes pour les espaces restent en usage actif aujourd'hui, et ne sont pas interchangeables. L'encodage pourcent, le standard à usage général, représente un espace comme `%20` et est valide partout dans une URL — le chemin, la chaîne de requête, partout. La convention `+` pour un espace vient d'un standard plus ancien et limité spécifiquement aux soumissions de formulaires HTML utilisant le type de contenu `application/x-www-form-urlencoded`, et n'est valide que dans la chaîne de requête ; un `+` littéral apparaissant dans un chemin d'URL n'est pas du tout interprété comme un espace, c'est simplement le caractère plus. Cet outil produit toujours `%20`, valide dans tout contexte, et décode correctement les deux formes en lisant une URL encodée.

Les règles d'encodage pourcent s'appliquent à toute URL quel que soit ce qui la construit ou la consomme — un payload de webhook construit par un service backend, un lien profond ouvert par une application mobile, une requête d'API assemblée par un script. Partout où une valeur pouvant contenir des espaces, esperluettes, ou caractères non ASCII est interpolée dans une chaîne d'URL, la même règle d'encoder-la-valeur-avant-de-l'insérer s'applique, donc c'est autant une préoccupation de backend et de script que de navigateur.