Conversor Punycode / IDN

Portanto o Punycode não é uma língua, um tipo de letra ou um código de país — é uma tradução entre duas grafias do mesmo nome. A grafia Unicode chama-se etiqueta U (中文.com, bücher.de), a grafia ASCII chama-se etiqueta A (xn--fiq228c.com, xn--bcher-kva.de), e a ideia de pôr nomes internacionais no DNS chama-se IDN (nomes de domínio internacionalizados) ou IDNA, o conjunto de regras construído por cima.

Existe porque o DNS foi concebido no início dos anos 80 em torno de um alfabeto deliberadamente minúsculo. Um nome de anfitrião que viaja pelo DNS, para um ficheiro de zona, uma cache de resolvedor, uma linha de registo ou um certificado TLS, tem de ser ASCII simples — o formato de transmissão simplesmente não tem campo para mais nada. O Punycode é a saída de emergência: deixa um nome que não é ASCII viajar como se o fosse, e deixa a extremidade recetora reconstruir os caracteres originais exatamente. É por isso que um domínio chinês funciona de todo num navegador, e por que xn-- é a única cadeia que verá em todos os sítios onde a grafia Unicode não pode ser enviada.

O que escreve (etiqueta U)	O que o DNS recebe (etiqueta A)	O que significa
中文.com	xn--fiq228c.com	As palavras chinesas para “língua chinesa”
中国	xn--fiqs8s	“China” em chinês
例え.jp	xn--r8jz45g.jp	Exemplos em japonês
bücher.de	xn--bcher-kva.de	Alemão bücher, “livros”
münchen.de	xn--mnchen-3ya.de	Munique
😂.com	xn--e28h.com	Uma etiqueta com emoji — legal na codificação, não na maioria dos registos

Uma comparação de comprimento que vale a pena reter: 中文 são 2 caracteres e 6 bytes em UTF-8, mas xn--fiq228c são 11 bytes ASCII. O Punycode normalmente torna um nome mais longo, nunca mais curto.

Pegue em bücher e observe os três movimentos. O motor chama-se bootstring, e o algoritmo inteiro são apenas algumas dezenas de linhas de código (pode lê-lo no script desta página).

1. Copie os caracteres simples para a frente. Cada carácter ASCII básico é copiado na sua ordem original e mantém-se legível: bücher → bcher. Como algo foi copiado e algo sobrou, acrescenta-se um único - como fronteira: bcher-.
2. Escreva o resto como números em base 36. Os caracteres restantes são tratados por ordem crescente de ponto de código, e cada um é escrito como um número de comprimento variável em base 36, em que a=0 … z=25 e 0=26 … 9=35. Para bücher, o carácter que sobra ü torna-se os dígitos kva.
3. Acrescente o prefixo. A parte codificada acrescentada à parte copiada dá bcher-kva, e em contexto de domínio escreve-se xn--bcher-kva.

O truque que torna isto engenhoso é o que esses números em base 36 contêm: não o próprio carácter, mas um delta — a distância do carácter ao ponto de código codificado anteriormente, mais o local onde pertence dentro da cadeia. O codificador percorre os pontos de código por ordem crescente e cada sequência de dígitos descreve uma posição e uma distância. Depois de cada carácter, um número partilhado chamado viés é ajustado para que o número seguinte precise do menor número possível de dígitos.

Duas consequências que pode ver por si próprio acima:

• Caracteres semelhantes são baratos. Como só se guardam distâncias, uma sequência do mesmo carácter custa quase nada: 30 cópias de 中 codificam-se em xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, apenas 36 bytes. Uma mistura medida de caracteres chineses não relacionados mas próximos cabe em cerca de 41 caracteres numa etiqueta legal de 63 bytes, e um só carácter repetido chega a 57.
• Caracteres dispersos são caros. Um carácter longe do anterior precisa de um número delta mais longo. Texto chinês com muitos caracteres diferentes custa tipicamente cerca de 2 a 3 letras extra por carácter, razão por que uma etiqueta CJK fica sem espaço algures entre 20 e 40 caracteres, apesar de o limite da etiqueta ser de 63 bytes.

