Encodeur/Décodeur URL

Encodeur et décodeur URL gratuit en ligne. Encodez texte pour URLs ou décodez chaînes encodées URL instantanément. Convertissez caractères spéciaux, espaces et Unicode en format encodé pourcentage. Parfait pour développeurs web travaillant avec paramètres requêtes, endpoints API et gestion URL.

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.

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 et décodeur URL gratuit en ligne. Encodez texte pour URLs ou décodez chaînes encodées URL instantanément. Conve — **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é.