Convertisseur Punycode / IDN

Punycode n’est donc ni une langue, ni une police, ni un code pays — c’est une traduction entre deux graphies du même nom. La graphie Unicode s’appelle une étiquette U (中文.com, bücher.de), la graphie ASCII une étiquette A (xn--fiq228c.com, xn--bcher-kva.de), et l’ensemble du principe qui consiste à faire entrer des noms internationaux dans le DNS s’appelle IDN (noms de domaine internationalisés) ou IDNA, l’ensemble des règles construites par-dessus.

Il existe parce que le DNS a été conçu au début des années 1980 autour d’un alphabet volontairement réduit. Un nom d’hôte qui circule dans le DNS, dans un fichier de zone, un cache de résolveur, une ligne de journal ou un certificat TLS doit être de l’ASCII pur — le format de transmission n’a tout simplement aucun champ pour autre chose. Punycode est la soupape de sécurité : il permet à un nom non ASCII de voyager comme s’il était ASCII, et au destinataire de reconstruire exactement les caractères d’origine. C’est pourquoi un domaine chinois fonctionne dans un navigateur, et pourquoi xn-- est la seule chaîne que vous verrez partout où l’écriture Unicode ne peut pas être transmise.

Ce que vous saisissez (étiquette U)	Ce que reçoit le DNS (étiquette A)	Signification
中文.com	xn--fiq228c.com	Les mots chinois pour « langue chinoise »
中国	xn--fiqs8s	« Chine » en chinois
例え.jp	xn--r8jz45g.jp	Exemples japonais
bücher.de	xn--bcher-kva.de	En allemand bücher, « livres »
münchen.de	xn--mnchen-3ya.de	Munich
😂.com	xn--e28h.com	Une étiquette emoji — légale dans l’encodage, mais pas dans la plupart des registres

Une comparaison de longueurs à retenir : 中文 compte 2 caractères et 6 octets en UTF-8, alors que xn--fiq228c compte 11 octets ASCII. Punycode allonge en général un nom, il ne le raccourcit jamais.

Prenez bücher et observez les trois étapes. Le moteur s’appelle un bootstring, et tout l’algorithme ne fait que quelques dizaines de lignes de code (vous pouvez le lire dans le script de cette page).

1. Recopiez d’abord les caractères simples. Chaque caractère ASCII de base est recopié dans son ordre d’origine et reste lisible : bücher → bcher. Comme on a recopié des caractères et qu’il reste des caractères à encoder, un seul - est ajouté comme frontière : bcher-.
2. Écrivez le reste en nombres base 36. Les caractères restants sont traités par ordre croissant de point de code, et chacun s’écrit comme un nombre à longueur variable en base 36, où a=0 … z=25 et 0=26 … 9=35. Pour bücher, le caractère restant ü devient les chiffres kva.
3. Ajoutez le préfixe. La partie encodée ajoutée à la partie recopiée donne bcher-kva, et dans un domaine elle s’écrit xn--bcher-kva.

L’astuce qui rend ce système astucieux tient à ce que contiennent ces nombres en base 36 : non pas le caractère lui-même, mais un delta — la distance entre le caractère et le point de code précédemment encodé, plus sa position dans la chaîne. L’encodeur parcourt les points de code par ordre croissant, et chaque suite de chiffres décrit une position et une distance. Après chaque caractère, un nombre commun appelé le biais est ajusté pour que le nombre suivant demande le moins de chiffres possible.

Deux conséquences que vous pouvez constater vous-même ci-dessus :

• Les caractères semblables coûtent peu. Comme seules les distances sont stockées, une suite d’un même caractère ne coûte presque rien : 30 occurrences de 中 s’encodent en xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, soit seulement 36 octets. Un mélange mesuré de caractères chinois sans lien entre eux mais proches tient en environ 41 caractères dans une étiquette légale de 63 octets, et un seul caractère répété atteint 57.
• Les caractères éloignés coûtent cher. Un caractère éloigné du précédent demande un nombre delta plus long. Un texte chinois avec beaucoup de caractères différents coûte en général 2 à 3 lettres supplémentaires par caractère, c’est pourquoi une étiquette CJK atteint sa limite vers 20 à 40 caractères, alors que la limite d’une étiquette est de 63 octets.

