Codec URL

Pourquoi les URL ont besoin d’encodage

Une URL est à la fois une adresse lisible et une chaîne structurée analysée par les navigateurs, proxies et serveurs. Certains caractères séparent les composants : ? démarre la requête, & sépare les paramètres, # commence le fragment, / divise les segments de chemin, et les espaces sont gênants dans bien des contextes. Si la valeur d’un paramètre contient elle-même & ou =, l’analyseur mal lirait la structure à moins que ces octets ne soient écrits sous une forme sûre.

L’encodage d’URL—plus formellement le percent-encoding—remplace les octets non sûrs ou réservés par un % suivi de deux chiffres hexadécimaux. L’octet space devient souvent %20 (ou + dans la variante application/x-www-form-urlencoded). Ce n’est pas du chiffrement ; c’est une orthographe de transport pour que structure et charge utile puissent coexister.

Essayez d’encoder une phrase avec l’outil texte vers URL encodée.

Caractères réservés versus non réservés

RFC 3986 définit les caractères unreserved qui apparaissent en général tels quels : lettres, chiffres et -._~. Les caractères reserved comme :/?#[]@!$&'()*+,;= ont des rôles dans la grammaire d’URL. Encoder un caractère réservé dépend de l’endroit où il apparaît. Un / dans le chemin est un séparateur ; un / dans les données d’un seul segment peut devoir être encodé si vous voulez une barre littérale dans la valeur de ce segment.

Règle pratique : encodez les données que vous injectez dans un composant pour que les caractères réservés perdent leur sens spécial pour l’analyseur environnant.

Mécanique du percent-encoding

1. Exprimer la chaîne en octets (presque toujours UTF-8 sur le web moderne).
2. Pour chaque octet à encoder, écrire % plus de l’hexadécimal en majuscules ou minuscules (les décodeurs acceptent les deux ; les émetteurs utilisent souvent les majuscules).
3. Laisser les caractères sûrs inchangés.

Exemple : l’espace dans hello world devient hello%20world. L’encodage UTF-8 de é est les octets C3 A9, donc le caractère devient %C3%A9.

Le décodage inverse le mapping. Les séquences incomplètes comme %Z ou un % final doivent être rejetées ou traitées selon les règles de votre plateforme—ne devinez pas silencieusement dans du code sensible à la sécurité.

Chaînes de requête et application/x-www-form-urlencoded

Les formulaires HTML encodent traditionnellement les espaces en + et utilisent & / = comme délimiteurs. Les bibliothèques nommées encodeURIComponent versus URLSearchParams diffèrent sur les cas limites. Lors du débogage :

• Confirmer si + signifie espace ou un plus littéral.
• Encoder les valeurs avant de les joindre avec &.
• Ne pas encoder toute l’URL à l’aveugle—le schéma et l’hôte ont des règles différentes.

encodeURI et encodeURIComponent en JavaScript encodent des jeux de caractères différents ; choisir le mauvais est une source fréquente de liens cassés.

Chemins, matrices et fragments

Les segments de chemin doivent encoder les espaces et la plupart des caractères réservés qui ne sont pas destinés à être des séparateurs. Les fragments (#...) sont gérés par le client et ne sont pas envoyés aux serveurs dans la requête HTTP ; l’encodage reste important pour la correction côté client. Le userinfo (user:pass@) est obsolète pour les secrets dans les URL—évitez de placer des identifiants dans les URL, quel que soit l’encodage.

Double encodage et bogues de décodage

Le double encodage survient lorsque %20 est encodé à nouveau en %2520. Symptômes : %20 littéral dans le texte de l’UI, ou fichiers introuvables car le serveur cherche le mauvais nom. Le sous-encodage laisse un & dans une valeur et tronque les paramètres suivants.

Un pipeline robuste encode exactement une fois à la frontière où une chaîne brute devient partie d’un composant d’URL, et décode une fois à l’extraction des valeurs.

Noms de domaine internationalisés et chemins

Les hôtes utilisent IDNA (Punycode) pour les libellés de domaine non ASCII—un mécanisme différent du percent-encoding des données de chemin et de requête. Chemins et requêtes utilisent le percent-encoding UTF-8. Mélanger des encodages système hérités (Latin-1 d’un côté, UTF-8 de l’autre) produit du mojibake après décodage.

Documentez toujours UTF-8 comme encodage d’octets pour les nouvelles API.

Angles de sécurité

L’encodage d’URL ne remplace ni l’échappement HTML, ni la paramétrisation SQL, ni la sécurité des arguments de commande. Une chaîne correctement percent-encodée pour un paramètre de requête peut rester dangereuse si elle est ensuite placée dans du HTML sans échappement, ou dans un shell sans guillemets appropriés.

Les problèmes d’open-redirect et de SSRF impliquent souvent des URL comme données. Validez schémas et hôtes après décodage—les attaquants peuvent encoder points, barres ou identifiants pour tromper des filtres naïfs. Comparez soigneusement les formes décodées ; mieux encore, analysez avec une bibliothèque URL standard et autorisez des propriétés par liste blanche.

Journalisation et confidentialité

Les chaînes de requête contiennent souvent des termes de recherche, des tokens ou des données personnelles. L’encodage ne les cache ni des journaux serveur ni de l’historique du navigateur. Préférez les corps POST ou les en-têtes pour les valeurs sensibles, et retirez les secrets des journaux d’accès.

Liste de contrôle de test

1. Encoder une chaîne avec espaces, &, = et caractères non ASCII.
2. Décoder et comparer aux points de code d’origine.
3. Placer la valeur encodée dans une vraie requête et la relire via l’API de paramètres de votre framework.
4. Vérifier que votre framework ne double-décode pas.
5. Vérifier que le comportement de + versus %20 correspond au type de média utilisé.

L’outil d’encodage URL aide pour les étapes 1–2 lors d’une exploration manuelle.

Scénarios courants

Construire des liens de recherche. Encoder la valeur de requête utilisateur ; ne pas encoder ?q= lui-même. URI de redirection OAuth. Une correspondance exacte de chaîne peut être exigée ; les différences d’encodage cassent les redirections. Clés d’object storage dans les URL. Encoder les segments de chemin pour que les clés imbriquées avec espaces fonctionnent. CSV de liens. Attention aux tableurs qui réinterprètent les séquences %.

Encodages connexes

Ne confondez pas percent-encoding avec Base64 ou les entités HTML. Base64 utilise un autre alphabet et sert pour des octets arbitraires en contexte texte ; les entités HTML protègent la structure du document dans le balisage. Utilisez l’encodeur qui correspond à l’analyseur récepteur.

Résumé

L’encodage d’URL permet à du texte arbitraire de voyager dans les composants d’URL sans casser les délimiteurs. Convertissez en octets UTF-8, percent-encodez les valeurs non sûres une fois, et décodez une fois en sortie. Choisissez soigneusement les API pour requête versus URI complète, validez les URL après analyse pour la sécurité, et souvenez-vous : l’encodage est une orthographe—pas de la confidentialité.