Convertisseur Punycode

Le marketing vous remet des domaines cyrilliques ou avec diacritiques alors que les panneaux DNS exigent des étiquettes xn--. Convertissez avant de coller dans le DNS Checker ou les champs glue du registrar — un seul caractère erroné produit NXDOMAIN sur toute la zone.

Les équipes sécurité décodent des URL de phishing depuis les logs mail où les MTA affichent Punycode. La conversion en Unicode révèle les attaques homographes ciblant des marques. Poursuivez avec WHOIS pour l'âge d'enregistrement et le vérificateur d'en-têtes HTTP sur l'hôte décodé — la conversion ne bloque pas les malwares.

Les développeurs testant le support IDN dans les apps collent l'entrée Unicode, convertissent en A-label, puis DIG A/AAAA sur le résultat. Les navigateurs appliquent IDNA2008/UTS46 ; le convertisseur DN01 s'aligne sur l'encodage Punycode standard pour les opérations DNS.

La documentation et les runbooks doivent stocker les deux formes : Unicode pour les humains, Punycode pour les machines. Les boutons de copie réduisent les erreurs de transcription dans les tickets par rapport à la ressaisie de longues chaînes xn-- depuis des PDF.

Les politiques ccTLD varient — certains espaces de noms restreignent les scripts. Punycode prouve l'encodage seulement ; l'acceptation du registre est une question WHOIS/politique que DN01 ne tranche pas.

Les équipes de localisation préparant des landing multilingues vérifient que les cibles hreflang utilisent des A-labels cohérents dans les attributs href tout en affichant l'Unicode dans le texte visible — les écarts cassent les entonnoirs analytics quand DNS et marketing ne s'accordent pas sur le hostname canonique.

Les listes SAN de certificats du vérificateur SSL peuvent afficher Punycode tandis que les dirigeants lisent l'Unicode sur les slides — convertissez dans les deux sens dans le même ticket pour que les CSR de renouvellement incluent chaque forme attendue par la CA.

Les campagnes typosquat enregistrent des lookalikes IDN minutes après une actualité de marque — le convertisseur accélère le triage mais les playbooks de réponse nécessitent encore juridique, abus registrar et communication client au-delà de tout outil DNS.

Les politiques d'affichage punycode dans le mail diffèrent : certains clients montrent l'Unicode, d'autres xn-- — formez le support à convertir dans les deux sens avant d'accuser les clients de fautes de frappe sur des URL internationalisées.

Les réseaux d'affiliation passent parfois des domaines de tracking Unicode — convertissez avant le Blacklist Checker ou WHOIS pour que les systèmes de tickets stockent des identifiants Punycode cohérents.

