Encodage et décodage d'URL en ligne, gratuits

Ce que fait réellement l’encodage d’URL

L’encodage d’URL (aussi appelé encodage par pourcentage) est le mécanisme que le web utilise pour faire tenir des données de caractères arbitraires dans une URL. Les URL ont été conçues à l’origine pour un tout petit alphabet ASCII (lettres, chiffres et un petit ensemble de signes de ponctuation) et les caractères en dehors de cet alphabet (espaces, lettres accentuées, esperluettes, barres obliques qui ne sont pas des séparateurs de chemin, émojis, tout ce qui est cyrillique, CJC ou arabe) doivent être échappés avant de pouvoir voyager sans encombre à travers HTTP, les journaux serveur, les barres d’adresse, les gestionnaires de copier-coller et les tuyaux du shell. La règle d’encodage est simple : prenez la séquence d’octets UTF-8 du caractère, écrivez chaque octet sous la forme d’un signe pourcentage suivi de deux chiffres hexadécimaux. Une espace (un octet, 0x20) devient %20. Une esperluette (0x26) devient %26. Le signe euro € (trois octets UTF-8 E2 82 AC) devient %E2%82%AC. La forme encodée est réversible (chaque analyseur d’URL du web sait la décoder) et le résultat est une chaîne qui ne contient que des caractères ASCII « sûrs ».

Brève histoire de la règle d’encodage

La convention d’encodage par pourcentage remonte à RFC 1738 (« Uniform Resource Locators (URL) », Tim Berners-Lee, Larry Masinter et Mark McCahill, décembre 1994), la première spécification formelle d’URL publiée par l’IETF. La RFC 1738 a défini le jeu original de caractères « réservés » (caractères ayant une signification structurelle dans les URL et qui doivent être encodés lorsqu’ils servent de données) et le jeu original « non réservés » (caractères qui n’ont jamais besoin d’être encodés). La spécification a été substantiellement révisée dans RFC 2396 (Berners-Lee, Fielding, Masinter, août 1998) puis (de manière définitive) dans RFC 3986 (« Uniform Resource Identifier (URI): Generic Syntax », Berners-Lee, Fielding, Masinter, janvier 2005), qui demeure aujourd’hui la spécification formelle des URI. La RFC 3986 a élargi le jeu non réservé pour inclure le tilde (~), a formalisé UTF-8 comme encodage des caractères non ASCII dans les IRI, et a resserré les règles déterminant quand un caractère réservé doit être encodé par pourcentage ou laissé tel quel. Pour les URI non ASCII, RFC 3987 (« Internationalized Resource Identifiers », Duerst et Suignard, janvier 2005) a défini l’extension IRI qui permet aux URL de contenir des caractères Unicode natifs, en faisant correspondre la forme IRI à la forme URI standard via UTF-8 + encodage par pourcentage. Pour les noms de domaine en particulier, RFC 3492 a défini Punycode (Costello, mars 2003), l’encodage utilisé pour représenter les étiquettes de domaine Unicode (xn--exmpla-...) dans le DNS, structurellement similaire mais reposant sur un algorithme différent. La spécification d’URL de fait du web moderne est le WHATWG URL Living Standard, édité par Anne van Kesteren, qui encode le comportement réel des navigateurs, divergeant parfois de la RFC 3986 pour rester rétrocompatible avec la façon dont les URL fonctionnent en pratique.

Réservés, non réservés, et les caractères qui s’encodent toujours

La RFC 3986 répartit les caractères d’URI en trois classes. Les caractères non réservés: lettres A-Z a-z, chiffres 0-9, et les quatre signes - _ . ~: n’ont jamais besoin d’être encodés et n’acquièrent aucune signification particulière lorsqu’ils le sont. Les caractères réservés: : / ? # [ ] @ ! $ & ' ( ) * + , ; =: ont une signification structurelle dans les URL (la barre oblique sépare les segments de chemin, le point d’interrogation introduit la requête, l’esperluette sépare les paramètres de requête, le dièse introduit le fragment). Les caractères réservés peuvent apparaître non encodés dans leur rôle structurel ; ils doivent être encodés lorsqu’ils servent de données ordinaires. Tous les autres caractères: caractères de contrôle, espaces, le pourcentage lui-même et tout octet d’une séquence UTF-8 non ASCII, doivent toujours être encodés par pourcentage. Le caractère pourcentage est spécial : il doit être encodé en %25 lorsqu’il sert de données, car un pourcentage non encodé dans un contexte d’URL introduit une séquence d’échappement par pourcentage que l’analyseur tentera de décoder. Sauter cette étape produit certains des bogues de manipulation d’URL les plus courants en circulation.

