Conversor Punycode / IDN

Así que Punycode no es un idioma, una fuente ni un código de país — es una traducción entre dos escrituras del mismo nombre. La escritura Unicode se llama etiqueta U (中文.com, bücher.de), la escritura ASCII se llama etiqueta A (xn--fiq228c.com, xn--bcher-kva.de), y la idea completa de meter nombres internacionales en el DNS se llama IDN (nombres de dominio internacionalizados) o IDNA, el conjunto de reglas construido sobre ella.

Existe porque el DNS se diseñó a principios de los años ochenta en torno a un alfabeto deliberadamente diminuto. Un nombre de host que viaja por el DNS, a un archivo de zona, a la caché de un resolutor, a una línea de registro o a un certificado TLS debe ser ASCII puro — el formato de red simplemente no tiene campo para nada más. Punycode es la vía de escape: permite que un nombre que no es ASCII viaje como si lo fuera, y que el extremo receptor reconstruya exactamente los caracteres originales. Por eso un dominio chino funciona en un navegador, y por eso xn-- es la única cadena que verá en cada lugar donde no se puede enviar la escritura Unicode.

Lo que escribe (etiqueta U)	Lo que recibe el DNS (etiqueta A)	Qué significa
中文.com	xn--fiq228c.com	Las palabras chinas para «idioma chino»
中国	xn--fiqs8s	«China» en chino
例え.jp	xn--r8jz45g.jp	ejemplos en japonés
bücher.de	xn--bcher-kva.de	alemán bücher, «libros»
münchen.de	xn--mnchen-3ya.de	Múnich
😂.com	xn--e28h.com	Una etiqueta con emoji — legal en la codificación, no en la mayoría de los registros

Una comparación de longitudes que conviene recordar: 中文 ocupa 2 caracteres y 6 bytes en UTF-8, pero xn--fiq228c son 11 bytes ASCII. Punycode normalmente alarga un nombre, nunca lo acorta.

Tome bücher y observe los tres pasos. El motor se llama bootstring, y todo el algoritmo son solo unas pocas decenas de líneas de código (puede leerlo en el script de esta página).

1. Copie los caracteres simples al principio. Cada carácter ASCII básico se copia en su orden original y se mantiene legible: bücher → bcher. Como se copió algo y quedó algo por codificar, se añade un único - como frontera: bcher-.
2. Escriba el resto como números en base 36. Los caracteres restantes se tratan en orden creciente de punto de código, y cada uno se escribe como un número de longitud variable en base 36, donde a=0 … z=25 y 0=26 … 9=35. Para bücher el carácter sobrante ü se convierte en los dígitos kva.
3. Ponga el prefijo. La parte codificada añadida a la parte copiada da bcher-kva, y en contexto de dominio se escribe xn--bcher-kva.

El truco que hace este método ingenioso es lo que contienen esos números en base 36: no el carácter en sí, sino un delta — a qué distancia está el carácter del punto de código codificado anteriormente, más dónde va dentro de la cadena. El codificador recorre los puntos de código en orden ascendente y cada grupo de dígitos describe una posición y una distancia. Tras cada carácter se ajusta un número compartido llamado sesgo para que el siguiente número necesite el menor número de dígitos posible.

Dos consecuencias que puede comprobar por sí mismo arriba:

• Los caracteres parecidos salen baratos. Como solo se guardan distancias, una serie del mismo carácter cuesta casi nada: 30 copias de 中 se codifican como xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, solo 36 bytes. Una mezcla medida de caracteres chinos no relacionados pero cercanos caben en unos 41 caracteres dentro de una etiqueta legal de 63 bytes, y un único carácter repetido llega a 57.
• Los caracteres dispersos salen caros. Un carácter alejado del anterior necesita un número delta más largo. El texto chino con muchos caracteres distintos cuesta normalmente de 2 a 3 letras extra por carácter, por eso una etiqueta CJK se queda sin espacio en algún punto entre 20 y 40 caracteres aunque el límite de la etiqueta sea de 63 bytes.

