Encodeur / décodeur d'URL — réussir l'encodage pour cent du premier coup

L’encodage pour cent est une de ces choses que chaque ingénieur pense comprendre jusqu’à ce qu’il écrive à la main une URL avec un + dans la chaîne de requête et le voie arriver sur le serveur comme un espace. Les règles sur quels caractères sont sûrs dans quelle partie d’une URL ne sont pas symétriques — un caractère acceptable dans le chemin peut casser la requête, un caractère acceptable dans un corps encodé en formulaire peut casser un en-tête. Rouler l’encodage à la main se trompe assez souvent pour que le bon réflexe soit d’arrêter de deviner. L’Encodeur / décodeur d’URL de PortJar enlève la devinette en un écran.

Ce que fait l’outil

L’outil prend n’importe quelle chaîne et produit sa forme encodée pour cent, ou prend une chaîne encodée pour cent et produit l’original. Il tourne entièrement dans votre navigateur — rien n’est envoyé aux serveurs de PortJar et rien n’est journalisé. Cela compte quand la chaîne que vous encodez est un jeton fourni par un client, un identifiant interne, ou n’importe quoi d’autre que vous ne voulez pas voir dans un journal tiers.

L’encodage suit les règles du jeu de caractères sûrs dans les composantes d’URL : les alphanumériques, plus -, ., _ et ~ passent tels quels, tout le reste devient une séquence d’octets %xx en UTF-8. Le décodage est l’inverse — chaque %xx devient l’octet original, puis ces octets sont interprétés comme UTF-8. Les séquences invalides sont signalées plutôt que silencieusement déformées.

Comment l’utiliser

Ouvrez portjar.com/tools/url-encoder. Collez la chaîne brute du côté encodeur pour voir sa forme encodée, ou collez la chaîne encodée du côté décodeur pour voir ce qu’elle représente réellement. La conversion est en direct — ce que vous collez est ce qui est converti, et vous pouvez copier le résultat directement sans détour par un terminal ou un fichier brouillon.

Quand vous y recourriez

Construire une URL avec un paramètre non ASCII. Un accent français, un nom cyrillique, un emoji dans un terme de recherche — n’importe lequel cassera une URL si vous le collez tel quel. Encoder la valeur d’abord garantit que le serveur récepteur reçoit les octets voulus.
Décoder un paramètre de requête collé depuis une ligne de journal. Les journaux d’accès préservent la forme encodée. Quand vous voulez savoir ce qu’une requête demandait réellement, le décodeur transforme %2Fadmin%2Fusers%3Fid%3D42 en /admin/users?id=42 d’un coller.
Attraper un bogue de double encodage. Quand une valeur ressemble à %2520 au lieu de %20, elle a été encodée deux fois — le plus souvent par un cadriciel qui avait déjà encodé la valeur puis a réencodé l’URL qui la contenait. Le décodeur rend la double couche évidente, parce que décoder une fois donne %20 et décoder à nouveau donne un espace.
Construire une URL signée à la main pour un test ponctuel. Quand vous devez simuler une URL signée contre un service pas encore branché au pipeline de déploiement, l’encodeur produit la séquence d’octets exacte que le signataire attend.
Lire une URL suspecte d’une alerte d’hameçonnage ou de sécurité. Les attaquants masquent les destinations avec de l’encodage supplémentaire pour contourner les filtres d’URL. Décoder l’URL avant de cliquer — ou avant de permettre à quelqu’un d’autre de cliquer — transforme le masquage en texte clair que vous pouvez évaluer.

Quoi faire de la sortie

Un aller-retour — encoder, puis décoder — devrait retourner exactement ce avec quoi vous avez commencé. Si ce n’est pas le cas, l’entrée avait un caractère que l’outil a signalé, ou avait des octets encodés qui ne formaient pas un UTF-8 valide. Les deux méritent une enquête avant d’expédier l’URL quelque part.

Surveillez l’espace. Un espace littéral s’encode en %20 dans le chemin ou une valeur de requête. La convention héritée de l’encodage de formulaire représente l’espace par +, ce qu’utilisent les corps application/x-www-form-urlencoded. Les deux ne sont pas interchangeables dans une URL — un + dans une valeur de requête est interprété comme un espace par certains récepteurs et comme un + littéral par d’autres, et le désaccord est une source fréquente de bogues. En cas de doute, utilisez %20.

Surveillez les barres. Un / dans un chemin d’URL est un séparateur de chemin. Un %2F est le caractère barre littéral et n’est pas interprété comme un séparateur — certains serveurs web rejettent la requête d’emblée (AllowEncodedSlashes off sur Apache, similaire sur nginx), et d’autres l’acceptent et la transmettent. Si une valeur que vous encodez contient une barre, cette barre est presque toujours censée être encodée, mais le serveur récepteur doit être configuré pour l’accepter.

Surveillez le point d’interrogation et l’esperluette. Un ? est le séparateur de requête et un & sépare les paramètres de requête. Les deux doivent être encodés s’ils apparaissent dans une valeur, sinon le récepteur les lit comme structurels et analyse l’URL incorrectement.

Un octet surprise après décodage — caractères de contrôle, un nul, une séquence UTF-8 qui ne forme pas un glyphe sensé — est souvent le constat le plus utile que l’outil produit. C’est le moment où vous réalisez que l’URL transportait quelque chose que le système qui l’a produite n’avait pas l’intention d’y mettre.

Pour les environnements où la manipulation des URLs, l’encodage des formulaires et l’hygiène des certificats doivent rester cohérents sur plusieurs sites, Stack Harbor s’en occupe dans le cadre des environnements infogérés.