Encodez et décodez des URL et des chaînes de requête par encodage en pourcentage. Choisissez le mode composant, l'URI complète ou les données de formulaire, et convertissez dans les deux sens pendant la saisie.
Encodez en pourcentage du texte pour les URL, ou décodez-le. Tapez dans l'un des champs et l'autre se met à jour immédiatement. Choisissez le mode correspondant à l'usage prévu de la valeur : un paramètre de requête unique, une URL complète ou une soumission de formulaire HTML.
L'encodage en pourcentage, expliqué correctement
Pourquoi les URL ont besoin d'encodage
Une URL n'est pas du texte libre. Des caractères comme ?, #, &, / et = sont réservés : ils portent une signification structurelle, marquant où le chemin se termine et où la requête commence, ou séparant un paramètre du suivant. Si une valeur que vous transmettez contient l'un de ces caractères, l'analyseur à l'autre extrémité lira votre URL de travers. L'encodage en pourcentage résout cela en remplaçant l'octet incriminé par un % suivi de sa valeur hexadécimale à deux chiffres, si bien qu'un & à l'intérieur d'une valeur voyage en %26 et ne peut jamais être confondu avec un séparateur.
Non réservé, réservé, et le reste
La RFC 3986 divise l'espace des caractères en trois groupes.
Non réservé — A-Z a-z 0-9 - . _ ~. Ceux-ci n'ont jamais besoin d'encodage et doivent être laissés tels quels. Les encoder quand même est légal mais produit des URL plus laides et peut casser des comparaisons de chaînes naïves.
Réservé — : / ? # [ ] @ ! $ & ' ( ) * + , ; =. Ceux-ci ne sont sûrs que là où ils sont structurels. À l'intérieur d'une valeur, ils doivent être encodés.
Le reste — espaces, caractères de contrôle et tout texte non ASCII. Ceux-ci nécessitent toujours un encodage.
Texte non ASCII et UTF-8
L'encodage en pourcentage opère sur les octets, pas sur les caractères, le texte doit donc d'abord être converti en octets. La réponse moderne est toujours UTF-8. Un signe € occupe trois octets en UTF-8 (E2 82 AC), il s'encode donc en %E2%82%AC. Les anciens systèmes utilisaient parfois le jeu de caractères propre à la page, c'est pourquoi on rencontre encore occasionnellement une URL mojibake encodée en Latin-1 ou GBK. Cet outil utilise UTF-8 partout, conformément à ce que les navigateurs et tous les frameworks de serveur actuels attendent.
Les trois modes, et quand chacun est faux
encodeURIComponent est le choix sûr par défaut et échappe tous les caractères réservés. Utilisez-le chaque fois que vous insérez une valeur dans une URL. encodeURI préserve délibérément les caractères réservés pour qu'une URL complète reste intacte — utilisez-le uniquement pour nettoyer une URL déjà assemblée, jamais sur un paramètre individuel, car il laissera volontiers un & dans votre valeur et corrompra la chaîne de requête.
Le mode formulaire fait exception. La sérialisation application/x-www-form-urlencoded, antérieure aux spécifications d'URL modernes, encode un espace en + plutôt qu'en %20. Les deux sont corrects dans une chaîne de requête, et les serveurs acceptent l'un comme l'autre, mais si vous construisez à la main le corps d'une requête POST, vous devez suivre la convention de formulaire.
L'ambiguïté du +
Comme l'encodage de formulaire donne au + un sens particulier, un signe plus littéral dans une valeur de formulaire doit lui-même être encodé en %2B. C'est le bogue d'encodage le plus courant rencontré : une chaîne base64 ou un numéro de téléphone au format international est transmise telle quelle, et le récepteur transforme chaque + en espace. Si vos données peuvent contenir des signes plus, encodez-les explicitement ou évitez le mode formulaire.
Double encodage
Encoder une chaîne déjà encodée transforme chaque % en %25, si bien que %20 devient %2520. C'est généralement un bogue — cela se produit lorsqu'une valeur est encodée par le code applicatif puis à nouveau par un framework ou un proxy. Si vous voyez %25 dans une URL là où vous ne vouliez pas de signe pourcent littéral, vous avez affaire à une valeur doublement encodée. Décoder deux fois récupère l'original, mais la vraie correction consiste à supprimer l'une des étapes d'encodage.
FAQ
Dois-je utiliser %20 ou + pour un espace ?
Les deux sont acceptés dans une chaîne de requête. Utilisez %20 si vous voulez une représentation valide partout, y compris dans un segment de chemin où + désigne un plus littéral. Utilisez + uniquement lorsque vous produisez des données application/x-www-form-urlencoded.
Pourquoi mon signe plus se transforme-t-il en espace ?
Un maillon de la chaîne analyse la valeur comme des données de formulaire, où + est l'encodage d'un espace. Encodez les signes plus littéraux en %2B avant de les envoyer.
Dois-je encoder une barre oblique ?
Uniquement lorsque la barre fait partie d'une valeur plutôt que d'un séparateur de chemin. Un nom de fichier contenant une barre doit être envoyé en %2F, sinon le serveur le lira comme un niveau de répertoire supplémentaire. Notez que certains serveurs rejettent %2F dans les chemins par défaut, par précaution contre les traversées.
L'encodage est-il sensible à la casse ?
Les chiffres hexadécimaux peuvent être en majuscules ou en minuscules et se décoderont de façon identique, mais la RFC 3986 recommande les majuscules. %2F et %2f sont le même caractère ; %2F est l'orthographe canonique.
Pourquoi le décodage échoue-t-il sur ma chaîne ?
Un signe pourcent doit être suivi de exactement deux chiffres hexadécimaux. Un % isolé ou quelque chose comme %zz est malformé et le décodeur lève une erreur. Si votre texte contient légitimement un signe pourcent, il aurait dû être encodé en %25.
Est-ce que cet outil envoie mes données quelque part ?
Non. L'encodage et le décodage s'exécutent dans votre navigateur à l'aide des fonctions URI intégrées. Rien n'est téléversé.