Decodificar es la misma receta al revés: copie el prefijo ASCII, lea los dígitos, convierta los deltas de nuevo en puntos de código e inserte cada carácter nuevo en la cadena en la posición que codifica el delta. En el bootstring solo existen dígitos en minúscula, por eso una letra mayúscula dentro de una parte codificada se rechaza en lugar de adivinarse — el DNS no distingue mayúsculas, así que permitir ambas haría ambiguas dos escrituras distintas.

• En la barra de direcciones. Los navegadores pueden mostrar xn--fiq228c.com en lugar de 中文.com. Es el mismo sitio. Algunos navegadores muestran a propósito la forma Punycode cuando un nombre mezcla escrituras, justamente para que un carácter parecido (la а cirílica frente a la a latina) no pueda esconderse en la URL.
• En el propio DNS. Los archivos de zona, las respuestas de dig / nslookup / DNS sobre HTTPS y los registros del resolutor solo contienen nunca la forma xn--; el Unicode simple se rechaza o se corrompe en silencio.
• En certificados TLS. El nombre alternativo del sujeto de un dominio internacional se guarda como etiqueta A (DNS:xn--fiq228c.com), así que un certificado que no parece el nombre que escribió es normal, no una discrepancia.
• En configuración y herramientas. Las entradas server_name del servidor web / hosts virtuales, los dominios de cookies, los paneles de alojamiento y CDN, los dominios de correo, las claves de API vinculadas a un dominio y las claves de base de datos son todos más seguros en forma de etiqueta A.
• En pruebas y flujos de datos. Algunas bibliotecas pasan el Unicode directamente al resolutor y fallan; convertir antes a Punycode es la solución estándar. Como la asignación es canónica — una etiqueta Unicode corresponde exactamente a una etiqueta A — la forma xn-- es también un identificador estable para registros y búsquedas.

Punycode es una escritura reversible, nada más. No es cifrado ni una función de seguridad: cualquiera puede decodificarlo con la herramienta de arriba, así que una etiqueta xn-- dice «esto fue codificado» y nada sobre quién es su dueño. Tampoco es compresión — normalmente hace el texto más largo, como muestra el ejemplo de 6 a 11 bytes de arriba. Y no es lo mismo que las otras formas en que el Unicode viaja por internet; esas resuelven capas distintas del problema.

Esquema	Convierte qué en qué	Dónde se usa	中文 se convierte en
Punycode (RFC 3492)	Una etiqueta de dominio Unicode en letras y dígitos ASCII	Solo etiquetas de dominio internacionales	xn--fiq228c
UTF-8 (RFC 3629)	Puntos de código en bytes	Todos los archivos y las peticiones web	E4 B8 AD E6 96 87 (6 bytes)
Codificación porcentual (RFC 3986)	Bytes en escapes %XX	Rutas de URL, cadenas de consulta, cuerpos de formulario	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Bytes en 64 caracteres ASCII	Binario dentro de texto, JSON, correo electrónico, URI de datos	5Lit5paH
Entidades HTML	Puntos de código en referencias con nombre o numéricas	Código fuente HTML y XML	中文
Escapes Unicode	Puntos de código en \uXXXX	Literales de cadena en código fuente y JSON	\u4e2d\u6587

La conclusión práctica: Punycode se aplica a las etiquetas de dominio de una URL, no a la URL completa. La ruta y la cadena de consulta son un problema distinto y usan codificación porcentual (vea los Codificadores de URL).