encodeURI vs encodeURIComponent, quand utiliser lequel

JavaScript fournit deux encodeurs intégrés, tous deux normalisés dans ECMAScript depuis 1999 (ES3). Le choix entre les deux est la décision d’encodage d’URL la plus courante dans le code web, et se tromper produit des bogues subtils qui passent les tests sur des entrées simples mais cassent sur des données utilisateur réelles contenant des esperluettes, des dièses ou des barres obliques.

• encodeURIComponent: encode tout sauf le jeu non réservé. À utiliser lorsqu’on encode une seule donnée destinée à être insérée dans une URL, la valeur d’un paramètre de requête, un segment de chemin, un identifiant de fragment, la valeur d’un champ de formulaire. La chaîne hello world&more devient hello%20world%26more: l’esperluette intérieure est encodée, elle ne sera donc pas interprétée comme un séparateur de paramètre de requête lorsque l’URL sera ultérieurement lue. C’est l’outil approprié pour « j’ai une saisie utilisateur, je veux la placer dans une URL en toute sécurité ».
• encodeURI: n’encode que les caractères illégaux n’importe où dans une URL. Il laisse délibérément intacts les caractères réservés (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) parce qu’ils peuvent jouer un rôle structurel. À utiliser lorsqu’on encode une URL entière dont la structure est déjà en place, une URL contenant ses propres séparateurs ? et &, une URL avec des caractères non ASCII dans le chemin ou la requête qui doivent être encodés sans perturber la grammaire de l’URL. La chaîne https://example.com/search?q=hello world devient https://example.com/search?q=hello%20world: les barres obliques et le point d’interrogation sont préservés, seule l’espace est encodée.

La règle mentale : encodeURIComponent pour les données, encodeURI pour les URL. Utilisez le mauvais et vous casserez soit la structure de l’URL (encodeURIComponent sur une URL entière échappe les barres obliques et esperluettes dont vous aviez besoin), soit l’échappement de la saisie utilisateur (encodeURI sur une valeur de requête laisse passer les esperluettes et vos données seront analysées comme plusieurs paramètres).

application/x-www-form-urlencoded, l’autre encodage

Il existe un second encodage, apparenté, utilisé spécifiquement pour les soumissions de formulaire HTML : application/x-www-form-urlencoded. Il ressemble presque à l’identique à l’encodage par pourcentage des URL à un détail près, les espaces sont encodées en + plutôt qu’en %20. Cette convention provient de la spécification originelle des formulaires HTML et est préservée dans l’URL Living Standard pour le sérialiseur application/x-www-form-urlencoded spécifiquement. Les décodeurs de données encodées en formulaire doivent inverser la convention : un + littéral dans des données de formulaire est encodé en %2B, et un + dans la chaîne encodée se décode en espace. L’API URLSearchParams de JavaScript gère cette convention automatiquement ; encodeURIComponent ne le fait pas: il encode toujours les espaces en %20. Pour des chaînes de requête assemblées à la main pour une action de formulaire HTML, utilisez URLSearchParams plutôt que d’appeler encodeURIComponent sur chaque valeur individuellement.

Quand cet outil est réellement nécessaire