Le décodage suit la même recette à l’envers : recopier le préfixe ASCII, lire les chiffres, transformer les deltas en points de code et insérer chaque nouveau caractère dans la chaîne à la position indiquée par le delta. Il n’existe que des chiffres minuscules dans le bootstring, c’est pourquoi une lettre majuscule dans une partie encodée est rejetée au lieu d’être devinée — le DNS ne distingue pas la casse, accepter les deux rendrait deux graphies différentes ambiguës.

• Dans la barre d’adresse. Les navigateurs peuvent afficher xn--fiq228c.com au lieu de 中文.com. C’est le même site. Certains navigateurs affichent volontairement la forme Punycode lorsqu’un nom mélange plusieurs écritures, précisément pour qu’un caractère qui lui ressemble (le а cyrillique au lieu du a latin) ne puisse pas se cacher dans l’URL.
• Dans le DNS lui-même. Les fichiers de zone, les réponses de dig / nslookup / DNS-over-HTTPS et les journaux de résolveur ne contiennent jamais que la forme xn-- ; l’Unicode brut est rejeté ou déformé en silence.
• Dans les certificats TLS. Le nom alternatif du sujet d’un domaine international est stocké sous forme d’étiquette A (DNS:xn--fiq228c.com) ; un certificat qui ne ressemble pas au nom que vous avez saisi est donc normal, et non une incohérence.
• Dans la configuration et les outils. Les entrées server_name / hôtes virtuels d’un serveur web, les domaines de cookies, les panneaux d’hébergement et de CDN, les domaines de messagerie, les clés d’API liées à un domaine et les clés de base de données sont tous plus sûrs sous forme d’étiquette A.
• Dans les tests et les chaînes de données. Certaines bibliothèques transmettent l’Unicode directement au résolveur et échouent ; convertir d’abord en Punycode est la solution standard. Comme la correspondance est canonique — une étiquette Unicode correspond à une seule étiquette A — la forme xn-- sert aussi d’identifiant stable dans les journaux et la recherche.

Punycode est une simple graphie réversible, rien de plus. Ce n’est ni du chiffrement ni une fonction de sécurité : n’importe qui peut le décoder avec l’outil ci-dessus, donc une étiquette xn-- indique « cela a été encodé » et rien sur son propriétaire. Ce n’est pas non plus de la compression — il allonge en général le texte, comme le montre l’exemple 6 octets / 11 octets plus haut. Et ce n’est pas la même chose que les autres moyens de faire circuler l’Unicode sur Internet ; ceux-ci résolvent d’autres couches du problème.

Schéma	Transforme quoi en quoi	Où c’est utilisé	中文 devient
Punycode (RFC 3492)	Une étiquette de domaine Unicode en lettres et chiffres ASCII	Uniquement les étiquettes de domaine internationales	xn--fiq228c
UTF-8 (RFC 3629)	Points de code en octets	Chaque fichier et chaque requête web	E4 B8 AD E6 96 87 (6 octets)
Encodage en pourcentage (RFC 3986)	Octets en séquences d’échappement %XX	Chemins d’URL, chaînes de requête, corps de formulaires	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Octets en 64 caractères ASCII	Binaire dans du texte, du JSON, des e-mails, des URL de données	5Lit5paH
Entités HTML	Points de code en références nommées ou numériques	Source HTML et XML	中文
Échappements Unicode	Points de code en \uXXXX	Code source et chaînes littérales JSON	\u4e2d\u6587

À retenir en pratique : Punycode s’applique aux étiquettes de domaine d’une URL, et non à l’URL entière. Le chemin et la chaîne de requête sont un autre problème et utilisent l’encodage en pourcentage (voir les Encodeurs d’URL).

