Conversor Punycode

O marketing entrega domínios cirílicos ou com diacríticos enquanto os painéis DNS exigem rótulos xn--. Converta antes de colar no Verificador DNS ou campos glue do registrador — um único carácter errado produz NXDOMAIN em toda a zona.

Equipas de segurança descodificam URLs de phishing a partir de logs de correio onde os MTA mostram Punycode. Converter para Unicode revela ataques homógrafos a marcas. Continue com WHOIS para idade de registo e verificador de cabeçalhos HTTP no host descodificado — a conversão não bloqueia malware.

Programadores a testar suporte IDN em apps colam entrada Unicode, convertem para A-label e depois DIG A/AAAA no resultado. Os browsers aplicam regras IDNA2008/UTS46; o conversor DN01 alinha-se com a codificação Punycode padrão para operações DNS.

Documentação e runbooks devem guardar ambas as formas: Unicode para humanos, Punycode para máquinas. Botões de cópia reduzem erros de transcrição em tickets face a reescrever longas cadeias xn-- de PDFs.

Políticas ccTLD variam — alguns namespaces restringem scripts. Punycode prova apenas codificação; aceitação do registo é questão WHOIS/política que a DN01 não decide.

Equipas de localização a preparar landings multilingues verificam que os hreflang usam A-labels consistentes em atributos href enquanto mostram Unicode no texto visível — discrepâncias quebram funis analíticos quando DNS e marketing discordam no hostname canónico.

Listas SAN de certificados do Verificador SSL podem mostrar Punycode enquanto executivos leem Unicode em slides — converta em ambos os sentidos no mesmo ticket para CSRs de renovação incluírem cada forma que a CA espera.

Campanhas typosquat registam lookalikes IDN minutos após notícias de marca — o conversor acelera triagem mas playbooks de resposta ainda precisam de legal, abuso do registrador e comunicação ao cliente.

Políticas de exibição punycode no correio diferem: alguns clientes mostram Unicode, outros xn-- — forme o suporte a converter em ambos os sentidos antes de acusar erros de digitação em URLs internacionalizadas.

Redes de afiliados passam por vezes domínios de tracking Unicode — converta antes do Verificador de listas negras ou WHOIS para sistemas de casos guardarem identificadores Punycode consistentes.