A descodificação é a mesma receita ao contrário: copiar o prefixo ASCII, ler os dígitos, converter os deltas de volta em pontos de código e inserir cada carácter novo na cadeia na posição que o delta codifica. Só existem dígitos em minúsculas no bootstring, razão por que uma letra maiúscula dentro de uma parte codificada é rejeitada em vez de ser adivinhada — o DNS não distingue maiúsculas, por isso aceitar ambas tornaria ambíguas duas grafias diferentes.

• Na barra de endereços. Os navegadores podem mostrar xn--fiq228c.com em vez de 中文.com. É o mesmo site. Alguns navegadores mostram de propósito a forma Punycode quando um nome mistura alfabetos, precisamente para que um carácter parecido (o а cirílico versus o a latino) não se possa esconder no URL.
• No próprio DNS. Os ficheiros de zona, as respostas de dig / nslookup / DNS-over-HTTPS e os registos de resolvedor contêm sempre apenas a forma xn--; o Unicode simples é rejeitado ou desfigurado em silêncio.
• Em certificados TLS. O nome alternativo do assunto para um domínio internacional é guardado como etiqueta A (DNS:xn--fiq228c.com), pelo que um certificado que não se pareça com o nome que escreveu é normal, não uma incompatibilidade.
• Na configuração e nas ferramentas. Entradas server_name / de anfitrião virtual no servidor web, domínios de cookies, painéis de alojamento e CDN, domínios de correio, chaves de API associadas a um domínio e chaves de base de dados são todas mais seguras na forma de etiqueta A.
• Em testes e pipelines de dados. Algumas bibliotecas passam o Unicode diretamente ao resolvedor e falham; converter primeiro para Punycode é a correção habitual. Como o mapeamento é canónico — uma etiqueta Unicode corresponde exatamente a uma etiqueta A — a forma xn-- também é um identificador estável para registos e pesquisas.

O Punycode é uma grafia reversível, nada mais. Não é cifragem nem uma funcionalidade de segurança: qualquer pessoa o descodifica com a ferramenta acima, pelo que uma etiqueta xn-- diz “isto foi codificado” e nada sobre quem a possui. Também não é compressão — normalmente torna o texto mais longo, como mostra o exemplo de 6 para 11 bytes acima. E não é o mesmo que as outras formas como o Unicode circula pela Internet; essas resolvem camadas diferentes do problema.

Esquema	Transforma o quê em quê	Onde é usado	中文 passa a
Punycode (RFC 3492)	Uma etiqueta de domínio Unicode em letras e dígitos ASCII	Apenas etiquetas de domínio internacionais	xn--fiq228c
UTF-8 (RFC 3629)	Pontos de código em bytes	Cada ficheiro e pedido web	E4 B8 AD E6 96 87 (6 bytes)
Codificação por percentagem (RFC 3986)	Bytes em escapes %XX	Caminhos de URL, query strings, corpos de formulários	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Bytes em 64 caracteres ASCII	Binário dentro de texto, JSON, correio eletrónico, URLs de dados	5Lit5paH
Entidades HTML	Pontos de código em referências com nome ou numéricas	Código-fonte HTML e XML	中文
Escapes Unicode	Pontos de código em \uXXXX	Código-fonte e literais de cadeia em JSON	\u4e2d\u6587

A conclusão prática: o Punycode aplica-se às etiquetas de domínio de um URL, não ao URL inteiro. O caminho e a query string são outro problema e usam codificação por percentagem (veja os Codificadores de URL).

