En bref : l'encodage d'URL (percent-encoding) remplace les caractères dangereux par des séquences %XX pour que les liens survivent aux espaces, accents et symboles. Un espace devient %20, une esperluette devient %26. L'astuce est de savoir quand encoder une URL entière plutôt qu'une seule valeur de requête — et que encodeURIComponent et encodeURI ne sont pas interchangeables.

Une URL ne peut contenir sans risque qu'un ensemble limité de caractères. Tout le reste — espaces, lettres accentuées et symboles réservés comme ?, &, # et = — doit être percent-encodé, sinon le lien casse ou pointe ailleurs qu'attendu.

Ce que fait vraiment le percent-encoding

Chaque caractère dangereux est remplacé par un signe pourcentage suivi de sa valeur d'octet hexadécimale. Un espace est %20, une esperluette %26, un point d'interrogation %3F. Le décodage inverse le processus, ramenant chaque %XX valide au caractère d'origine.

%20 contre + pour les espaces

Les deux peuvent signifier « espace », mais pas au même endroit. %20 est l'espace percent-encodé utilisé dans tout le chemin et la requête d'une URL. Le signe plus + ne signifie un espace que dans le contexte application/x-www-form-urlencoded — envois de formulaire et chaînes de requête — et est traité littéralement ailleurs. Dans le doute, %20 est le choix le plus sûr et le plus universel.

encodeURIComponent contre encodeURI

C'est la distinction qui déroute. Utilisez encodeURIComponent pour une valeur unique insérée dans une URL — par exemple le terme de recherche dans ?q=hello%20world. Il encode les caractères réservés comme & et = pour qu'ils ne soient pas pris pour la structure de l'URL. Utilisez encodeURI uniquement sur une URL complète, où ces caractères réservés doivent garder leur sens structurel. Encoder une URL entière avec encodeURIComponent abîmerait ses propres :// et ? ; encoder un seul paramètre avec encodeURI laisse des caractères dangereux non échappés.

Quand encoder

  • En construisant une chaîne de requête à partir d'entrées utilisateur (termes de recherche, filtres, noms).
  • En plaçant un lien dans un autre lien comme paramètre ?redirect= ou ?url=.
  • En gérant des noms de fichiers ou chemins contenant espaces ou accents.
  • En déboguant un lien qui marche en local mais casse une fois partagé.

L'encodage d'URL n'est pas le Base64

Ils résolvent des problèmes différents. Le percent-encoding rend les caractères dangereux sûrs dans une URL ; le Base64 réencode des données binaires en une chaîne ASCII compacte, et sa sortie a encore besoin d'un encodage d'URL si elle va dans un lien. Choisir le mauvais produit des liens qui semblent encodés mais ne fonctionnent pas.

Un flux pratique

Collez la valeur brute dans l'Encodeur / Décodeur d'URL pour encoder un paramètre ou décoder une chaîne %XX suspecte — il décode les séquences valides et signale les invalides au lieu de les corrompre en silence. Si le même contenu passe aussi par le Base64, vérifiez-le avec l'Encodeur / Décodeur Base64 pour appliquer les deux étapes dans le bon ordre.

Erreurs courantes à éviter

  • Encoder une URL complète avec encodeURIComponent et casser sa structure.
  • Supposer que + signifie un espace partout dans une URL.
  • Double encodage — repasser dans l'encodeur une chaîne déjà encodée.
  • Confondre le percent-encoding avec le Base64.

Encodez les parties, pas le tout, et un lien avec espaces, accents ou URL imbriquée voyagera intact.