• Les limites de taille viennent du DNS, pas de Punycode. Une étiquette ne peut pas dépasser 63 octets et un nom complet 255 octets (RFC 1034 / 1035). Comme une étiquette A est purement ASCII, le nombre d’octets égale le nombre de caractères, et chaque caractère non ASCII consomme une partie de ce budget — environ 1 caractère de budget pour 1 à 4 lettres Punycode.
• Punycode convertit tout ; les registres n’autorisent que certaines choses. Les règles IDNA s’appliquent par-dessus et restreignent les points de code qui peuvent être enregistrés — majuscules, espaces, ponctuation comme !, et drapeaux ne sont pas admis dans un domaine réel. Cette page effectue la conversion de la RFC 3492, elle encodera donc volontiers un texte qu’un registre refuserait.
• Restez dans une seule écriture. IDNA déconseille de mêler les écritures dans une même étiquette, précisément à cause des attaques par caractères qui se ressemblent. Un nom peut être encodé tout en restant inutilisable, ou utilisable mais bloqué par les navigateurs.
• Ne pas encoder deux fois. xn-- suivi d’un texte déjà encodé n’est pas valide, et une étiquette purement ASCII ne change jamais — il n’y a rien à encoder, donc aucun préfixe n’est ajouté.
• Un point final ne pose pas de problème. 例え.jp. est un nom complet (FQDN) et l’étiquette vide finale est conservée ; les étiquettes vides au milieu d’un nom ne sont pas valides.

« Pourquoi mon domaine chinois apparaît-il comme xn--fiq228c.com dans la barre d’adresse ? »

Parce que le navigateur a choisi d’afficher l’étiquette A. Le site est identique ; utilisez le sens Décodage de cette page pour voir la forme Unicode, ou encodez la forme Unicode pour vérifier que les deux écritures correspondent.

« Dois-je modifier mes enregistrements DNS, mon certificat ou mon hébergement ? »

Non. Gardez l’étiquette A xn-- partout où une machine lit le nom (DNS, certificats, configurations), et n’utilisez la forme Unicode que là où un humain le lit.

« Pourquoi le résultat est-il plus long que ce que j’ai saisi ? »

Parce que l’encodage ne transporte pas les caractères eux-mêmes, mais des distances en base 36, et l’alphabet de 36 caractères doit écrire des nombres qui peuvent être grands. La croissance est attendue, ce n’est pas un bogue.

« Pourquoi le décodage indique-t-il « lettre majuscule » ? »

Parce que les chiffres bootstring sont définis en minuscules uniquement (a-z, 0-9). Un A-Z majuscule après le dernier tiret est ambigu puisque le DNS ne distingue pas la casse — il est signalé au lieu d’être deviné silencieusement.

« Punycode s’applique-t-il à la partie située avant le @ dans une adresse e-mail ? »

Seule la partie domaine est un nom DNS et peut être en Punycode. La partie locale est gérée par le système de messagerie, et non par le DNS, donc cet encodage ne s’y applique pas.

« Deux noms Unicode différents peuvent-ils produire la même étiquette A ? »

Non. L’encodage est injectif : des suites de points de code distinctes produisent toujours des bootstrings distincts, donc décoder xn--fiq228c redonne exactement 中文 et rien d’autre. Ce qui peut se confondre, c’est l’apparence — des caractères différents qui se ressemblent — ce qui relève du répertoire Unicode et non de l’encodage.

• RFC 3492 — Punycode, l’encodage bootstring implémenté sur cette page. Les vecteurs de référence cités plus haut sont vérifiés contre les chaînes d’exemple de ce document.
• RFC 5890, RFC 5891, RFC 5892 et Unicode UTS #46 — IDNA2008 et son interprétation côté navigateur, les règles qui déterminent quels caractères sont valides, comment les étiquettes sont normalisées et comment les écritures peuvent être mêlées.
• RFC 1034 et RFC 1035 — les limites de 63 octets par étiquette et de 255 octets par nom, héritées du DNS.
• RFC 3490 et RFC 3491 — l’ancienne génération IDNA2003, remplacée par IDNA2008. Si un nom se comporte différemment dans d’anciens logiciels, c’est généralement la raison.

Note de portée : cet outil effectue la conversion de la RFC 3492 et rien d’autre. Ce n’est pas un validateur IDN et il ne vérifie ni les règles d’enregistrement, ni les tarifs, ni la disponibilité d’un domaine — et comme il ne contacte jamais le réseau, il ne peut pas vous dire si un nom existe.

Essayez ci-dessus : collez 中文 et cliquez sur Encoder texte → Punycode pour voir l’étiquette A, ou collez xn--fiq228c et cliquez sur Décoder Punycode → texte pour retrouver les caractères.