Encodeur/Décodeur URL

Encodeur/décodeur URL gratuit avec encodeURIComponent vs encodeURI et mode RFC 3986 strict pour OAuth et AWS SigV4. Le décodage préserve le + littéral.

Vous avez des commentaires ? Signalez des bugs, suggérez des fonctionnalités ou partagez vos idées — nous lisons tout

Encodeur/Décodeur URL - Encoder et Décoder URLs en Ligne

Puissant encodeur et décodeur URL en ligne vous aidant encoder texte pour utilisation sûre dans URLs ou décoder chaînes URL encodées pourcentage en texte brut. Fonctionnalités gestion automatique caractères spéciaux, espaces, Unicode et diverses options encodage. Essentiel pour développeurs web travaillant avec paramètres requêtes, endpoints API, données formulaires et manipulation URL.

Pourquoi l'encodage URL transforme-t-il un espace en %20 ?

Les URLs étaient à l'origine restreintes à un petit ensemble de caractères ASCII par la RFC 1738 (1994) et plus tard la RFC 3986 (2005), excluant les espaces car ils brisent les analyseurs qui délimitent les composants par des espaces. Tout caractère ne faisant pas partie de l'ensemble non réservé (A-Z, a-z, 0-9, et -._~) doit être encodé en pourcentage : l'octet est écrit comme % suivi de sa valeur hexadécimale à deux chiffres. Un espace est l'octet 0x20, d'où %20. Dans l'ancien format application/x-www-form-urlencoded utilisé par les formulaires HTML, un espace peut être encodé comme +. Les deux formes se décodent en espace, mais elles ne sont pas interchangeables dans tous les contextes : dans la chaîne de requête, + signifie communément espace, mais dans le chemin ou le fragment, + signifie un + littéral.

Quelle est la différence entre encodeURI et encodeURIComponent ?

Ces deux fonctions JavaScript encodent différents ensembles de caractères car elles ciblent des portées différentes. encodeURI suppose que vous passez une URL complète et préserve les caractères ayant une signification structurelle : : / ? # [ ] @ ! $ & ' ( ) * + , ; = ~ restent tels quels. encodeURIComponent suppose que vous passez une valeur de composant unique (un segment de chemin, une valeur de requête, un fragment) qui doit être intégrable dans une URL sans casser la syntaxe, il échappe donc aussi tous ces caractères structurels. Règle pratique : construisez le squelette URL avec encodeURI, mais enveloppez toujours chaque valeur fournie par l'utilisateur avec encodeURIComponent avant de concaténer. Utiliser encodeURI pour les valeurs de requête est la cause la plus fréquente de liens de recherche et de tracking cassés.

Pourquoi encodeURIComponent n'échappe-t-il pas ! * ' ( ) et comment le rendre strict selon RFC 3986 ?

encodeURIComponent de JavaScript a été implémenté selon l'ancienne spécification RFC 2396, qui classait ! * ' ( ) comme des marques ne nécessitant pas d'échappement. RFC 3986 les a reclassés en sub-delims réservés dans certains contextes. Pour une conformité totale à RFC 3986, post-traitez le résultat : encodeURIComponent(str).replace(/[!*'()]/g, c => '%' + c.charCodeAt(0).toString(16).toUpperCase()). Cela compte lors de la génération de signatures OAuth 1.0a (la spec impose un encodage strict), lors de la construction de requêtes canoniques AWS Signature V4, ou lors de l'interopérabilité avec des bibliothèques strictes côté serveur. Pour les liens web typiques, la fonction intégrée JavaScript convient. Cet outil offre un mode strict qui échappe l'ensemble réservé complet selon la RFC 3986 section 2.2.

Quelle méthode d'encodage choisir : Composant, URL Complète ou RFC 3986 Strict ?

Adaptez la méthode à ce que vous construisez :

Composant (encodeURIComponent) — la valeur par défaut. Utilisez-la pour UNE SEULE valeur que vous insérez dans une URL : la valeur d'un paramètre de requête, un segment de chemin, un champ de formulaire ou toute saisie utilisateur. Elle échappe les caractères structurels : / ? # & = + afin qu'ils ne cassent pas l'URL environnante. Exemple : le terme de recherche "café & thé" devient caf%C3%A9%20%26%20th%C3%A9 pour que le & ne soit pas lu comme séparateur de paramètres.

URL Complète (encodeURI) — utilisez-la sur une URL COMPLÈTE déjà assemblée, lorsque vous voulez seulement corriger les espaces et les caractères non-ASCII tout en gardant la structure intacte. Elle laisse : / ? # & = tels quels. Exemple : https://exemple.com/chemin?q=bonjour monde devient https://exemple.com/chemin?q=bonjour%20monde. Ne l'utilisez jamais sur une valeur de requête isolée — son & survivrait et corromprait la requête.

RFC 3986 Strict — Composant plus l'échappement de ! * ' ( ), que la fonction intégrée de JavaScript omet. Utilisez-la lorsqu'une signature ou une forme canonique dépend d'un encodage octet par octet : les chaînes de base de signature OAuth 1.0a et les requêtes canoniques AWS Signature V4 l'imposent. Sous-échapper ici produit une signature invalide et une requête rejetée, alors que la même valeur fonctionnerait comme un lien ordinaire.