Erros de entrada inválida significam geralmente caracteres não permitidos, rótulos vazios ou pontos finais no campo errado. Remova caminhos e esquemas — converta apenas rótulos de host (não https://).

Rótulos de script misto podem ser rejeitados por browsers mesmo quando Punycode codifica — a política é do lado do cliente. Não assuma que codificável equivale a registável.

O round-trip Unicode → Punycode → Unicode deve coincidir após normalização. Se não, verifique joiners Unicode invisíveis ou diferenças de normalização homóglifo entre ferramentas.

O Verificador DNS aceita Unicode e normaliza internamente — ainda assim verifique que a saída codificada coincide com registos do registrador ao depurar disputas de delegação.

Rótulos Punycode são case-insensitive em DNS — compare sempre formas xn-- em minúsculas ao comparar exportações WHOIS com a saída do conversor.

Nomes de domínio internacionalizados existem porque os rótulos DNS eram historicamente limitados a ASCII. Punycode é codificação reversível, não encriptação — qualquer pessoa pode descodificar cadeias xn-- com esta ferramenta ou bibliotecas padrão.

Ataques homógrafos exploram caracteres visualmente semelhantes entre scripts. Converta URLs suspeitas, compare com Punycode de marca conhecida e escale via canais de abuso do registrador com evidência WHOIS. A DN01 não mantém allowlists de marca nem pontuações automáticas de phishing.

Parsers de correio e URL deixam por vezes IDN em Unicode enquanto as suas ferramentas DNS precisam de A-labels — padronize em Punycode antes de traces DIG MX em domínios de correio internacionalizados.

Acesso API suporta conversão em lote em scripts após registo de token — a UI do browser continua ideal para cópias rápidas com etiquetas localizadas.

Fabricantes de browsers mantêm blocklists de caracteres confusíveis — codificável na DN01 não significa renderizável em todo user agent. Teste browsers reais de clientes após go-live DNS.

Motores de busca indexam canónicos IDN — equipas SEO devem alinhar URLs do sitemap com a forma Punycode que os crawlers obtêm, enquanto microcopy de marketing permanece Unicode.

Deep links móveis com hosts Unicode devem corresponder ao tratamento IDN da app — converta antes de testar universal links; regras de normalização iOS e Android diferem ligeiramente da rigidez Punycode DNS.

WHOIS em Punycode permanece autoritativo em disputas de registo — anexe a saída do conversor ao escalar domínios lookalike a registradores.

Correio internacionalizado (EAI) introduz Unicode em cabeçalhos — o DNS para MX continua a usar Punycode; converta domínios de caixa antes de DIG ao depurar certificados TLS SMTP em hosts de correio IDN.

Registos publicam tabelas IDN por TLD — caracteres válidos em IDN .com podem diferir de regras ccTLD; o conversor codifica o Unicode fornecido sem julgar política do registo.

Playbooks de resposta a phishing devem listar o conversor Punycode DN01 junto a WHOIS e Verificador DNS — primeiros respondedores convertem URLs antes de bloquear no proxy.

Prémios de registo de domínios Unicode diferem por registrador — o conversor não cota preços nem verifica disponibilidade; WHOIS responde ao registo após codificar corretamente.

Proxies empresariais bloqueiam por vezes URLs xn-- como suspeitas — Unicode descodificado pode passar revisão de política enquanto Punycode dispara filtros; documente ambas as formas para exceções de firewall.

Certificados TLS para sites IDN listam Punycode em SAN — a saída do Verificador SSL deve ser convertida para relatórios executivos com verificação do Verificador DNS dos mesmos A-labels.

O conversor DN01 é gratuito para uso manual; limites de API aplicam-se a pipelines de conversão em massa — a mesma honestidade que outras ferramentas de rede DN01 sem mapas de propagação.

idn2/idnkit na linha de comandos funciona em scripts mas falta em muitas imagens corporativas Windows. A DN01 oferece conversão bidirecional instantânea com ligações DNS e WHOIS — não substitui integração de biblioteca no código da aplicação.

Browsers mostram Unicode na barra de endereços enquanto copiam Punycode — confuso durante triagem de incidentes. Páginas de conversor dedicadas documentam ambas as formas explicitamente para tickets.

Não registamos IDN, não filtramos marcas nem detetamos automaticamente todas as combinações homógrafas. Âmbito honesto: codificação/descodificação precisa, oito idiomas com EN/RU em profundidade completa, guias localizados mais curtos noutros idiomas, apenas histórico local.

Sem alegação de validar SSL em nomes convertidos automaticamente — execute o Verificador SSL após o Verificador DNS confirmar resolução.

Formas de normalização Unicode (NFC vs NFD) podem alterar aparência sem alterar significado — se o round-trip falhar, inspecione pontos de código numa ferramenta Unicode dedicada; a DN01 foca-se em Punycode DNS.

Registradores mostram por vezes ambas as formas em faturas — anexe saída do conversor a tickets de finanças para pagamentos de renovação coincidirem com delegação técnica verificada em WHOIS e DIG.

Serviços de proteção de marca monitorizam registos homógrafos — o conversor DN01 ajuda analistas a descodificar rótulos suspeitos rapidamente; não alertamos automaticamente sobre novos registos.

Matrizes de teste IDN de programadores devem incluir rótulos de script misto que o produto deve rejeitar — o conversor produz A-labels esperados para testes unitários.

Portais governamentais e bancários exigem por vezes scripts IDN específicos — revisão legal precede lançamento técnico; o conversor não certifica aprovação regulatória.

Chaves de cache CDN podem usar cabeçalhos Host Punycode — quando purge falha para URLs de marketing Unicode, converta e purgue variante A-label; verificador de cabeçalhos HTTP confirma qual cabeçalho Host o edge viu.