Encodeur/décodeur URL

• Encodeur/décodeur Base64
• Encodeur Base64
• Décodeur Base64
• Tous les convertisseurs

Navigateurs, serveurs et caches traitent certains caractères comme de la structure — espaces, esperluettes, dièses et texte non ASCII doivent être échappés quand ce sont des données et non de la syntaxe. Un outil dédié prévisualise la chaîne exacte qu’un client HTTP enverra.

Avantages d’un encodage URL correct

• Transmission sûre : Le contenu utilisateur cesse de casser les analyseurs qui découpent chemins, requêtes et fragments.
• Support Unicode : Les octets UTF‑8 peuvent s’écrire comme des % pour que le texte international survive aux transports ASCII seul.
• API prévisibles : S’aligner sur RFC 3986 réduit les écarts entre front-end, apps mobiles et backends.
• Moins d’erreurs 400 : Des paramètres bien encodés sont moins souvent rejetés par des passerelles strictes.
• Débogage plus simple : Comparez votre chaîne manuelle à encodeURIComponent avant de livrer un correctif.

Le percent-encoding réécrit chaque octet qui ne peut pas apparaître littéralement comme %HH, HH en hexadécimal. Les caractères qui restent littéraux dépendent de protéger une URL entière ou un composant isolé.

Modes de cet outil

• Mode composant : Calque encodeURIComponent / decodeURIComponent — idéal pour clés, valeurs, segments de chemin ou tout texte intégré dans une requête.
• Mode URL complète : Calque encodeURI / decodeURI — pour des chaînes qui contiennent encore schéma, hôte, barres et ponctuation de requête après transformation.
• Transformation en direct : Chaque modification passe par la paire choisie pour voir immédiatement une entrée mal formée ou un double encodage.

Des détails comme le + dans les envois de formulaires par rapport au vrai percent-encoding piègent les équipes quand les frameworks diffèrent.

Référence rapide

• L’espace est souvent %20 dans la query ; les formulaires HTML peuvent utiliser + dans application/x-www-form-urlencoded.
• Seuls les caractères non réservés (lettres, chiffres, -._~) peuvent rester non encodés en mode composant strict.
• La double encodage (encoder une chaîne déjà encodée) allonge l’URL et peut perturber les serveurs.
• decodeURIComponent lève une erreur si % est suivi d’un hex incomplet ; corrigez la source avant décodage.
• Les noms de domaine internationalisés utilisent Punycode dans le DNS ; l’encodage URL couvre chemin et requête, pas la conversion ACE du nom d’hôte.

Bonnes pratiques

Encodez à la frontière où le texte non fiable devient partie d’une URL et décodez une fois quand vous le traitez à nouveau comme données.

• Encodez chaque valeur de requête séparément au lieu d’encoder deux fois l’URL entière.
• Journalisez l’entrée brute séparément de la chaîne encodée lors du débogage analytics ou redirections.
• Préférez HTTPS pour partager des URLs encodées avec jetons sensibles.
• Validez la sortie décodée avant injection HTML pour éviter le XSS via liens malveillants.
• Testez les deux modes si le produit gère des liens profonds depuis e-mail ou SMS.

Cas d’usage

• Développement web : Filtres de recherche, UTM, URIs de redirection OAuth.
• Intégration API : Comportement conforme quand la doc cite RFC 3986.
• QA et support : Reproduire les URLs clients sans deviner les échappements.
• Documentation : Exemples avant/après pour partenaires.
• Scripts de migration : Comparer règles d’échappement legacy et fonctions navigateur modernes.