Outils de développement · Encodeur et décodeur d'URL
Fonctionnement du codage en pourcentage : des caractères aux UTF-8 octets en passant par les séquences %XX
· Comment ça marche
encodage d'URL utf-8 encodage en pourcentage développeur promoteur
Le codage en pourcentage n'encode pas les caractères ; il code les octets. Cet article montre comment un caractère devient UTF-8 octets, puis des paires hexadécimales, et pourquoi une lettre accentuée prend deux groupes %XX alors qu'un emoji en prend quatre.
Pourquoi 'é' se transforme en %C3%A9 plutôt qu'en %E9 — l'observation qui révèle la couche d'octets en dessous
Lorsqu'un développeur junior voit %C3%A9 dans une URL, le codage en pourcentage fonctionne sur les octets et non sur les caractères. Le caractère é ne fait pas un octet ; UTF-8 le code comme deux : C3 A9. La règle de codage en pourcentage de la RFC 3986 est simple : codez chaque octet sous la forme d'un signe de pourcentage suivi de deux chiffres hexadécimaux. Cette distinction transforme l’explication de mystérieuse en logique.
Comprendre le codage en pourcentage nécessite de comprendre UTF-8. Le texte doit être converti en octets à l'aide du codage de caractères. UTF-8 est la norme pour les URL et le Web. Il exprime les caractères sous forme de séquences d'octets de longueur variable : ASCII utilise un octet, les lettres accentuées en utilisent deux, les emoji en utilisent quatre. Chaque étape est distincte : caractère, point de code Unicode, UTF-8 octets, puis %XX paires. Passer en hexadécimal sans comprendre les octets passe à côté de l'essentiel.
La règle de codage en pourcentage de RFC 3986 — un % suivi de deux chiffres hexadécimaux par octet, en majuscules de préférence
RFC 3986 définit une règle : coder chaque octet en pourcentage suivi de deux chiffres hexadécimaux majuscules. Les caractères non réservés ne nécessitant aucun encodage sont les lettres, les chiffres, le trait d'union, le trait de soulignement, le point et le tilde. Tout le reste doit être codé. Les espaces deviennent %20, les barres obliques deviennent %2F et le signe de pourcentage devient %25. Cela empêche les caractères spéciaux dans les valeurs de requête de briser la structure de l'URL.
Un espace est codé sous forme d'octet 0x20, devenant %20. Une barre oblique est 0x2F, devenant %2F. Ce sont des caractères ASCII nécessitant un octet. Les lettres accentuées et les emoji diffèrent. Le signe de pourcentage devient %25. Les délimiteurs réservés comme les deux-points sont codés pour préserver la structure. Cela empêche une esperluette ou un égal intégré dans un paramètre de requête d'interrompre l'analyse. Chaque octet devient %HH.
UTF-8 comme jeu de caractères supposé – pourquoi les URL modernes sont UTF-8 et où se trouvent les exceptions héritées
UTF-8 utilise un codage de longueur variable. L'ASCII des points de code 0 à 127 fait un octet. Les caractères de 128 à 2047, y compris les lettres latines accentuées, font deux octets. Les caractères de 2048 à 65535, courants dans les scripts d'Asie de l'Est, font trois octets. Les caractères au-dessus de 65535, y compris la plupart des emoji, font quatre octets. Chaque octet est préfixé par des bits signalant le nombre d'octets qui suivent.
La lettre accentuée é est le point de code Unicode U+00E9. UTF-8 le code sur deux octets : 0xC3 et 0xA9. Le codage en pourcentage produit %C3%A9. L'allemand ü (U+00FC) code comme 0xC3 0xBC, devenant %C3%BC. Espagnol ñ (U+00F1) code comme 0xC3 0xB1, devenant %C3%B1. Le modèle est cohérent : le premier octet signale une séquence de deux octets. Une lettre accentuée se développe de six caractères lors du codage.
Exemple concret : encodage 'café 😀' octet par octet — les points de code, les UTF-8 octets et la chaîne résultante
Emoji rend la couche d'octets évidente. L'emoji pouce levé 👍 est le point de code U+1F44D. UTF-8 le code sur quatre octets : F0 9F 91 8D. Le codage en pourcentage produit %F0%9F%918D : douze caractères pour un symbole. Le smiley 😀 (U+1F600) code comme F0 9F 98 80, devenant %F0%9F%9880. Les séquences de quatre octets deviennent des caractères codés à douze pour cent.
Un texte mixte montre pourquoi la compréhension des octets est importante. L'expression « café 😀 » contient du ASCII simple, un accent et un emoji. Les lettres c, a, f codent comme 63, 61, 66. Le é code comme C3 A9. L'espace est codé comme 20. L'emoji est codé comme F0 9F 98 80. Le résultat est "caf%C3%A9%20%F0%9F%9880". Comprendre quels octets doivent être codés rend la sortie prévisible.
Décodage inversé : collecter %XX groupes en octets et ensuite les interpréter comme UTF-8
Le décodage inverse le processus. Un décodeur recherche les paires %XX et les collecte en valeurs d'octets. En voyant %C3%A9, il extrait les octets C3 et A9. Le décodage UTF-8 les interprète comme le caractère é. Si une séquence est incomplète, comme %C3 seul, le résultat est une erreur. Le décodeur sait grâce aux bits de préfixe UTF-8 que C3 nécessite un deuxième octet.
La casse n'a pas d'importance en chiffres hexadécimaux ; %C3%A9 et %c3%a9 décodent de manière identique. RFC autorise les majuscules et les minuscules, bien que les majuscules soient préférées. Mais la casse est importante pour les caractères : é (comme %C3%A9) n'est pas la même chose que É (comme %C3%89). La comparaison d'URL doit normaliser le pourcentage de codage, sinon elle risque de traiter des ressources identiques comme différentes. Les frameworks se normalisent avant la mise en cache.
Pourquoi la casse n'a pas d'importance dans les chiffres hexadécimaux mais l'est ailleurs – règles de normalisation et comparaison d'URL
RFC 3986 mentionne le punycode pour les noms de domaine et l'encodage de formulaire pour les soumissions en tant que règles distinctes. Punycode encode les noms de domaine non-ASCII sans signes de pourcentage pour la compatibilité DNS. Le domaine 😀.example devient "xn--js8h.example". L'encodage du formulaire modifie l'encodage en pourcentage à une exception près : les espaces deviennent des signes plus au lieu de %20. Les formulaires soumis en tant qu'application/x-www-form-urlencoded utilisent plus pour les espaces.
L'outil d'encodage d'URL affiche les trois modes : encodage de composants, encodage d'URL complète et encodage de formulaire. L'encodage de composants avec encodeURIComponent encode tous les caractères spéciaux, y compris les délimiteurs, adaptés aux valeurs de requête. Le codage d'URL complète avec encodeURI préserve les caractères structurels pour les URL complètes. L’encodage des formulaires est destiné aux corps POST. Chacun utilise UTF-8 ; ils diffèrent uniquement par les octets non codés.
Punycode et encodage de formulaire : normes frères et sœurs, pas d'extensions d'encodage en pourcentage
La perspective octet résout les mystères des URL. Pourquoi un emoji a-t-il besoin de douze caractères ? Parce que UTF-8 utilise quatre octets, chacun devenant %HH. Pourquoi certaines URL ont-elles %2F pour les barres obliques alors que d'autres ont des barres obliques simples ? Parce que c'est le mode d'encodage qui décide : une barre oblique dans un segment de chemin reste non codée, mais à l'intérieur d'une valeur de requête, elle doit être %2F pour éviter une mauvaise lecture.
Pensez en octets pour un codage en pourcentage prévisible. Un caractère est un point de code Unicode. UTF-8 est sa représentation en octets. Le codage en pourcentage est le format de transmission. L'expansion des caractères se produit au niveau de la couche UTF-8. La casse hexadécimale n'affecte pas le décodage, contrairement à la casse des caractères. Les séquences d'octets non valides échouent à UTF-8 en raison de règles de préfixe strictes. L'outil d'encodage d'URL montre cette progression.
À retenir : pensez en octets : comment l'encodeur et le décodeur d'URL affichent la sortie %XX exacte pour tout texte que vous collez, dans le navigateur
Exemple concret : encodage "café 😀". Le mot café comporte les lettres c, a, f sous forme d'octets simples ASCII : 63, 61, 66. Le é est UTF-8 deux octets : C3 A9. L'espace est 20. Emoji 😀 fait quatre octets : F0 9F 98 80. Les lettres ASCII non réservées restent visibles. Résultat : "caf%C3%A9%20%F0%9F%9880". Cela montre pourquoi un emoji s'étend jusqu'à douze caractères.
À retenir : pensez en octets, pas en caractères. Le codage en pourcentage est appliqué après le codage UTF-8. Chaque octet devient %HH. UTF-8 de longueur variable signifie que les caractères se développent différemment : ASCII devient %XX (deux caractères), les accents de deux octets deviennent %XX%XX (six caractères), les emoji de quatre octets deviennent %XX%XX%XX%XX (douze caractères). Collez le texte dans l'outil d'encodage d'URL et observez la progression.