Qué hace
Este convertidor traduce nombres de dominio internacionalizados (IDN) entre la forma que lee la gente y la forma que guarda el DNS. Escribe español.example y obtienes xn--espaol-zwa.example; pega un nombre xn-- y obtienes el original en Unicode. Funciona en los dos sentidos mientras escribes, etiqueta por etiqueta, así que en tienda.español.example solo la etiqueta con caracteres que no son ASCII recibe el prefijo xn--.
La codificación es Punycode (RFC 3492), implementada en JavaScript dentro de tu navegador; nada de lo que escribes se envía a ningún lado. Antes de codificar, la herramienta pasa cada etiqueta a minúsculas y aplica la normalización Unicode NFC, así que una ñ precompuesta y una n seguida de una tilde combinable dan el mismo resultado. No aplica todas las reglas de mapeo de IDNA2008 ni de UTS #46, así que una conversión exitosa es una codificación correcta, no una prueba de que un registro vaya a aceptar el nombre.
Junto al resultado ves un desglose de cada etiqueta (forma Unicode, forma ASCII y longitud), una comprobación de los límites del DNS de 63 octetos por etiqueta y 253 para el nombre completo, y un aviso cuando una misma etiqueta mezcla alfabetos, como el latino con el cirílico o el griego.
Cómo usarlo
- Escribe o pega un nombre de dominio, una URL completa o una dirección de correo.
- Mira cómo se actualiza la forma convertida: una entrada en Unicode da la forma
xn--, y una entradaxn--da Unicode. - Revisa el desglose de etiquetas para ver las longitudes, los errores de límite y cualquier aviso de alfabetos mezclados.
- Copia la forma que espera el destino.
Con una URL, solo se convierte el host; el resto queda como lo escribiste. (En la web, los caracteres que no son ASCII en una ruta o en una cadena de consulta se codifican con porcentajes como UTF-8; no se convierten a Punycode.) Con una dirección de correo, solo se convierte la parte después de la @. Una parte local como josé no tiene forma Punycode; para entregarle correo hace falta que todos los servidores del camino admitan SMTPUTF8 (RFC 6531).
Casos de uso
- Revisar un enlace sospechoso. Pega la URL de un mensaje antes de abrirla. Si el host se decodifica en letras de dos alfabetos, o un nombre que parece conocido resulta ser una etiqueta
xn--, míralo con más cuidado antes de hacer clic. - Escribir registros DNS. Los archivos de zona y la mayoría de los paneles de hosting DNS esperan la forma ASCII. Usa exactamente esa cadena en cualquier registro que haga referencia al nombre, incluidos los destinos de CNAME y los hosts de MX.
- Pedir certificados TLS. Las autoridades de certificación y los clientes ACME usan la forma
xn--en los nombres alternativos del sujeto (SAN). Decodificar la lista SAN de un certificado muestra qué nombres Unicode cubre en realidad. - Leer logs. Los logs de servidores web, los encabezados Host de HTTP y los valores SNI de TLS llevan el nombre codificado. Decodifica una entrada desconocida para leerla.
- Configurar el correo de un IDN. Los registros MX, SPF, DKIM y DMARC van todos bajo el nombre
xn--, y una dirección comoinfo@xn--espaol-zwa.examplefunciona con cualquier programa de correo común. - Comprobar la longitud antes de registrar. La codificación alarga bastante algunos alfabetos: la etiqueta tailandesa de siete caracteres ภาษาไทย se convierte en
xn--o3crh0a8bb0k, de 16 octetos, así que una etiqueta que parece corta igual puede pasar de 63.
Los registros DNS y una solicitud de firma de certificado (CSR) para español.example usan el nombre codificado, como cualquier otro nombre de host:
xn--espaol-zwa.example. 3600 IN A 192.0.2.10
www.xn--espaol-zwa.example. 3600 IN CNAME xn--espaol-zwa.example.
xn--espaol-zwa.example. 3600 IN MX 10 mail.xn--espaol-zwa.example.
openssl req -new -key site.key -out site.csr \
-subj "/CN=xn--espaol-zwa.example" \
-addext "subjectAltName=DNS:xn--espaol-zwa.example,DNS:www.xn--espaol-zwa.example"Cómo hace Punycode para meter Unicode en un nombre de host
En sentido estricto, el formato del DNS en la red puede llevar cualquier valor de byte. En la práctica, desde los años ochenta los nombres de host se limitan a letras ASCII, dígitos y guion (la regla LDH de los RFC 952 y RFC 1123), y los resolvedores, los servidores de correo y las comprobaciones de certificados se construyeron sobre esa base. En lugar de cambiarlos, IDNA convierte los nombres dentro de la aplicación, antes de enviar cualquier consulta, en una cadena que ya cumple la regla antigua.
Punycode trabaja en dos etapas. Primero copia en orden los caracteres ASCII de la etiqueta y agrega un guion si había alguno: español da espaol-. Después describe cada carácter que falta con un único número que dice qué punto de código insertar y dónde. La ñ es U+00F1, 241 en decimal. Contando desde 128, con seis letras ya colocadas y, por lo tanto, siete posiciones posibles de inserción, el número es (241 − 128) × 7 + 4 = 795, donde el 4 final significa después de la cuarta letra. Ese número se escribe en una forma de base 36 de longitud variable con a–z y 0–9, con umbrales que se adaptan para que los números pequeños queden cortos. El resultado es zwa, lo que da xn--espaol-zwa.
Decodificar invierte el proceso: todo lo que está antes del último guion se copia, y los caracteres que vienen después se leen como inserciones. Una etiqueta sin letras ASCII, como la tailandesa de arriba, no tiene guion separador después del prefijo. Como la etiqueta codificada es la que viaja por el DNS, el límite de 63 octetos se aplica a ella, no al texto Unicode.
Dominios de imitación y la barra de direcciones
Muchas letras de distintos alfabetos se ven idénticas. La а cirílica (U+0430) es igual a la a latina en la mayoría de las fuentes, así que bаnco.example, con la segunda letra en cirílico, se lee como una palabra común, pero se codifica como xn--bnco-53d.example. Esto es un ataque homográfico.
Los navegadores deciden etiqueta por etiqueta si muestran Unicode o la forma xn--. Las políticas cambian según el fabricante, pero entre las pruebas habituales están si una etiqueta mezcla alfabetos en combinaciones que los nombres reales casi no usan, si está escrita entera con letras que imitan las latinas y si se parece mucho a un dominio conocido. En Firefox, poner network.IDN_show_punycode en true en about:config obliga a mostrar la forma ASCII de todos los nombres.
El aviso de alfabetos mezclados de esta página busca más de un alfabeto dentro de una misma etiqueta. Una etiqueta escrita toda con letras cirílicas parecidas a las latinas no está mezclada, así que un resultado limpio no prueba que un nombre sea legítimo. Compara el nombre decodificado con la dirección que esperabas y, si tienes dudas, escribe la dirección tú mismo.
Preguntas frecuentes
¿Cómo se escribe en Punycode un dominio con ñ?
Pega el nombre en el campo de arriba y verás su forma xn-- al instante: por ejemplo, español.example se convierte en xn--espaol-zwa.example. Primero se copian las letras ASCII de la etiqueta, después va un guion y al final un código corto que indica qué carácter insertar y en qué posición, en este caso la ñ después de la cuarta letra.
¿Por qué mi navegador muestra xn-- en lugar del nombre real?
Los navegadores muestran Unicode solo cuando una etiqueta cumple su política de visualización. Si mezcla alfabetos de formas poco habituales, está escrita entera con caracteres que imitan letras latinas o se parece demasiado a un dominio conocido, el navegador muestra la forma codificada. El sitio carga igual que siempre; pega el nombre aquí para ver qué dice la etiqueta xn-- una vez decodificada.
¿Es peligroso un dominio que empieza con xn--?
No. El prefijo solo significa que la etiqueta se codificó a partir de Unicode, y muchos sitios legítimos en alemán, chino, árabe, ruso y otros idiomas lo usan. Lo que importa es el texto decodificado. Si dice el nombre que esperabas, en un solo alfabeto, no tiene nada de raro. Si imita un nombre conocido con letras prestadas de otro alfabeto, trata el enlace con precaución.
¿Por qué otro convertidor da un resultado distinto con la ß alemana?
El procesamiento IDNA2003, más antiguo, y el modo de transición de UTS #46 convierten la ß en ss y la sigma final ς en σ antes de codificar, así que straße queda como strasse a secas. IDNA2008 conserva esos caracteres tal como están. Pasar a minúsculas y aplicar NFC, que son los pasos que hace esta herramienta, deja la ß sin cambios, así que aquí faß se codifica como xn--fa-hia. Comprueba qué forma esperan tu registro y el software de tus usuarios.
¿Puedo poner Unicode directamente en un archivo de zona o en un certificado?
Usa la forma xn-- en los dos. Un certificado guarda los nombres DNS en un campo que solo admite ASCII, así que las autoridades de certificación esperan la forma codificada en la lista de nombres alternativos del sujeto (SAN). En un archivo de zona, un nombre escrito con bytes UTF-8 tal cual no coincidiría con las consultas xn-- que envían los resolvedores y los navegadores, así que el registro nunca se encontraría.
¿Qué pasa con la parte antes de la @ en un correo electrónico?
Queda exactamente como la escribiste, porque Punycode solo se aplica a nombres de dominio. Si la parte local tiene caracteres que no son ASCII, como josé, la entrega depende de la extensión SMTPUTF8 definida en el RFC 6531. Todos los servidores del camino tienen que admitirla; no hay una alternativa ASCII comparable a Punycode, así que un mensaje a esa dirección normalmente rebota donde falta el soporte.
¿Por qué un registro podría rechazar un nombre que esta herramienta convierte sin problemas?
La herramienta hace una codificación correcta según el RFC 3492 después de pasar a minúsculas y normalizar con NFC, pero no implementa todas las reglas de IDNA2008 ni de UTS #46. IDNA2008 prohíbe la mayoría de los símbolos y tiene reglas de contexto para caracteres como los de unión (joiners), y cada registro publica su propia tabla de caracteres permitidos para su dominio de nivel superior. Un nombre puede codificarse bien aquí y aun así no pasar esas comprobaciones.
¿Lo que escribo se envía a algún servidor?
No. La conversión, la comprobación de longitud y el aviso de alfabetos mezclados se ejecutan en JavaScript dentro de tu navegador, así que los nombres, las URL y las direcciones de correo que pegas nunca salen de tu dispositivo. Además, iseeu.cc no guarda registros de direcciones IP ni de consultas, no tiene base de datos de visitantes, no usa cookies y no muestra anuncios.
Una conversión limpia muestra que el nombre está bien codificado, no que se pueda registrar ni que sea seguro. Los registros aplican sus propias reglas de caracteres, y los nombres de imitación pueden evitar mezclar alfabetos.