Encoder une URL

Trois réponses correctes, et pourquoi un seul bouton se trompe

L'encodage pourcent remplace un caractère par un % suivi de la valeur de son octet en hexadécimal. La spécification répartit les caractères en trois groupes, et tout ce qui prête à confusion en découle. Les caractères non réservés — lettres, chiffres, trait d'union, point, tiret bas et tilde — n'ont jamais besoin d'être encodés. Les caractères réservés — barres obliques, points d'interrogation, esperluettes, signes égal et deux-points qui donnent à une URL sa structure — doivent être encodés *quand ce sont des données* et ne doivent pas l'être *quand ils font partie de la structure*. Tout le reste est toujours encodé.

C'est pourquoi il n'existe pas de réponse unique. Encoder une URL entière doit laisser intacts les barres obliques et le point d'interrogation, sinon l'adresse cesse d'en être une. Encoder une valeur destinée à un paramètre de requête doit échapper les esperluettes et les signes égal, sinon une valeur qui en contient un se scinde en deux paramètres. Encoder un segment de chemin doit échapper les barres obliques, sinon un nom de fichier contenant une barre oblique devient deux dossiers. Un bouton « Encoder » unique choisit l'un de ces cas et se trompe les deux autres fois sur trois — généralement sans rien signaler, et généralement d'une manière qui n'apparaît qu'avec des données inhabituelles.

L'espace est le caractère le plus chargé d'histoire. Dans une URL, c'est %20. Dans un formulaire HTML envoyé, c'est un +, un encodage distinct et plus ancien qui perdure parce que les formulaires fonctionnent ainsi depuis 1994. Chacun est correct dans son contexte et aucun ne l'est dans l'autre : c'est pourquoi un signe plus dans une chaîne de requête est ambigu, d'une façon qu'aucune précaution côté encodage ne peut corriger.

Le texte non ASCII est d'abord encodé en UTF-8, puis octet par octet : une seule lettre accentuée devient ainsi deux séquences pourcent, et un emoji quatre. Le double encodage est le bug classique : encoder quelque chose de déjà encodé transforme chaque % en %25, si bien que %20 devient %2520 et que l'autre extrémité reçoit un signe pourcent littéral. Si une URL est remplie de %25, elle est passée par un encodeur de trop.

Si vous cherchez autre chose

Dans le code, utilisez la fonction propre au langage et choisissez-la aussi délibérément que cette page vous y oblige. JavaScript a encodeURI pour les adresses entières et encodeURIComponent pour les valeurs ; Python a urllib.parse.quote, avec un argument safe qui laisse par défaut les barres obliques intactes ; PHP distingue rawurlencode de urlencode, qui diffèrent précisément sur la question espace ou plus évoquée plus haut. Mieux encore, construisez vos URL avec un type URL plutôt qu'en concaténant des chaînes, et la question disparaît.

En ligne de commande, jq -rR @uri encode de façon sûre et gère une liste, et curl --data-urlencode construit un paramètre correctement encodé sans que vous ayez à vous demander dans lequel des trois cas vous êtes — c'est le seul endroit où c'est vraiment simple.