Saisissez un domaine pour comparer ses deux formes. Les remarques aident à examiner les noms suspects sans garantir la fiabilité du site.
Fonctionne localement dans votre navigateur| Étiquette | ASCII / Punycode | Scripts | Risque |
|---|---|---|---|
| Entrez un domaine pour inspecter chaque étiquette. | |||
Pour la récupération de compte, les certificats, les listes d'autorisation de courrier électronique, les redirections et les décisions de sécurité, normalisez le nom d'hôte et comparez le formulaire ASCII à l'aide d'une implémentation IDNA actuelle et d'une stratégie spécifique à l'application.
Saisissez ou collez un nom d’hôte — en Unicode ou déjà encodé — puis lancez Convertir et analyser. L’outil réduit la saisie à un nom d’hôte, replie la casse et les formes de compatibilité (NFKC et minuscules), supprime les caractères ignorés par IDNA et encode en Punycode chaque étiquette non ASCII : la ligne ASCII correspond donc à la forme qu’un résolveur ou une liste d’autorisation verrait réellement.
Les étiquettes Punycode sont aussi décodées puis réencodées : une étiquette qui ne revient pas à sa forme canonique est signalée comme Punycode invalide au lieu d’être affichée en caractères parasites. Tout s’exécute dans la page, sans requête DNS ni appel au site ; un rapport propre signifie qu’aucun risque évident au niveau des caractères n’a été trouvé, pas que le domaine est digne de confiance.
Le champ est traité comme un nom d’hôte, pas comme une URL : schéma, chemin, paramètres et port final sont supprimés, un point final est ignoré, et un littéral IP comme [::1] est refusé avec un message au lieu d’être converti. Un champ vide est également refusé.
Avant l’encodage, le nom est ramené à sa forme canonique : NFKC replie les caractères pleine largeur et de compatibilité, les étiquettes passent en minuscules, et les points de code ignorés par IDNA — espaces de largeur nulle, traits d’union conditionnels, marques d’ordre des octets, sélecteurs de variante, contrôles bidirectionnels — sont supprimés. C’est le traitement appliqué par les navigateurs avant d’utiliser un nom d’hôte : münchen.de, MÜNCHEN.DE et une graphie contenant un espace de largeur nulle aboutissent donc à la même sortie ASCII.
Chaque étiquette non ASCII est ensuite encodée en Punycode et préfixée par xn--. Les étiquettes Punycode sont elles aussi décodées puis réencodées : lorsqu’une étiquette ne se décode pas en une étiquette Unicode canonique — xn--a, par exemple —, l’outil la signale comme Punycode invalide au lieu d’afficher les octets décodés.
Un signalement rouge désigne ce qu’un navigateur ou un résolveur rejetterait, ou ce qui cache un caractère : étiquette commençant ou finissant par un trait d’union, caractère interdit dans une étiquette de nom d’hôte (souligné, @, espaces), étiquette Punycode invalide, ou étiquette dépassant 63 octets après conversion. Le nom ASCII complet ne doit pas dépasser 253 caractères.
Le mélange d’écritures dans une même étiquette, les caractères invisibles ou bidirectionnels et les homoglyphes courants — signalés avec le squelette simplifié — sont les motifs sur lesquels reposent les attaques homographes. Le badge de risque du tableau reprend ce jugement étiquette par étiquette : Élevé quand l’étiquette est inutilisable ou mélange les écritures, Moyen avec un préfixe Punycode ou un homoglyphe, Faible pour une étiquette ASCII ordinaire.
L’analyse reste au niveau des caractères. Aucun enregistrement DNS n’est interrogé, aucun certificat n’est récupéré et aucune source de registre ou de réputation n’est consultée : un nom peut passer toutes les vérifications de cette page et rester un domaine d’hameçonnage enregistré, qui résout et sert du contenu.
Comparez la forme ASCII : pour les listes d’autorisation, les certificats et les règles de redirection, comparez le nom d’hôte ASCII normalisé — pas le nom Unicode affiché — et confrontez-le à la forme ASCII produite par l’autre système. Si la décision doit être exacte au niveau du registre, confirmez le résultat avec une implémentation complète UTS#46/IDNA.