Encodeur et Décodeur d'URL

La différence tient à l'étendue de l'encodage. encodeURIComponent échappe tous les caractères réservés, y compris : / ? # @ & = + $, et sert donc pour un seul fragment d'URL — typiquement une valeur de chaîne de requête. Si cette valeur contenait un & ou un = isolé, l'encoder évite qu'elle ne démarre par erreur un nouveau paramètre. encodeURI est plus permissif : il préserve les caractères structurants : / ? # afin qu'une adresse complète déjà assemblée reste utilisable en tant qu'URL. La règle à retenir : utilisez encodeURIComponent sur le petit fragment que vous insérez dans une URL, et encodeURI sur une URL entière que vous ne voulez pas casser. Confondre les deux est le bug d'URL le plus fréquent. Cet outil propose les deux comme portées distinctes, plus des modes chemin uniquement et requête uniquement, pour appliquer exactement le bon niveau.

Une URL ne peut transporter en toute sécurité qu'un ensemble limité de caractères, et certains sont réservés car ils ont une signification structurelle. Un espace n'est pas autorisé du tout et doit devenir %20, sinon navigateurs, serveurs et analyseurs de liens peuvent tronquer l'adresse à cet endroit. L'esperluette est encore plus problématique : dans une chaîne de requête, & sépare un paramètre du suivant, donc un & non encodé au sein d'une valeur sera lu comme le début d'un tout nouveau paramètre, coupant vos données en deux. L'encoder en %26 le conserve comme texte littéral. Le même principe s'applique à #, qui marque un fragment, ainsi qu'à ? et / qui marquent la requête et le chemin. Le percent-encoding remplace chacun de ces caractères par un code sûr préfixé par %. Collez votre lien dans l'outil, choisissez la bonne portée, et il échappe pour vous les caractères problématiques afin que l'URL reste intacte.

Les deux peuvent représenter un espace, mais ils appartiennent à des schémas d'encodage différents et ne sont pas toujours interchangeables. %20 est le percent-encoding standard d'un espace et reste valide partout dans une URL — chemin, requête ou fragment. Le signe + ne signifie un espace que dans un contexte précis : les données application/x-www-form-urlencoded, le format utilisé par les formulaires HTML pour envoyer leurs valeurs. Dans ce format, un espace littéral devient +, et un + littéral doit lui-même être encodé en %2B pour ne pas être interprété comme un espace. En dehors de l'encodage de formulaire, un + dans une URL n'est qu'un simple signe plus et n'est pas décodé en espace. Mélanger les deux conventions est une source fréquente de bugs, par exemple un nom comme « John Doe » qui arrive sous la forme « John+Doe ». Cet outil propose un mode dédié d'encodage de formulaire aux côtés du percent-encoding standard, pour choisir la convention attendue par votre système.

%2520 est la signature caractéristique d'un double encodage — une chaîne encodée deux fois en percent-encoding. Un espace devient d'abord %20 ; si ce résultat est encodé une seconde fois, le % lui-même est échappé en %25, transformant %20 en %2520. On observe souvent des séquences 25 en trop disséminées dans un lien corrompu, comme %253A ou %252F. Cela arrive généralement lorsqu'un code encode une valeur déjà encodée, par exemple en enveloppant une URL déjà construite dans encodeURIComponent. La correction consiste simplement à décoder la chaîne deux fois : un premier décodage transforme %2520 en %20, et un second décodage retrouve l'espace d'origine. Le validateur de cet outil signale le double encodage lorsqu'il détecte ce motif, et vous pouvez relancer le décodage plusieurs fois pour retirer chaque couche jusqu'à ce que l'URL redevienne normale. Collez le lien suspect pour vérifier et récupérer l'original.

Les noms d'hôte suivent des règles différentes du reste d'une URL : l'hôte ne peut pas contenir directement de lettres non-ASCII, et il n'utilise pas le percent-encoding comme le fait un chemin ou une requête. Les noms de domaine internationalisés sont à la place convertis en Punycode, un encodage compatible ASCII qui préfixe l'étiquette convertie par xn--. Par exemple, münchen.de devient xn--mnchen-3ya.de, la forme qui circule réellement via le DNS, tandis que les navigateurs affichent aux utilisateurs la version Unicode plus lisible. La conversion est réversible : vous pouvez donc reconvertir un hôte Punycode vers sa forme lisible pour vérifier vers quoi un lien pointe réellement — utile pour repérer des domaines usurpés ou trompeurs. Le convertisseur IDN de cet outil gère les deux sens grâce à la normalisation d'URL native du navigateur, en séparant bien l'hôte du percent-encoding que vous appliqueriez au chemin et à la requête. Collez un domaine pour le convertir vers ou depuis le Punycode.