Convertisseur Punycode / IDN

Qu’est-ce que Punycode ?#

Le système de noms de domaine (DNS) a été bâti sur l’ASCII — les lettres A-Z, les chiffres et le trait d’union. Alors comment un navigateur résout-il un domaine comme 中文.com ou münchen.de, dont les caractères ne sont pas dans cet alphabet ? La réponse est Punycode (et le cadre IDN autour) : un encodage réversible qui transforme chaque label non ASCII en une forme ASCII-safe commençant par le préfixe xn--. Le DNS ne voit jamais que xn--fiq228c.com ; le navigateur vous montre 中文.com.

Cet outil convertit dans les deux sens :

• Unicode → Punycode prend un domaine ou un e-mail Unicode et produit la forme xn-- que le DNS et les certificats portent réellement. Chaque label est converti indépendamment — münchen.中文.com devient xn--mnchen-3ya.xn--fiq228c.com, le .com final étant laissé tranquille parce qu’il est déjà ASCII.
• Punycode → Unicode fait l’inverse : il relit les labels xn-- pour retrouver l’écriture lisible par l’humain.

Les e-mails sont aussi gérés. L’outil détecte le @, ne convertit que la partie domaine, et laisse la partie locale (le nom de boîte aux lettres) intacte — donc Büchner@中文.com devient Bü[email protected], jamais une conversion calamiteuse de toute la chaîne.

Mode d’emploi#

1. Choisissez Unicode → Punycode ou Punycode → Unicode avec le commutateur en haut à gauche. L’outil suggère aussi une direction quand il remarque un label xn-- dans votre entrée.
2. Collez un domaine ou un e-mail dans le panneau Entrée. L’en-tête indique s’il a été reconnu comme un domaine ou un e-mail.
3. Le résultat converti remplit le panneau Sortie ; cliquez sur Copier pour le récupérer.
4. Sous les panneaux, le tableau de détail par label affiche chaque label et ce qu’il est devenu — pratique quand un long domaine a plusieurs labels non ASCII et que seuls quelques-uns ont changé.
5. Utilisez Sortie → Entrée pour replacer la sortie dans l’entrée et inverser la direction (une vérification d’aller-retour rapide), Exemple pour charger münchen.中文.com, et Effacer pour réinitialiser.

Principales fonctionnalités#

• Les deux sens, chaque label séparément. Chaque label est converti indépendamment et le tableau de détail montre exactement lesquels ont changé et lesquels sont restés ASCII.
• Conscient des e-mails. Un @ unique est détecté et le nom de boîte est préservé ; seule la partie domaine est encodée. Une entrée avec plusieurs @ est rejetée par un message clair plutôt que de corrompre silencieusement le résultat.
• Normalisation des séparateurs. Le point pleine chasse ．, l’idéographique 。 et le ｡ demi-chasse sont tous traités comme le . ASCII qu’ils sont réellement en IDN, donc le texte collé ne casse pas.
• Strict sur l’entrée mal formée. Un mauvais label xn-- (par exemple xn--!!) lève une erreur nette pointant vers le label fautif, au lieu de produire un domaine erroné.
• Honnête sur la portée. La note de conformence sous l’outil indique clairement que cela implémente l’encodage Punycode et l’étape de mappage — ce n’est pas un vérificateur de validité IDNA2008 complet, donc un label ACE techniquement invalide en IDNA2008 peut néanmoins se décoder ici.

Exemple détaillé#

Convertir en Unicode → Punycode, l’espace réservé münchen.中文.com devient :

xn--mnchen-3ya.xn--fiq228c.com

Le détail montre trois labels, dont deux convertis : münchen → xn--mnchen-3ya, 中文 → xn--fiq228c, et .com intact parce qu’il était déjà ASCII. Basculez sur Punycode → Unicode et collez le résultat en retour pour retrouver münchen.中文.com à l’identique.

Quelques autres conversions réelles qui valent la peine d’être vues :

中文.com           → xn--fiq228c.com
münchen.de        → xn--mnchen-3ya.de
😂.com             → xn--g28h.com
café.fr           → xn--caf-dma.fr
日本語.jp          → xn--wgv71a119e.jp
Büchner@中文.com   → Bü[email protected]   (e-mail : boîte préservée)

La dernière est le cas qui piège les gens : les outils naïfs encodent toute la chaîne et cassent l’adresse. Ici, seule la partie domaine après @ change.

FAQ#

Pourquoi mon domaine emoji se convertit-il en un label xn-- si court ?#

Un domaine à un seul caractère emoji comme 😂.com devient xn--g28h.com parce que Punycode est extraordinairement compact pour un label avec un seul caractère non ASCII suivi d’ASCII — il encode les positions et points de code des caractères non ASCII relativement aux caractères ASCII, donc un label à un caractère a besoin de très peu d’octets. Les labels non ASCII plus longs ou plus variés produisent des chaînes ACE plus longues.

La sortie ressemble à l’entrée — quelque chose s’est-il passé ?#

Si chaque label de votre entrée est déjà pure ASCII (par exemple example.com), il n’y a rien à encoder, et la sortie égale l’entrée. Le tableau de détail est l’indicateur fiable : un label dont la sortie égale son entrée n’a pas été converti, parce qu’il n’en avait pas besoin.

J’ai collé un e-mail et la partie locale n’a pas été convertie. Est-ce correct ?#

Oui, et c’est délibéré. L’e-mail internationalisé (SMTPUTF8) autorise de l’UTF-8 dans le nom de boîte, mais le convertir en xn-- est faux pour le cas courant — la partie locale n’est pas un nom DNS et n’est pas résolue par Punycode. Cet outil ne convertit que la partie domaine, qui est la partie qui doit être DNS-safe. C’est aussi pourquoi plusieurs @ sont rejetés : ils rendent « la partie domaine » ambiguë.

Puis-je utiliser la forme ASCII pour enregistrer ou résoudre n’importe quel domaine ?#

Pour la résolution par tout navigateur ou résolveur moderne, oui. Pour l’enregistrement, les règles sont plus strictes : IDNA2008 interdit certains caractères et normalisations que les mappings anciens (IDNA2003) autorisaient. Cet outil fait l’encodage fidèlement mais n’exécute pas les contrôles de validité IDNA2008 complets, donc une chaîne qui s’encode proprement ici peut encore être rejetée par un bureau d’enregistrement. En cas de doute, confirmez avec l’outil de recherche de votre bureau d’enregistrement.