Ce que fait cet outil
Ce convertisseur fait passer les noms de domaine internationalisés (IDN) de la forme que lisent les gens à celle que stocke le DNS, et inversement. Tapez café.example et vous obtenez xn--caf-dma.example ; collez un nom en xn-- et vous obtenez l'original Unicode. La conversion fonctionne dans les deux sens au fil de la saisie, étiquette par étiquette : dans boutique.café.example, seule l'étiquette qui contient des caractères non ASCII reçoit le préfixe xn--.
L'encodage est Punycode (RFC 3492), implémenté en JavaScript dans votre navigateur ; rien de ce que vous tapez n'est envoyé nulle part. Avant l'encodage, l'outil met chaque étiquette en minuscules et applique la normalisation Unicode NFC : un é précomposé et un e suivi d'un accent aigu combinant donnent donc le même résultat. Il n'applique pas toutes les règles de mappage d'IDNA2008 ou d'UTS #46 : une conversion réussie est un encodage correct, pas la preuve qu'un registre acceptera le nom.
À côté du résultat, vous obtenez le détail de chaque étiquette (forme Unicode, forme ASCII et longueur), une vérification des limites du DNS, 63 octets par étiquette et 253 pour le nom complet, et une alerte quand une même étiquette mélange des écritures, par exemple le latin avec le cyrillique ou le grec.
Mode d'emploi
- Tapez ou collez un nom de domaine, une URL complète ou une adresse e-mail.
- Regardez la forme convertie se mettre à jour : une saisie en Unicode donne la forme
xn--, et une saisie enxn--donne l'Unicode. - Lisez le détail des étiquettes : longueurs, dépassements de limite et éventuelle alerte d'écritures mélangées.
- Copiez la forme qu'attend la destination.
Avec une URL, seul l'hôte est converti ; le reste est conservé tel que saisi. (Sur le web, les caractères non ASCII d'un chemin ou d'une chaîne de requête sont encodés en pourcentage à partir de l'UTF-8, pas convertis en Punycode.) Avec une adresse e-mail, seule la partie après le @ est convertie. Une partie locale comme hélène n'a pas de forme Punycode ; pour y remettre du courrier, il faut que chaque serveur du trajet prenne en charge SMTPUTF8 (RFC 6531).
Cas d'usage
- Vérifier un lien suspect. Collez l'URL d'un message avant de l'ouvrir. Si l'hôte se décode en lettres de deux écritures, ou si un nom d'apparence familière se révèle être une étiquette
xn--, regardez de plus près avant de cliquer. - Rédiger des enregistrements DNS. Les fichiers de zone et la plupart des interfaces d'hébergement DNS attendent la forme ASCII. Utilisez exactement cette chaîne partout où un enregistrement fait référence au nom, y compris les cibles de CNAME et les hôtes MX.
- Demander des certificats TLS. Les autorités de certification et les clients ACME prennent la forme
xn--dans les noms alternatifs du sujet (SAN). Décoder la liste SAN d'un certificat montre quels noms Unicode il couvre réellement. - Lire des journaux. Les journaux de serveur web, les en-têtes HTTP Host et les valeurs SNI de TLS contiennent le nom encodé. Décodez une entrée inconnue pour la lire.
- Configurer la messagerie d'un IDN. Les enregistrements MX, SPF, DKIM et DMARC se trouvent tous sous le nom en
xn--, et une adresse commeinfo@xn--caf-dma.examplefonctionne avec les logiciels de messagerie ordinaires. - Vérifier la longueur avant d'enregistrer un nom. L'encodage allonge nettement certaines écritures : l'étiquette thaïe de sept caractères ภาษาไทย devient
xn--o3crh0a8bb0k, soit 16 octets ; une étiquette qui semble courte peut donc dépasser 63.
Les enregistrements et une demande de signature de certificat (CSR) pour café.example utilisent le nom encodé comme n'importe quel autre nom d'hôte :
xn--caf-dma.example. 3600 IN A 192.0.2.10
www.xn--caf-dma.example. 3600 IN CNAME xn--caf-dma.example.
xn--caf-dma.example. 3600 IN MX 10 mail.xn--caf-dma.example.
openssl req -new -key site.key -out site.csr \
-subj "/CN=xn--caf-dma.example" \
-addext "subjectAltName=DNS:xn--caf-dma.example,DNS:www.xn--caf-dma.example"Comment Punycode fait entrer l'Unicode dans un nom d'hôte
À strictement parler, le format du DNS sur le réseau peut transporter n'importe quelle valeur d'octet. En pratique, les noms d'hôte sont limités depuis les années 1980 aux lettres ASCII, aux chiffres et au tiret (la règle LDH des RFC 952 et RFC 1123), et les résolveurs, les serveurs de messagerie et les vérifications de certificats ont été construits sur cette hypothèse. Plutôt que de les modifier, IDNA convertit les noms dans l'application, avant l'envoi de toute requête, en une chaîne qui respecte déjà l'ancienne règle.
Punycode procède en deux étapes. D'abord, il recopie dans l'ordre les caractères ASCII de l'étiquette et ajoute un tiret s'il y en avait : café donne caf-. Ensuite, il décrit chaque caractère manquant par un seul nombre qui indique quel point de code insérer et où. Le é est U+00E9, soit 233 en décimal. En comptant à partir de 128, avec trois lettres déjà placées et donc quatre positions d'insertion possibles, le nombre vaut (233 − 128) × 4 + 3 = 423, où le 3 final signifie « après la troisième lettre ». Ce nombre s'écrit sous une forme en base 36 de longueur variable avec a–z et 0–9, avec des seuils qui s'adaptent pour que les petits nombres restent courts. On obtient dma, d'où xn--caf-dma.
Le décodage fait l'inverse : tout ce qui précède le dernier tiret est recopié, et les caractères qui le suivent sont relus comme des insertions. Une étiquette sans aucune lettre ASCII, comme l'étiquette thaïe ci-dessus, n'a pas de tiret séparateur après le préfixe. Comme c'est l'étiquette encodée qui circule dans le DNS, la limite de 63 octets s'applique à elle, pas au texte Unicode.
Domaines sosies et barre d'adresse
Beaucoup de lettres d'écritures différentes se ressemblent trait pour trait. Le а cyrillique (U+0430) est identique au a latin dans la plupart des polices : bаnque.example, avec une deuxième lettre cyrillique, se lit comme un mot ordinaire mais s'encode en xn--bnque-4ve.example. C'est ce qu'on appelle une attaque par homographe.
Les navigateurs décident étiquette par étiquette s'ils affichent l'Unicode ou la forme xn--. Les politiques varient d'un éditeur à l'autre, mais les tests courants vérifient si une étiquette mélange des écritures dans des combinaisons que les vrais noms utilisent rarement, si elle est entièrement écrite avec des lettres qui imitent les latines, et si elle ressemble de près à un domaine connu. Dans Firefox, passer network.IDN_show_punycode à true dans about:config force la forme ASCII pour tous les noms.
L'alerte d'écritures mélangées de cette page cherche plus d'une écriture à l'intérieur d'une même étiquette. Une étiquette entièrement écrite en lettres cyrilliques qui ressemblent aux latines n'est pas mélangée : un résultat sans alerte ne prouve donc pas qu'un nom est authentique. Comparez le nom décodé avec l'adresse attendue et, en cas de doute, tapez l'adresse vous-même.
Questions fréquentes
Comment écrire en Punycode un nom de domaine avec un accent ?
Collez le nom dans le champ ci-dessus et sa forme xn-- s'affiche aussitôt : café.example devient par exemple xn--caf-dma.example. Les lettres ASCII de l'étiquette sont recopiées d'abord, suivies d'un tiret, puis d'un court code qui indique quel caractère insérer et à quelle position, ici le « é » placé après la troisième lettre.
Pourquoi mon navigateur affiche-t-il xn-- au lieu du vrai nom ?
Les navigateurs n'affichent l'Unicode que si une étiquette respecte leur politique d'affichage. Si elle mélange des écritures de façon inhabituelle, si elle est entièrement composée de caractères qui imitent des lettres latines ou si elle ressemble trop à un domaine connu, le navigateur affiche plutôt la forme encodée. Le site se charge normalement ; collez le nom ici pour voir ce que donne l'étiquette xn-- une fois décodée.
Un domaine qui commence par xn-- est-il dangereux ?
Non. Le préfixe signifie seulement que l'étiquette a été encodée à partir d'Unicode, et beaucoup de sites légitimes en allemand, en chinois, en arabe, en russe et dans d'autres langues l'utilisent. Ce qui compte, c'est le texte décodé. S'il donne le nom attendu, dans une seule écriture, il n'y a rien d'anormal. S'il imite un nom familier avec des lettres empruntées, méfiez-vous du lien.
Pourquoi un autre convertisseur donne-t-il un résultat différent pour un nom avec ß ?
L'ancien traitement IDNA2003, ainsi que le mode transitoire d'UTS #46, transforment ß en ss et le sigma final ς en σ avant l'encodage : straße devient alors simplement strasse. IDNA2008 conserve ces caractères tels quels. La mise en minuscules et la normalisation NFC, les étapes qu'applique cet outil, laissent ß inchangé : faß est donc encodé ici en xn--fa-hia. Vérifiez quelle forme attendent votre registre et les logiciels de vos utilisateurs.
Puis-je mettre de l'Unicode directement dans un fichier de zone ou un certificat ?
Utilisez la forme xn-- dans les deux cas. Un certificat stocke les noms DNS dans un champ limité à l'ASCII : les autorités de certification attendent donc la forme encodée dans la liste des noms alternatifs du sujet (SAN). Dans un fichier de zone, un nom écrit en octets UTF-8 bruts ne correspondrait pas aux requêtes xn-- qu'envoient les résolveurs et les navigateurs, et l'enregistrement ne serait tout simplement jamais trouvé.
Que devient la partie avant le @ dans une adresse e-mail ?
Elle reste exactement telle que vous l'avez saisie, car Punycode ne s'applique qu'aux noms de domaine. Si la partie locale contient des caractères non ASCII, comme hélène, la remise dépend de l'extension SMTPUTF8 définie dans la RFC 6531. Chaque serveur du trajet doit la prendre en charge ; il n'existe pas de solution de repli en ASCII comparable à Punycode, et un message adressé à une telle adresse est donc généralement rejeté là où la prise en charge manque.
Pourquoi un registre pourrait-il refuser un nom que cet outil convertit sans broncher ?
L'outil produit un encodage RFC 3492 correct après mise en minuscules et normalisation NFC, mais il n'implémente pas toutes les règles d'IDNA2008 ni d'UTS #46. IDNA2008 interdit la plupart des symboles et prévoit des règles contextuelles pour des caractères comme les liants (joiners), et chaque registre publie sa propre table des caractères autorisés pour son domaine de premier niveau. Un nom peut s'encoder sans erreur ici et échouer malgré tout à ces vérifications.
Ce que je saisis est-il envoyé à un serveur ?
Non. La conversion, le contrôle des longueurs et l'alerte d'écritures mélangées s'exécutent en JavaScript dans votre navigateur : les noms, URL et adresses e-mail que vous collez ne quittent jamais votre appareil. Par ailleurs, iseeu.cc ne conserve aucun journal des adresses IP ni des recherches, n'a pas de base de données de visiteurs, ne dépose aucun cookie et n'affiche aucune publicité.
Une conversion sans erreur montre que le nom est correctement encodé, pas qu'il peut être enregistré ni qu'il est sûr. Les registres appliquent leurs propres règles de caractères, et les noms sosies peuvent éviter de mélanger les écritures.