Ce que fait cet outil
Applique et retire le percent-encoding sur des strings pour usage dans des URLs. Il supporte le mode component (encode chaque caractère réservé pour que la valeur soit safe dans un paramètre de query ou un segment de path) et le mode URL complète (préserve la structure de https://host/path?query tout en n'encodant que les parties qui en ont besoin).
Quand l'utiliser
- Construire une query string à la main et avoir besoin d'échapper les espaces, esperluettes et signes égal.
- Décoder une URL de redirection qui revient enveloppée dans
%2Fet%3D. - Comparer la forme encodée d'une URL à une allow-list.
- Produire un lien partageable propre à partir d'une string avec des caractères non-ASCII.
Comment ça marche
L'encodage component utilise encodeURIComponent, qui percent-encode chaque caractère qui n'est pas un caractère non-réservé (A-Z a-z 0-9 - _ . ! ~ * ' ( )). L'encodage URL complète utilise encodeURI, qui laisse les caractères structurels réservés (: / ? # [ ] @) tranquilles. Le décodage utilise les fonctions inverses, avec les séquences mal formées remontées comme erreurs au lieu d'être silencieusement abandonnées.
Notes
Pourquoi + se décode-t-il parfois en espace ? C'est l'ancienne convention application/x-www-form-urlencoded utilisée dans les soumissions de formulaire, pas l'encodage URL standard. Le RFC 3986 laisse + tranquille. La plupart des décodeurs ne traitent + comme espace que dans la query string, jamais dans le path.
Devrais-je utiliser ça sur l'URL entière ou juste une partie ? Encode les parties. Si tu encodes une URL complète en mode component, tu casseras le :// et les slashes du path. Construis l'URL à partir de morceaux pré-encodés, ou utilise le mode URL complète.
Ça gère l'Unicode ? Oui. UTF-8 d'abord, puis percent-encoding sur chaque byte. café devient caf%C3%A9.
Outils liés
- Base64 — mécanisme d'échappement différent pour du binaire-dans-texte
- Formateur JSON — pour des payloads de body au lieu de query strings