Convertitore Punycode

Il marketing consegna domini cirillici o con diacritici mentre i pannelli DNS richiedono etichette xn--. Converti prima di incollare nel DNS Checker o nei campi glue del registrar — un solo carattere errato produce NXDOMAIN su tutta la zona.

I team sicurezza decodificano URL di phishing dai log mail dove gli MTA mostrano Punycode. Convertire in Unicode rivela attacchi omografi contro marchi. Prosegui con WHOIS per l'età di registrazione e HTTP header checker sull'host decodificato — la conversione non blocca malware.

Gli sviluppatori che testano supporto IDN nelle app incollano input Unicode, convertono in A-label, poi DIG A/AAAA sul risultato. I browser applicano regole IDNA2008/UTS46; il convertitore DN01 si allinea alla codifica Punycode standard per operazioni DNS.

Documentazione e runbook dovrebbero archiviare entrambe le forme: Unicode per umani, Punycode per macchine. I pulsanti copia riducono errori di trascrizione nei ticket rispetto a riscrivere lunghe stringhe xn-- da PDF.

Le politiche ccTLD variano — alcuni namespace limitano gli script. Punycode prova solo la codifica; l'accettazione del registry è una questione WHOIS/politica che DN01 non decide.

I team di localizzazione che preparano landing multilingue verificano che gli hreflang usino A-label coerenti negli attributi href mentre mostrano Unicode nel testo visibile — le discrepanze rompono funnel analytics quando DNS e marketing non concordano sul hostname canonico.

Le liste SAN dei certificati dall'SSL Certificate Checker possono mostrare Punycode mentre i dirigenti leggono Unicode sulle slide — converti in entrambe le direzioni nello stesso ticket affinché i CSR di rinnovo includano ogni forma attesa dalla CA.

Le campagne typosquat registrano lookalike IDN minuti dopo notizie di marchio — il convertitore accelera il triage ma i playbook di risposta richiedono ancora legal, abuso registrar e comunicazione clienti.

Le politiche di visualizzazione punycode nel mail differiscono: alcuni client mostrano Unicode, altri xn-- — forma il supporto a convertire in entrambe le direzioni prima di accusare errori di battitura su URL internazionalizzate.

Le reti di affiliazione passano a volte domini di tracking Unicode — converti prima di Blacklist Checker o WHOIS affinché i sistemi di case memorizzino identificatori Punycode coerenti.