• Os limites de tamanho vêm do DNS, não do Punycode. Uma etiqueta pode ter no máximo 63 bytes e um nome completo no máximo 255 bytes (RFC 1034 / 1035). Como uma etiqueta A é apenas ASCII, a contagem de bytes iguala a contagem de caracteres, e cada carácter não ASCII gasta parte desse orçamento — cerca de 1 carácter de orçamento por 1 a 4 letras Punycode.
• O Punycode converte qualquer coisa; os registos só permitem algumas. As regras IDNA assentam por cima e restringem que pontos de código podem ser registados — letras maiúsculas, espaços, pontuação como ! e marcadores não são legais num domínio real. Esta página faz a conversão RFC 3492, pelo que codificará alegremente um texto que um registo recusaria.
• Fique num só alfabeto. O IDNA desaconselha misturar alfabetos dentro de uma só etiqueta precisamente por causa dos ataques com caracteres parecidos. Um nome pode ser codificado e continuar inutilizável, ou utilizável mas bloqueado pelos navegadores.
• Não codifique duas vezes. xn-- seguido de texto já codificado é inválido, e uma etiqueta só ASCII nunca muda — não há nada para codificar, pelo que não se acrescenta prefixo.
• Um ponto final é aceitável. 例え.jp. é um nome totalmente qualificado e a etiqueta vazia no fim é mantida; etiquetas vazias no meio não são nomes de anfitrião válidos.

“Porque é que o meu domínio chinês aparece como xn--fiq228c.com na barra de endereços?”

Porque o navegador optou por mostrar a etiqueta A. O site é o mesmo; use a direção Descodificar desta página para ver a forma Unicode, ou codifique a forma Unicode para confirmar que as duas grafias coincidem.

“Preciso de alterar os meus registos DNS, certificado ou alojamento?”

Não. Mantenha a etiqueta A xn-- em todo o lado onde uma máquina lê o nome (DNS, certificados, configurações) e use a forma Unicode apenas onde uma pessoa o lê.

“Porque é que o resultado é mais longo do que o que escrevi?”

Porque a codificação não transporta os próprios caracteres, transporta distâncias em base 36, e o alfabeto de 36 caracteres tem de soletrar números que podem ser grandes. O crescimento é esperado, não é um erro.

“Porque é que a descodificação diz ‘letra maiúscula’?”

Porque os dígitos do bootstring são definidos apenas em minúsculas (a-z, 0-9). Um A-Z maiúsculo depois do último hífen é ambíguo quando se considera a insensibilidade a maiúsculas do DNS, por isso é reportado em vez de ser adivinhado em silêncio.

“O Punycode aplica-se à parte antes do @ num endereço de correio eletrónico?”

Só a parte do domínio é um nome DNS e pode ser Punycode. A parte local é tratada pelo sistema de correio, não pelo DNS, por isso esta codificação não se lhe aplica.

“Podem dois nomes Unicode diferentes produzir a mesma etiqueta A?”

Não. A codificação é injetiva: sequências de pontos de código distintas produzem sempre bootstrings distintos, pelo que descodificar xn--fiq228c devolve exatamente 中文 e mais nada. O que pode colidir é a aparência — caracteres diferentes que se parecem — o que é uma propriedade do repertório Unicode, não da codificação.

• RFC 3492 — Punycode, a codificação bootstring implementada nesta página. Os vetores conhecidos citados acima são verificados contra as cadeias de exemplo desse documento.
• RFC 5890, RFC 5891, RFC 5892 e Unicode UTS #46 — o IDNA2008 e a sua interpretação do lado do navegador, as regras que decidem que caracteres são legais, como as etiquetas são normalizadas e como os alfabetos podem ser misturados.
• RFC 1034 e RFC 1035 — os limites de 63 bytes por etiqueta e de 255 bytes por nome herdados do DNS.
• RFC 3490 e RFC 3491 — a geração mais antiga IDNA2003, substituída pelo IDNA2008. Se um nome se comporta de forma diferente em software antigo, normalmente é por isto.

Nota de âmbito: esta ferramenta faz a conversão RFC 3492 e mais nada. Não é um validador de IDN e não verifica regras de registo, preços ou disponibilidade de um domínio — e como nunca contacta a rede, não lhe pode dizer se um nome existe.

Experimente acima: cole 中文 e carregue em Codificar Texto → Punycode para ver a etiqueta A, ou cole xn--fiq228c e carregue em Descodificar Punycode → Texto para recuperar os caracteres.