Règle pratique : construisez le squelette avec URL Complète, encodez chaque valeur insérée avec Composant, et passez à Strict uniquement pour signer des requêtes.

Comment les caractères non-ASCII comme le chinois, le vietnamien ou les emoji sont-ils encodés ?

Selon la RFC 3986 section 2.5 (et les spécifications IRI antérieures dans la RFC 3987), le texte non-ASCII dans les URLs doit d'abord être converti en octets UTF-8 puis chaque octet encodé en pourcentage. Le caractère "é" fait deux octets en UTF-8 (C3 A9), donc il devient %C3%A9 — deux échappements pourcentage, pas un. L'emoji "🎉" fait quatre octets UTF-8 (F0 9F 8E 89) et devient %F0%9F%8E%89 — quatre échappements. Les anciens systèmes utilisaient parfois Latin-1 ou Windows-1252 et produisaient %E9 pour é, qu'un décodeur UTF-8 moderne interprétera mal. Si vous voyez ? ou des caractères de remplacement après décodage, la source utilisait probablement un encodage d'octets non-UTF-8. Cet outil encode et décode toujours en UTF-8.

Encodeur/Décodeur URL — Encodeur/décodeur URL gratuit avec encodeURIComponent vs encodeURI et mode RFC 3986 strict pour OAuth et AWS SigV4. Le d — **Encodeur/Décodeur URL**

Quels caractères n'ont jamais besoin d'être encodés dans une URL ?

RFC 3986 définit l'ensemble non réservé : A-Z majuscules, a-z minuscules, chiffres 0-9, et les quatre marques - . _ ~. Ces 66 caractères sont garantis de signifier la même chose dans chaque composant URL et ne nécessitent jamais d'encodage. Les caractères réservés se divisent en deux groupes : gen-delims (: / ? # [ ] @) qui séparent les composants URL et doivent être encodés dans la valeur d'un composant, et sub-delims (! $ & ' ( ) * + , ; =) qui ont une signification spéciale dans certains composants. Que les sub-delims nécessitent un encodage dépend du contexte — = et & sont critiques dans les chaînes de requête mais inoffensifs dans un segment de chemin. Raccourci sûr : encodez tout en dehors de l'ensemble non réservé.

Pourquoi le décodage laisse-t-il parfois un %25 littéral dans ma chaîne ?

Parce que % lui-même doit être encodé en %25 pour le distinguer de la séquence d'échappement d'encodage pourcentage. Si votre chaîne contenait un signe pourcentage littéral correctement encodé une fois en %25, une seule passe de décodage le transforme en %. Mais si la chaîne a été doublement encodée — encodée une fois lors du stockage, encodée à nouveau lors de la concaténation dans une autre URL — un seul décodage laisse %25 en place, ce qui ressemble alors à un échappement égaré. Le double encodage est répandu dans les pipelines où une URL est passée comme paramètre de requête à un autre service : chaque saut ajoute une couche. Le remède est de décoder exactement une fois par saut d'encodage, jamais plus, jamais moins.

Les fragments URL (la partie après #) sont-ils encodés comme le chemin ou la requête ?

Principalement, mais avec deux différences clés. RFC 3986 section 3.5 définit l'alphabet du fragment comme pchar / "/" / "?", ce qui permet / et ? non échappés dans le fragment sans ambiguïté (il n'y a plus de délimiteur après #). Cela signifie que encodeURIComponent va sur-échapper ces caractères dans les fragments, produisant %2F et %3F là où les formes non échappées sont légales. De plus, le fragment n'est jamais envoyé au serveur dans les requêtes HTTP — il est purement côté client — donc les décodeurs côté serveur peuvent ne jamais le voir. Lors de la construction de fragments de deep-link pour des SPAs contenant JSON ou des routes, le sur-échappement de encodeURIComponent est généralement acceptable. Cet outil expose un mode conscient du fragment.

Quelle est la longueur maximale d'une URL, et que se passe-t-il si je la dépasse ?

Il n'y a pas de limite stricte dans les spécifications HTTP ou URL — RFC 7230 recommande explicitement que les serveurs supportent "une ligne de requête d'au moins 8000 octets". En pratique, les navigateurs, serveurs et intermédiaires imposent leurs propres plafonds. Chrome accepte jusqu'à 32 Ko dans la barre d'adresse mais tronque au-delà de 2 Mo en interne. Apache par défaut 8 Ko (LimitRequestLine), Nginx 8 Ko (large_client_header_buffers), et IIS 16 Ko. AWS API Gateway plafonne à 8 Ko. Au-delà de la limite du saut le plus bas, vous obtenez une erreur 414 URI Too Long. Pour des données de plus de quelques centaines d'octets, passez à un corps POST ou fragmentez les données sur plusieurs requêtes. Gardez les URLs sous 2 Ko pour la portabilité.