Errori di input non valido significano di solito caratteri non consentiti, etichette vuote o punti finali nel campo sbagliato. Rimuovi percorsi e schemi — converti solo etichette host (non https://).

Etichette a script misto possono essere rifiutate dai browser anche se Punycode codifica — la policy è lato client. Non assumere che codificabile equivalga a registrabile.

Il round-trip Unicode → Punycode → Unicode dovrebbe corrispondere dopo normalizzazione. Se no, controlla joiner Unicode invisibili o differenze di normalizzazione omografo tra strumenti.

Il DNS Checker accetta Unicode e normalizza internamente — verifica comunque che l'output codificato corrisponda ai record del registrar quando debugghi dispute di delegazione.

Le etichette Punycode sono case-insensitive in DNS — confronta sempre forme xn-- minuscole quando diffi export WHOIS con output del convertitore.

I nomi di dominio internazionalizzati esistono perché le etichette DNS erano storicamente limitate ad ASCII. Punycode è codifica reversibile, non crittografia — chiunque può decodificare stringhe xn-- con questo strumento o librerie standard.

Gli attacchi omografi sfruttano caratteri visivamente simili tra script. Converti URL sospette, confronta con Punycode di marchio noto ed escala via canali abuso registrar con evidenza WHOIS. DN01 non mantiene allowlist di marchi né punteggi phishing automatici.

I parser mail e URL lasciano a volte IDN in Unicode mentre i tuoi strumenti DNS necessitano A-label — standardizza su Punycode prima di trace DIG MX su domini mail internazionalizzati.

L'accesso API supporta conversione batch negli script dopo registrazione token — l'UI browser resta ideale per copie rapide con etichette localizzate.

I vendor browser mantengono blocklist di caratteri confondibili — codificabile in DN01 non significa renderizzabile in ogni user agent. Testa browser reali dei clienti dopo go-live DNS.

I motori di ricerca indicizzano canonici IDN — i team SEO dovrebbero allineare URL sitemap alla forma Punycode che i crawler recuperano, mentre il microcopy marketing resta Unicode.

Deep link mobili con host Unicode devono corrispondere alla gestione IDN dell'app — converti prima di testare universal link; le regole di normalizzazione iOS e Android differiscono leggermente dalla rigidità Punycode DNS.

WHOIS su Punycode resta autorevole per dispute di registrazione — allega output del convertitore quando escali domini lookalike ai registrar.

La mail internazionalizzata (EAI) introduce Unicode negli header — il DNS per MX usa ancora Punycode; converti domini mailbox prima di DIG quando debugghi certificati TLS SMTP su host mail IDN.

I registry pubblicano tabelle IDN per TLD — caratteri validi in IDN .com possono differire da regole ccTLD; il convertitore codifica l'Unicode fornito senza giudicare policy del registry.

I playbook risposta phishing dovrebbero elencare il convertitore Punycode DN01 accanto a WHOIS e DNS Checker — i primi risponditori convertono URL prima del blocco proxy.

I premi di registrazione domini Unicode differiscono per registrar — il convertitore non quoter prezzi né verifica disponibilità; WHOIS risponde alla registrazione dopo codifica corretta.

I proxy aziendali a volte bloccano URL xn-- come sospette — Unicode decodificato può passare revisione policy mentre Punycode scatena filtri; documenta entrambe le forme per eccezioni firewall.

I certificati TLS per siti IDN elencano Punycode in SAN — l'output dell'SSL Certificate Checker dovrebbe essere convertito per report esecutivi con verifica DNS Checker degli stessi A-label.

Il convertitore DN01 è gratuito per uso manuale; limiti API si applicano a pipeline di conversione bulk — la stessa onestà degli altri strumenti di rete DN01 senza mappe di propagazione.

idn2/idnkit da riga di comando funziona negli script ma manca su molte immagini Windows aziendali. DN01 offre conversione bidirezionale istantanea con link DNS e WHOIS — non sostituisce integrazione libreria nel codice applicativo.

I browser mostrano Unicode nella barra indirizzi mentre copiano Punycode — confuso durante triage incidenti. Pagine convertitore dedicate documentano esplicitamente entrambe le forme per i ticket.

Non registriamo IDN, non filtriamo marchi né rileviamo automaticamente tutte le combinazioni omografe. Ambito onesto: codifica/decodifica accurata, otto lingue con EN/RU a profondità completa, guide localizzate più brevi altrove, solo cronologia locale.

Nessuna pretesa di validare SSL su nomi convertiti automaticamente — esegui tu SSL Certificate Checker dopo che DNS Checker conferma risoluzione.

Le forme di normalizzazione Unicode (NFC vs NFD) possono cambiare aspetto senza cambiare significato — se il round-trip fallisce, ispeziona codepoint in uno strumento Unicode dedicato; DN01 si concentra su Punycode DNS.

I registrar mostrano a volte entrambe le forme sulle fatture — allega output convertitore ai ticket finance affinché i pagamenti rinnovo corrispondano alla delegazione tecnica verificata in WHOIS e DIG.

I servizi protezione marchio monitorano registrazioni omografe — il convertitore DN01 aiuta gli analisti a decodificare rapidamente etichette sospette; non alertiamo automaticamente su nuove registrazioni.

Le matrici test IDN degli sviluppatori dovrebbero includere etichette script misto che il prodotto deve rifiutare — il convertitore produce A-label attesi per unit test.

Portali governativi e bancari a volte impongono script IDN specifici — revisione legale precede il lancio tecnico; il convertitore non certifica approvazione regolamentare.

Le chiavi cache CDN possono usare header Host Punycode — quando il purge fallisce per URL marketing Unicode, converti e purga variante A-label; HTTP header checker conferma quale header Host ha visto l'edge.