Passer du texte aux séquences d'échappement

Collez votre texte directement. La conversion s'effectue dans le navigateur sans consulter l'adresse saisie. Il n'y a ni import de fichiers ni traitement par lots.

  1. Saisissez le texte original ou le composant encodé, puis choisissez Encoder ou Décoder.
  2. Vérifiez la sortie et utilisez Copier le résultat. Une erreur efface le résultat précédent et désactive la copie.
  3. Pour effectuer l'opération inverse, collez vous-même le résultat dans la saisie. Effacer vide les deux champs.

Les limites de l'encodage de composants

UTF-8 et caractères laissés tels quels

A-Z a-z 0-9 et - _ . ! ~ * ' ( ) restent inchangés à l'encodage. Les autres caractères Unicode valides deviennent des échappements UTF-8 : 你好 😀 donne %E4%BD%A0%E5%A5%BD%20%F0%9F%98%80. Aucun échappement supplémentaire de ! ' ( ) * n'est appliqué pour une conformité stricte à la RFC 3986.

La chaîne entière devient une donnée

a=1&b=two words devient a%3D1%26b%3Dtwo%20words. Une URL complète verra également ses : / ? & = encodés. Ce traitement convient lorsque l'adresse entière doit servir de valeur, pas lorsque sa structure doit rester intacte.

Réinsérer des séparateurs décodés peut modifier l'interprétation d'une URL. Traitez le résultat comme donnée de paramètre selon le contexte. L'outil ne valide pas les URL et ne chiffre rien. La sortie est du texte, pas du HTML exécuté.

Un seul niveau de décodage

Encoder %20 produit %2520, car le signe % est lui aussi encodé. Décoder %2520 restitue le texte littéral %20, pas encore une espace. L'outil ne recommence pas automatiquement et ne remplace pas la saisie par le résultat.

Questions sur l'encodage de composants

Pourquoi + ne devient-il pas une espace ?

L'outil n'applique pas application/x-www-form-urlencoded. À l'encodage, une espace devient %20 et + devient %2B. Au décodage, le + littéral reste inchangé : a+b%20c donne a+b c.

Qu'est-ce qui provoque URIError ?

Décoder %, %GG ou %E4%A échoue pour échappement mal formé ; %FF et %C0%AF échouent pour UTF-8 invalide, sans caractères de remplacement. Encoder un substitut UTF-16 isolé échoue aussi. Le décodage laisse intact le texte littéral sans échappement ; il ne valide pas chaque caractère.

La saisie conserve-t-elle espaces et fins de ligne ?

Les caractères blancs ne sont pas supprimés, même aux extrémités. Le textarea du navigateur normalise toutefois les fins de ligne saisies en LF, encodé en %0A, sans conserver les octets CRLF ou CR d'origine. Aucune normalisation Unicode n'est ajoutée. Une saisie vide donne un résultat vide.

Outils récents :