Conversor de Punycode / IDN

O que é o Punycode?#

O Sistema de Nomes de Domínio (DNS) foi construído sobre ASCII — as letras A-Z, dígitos e o hífen. Então como é que um navegador resolve um domínio como 中文.com ou münchen.de, cujos caracteres não estão nesse alfabeto? A resposta é o Punycode (e a framework IDN à sua volta): uma codificação reversível que transforma cada etiqueta não-ASCII numa forma segura para ASCII que começa pelo prefixo xn--. O DNS só vê xn--fiq228c.com; o navegador mostra-lhe 中文.com.

Esta ferramenta converte em ambas as direções:

• Para ASCII (Unicode → Punycode) pega um domínio ou e-mail Unicode e produz a forma xn-- que o DNS e os certificados realmente transportam. Cada etiqueta é convertida independentemente — münchen.中文.com torna-se xn--mnchen-3ya.xn--fiq228c.com, com o .com final deixado em paz porque já é ASCII.
• Para Unicode (Punycode → Unicode) faz o inverso: lê etiquetas xn-- de volta para o script legível por humanos.

E-mail também é tratado. A ferramenta deteta o @, converte apenas a parte do domínio, e deixa a parte local (o nome da caixa de correio) intocada — pelo que Büchner@中文.com se torna Bü[email protected], nunca uma conversão da string inteira corrompida.

Como usar#

1. Escolha Unicode → Punycode ou Punycode → Unicode no interruptor no canto superior esquerdo. A ferramenta também sugere uma direção quando nota uma etiqueta xn-- na sua entrada.
2. Cole um domínio ou e-mail no painel Entrada. O cabeçalho mostra se foi reconhecido como domínio ou e-mail.
3. O resultado convertido preenche o painel Saída; clique em Copiar para o recolher.
4. Por baixo dos painéis, a tabela de detalhamento por rótulo mostra cada etiqueta e no que se tornou — útil quando um domínio longo tem várias etiquetas não-ASCII e só algumas mudaram.
5. Use Saída → Entrada para mover a saída de volta para a entrada e inverter a direção (uma verificação rápida de ida-e-volta), Exemplo para carregar münchen.中文.com, e Limpar para repor.

Principais funcionalidades#

• Ambas as direções, cada etiqueta por si. Cada etiqueta é convertida independentemente e a tabela de detalhamento mostra exatamente quais mudaram e quais se mantiveram em ASCII.
• Conhecedor de e-mail. Um único @ é detetado e o nome da caixa de correio é preservado; apenas o lado do domínio é codificado. Entrada com vários caracteres @ é rejeitada com uma mensagem clara em vez de corromper silenciosamente o resultado.
• Normalização de separadores. O ponto de largura total ．, o stop ideográfico de largura total 。 e o ｡ de meia largura são todos tratados como o . ASCII que realmente são no IDN, pelo que texto colado não parte.
• Rigoroso com entrada malformada. Uma etiqueta xn-- má (por exemplo xn--!!) lança um erro limpo apontando para a etiqueta ofensiva, em vez de produzir um domínio errado.
• Honesto quanto ao âmbito. A nota de conformidade por baixo da ferramenta afirma claramente que isto implementa a codificação Punycode e o passo de mapeamento — não é um verificador de validade IDNA2008 completo, pelo que uma etiqueta ACE tecnicamente inválida pode ainda decodificar aqui.

Exemplo prático#

A converter Para ASCII (Unicode → Punycode), o marcador münchen.中文.com torna-se:

xn--mnchen-3ya.xn--fiq228c.com

O detalhamento mostra três etiquetas, duas delas convertidas: münchen → xn--mnchen-3ya, 中文 → xn--fiq228c, e .com intocado porque já era ASCII. Mude para Para Unicode e cole o resultado de volta para recuperar münchen.中文.com exatamente.

Mais algumas conversões reais que vale a pena ver:

中文.com           → xn--fiq228c.com
münchen.de        → xn--mnchen-3ya.de
😂.com             → xn--g28h.com
café.fr           → xn--caf-dma.fr
日本語.jp          → xn--wgv71a119e.jp
Büchner@中文.com   → Bü[email protected]   (email: mailbox preserved)

A última é o caso que apanha as pessoas: ferramentas ingénuas codificam a string inteira e partem o endereço. Aqui apenas a parte do domínio depois do @ muda.

FAQ#

Porque é que o meu domínio de emoji se converte numa etiqueta xn-- tão curta?#

Um domínio de emoji de carácter único como 😂.com torna-se xn--g28h.com porque o Punycode é extraordinariamente compacto para uma etiqueta com um carácter não-ASCII seguido de ASCII — codifica as posições e pontos de código dos caracteres não-ASCII em relação aos ASCII, pelo que uma etiqueta de um carácter precisa de muito poucos bytes. Etiquetas não-ASCII mais longas ou mais variadas produzem strings ACE mais longas.

A saída parece igual à entrada — aconteceu alguma coisa?#

Se todas as etiquetas na sua entrada já são ASCII puro (por exemplo example.com), não há nada para codificar, e a saída é igual à entrada. A tabela de detalhamento é o indicador fiável: uma etiqueta cuja saída corresponde à sua entrada não foi convertida, porque não precisava de o ser.

Colei um e-mail e a parte local não foi convertida. Isso está correto?#

Sim, e é deliberado. O e-mail internacionalizado (SMTPUTF8) permite UTF-8 no nome da caixa de correio, mas convertê-lo para xn-- é errado para o caso comum — a parte local não é um nome DNS e não é resolvida por Punycode. Esta ferramenta converte apenas o lado do domínio, que é a parte que tem de ser segura para DNS. É também por isso que vários caracteres @ são rejeitados: tornam “o lado do domínio” ambíguo.

Posso usar a forma ASCII para registrar ou resolver qualquer domínio?#

Para resolução por qualquer navegador ou resolvedor moderno, sim. Para registro, as regras são mais estritas: o IDNA2008 proíbe certos caracteres e normalizações que os mapeamentos mais antigos (IDNA2003) permitiam. Esta ferramenta faz a codificação fielmente mas não executa as verificações de validade IDNA2008 completas, pelo que uma string que codifique limpas aqui pode ainda ser rejeitada por um registrador. Em caso de dúvida, confirme com a ferramenta de pesquisa do seu registrador.