Les erreurs d'entrée invalide signifient généralement des caractères interdits, des étiquettes vides ou des points finaux dans le mauvais champ. Retirez chemins et schémas — convertissez uniquement les étiquettes d'hôte (pas https://).

Les étiquettes à scripts mixtes peuvent être rejetées par les navigateurs même si Punycode encode — la politique est côté client. Ne supposez pas que encodable équivaut à enregistrable.

Le aller-retour Unicode → Punycode → Unicode doit correspondre après normalisation. Sinon, vérifiez les joiners Unicode invisibles ou les différences de normalisation homoglyphe entre outils.

Le DNS Checker accepte l'Unicode et normalise en interne — vérifiez tout de même que la sortie encodée correspond aux enregistrements registrar lors de litiges de délégation.

Les étiquettes Punycode sont insensibles à la casse en DNS — comparez toujours les formes xn-- en minuscules lors du diff des exports WHOIS avec la sortie du convertisseur.

Les noms de domaine internationalisés existent car les étiquettes DNS étaient historiquement limitées à l'ASCII. Punycode est un encodage réversible, pas un chiffrement — quiconque peut décoder les chaînes xn-- avec cet outil ou des bibliothèques standard.

Les attaques homographes exploitent des caractères visuellement similaires entre scripts. Convertissez les URL suspectes, comparez au Punycode de marque connu et escaladez via les canaux d'abus registrar avec preuves WHOIS. DN01 ne maintient pas de listes blanches de marques ni de scores phishing automatiques.

Les parseurs mail et URL laissent parfois l'IDN en Unicode alors que vos outils DNS ont besoin d'A-labels — standardisez sur Punycode avant les traces DIG MX sur les domaines mail internationalisés.

L'accès API prend en charge la conversion par lots dans les scripts après enregistrement du token — l'UI navigateur reste idéale pour les copies rapides avec libellés localisés.

Les éditeurs de navigateurs maintiennent des blocklists de caractères confusibles — encodable dans DN01 ne signifie pas rendable dans chaque user agent. Testez les vrais navigateurs clients après mise en production DNS.

Les moteurs de recherche indexent les canoniques IDN — les équipes SEO doivent aligner les URL du sitemap sur la forme Punycode que les crawlers récupèrent, tandis que le microcopy marketing reste en Unicode.

Les deep links mobiles avec hôtes Unicode doivent correspondre au traitement IDN de l'app — convertissez avant de tester les universal links ; les règles de normalisation iOS et Android diffèrent légèrement de la rigueur Punycode DNS.

WHOIS sur Punycode reste autoritatif pour les litiges d'enregistrement — joignez la sortie du convertisseur lors de l'escalade de domaines lookalike vers les registrars.

Le mail internationalisé (EAI) introduit l'Unicode dans les en-têtes — le DNS pour MX utilise toujours Punycode ; convertissez les domaines de boîtes avant DIG lors du débogage TLS SMTP sur hôtes mail IDN.

Les registres publient des tables IDN par TLD — les caractères valides en IDN .com peuvent différer des règles ccTLD ; le convertisseur encode l'Unicode fourni sans juger la politique du registre.

Les playbooks de réponse phishing doivent lister le convertisseur Punycode DN01 à côté de WHOIS et DNS Checker — les premiers intervenants convertissent les URL avant blocage proxy, réduisant les faux positifs sur commerçants IDN légitimes.

Les primes d'enregistrement de domaines Unicode varient selon le registrar — le convertisseur ne cite pas les prix ni ne vérifie la disponibilité ; WHOIS répond à l'enregistrement après encodage correct.

Les proxys d'entreprise bloquent parfois les URL xn-- comme suspectes — l'Unicode décodé peut passer la revue de politique tandis que Punycode déclenche des filtres ; documentez les deux formes pour les exceptions firewall.

Les certificats TLS pour sites IDN listent Punycode dans SAN — la sortie du vérificateur SSL doit être convertie pour les rapports exécutifs avec la vérification DNS Checker des mêmes A-labels.

Le convertisseur DN01 est gratuit en usage manuel ; les limites API s'appliquent aux pipelines de conversion en masse — la même honnêteté que les autres outils réseau DN01 sans cartes de propagation.

idn2/idnkit en ligne de commande fonctionne dans les scripts mais manque souvent sur les images Windows d'entreprise. DN01 offre une conversion bidirectionnelle instantanée avec liens DNS et WHOIS — pas un remplacement d'intégration bibliothèque dans votre code applicatif.

Les navigateurs affichent l'Unicode dans la barre d'adresse tout en copiant Punycode — déroutant lors du triage d'incident. Les pages convertisseur dédiées documentent explicitement les deux formes pour les tickets.

Nous n'enregistrons pas d'IDN, ne filtrons pas les marques ni ne détectons automatiquement toutes les combinaisons homographes. Portée honnête : encodage/décodage précis, huit langues avec EN/RU en profondeur complète, guides localisés plus courts ailleurs, historique local uniquement.

Pas de prétention à valider SSL sur les noms convertis automatiquement — lancez vous-même le vérificateur SSL après confirmation de résolution par DNS Checker.

Les formes de normalisation Unicode (NFC vs NFD) peuvent changer l'apparence sans changer le sens — si le aller-retour échoue, inspectez les points de code dans un outil Unicode dédié ; DN01 se concentre sur Punycode DNS.

Les registrars affichent parfois les deux formes sur les factures — joignez la sortie du convertisseur aux tickets finance pour que les paiements de renouvellement correspondent à la délégation technique vérifiée dans WHOIS et DIG.

Les services de protection de marque surveillent les enregistrements homographes — le convertisseur DN01 aide les analystes à décoder rapidement les étiquettes suspectes ; nous n'alertons pas automatiquement sur les nouveaux enregistrements.

Les matrices de test IDN des développeurs doivent inclure des étiquettes à scripts mixtes que votre produit doit rejeter — le convertisseur produit les A-labels attendus pour les tests unitaires.

Les portails gouvernementaux et bancaires exigent parfois des scripts IDN spécifiques — la revue juridique précède le lancement technique ; le convertisseur ne certifie pas l'approbation réglementaire.

Les clés de cache CDN peuvent utiliser des en-têtes Host Punycode — si le purge échoue pour des URL marketing Unicode, convertissez et purgez la variante A-label ; le vérificateur d'en-têtes HTTP confirme l'en-tête Host vu par l'edge.