• Los límites de tamaño vienen del DNS, no de Punycode. Una etiqueta puede tener como máximo 63 bytes y un nombre completo como máximo 255 bytes (RFC 1034 / 1035). Como una etiqueta A es ASCII puro, el número de bytes es igual al número de caracteres, y cada carácter no ASCII gasta parte de ese presupuesto — aproximadamente 1 carácter de presupuesto por cada 1 a 4 letras Punycode.
• Punycode convierte cualquier cosa; los registros solo permiten algunas. Las reglas de IDNA están por encima y restringen qué puntos de código pueden registrarse en absoluto — las mayúsculas, los espacios, la puntuación como ! y las banderas no son legales en un dominio real. Esta página hace la conversión de la RFC 3492, así que codificará alegremente un texto que un registro rechazaría.
• Mantenga una sola escritura. IDNA desaconseja mezclar escrituras dentro de una misma etiqueta precisamente por los ataques de caracteres parecidos. Un nombre puede codificarse y aun así no ser utilizable, o ser utilizable pero estar en lista negra en los navegadores.
• No codifique dos veces. xn-- seguido de texto ya codificado no es válido, y una etiqueta que es ASCII puro nunca cambia — no hay nada que codificar, así que no se añade prefijo.
• Un punto final es correcto. 例え.jp. es un nombre completo y se conserva la etiqueta vacía del final; las etiquetas vacías en medio no son nombres de host válidos.

«¿Por qué mi dominio chino aparece como xn--fiq228c.com en la barra de direcciones?»

Porque el navegador decidió mostrar la etiqueta A. El sitio es idéntico; use la dirección Decodificar de esta página para ver la forma Unicode, o codifique la forma Unicode para comprobar que ambas escrituras coinciden.

«¿Tengo que cambiar mis registros DNS, mi certificado o mi alojamiento?»

No. Mantenga la etiqueta A xn-- en todos los lugares donde una máquina lee el nombre (DNS, certificados, configuraciones) y use la forma Unicode solo donde lo lee una persona.

«¿Por qué el resultado es más largo que lo que escribí?»

Porque la codificación no transporta los caracteres en sí, sino distancias en base 36, y el alfabeto de 36 caracteres tiene que escribir números que pueden ser grandes. El crecimiento es lo esperado, no un error.

«¿Por qué la decodificación dice «letra mayúscula»?»

Porque los dígitos del bootstring se definen solo en minúscula (a-z, 0-9). Una A-Z mayúscula tras el último guion es ambigua una vez que se tiene en cuenta que el DNS no distingue mayúsculas, así que se informa en lugar de adivinarse en silencio.

«¿Se aplica Punycode a la parte anterior a la @ de una dirección de correo?»

Solo la parte de dominio es un nombre DNS y puede ser Punycode. La parte local la gestiona el sistema de correo, no el DNS, así que esta codificación no se le aplica.

«¿Pueden dos nombres Unicode distintos producir la misma etiqueta A?»

No. La codificación es inyectiva: secuencias de puntos de código distintas siempre producen bootstrings distintos, así que decodificar xn--fiq228c devuelve exactamente 中文 y nada más. Lo que sí puede coincidir es la apariencia — caracteres distintos que se parecen — y eso es una propiedad del repertorio Unicode, no de la codificación.

• RFC 3492 — Punycode, la codificación bootstring implementada en esta página. Los vectores conocidos citados arriba se comprueban con las cadenas de muestra de ese documento.
• RFC 5890, RFC 5891, RFC 5892 y Unicode UTS #46 — IDNA2008 y su interpretación en el navegador, las reglas que deciden qué caracteres son legales, cómo se normalizan las etiquetas y cómo pueden mezclarse las escrituras.
• RFC 1034 y RFC 1035 — los límites de 63 bytes por etiqueta y 255 bytes por nombre heredados del DNS.
• RFC 3490 y RFC 3491 — la generación anterior IDNA2003, sustituida por IDNA2008. Si un nombre se comporta de otra manera en software antiguo, normalmente es por esto.

Nota de alcance: esta herramienta realiza únicamente la conversión de la RFC 3492 y nada más. No es un validador de IDN y no comprueba las reglas de registro, el precio ni la disponibilidad de un dominio — y como nunca contacta con la red, no puede decirle si un nombre existe.

Pruébelo arriba: pegue 中文 y pulse Codificar texto → Punycode para ver la etiqueta A, o pegue xn--fiq228c y pulse Decodificar Punycode → texto para recuperar los caracteres.