Pular para o conteúdo
iseeu.cc
PT – Idioma: Português (Brasil)

Conversor Punycode

Converta nomes de domínio internacionalizados entre Unicode e a forma ASCII xn-- enquanto você digita. Cole um domínio, uma URL ou um endereço de e-mail; tudo roda no seu navegador.

Forma ASCII (xn--)
Forma Unicode

Resposta curta

O Punycode (RFC 3492) escreve um rótulo Unicode usando só letras, dígitos e hífens, e o IDNA acrescenta o prefixo xn--; assim, pão.example fica guardado no DNS como xn--po-sia.example. Depois da conversão, cada rótulo pode ter no máximo 63 caracteres (RFC 1035).

Como é obtido

A conversão é feita rótulo por rótulo. Primeiro são copiados os caracteres ASCII do rótulo, seguidos de um hífen se houver algum; depois, cada caractere não ASCII é codificado como um número em base 36 de tamanho variável, que registra qual ponto de código inserir e onde, usando as constantes fixadas na RFC 3492 (base 36, tmin 1, tmax 26, skew 38, damp 700, bias inicial 72, n inicial 128). Antes disso, a entrada de domínio passa pelo mapeamento IDNA que os navegadores aplicam (UTS #46): letras de largura total e o ponto final ideográfico viram as suas formas ASCII, e o nome é passado para minúsculas.

Exemplo prático

pão: copia po, acrescenta - e depois codifica o ã (U+00E3), inserido na posição 1, como sia, o que dá po-sia; assim, pão.example vira xn--po-sia.example. No sentido inverso, xn--wgv71a119e.jp é decodificado como 日本語.jp.

Limites

  • O tamanho e os caracteres são verificados, mas não todas as regras do IDNA2008 (por exemplo, as regras contextuais para caracteres de junção); cada registro também tem a própria lista de caracteres permitidos.
  • Nomes que misturam alfabetos são sinalizados como possíveis imitações; uma imitação escrita num só alfabeto, como letras todas cirílicas parecidas com uma palavra latina, não é detectada.

Fontes

Fontes conferidas em . Página atualizada em .

O que a ferramenta faz

Este conversor traduz nomes de domínio internacionalizados (IDNs) entre a forma que as pessoas leem e a forma que o DNS guarda. Digite pão.example e você recebe xn--po-sia.example; cole um nome xn-- e você recebe o original em Unicode. Funciona nos dois sentidos enquanto você digita, rótulo por rótulo, então em loja.pão.example só o rótulo com caracteres não ASCII ganha o prefixo xn--.

A codificação é o Punycode (RFC 3492), implementado em JavaScript dentro do seu navegador; nada do que você digita é enviado a lugar nenhum. Antes de codificar, a ferramenta passa cada rótulo para minúsculas e aplica a normalização Unicode NFC, então um ã pré-composto e um a seguido de um til combinante dão o mesmo resultado. Ela não aplica todas as regras de mapeamento do IDNA2008 ou do UTS #46, então uma conversão bem-sucedida é uma codificação correta, e não uma prova de que um registro vai aceitar o nome.

Ao lado do resultado aparece o detalhamento de cada rótulo (forma Unicode, forma ASCII e tamanho), uma verificação dos limites do DNS, de 63 octetos por rótulo e 253 para o nome completo, e um alerta quando um mesmo rótulo mistura alfabetos, como o latino com o cirílico ou o grego.

Como usar

  1. Digite ou cole um nome de domínio, uma URL completa ou um endereço de e-mail.
  2. Veja a forma convertida se atualizar: uma entrada em Unicode gera a forma xn--, e uma entrada xn-- gera Unicode.
  3. Leia o detalhamento dos rótulos para ver tamanhos, erros de limite e eventuais alertas de alfabetos misturados.
  4. Copie a forma que o destino espera.

Numa URL, só o host é convertido; o resto fica como foi digitado. (Na web, caracteres não ASCII num caminho ou numa query string são codificados em porcentagem como UTF-8, e não convertidos para Punycode.) Num endereço de e-mail, só a parte depois do @ é convertida. Uma parte local como joão não tem forma em Punycode; entregar e-mail para ela exige suporte a SMTPUTF8 (RFC 6531) em todos os servidores do caminho.

Casos de uso

  • Checar um link suspeito. Cole a URL de uma mensagem antes de abri-la. Se o host decodificar para letras de dois alfabetos, ou se um nome com cara de conhecido for na verdade um rótulo xn--, olhe com mais atenção antes de clicar.
  • Escrever registros DNS. Arquivos de zona e a maioria dos painéis de hospedagem de DNS esperam a forma ASCII. Use exatamente essa string onde quer que um registro se refira ao nome, incluindo destinos de CNAME e hosts de MX.
  • Pedir certificados TLS. Autoridades certificadoras e clientes ACME recebem a forma xn-- nos nomes alternativos (SAN). Decodificar a lista SAN de um certificado mostra quais nomes Unicode ele cobre de fato.
  • Ler logs. Logs de servidor web, cabeçalhos HTTP Host e valores de SNI do TLS trazem o nome codificado. Decodifique uma entrada desconhecida para conseguir lê-la.
  • Configurar e-mail para um IDN. Os registros MX, SPF, DKIM e DMARC ficam todos sob o nome xn--, e um endereço como contato@xn--po-sia.example funciona com programas de e-mail comuns.
  • Conferir o tamanho antes de registrar. A codificação expande bastante alguns sistemas de escrita: o rótulo tailandês de sete caracteres ภาษาไทย vira xn--o3crh0a8bb0k, com 16 octetos, então um rótulo que parece curto ainda pode passar de 63.

Os registros DNS e a solicitação de assinatura de certificado (CSR) para bücher.example usam o nome codificado como qualquer outro nome de host:

xn--bcher-kva.example.      3600 IN A     192.0.2.10
www.xn--bcher-kva.example.  3600 IN CNAME xn--bcher-kva.example.
xn--bcher-kva.example.      3600 IN MX    10 mail.xn--bcher-kva.example.

openssl req -new -key site.key -out site.csr \
  -subj "/CN=xn--bcher-kva.example" \
  -addext "subjectAltName=DNS:xn--bcher-kva.example,DNS:www.xn--bcher-kva.example"

Como o Punycode encaixa Unicode num nome de host

A rigor, o formato de transmissão do DNS aceita quaisquer valores de byte. Na prática, os nomes de host se limitam a letras ASCII, dígitos e hífen desde os anos 1980 (a regra LDH das RFC 952 e RFC 1123), e resolvedores, servidores de e-mail e verificações de certificado foram construídos sobre essa premissa. Em vez de mudar tudo isso, o IDNA converte os nomes dentro do aplicativo, antes de qualquer consulta ser enviada, numa string que já obedece à regra antiga.

O Punycode trabalha em duas etapas. Primeiro, copia em ordem os caracteres ASCII do rótulo e acrescenta um hífen se houver algum: pão dá po-. Depois, descreve cada caractere que falta como um único número que diz qual ponto de código inserir e onde. O ã é U+00E3, 227 em decimal. Contando a partir de 128, com duas letras já colocadas e, portanto, três posições possíveis de inserção, o número é (227 − 128) × 3 + 1 = 298, em que o 1 final significa “depois da primeira letra”. Esse número é escrito numa forma de base 36 de tamanho variável, com a–z e 0–9, usando limites que se ajustam para que números pequenos continuem curtos. O resultado é sia, o que dá xn--po-sia.

A decodificação faz o caminho inverso: tudo antes do último hífen é copiado, e os caracteres depois dele são lidos de volta como inserções. Um rótulo sem nenhuma letra ASCII, como o tailandês acima, não tem hífen separador depois do prefixo. Como é o rótulo codificado que trafega pelo DNS, o limite de 63 octetos vale para ele, e não para o texto Unicode.

Domínios imitadores e a barra de endereços

Muitas letras de alfabetos diferentes são idênticas. O а cirílico (U+0430) é igual ao a latino na maioria das fontes, então bаnco.example, com um а cirílico na segunda letra, parece uma palavra comum, mas é codificado como xn--bnco-53d.example. Isso é um ataque homógrafo.

Os navegadores decidem, rótulo por rótulo, se mostram Unicode ou a forma xn--. As políticas variam de fabricante para fabricante, mas os testes comuns incluem verificar se um rótulo mistura alfabetos em combinações que nomes reais raramente usam, se é escrito só com letras que imitam as latinas e se é muito parecido com um domínio conhecido. No Firefox, definir network.IDN_show_punycode como true em about:config força a forma ASCII para todos os nomes.

O alerta de alfabetos misturados desta página procura mais de um alfabeto dentro de um mesmo rótulo. Um rótulo escrito todo com letras cirílicas parecidas com as latinas não é misto, então um resultado limpo não prova que um nome é legítimo. Compare o nome decodificado com o endereço que você esperava e, na dúvida, digite o endereço você mesmo.

Perguntas frequentes

Por que meu navegador mostra xn-- em vez do nome de verdade?

Os navegadores só exibem Unicode quando um rótulo passa pela política de exibição deles. Se o rótulo mistura alfabetos de um jeito incomum, é escrito só com caracteres que imitam letras latinas ou se parece demais com um domínio conhecido, o navegador mostra a forma codificada. O site carrega normalmente; cole o nome aqui para ver o que o rótulo xn-- significa depois de decodificado.

Domínio que começa com xn-- é perigoso?

Não. O prefixo só significa que o rótulo foi codificado a partir de Unicode, e muitos sites legítimos em alemão, chinês, árabe, russo e outras línguas o usam. O que importa é o texto decodificado. Se ele forma o nome que você esperava, num único alfabeto, não há nada de estranho. Se ele imita um nome conhecido com letras emprestadas de outro alfabeto, trate o link com cuidado.

Por que outro conversor dá um resultado diferente para um nome com ß?

O processamento antigo do IDNA2003, e o modo de transição do UTS #46, trocam ß por ss e o sigma final ς por σ antes de codificar, então straße vira simplesmente strasse. O IDNA2008 mantém esses caracteres como estão. A conversão para minúsculas e a normalização NFC, as etapas que esta ferramenta aplica, deixam o ß intacto, então faß é codificado aqui como xn--fa-hia. Confira qual forma o seu registro e os programas dos seus usuários esperam.

Posso colocar Unicode direto num arquivo de zona ou num certificado?

Use a forma xn-- nos dois. Um certificado guarda nomes DNS num campo que só aceita ASCII, então as autoridades certificadoras esperam a forma codificada na lista de nomes alternativos (SAN). Num arquivo de zona, um nome escrito com bytes UTF-8 crus não corresponderia às consultas xn-- que resolvedores e navegadores enviam, então o registro simplesmente nunca seria encontrado.

E a parte antes do @ num e-mail, como fica?

Fica exatamente como você digitou, porque o Punycode só se aplica a nomes de domínio. Se a parte local tiver caracteres fora do ASCII, como em joão, a entrega depende da extensão SMTPUTF8, definida na RFC 6531. Todos os servidores do caminho precisam suportá-la; não existe uma alternativa em ASCII parecida com o Punycode, então uma mensagem para esse tipo de endereço normalmente volta onde não há suporte.

Por que um registro pode recusar um nome que esta ferramenta converte sem reclamar?

A ferramenta faz uma codificação correta segundo a RFC 3492, depois de passar o nome para minúsculas e aplicar a normalização NFC, mas não implementa todas as regras do IDNA2008 ou do UTS #46. O IDNA2008 proíbe a maioria dos símbolos e tem regras de contexto para caracteres como os de junção, e cada registro publica a própria tabela de caracteres permitidos para o seu domínio de topo. Um nome pode ser codificado sem problema aqui e ainda assim ser barrado nessas verificações.

O que eu digito é enviado para algum servidor?

Não. A conversão, a verificação de tamanho e o alerta de alfabetos misturados rodam em JavaScript dentro do seu navegador, então os nomes, URLs e endereços de e-mail que você cola nunca saem do seu dispositivo. Além disso, o iseeu.cc não guarda registros de endereços IP nem de consultas, não tem banco de dados de visitantes, não usa cookies e não exibe anúncios.

Uma conversão limpa mostra que o nome está codificado corretamente, não que ele pode ser registrado ou que é seguro. Os registros aplicam as próprias regras de caracteres, e nomes imitadores podem evitar a mistura de alfabetos.

Ver todas as ferramentas