link Encodage / Décodage URL star

Comment ça fonctionne

Une URL ne peut transporter en toute sécurité qu'un petit alphabet : les lettres, les chiffres et les quatre symboles non réservés - _ . ~. Tout le reste est réécrit sous forme d'un triplet %XX, où XX est la valeur hexadécimale de l'octet du caractère — c'est l'encodage en pourcentage RFC 3986. Les caractères qui structurent une URL (? # / : @ & =, l'ensemble « réservé ») sont eux aussi encodés dès qu'ils apparaissent à l'intérieur d'une valeur plutôt que comme délimiteurs, car un & littéral à l'intérieur d'une valeur de requête serait sinon lu comme le début du paramètre suivant.

Le texte non-ASCII est encodé octet par octet, pas caractère par caractère : l'outil convertit d'abord votre chaîne en UTF-8, puis encode en hexadécimal chaque octet résultant. La lettre turque « ç » représente deux octets UTF-8 (0xC3 0xA7), elle devient donc deux blocs de pourcentage, %C3%A7 — pas un seul code. Un exemple concret : encoder İstanbul çayı & simit produit %C4%B0stanbul%20%C3%A7ay%C4%B1%20%26%20simit. Remarquez que l'espace devient %20, le & réservé devient %26, et chaque lettre accentuée se développe en sa propre séquence multi-octets.

En pratique, cette distinction compte surtout lors de la construction manuelle de requêtes : coller une URL de webhook contenant une valeur de requête que quelqu'un vous a envoyée, décoder un paramètre de suivi issu d'un e-mail marketing, ou comprendre pourquoi un appel API échoue parce qu'un & ou un # brut s'est glissé non encodé dans une valeur et a été lu comme un délimiteur plutôt que comme une donnée. Encoder d'abord la valeur, puis l'insérer dans le modèle d'URL, évite exactement ce type de bug.

Ce qu'il faut savoir

• %20 ou + : l'encodage en pourcentage RFC 3986 utilise toujours %20 pour un espace. La convention + appartient à un standard différent et plus ancien — application/x-www-form-urlencoded, utilisé quand un formulaire HTML soumet des données — et ne s'applique qu'à l'intérieur de ce format de corps spécifique, jamais dans un chemin ou une valeur de requête correctement encodée en pourcentage. Confondre les deux est une source classique de bugs : un serveur attendant un encodage de formulaire lit un + égaré dans une chaîne encodée en pourcentage comme un signe plus littéral, pas comme un espace.
• Encoder un composant, pas l'URL entière : cet outil est conçu pour une seule valeur de requête ou un seul segment de chemin. Faire passer l'adresse entière (y compris https://) dans l'encodeur échapperait aussi les barres obliques et les deux-points qui rendent l'URL valide, la cassant complètement.
• Le même moteur que votre navigateur : il appelle les fonctions natives encodeURIComponent/decodeURIComponent du navigateur, donc les résultats correspondent exactement à ce que produirait un vrai navigateur ou un appel JavaScript fetch — pas une approximation.
• L'aller-retour est sans perte : encoder une chaîne puis décoder le résultat renvoie toujours exactement les octets d'origine, ce qui permet de vérifier facilement un encodage manuel en décodant le résultat et en le comparant au texte source.
• Rien ne quitte votre navigateur : l'encodage et le décodage s'exécutent entièrement côté client, instantanément, sans aucun envoi.