• Déboguer un appel d’API. Vous interrogez un point d’accès REST avec un paramètre de requête contenant des espaces ou des caractères spéciaux et vous obtenez des erreurs 400 ou des résultats inattendus. Encodez ici la valeur du paramètre, collez le résultat dans votre requête, et vérifiez que l’API traite correctement l’entrée.
• Construire une URL partageable à la main. Composer un lien profond vers une page de résultats de recherche, une vue filtrée d’un tableau de bord SaaS, ou un formulaire prérempli, partout où vous devez intégrer une requête de recherche ou un état de sélection dans l’URL.
• Décoder une URL capturée pour lire ce qu’elle contient réellement. Une URL journalisée contient %E2%9C%93%20done: qu’est-ce que cela donne une fois décodé ? Collez, cliquez sur Décoder, voyez ✓ done.
• URL OAuth et webhooks. Le paramètre redirect_uri dans les flux OAuth doit être encodé par pourcentage avec précision ; se tromper produit des erreurs opaques « redirect_uri mismatch ». Les URL de webhook qui contiennent des paramètres avec des données utilisateur exigent un encodage soigneux.
• Noms de fichier avec caractères non ASCII dans les liens de téléchargement. Un lien direct vers un fichier nommé café-menu.pdf a besoin que le é soit encodé par pourcentage pour que le lien fonctionne dans tous les navigateurs et outils du shell.
• Chaînes de connexion à la base de données. Les URL de PostgreSQL, MySQL et bases de données similaires (postgres://user:p@ssw0rd@host/db) ont besoin que le mot de passe soit encodé par pourcentage s’il contient @, :, / ou d’autres caractères réservés qui désorienteraient l’analyseur d’URL.

Sécurité : pourquoi l’encodage compte au-delà de l’esthétique

Un encodage d’URL incorrect est une source ancienne de vulnérabilités web. Le HTTP response splitting exploite des sauts de ligne non encodés (CR, LF, %0D%0A) dans des paramètres d’URL qui sont reflétés dans des en-têtes HTTP, permettant à un attaquant d’injecter des en-têtes arbitraires voire une réponse complète. Les redirections ouvertes exploitent une manipulation naïve d’URL qui ne décode et ne valide pas correctement les URL fournies par l’utilisateur avant de rediriger. La falsification de requêtes côté serveur (SSRF) peut abuser de caractères encodés pour contourner des listes blanches d’URL, une expression régulière qui bloque « http://internal » manque « http://%69nternal » si le serveur décode après le filtrage. L’injection SQL via des paramètres d’URL n’est pas en soi une question d’encodage d’URL, mais elle est aggravée lorsque les guillemets simples et autres méta-caractères SQL survivent jusqu’à la requête de base de données. La recommandation de l’OWASP depuis le début des années 2000 est : encoder à la frontière en entrée, décoder à la frontière en sortie, ne jamais mélanger formes encodées et décodées dans le même tampon. Cet outil effectue précisément l’étape encoder/décoder, ce que vous faites du résultat vous appartient, et la responsabilité de la sécurité se trouve à la couche applicative.

Double encodage, le bogue le plus courant

Le double encodage survient lorsqu’une chaîne déjà encodée est encodée à nouveau. Le caractère espace dans une URL déjà encodée vaut %20 ; encodez-le encore et vous obtenez %2520 (parce que % s’encode en %25). Lorsque le destinataire décode une fois, il récupère %20 au lieu d’une espace. Lorsqu’il décode deux fois (dans les rares cas où le double décodage est pris en charge), il obtient l’espace, mais la plupart des analyseurs ne le font pas, et l’URL contient silencieusement un %20 visible dans la barre d’adresse. Le correctif est toujours : décodez d’abord si vous ne savez pas si l’entrée est déjà encodée, puis encodez exactement une fois. Le même schéma s’applique en code, n’appelez jamais encodeURIComponent deux fois sur la même chaîne. Si vous devez transférer une valeur d’un contexte à un autre, décodez l’encodage précédent avant de réencoder pour le nouveau contexte. Le bouton Échanger de cet outil aide pour le cycle de diagnostic : collez une URL suspecte, cliquez sur Décoder pour voir ce qu’elle contient, cliquez sur Échanger, cliquez sur Encoder pour récupérer la forme encodée canonique.

Confidentialité : exécution uniquement dans le navigateur

Les URL embarquent fréquemment des données sensibles, jetons d’authentification dans les paramètres de requête, identifiants d’utilisateur dans les segments de chemin, requêtes de recherche contenant un contexte personnel, valeurs d’état OAuth, URL de webhook incluant des clés d’API. Les encodeurs d’URL côté serveur conservent une copie de chaque URL que vous y collez dans leurs journaux. Cet outil utilise les fonctions intégrées de JavaScript encodeURIComponent, encodeURI, decodeURIComponent et decodeURI exécutées localement dans votre onglet de navigateur. Aucune étape de téléversement, aucune télémétrie, aucune journalisation, vérifiez dans l’onglet Réseau des DevTools pendant que vous cliquez sur Encoder (aucune requête ne part), ou mettez la page hors ligne (mode avion) après son chargement et l’encodeur fonctionne toujours. Sûr pour les URL contenant des jetons, des clés d’API, des points d’accès internes, ou toute URL que vous ne voudriez pas voir copiée sur le disque dur d’un inconnu.

Questions fréquentes

Quand dois-je encoder un texte pour une URL ?

Chaque fois que vous insérez une saisie utilisateur ou des données contenant des caractères spéciaux dans une URL, requêtes de recherche dans une chaîne de requête, noms de fichier dans un chemin, valeurs de paramètre dans des requêtes d’API, cibles de redirection dans des flux OAuth. Sans encodage, les caractères spéciaux soit cassent la structure de l’URL (une & non échappée dans une valeur est interprétée comme un séparateur de paramètre), soit introduisent des vulnérabilités de sécurité (un saut de ligne non échappé permet le HTTP response splitting). La règle empirique : toute chaîne contenant autre chose que des lettres, des chiffres et les quatre signes -_.~ doit être encodée avant de rejoindre une URL.

Qu'est-ce que le double encodage et comment l'éviter ?

Le double encodage survient lorsqu’un texte déjà encodé est encodé une seconde fois, transformant %20 en %2520 (parce que le caractère pourcentage lui-même est encodé en %25). Les destinataires qui décodent une fois récupèrent la forme à demi décodée plutôt que l’original. Toujours : si vous ne savez pas si une chaîne est déjà encodée, décodez-la d’abord, puis encodez-la exactement une fois. En code, n’appelez jamais encodeURIComponent sur la sortie d’un autre encodeURIComponent.

Cet outil est-il sûr pour des URL sensibles ?

Oui. L’encodeur/décodeur utilise les fonctions intégrées de JavaScript exécutées entièrement dans votre navigateur. L’URL que vous collez ne traverse jamais le réseau, vérifiez dans l’onglet Réseau des DevTools pendant que vous cliquez sur Encoder (aucune requête ne part), ou mettez la page hors ligne (mode avion) après son chargement. Sûr pour les URL contenant des jetons OAuth, des clés d’API, des adresses de points d’accès internes, ou toute valeur que vous ne voudriez pas voir journalisée sur un serveur tiers.

Pourquoi mes données de formulaire ont-elles des signes plus au lieu de %20 ?

Les soumissions de formulaire HTML utilisent un encodage distinct mais apparenté appelé application/x-www-form-urlencoded, qui encode les espaces en + plutôt qu’en %20 par convention historique. Les deux formes sont valides dans les chaînes de requête d’URL ; les analyseurs modernes acceptent l’une ou l’autre. L’API URLSearchParams de JavaScript utilise la convention de formulaire ; encodeURIComponent utilise toujours %20. Si vos données doivent interopérer avec du code ancien de gestion de formulaire, utilisez URLSearchParams ; sinon, l’une ou l’autre forme convient.

Et les caractères non ASCII et les émojis ?

L’encodage d’URL moderne utilise UTF-8 : chaque caractère non ASCII est converti en sa représentation UTF-8 multi-octets, puis chaque octet est encodé par pourcentage. Le signe euro (€, trois octets UTF-8) devient %E2%82%AC ; un émoji comme la fusée 🚀 (quatre octets) devient %F0%9F%9A%80. La RFC 3987 (IRI) et le WHATWG URL Standard formalisent tous deux cette convention UTF-8 d’abord. Les systèmes plus anciens utilisaient parfois Latin-1 ou d’autres encodages ; si vous décodez d’anciennes URL et que le résultat semble brouillé, la source a pu utiliser un autre encodage de caractères avant l’encodage par pourcentage.

Outils associés