Encodeur / décodeur URL
Convertissez du texte en encodage URL ou l'inverse, en direct dans les deux sens.
Qu'est-ce que l'encodage URL ?
L'encodage URL, ou percent-encoding, remplace tout caractère qu'une URL ne peut pas porter tel quel par une séquence %XX, où XX est le code hexadécimal de l'octet correspondant. Un espace devient %20, le caractère « é » devient %C3%A9 une fois converti en UTF-8. Le mécanisme est décrit par la RFC 3986.
Deux problèmes distincts sont ainsi résolus. Le premier est un problème de jeu de caractères : une URL ne s'écrit qu'en ASCII, donc tout ce qui n'en fait pas partie — accents, cyrillique, emojis — doit être transcrit en octets. Le second, plus subtil, est un problème d'ambiguïté : les caractères ?, &, =, # et / ont une signification structurelle. Une valeur qui les contient sans les encoder ne casse pas l'URL au sens strict — elle est simplement lue autrement. Un paramètre ?q=Dupont & Fils devient deux paramètres, dont le second s'appelle « Fils ».
encodeURI ou encodeURIComponent ?
JavaScript fournit deux fonctions, et le choix entre les deux est la source d'erreur la plus fréquente. encodeURIComponent, celle qu'utilise cet outil, encode tout sauf les lettres, les chiffres et - _ . ! ~ * ' ( ) : elle est faite pour un fragment isolé, typiquement la valeur d'un paramètre. encodeURI préserve en plus les caractères de structure ; / ? : @ & = + $ , #, car elle est prévue pour une URL déjà assemblée qu'il ne faut pas déformer.
En pratique : construisez votre URL, puis encodez chaque valeur insérée avec encodeURIComponent. Appliquer encodeURI à une valeur de paramètre laisse passer les & et les =, ce qui produit silencieusement de mauvaises données côté serveur. À noter : encodeURIComponent laisse intacts ! ' ( ) *, que la RFC 3986 classe pourtant parmi les caractères réservés — certaines API exigent de les encoder à la main.
| Caractère | encodeURIComponent | encodeURI | Pourquoi |
|---|---|---|---|
| espace | %20 | %20 | Encodé par les deux. Un formulaire écrit + à la place. |
| & | %26 | & | Sépare deux paramètres : à encoder dans une valeur. |
| = | %3D | = | Sépare le nom de la valeur d'un paramètre. |
| ? | %3F | ? | Ouvre la chaîne de requête. |
| # | %23 | # | Ouvre l'ancre : jamais transmis au serveur s'il reste brut. |
| / | %2F | / | Sépare les segments de chemin. |
| + | %2B | + | Sinon relu comme un espace par de nombreux serveurs. |
| : | %3A | : | Sépare le schéma, et l'hôte du port. |
| é | %C3%A9 | %C3%A9 | Deux octets UTF-8, donc deux séquences %XX. |
| € | %E2%82%AC | %E2%82%AC | Trois octets UTF-8. |
| - _ . ~ | inchangé | inchangé | Caractères non réservés de la RFC 3986. |
Le cas du « + » et de l'espace
Un espace admet deux écritures selon le contexte. Le percent-encoding le note %20 ; l'encodage de formulaire application/x-www-form-urlencoded, celui des formulaires HTML et de URLSearchParams, le note +. Les deux se croisent dans une chaîne de requête, où la plupart des serveurs les acceptent indifféremment.
La conséquence est asymétrique et vaut d'être retenue : un vrai signe plus doit être encodé en %2B, sans quoi il ressortira comme un espace — un numéro de téléphone +33 6… transmis brut arrive au serveur avec son + transformé en espace, soit 33 6… : les chiffres sont intacts mais le marqueur international a disparu, et le numéro n'est plus reconnu comme tel. Dans l'autre sens, decodeURIComponent ne retransforme jamais un + en espace : décoder du contenu de formulaire avec cette fonction laisse donc les plus visibles. Enfin, dans un chemin d'URL et non dans la chaîne de requête, seul %20 est valide.
encodeURIComponent, utilisé par cet outil, encode tout ce qui n'est pas une lettre, un chiffre ou l'un des caractères - _ . ! ~ * ' ( ). Il est fait pour un morceau d'URL isolé : la valeur d'un paramètre, un segment de chemin. encodeURI, lui, laisse intacts les caractères de structure ; / ? : @ & = + $ , # car il est prévu pour une URL déjà complète, qu'il ne doit pas casser. La règle pratique : encodeURI sur une URL entière, encodeURIComponent sur chaque valeur que vous y insérez.
Parce que l'encodage de formulaire application/x-www-form-urlencoded, historiquement utilisé pour les envois de formulaire et généré par URLSearchParams en JavaScript, remplace l'espace par un + au lieu de %20. Les deux formes sont acceptées par la plupart des serveurs dans une chaîne de requête, mais elles ne sont pas interchangeables partout : dans un chemin d'URL, un + reste littéralement un signe plus.
Parce que decodeURIComponent applique strictement le percent-encoding, où seul %20 désigne un espace : un + est un caractère ordinaire qu'il restitue tel quel. C'est le décodage de formulaire qui traite le + comme un espace. Si vous décodez une chaîne issue d'un formulaire, remplacez les + par des espaces avant, ou utilisez URLSearchParams qui s'en charge.
Oui. encodeURIComponent convertit d'abord le texte en octets UTF-8, puis échappe chaque octet en %XX. Un caractère accentué occupe deux octets et produit donc deux séquences — é devient %C3%A9 — un emoji quatre octets et quatre séquences. L'aller-retour restitue exactement le texte d'origine, à condition que la chaîne encodée soit elle-même de l'UTF-8 valide.
Elle apparaît au décodage quand la chaîne saisie ne respecte pas le format attendu : un % qui n'est pas suivi de deux chiffres hexadécimaux, ou une suite d'octets qui ne forme pas de l'UTF-8 valide, comme %C3 laissé seul. Une cause fréquente est une chaîne déjà décodée une fois de trop, ou une valeur tronquée à la copie.
Non. L'encodage et le décodage s'exécutent entièrement dans votre navigateur, via les fonctions natives encodeURIComponent et decodeURIComponent. Aucune requête réseau ne contient votre texte, ce qui compte quand la valeur manipulée est un jeton ou un identifiant.