Quelle est la différence entre l'encodage d'un composant et un URI complet ?

L'encodage des composants (le défaut) échappe aux caractères réservés comme & = ? /, donc c'est correct pour une seule valeur de requête. L'encodage URI complet laisse ces caractères en place, donc c'est correct pour une URL entière.

Gère-t-il les caractères non anglais ?

Oui. Le texte est encodé en pourcentage en UTF-8, donc les accents, les emoji et les caractères CJK s'encodent et se décodent correctement.

Que se passe-t-il si je colle du texte codé invalide ?

Si un caractère d'échappement en pourcentage est mal formé (comme un % isolé), le décodage affiche une erreur au lieu de produire du charabia.

Pourquoi un espace devient-il parfois %20 et d'autres fois un + ?

Les deux représentent un espace, mais dans des contextes différents. L'encodage en pourcentage (RFC 3986) utilise toujours %20, ce que cet outil produit. Le caractère + est une convention héritée du format application/x-www-form-urlencoded plus ancien utilisé par les soumissions de formulaires HTML, où + signifie espace et un signe plus littéral doit lui-même être encodé en %2B.

Encodeur / Décodeur URL

Encodez le texte pour utilisation dans les URL et chaînes de requête, ou décodez les URL encodées en pourcentage en texte lisible — avec support Unicode complet, tout dans votre navigateur.

URI complet (garder :/?&=)

Entrée

Sortie

https%3A%2F%2Ftoolverse.me%2Fsearch%3Fq%3Dhello%20world%26page%3D2

Comment l'utiliser

Choisissez Encoder ou Décoder et collez votre texte ou URL. Par défaut, il encode une seule valeur (en échappant les caractères comme & = ? /). Activez « URI complet » pour conserver la structure d'une URL intacte et n'échapper que les caractères non sûrs. Cliquez sur copier pour saisir le résultat. L'encodage d'URL, aussi appelé encodage en pourcentage, est la façon standard de rendre le texte sûr pour le placer à l'intérieur d'une URL ou d'une chaîne de requête. Tout caractère en dehors d'un petit ensemble de caractères ASCII réservés et non réservés est remplacé par un signe de pourcentage suivi de deux chiffres hexadécimaux représentant la valeur d'octet de ce caractère — un espace devient %20, une esperluette devient %26, et ainsi de suite. Les URL ne permettent qu'un ensemble limité de caractères ASCII : des lettres, des chiffres et une poignée de marques de ponctuation comme - _ . ~. Tout le reste, y compris les espaces, les guillemets et les lettres non anglaises, doit être échappé avant de pouvoir voyager en toute sécurité dans une URL. Sans encodage, un navigateur ou un serveur peut mal interpréter où se termine une partie d'une URL et où commence une autre — un & non échappé à l'intérieur d'une valeur ressemble au début d'un nouveau paramètre de requête, un ? non échappé ressemble au début de la chaîne de requête elle-même, et un # non échappé est traité comme un identifiant de fragment, coupant silencieusement tout ce qui le suit. Prenez la phrase "café & bar" comme exemple de valeur de requête. Les caractères d'espace deviennent %20, l'esperluette devient %26, et l'accent é — qui prend deux octets en UTF-8 — devient %C3%A9. Encodé en pourcentage, la phrase devient caf%C3%A9%20%26%20bar. Le décodage inverse le processus : chaque paire %XX est relue en tant qu'octet UTF-8 et réassemblée en caractère original, donc décoder cette chaîne rend café & bar exactement comme il a commencé. L'encodage d'une URL entière et l'encodage d'une seule valeur de chaîne de requête sont des tâches différentes. L'encodage URI complet échappe aux caractères non sûrs mais laisse délibérément les caractères structurels d'une URL — / : ? & = # — intacts, car les supprimer briserait la syntaxe de l'URL elle-même. L'encodage des composants (le défaut ici) échappe également à ces mêmes caractères, car une valeur insérée dans une chaîne de requête ne doit jamais être autorisée à introduire un & ou = errant qu'un serveur prendrait pour un nouveau paramètre. L'encodage en pourcentage apparaît constamment dans le travail web quotidien : construire un paramètre de requête à partir de l'entrée utilisateur, partager un lien qui inclut un terme de recherche ou un filtre, assembler des URL de requête API, soumettre les données de formulaire via GET, et construire des paramètres UTM pour les liens de marketing. C'est aussi la correction de l'erreur classique « URI malformé » levée par decodeURIComponent — cette erreur signifie que la chaîne en cours de décodage contient un % qui n'est pas suivi de deux chiffres hexadécimaux valides, généralement parce qu'elle a été mal encodée ou encodée deux fois.

Questions fréquemment posées

Quelle est la différence entre l'encodage d'un composant et un URI complet ?: L'encodage des composants (le défaut) échappe aux caractères réservés comme & = ? /, donc c'est correct pour une seule valeur de requête. L'encodage URI complet laisse ces caractères en place, donc c'est correct pour une URL entière.
Gère-t-il les caractères non anglais ?: Oui. Le texte est encodé en pourcentage en UTF-8, donc les accents, les emoji et les caractères CJK s'encodent et se décodent correctement.
Que se passe-t-il si je colle du texte codé invalide ?: Si un caractère d'échappement en pourcentage est mal formé (comme un % isolé), le décodage affiche une erreur au lieu de produire du charabia.
Pourquoi un espace devient-il parfois %20 et d'autres fois un + ?: Les deux représentent un espace, mais dans des contextes différents. L'encodage en pourcentage (RFC 3986) utilise toujours %20, ce que cet outil produit. Le caractère + est une convention héritée du format application/x-www-form-urlencoded plus ancien utilisé par les soumissions de formulaires HTML, où + signifie espace et un signe plus littéral doit lui-même être encodé en %2B.