Conversor Punycode

Marketing le entrega dominios cirílicos o con diacríticos mientras los paneles DNS exigen etiquetas xn--. Convierta antes de pegar en el Comprobador DNS o en campos glue del registrador — un solo carácter erróneo produce NXDOMAIN en toda la zona.

Los equipos de seguridad decodifican URLs de phishing desde logs de correo donde los MTA muestran Punycode. Convertir a Unicode revela ataques homógrafos contra marcas. Continúe con WHOIS para la antigüedad del registro y el comprobador de cabeceras HTTP en el host decodificado — la conversión no bloquea malware.

Los desarrolladores que prueban soporte IDN en apps pegan entrada Unicode del usuario, convierten a A-label y luego DIG A/AAAA sobre el resultado. Los navegadores aplican reglas IDNA2008/UTS46; el conversor DN01 se alinea con la codificación Punycode estándar para operaciones DNS.

La documentación y runbooks deben almacenar ambas formas: Unicode para humanos, Punycode para máquinas. Los botones de copia reducen errores de transcripción en tickets frente a reescribir largas cadenas xn-- desde PDFs.

Las políticas ccTLD varían — algunos espacios de nombres restringen scripts. Punycode solo prueba codificación; la aceptación del registro es una cuestión WHOIS/política que DN01 no decide.

Los equipos de localización que preparan landings multilingües verifican que los hreflang usen A-labels consistentes en atributos href mientras muestran Unicode en el texto visible — las discrepancias rompen embudos analíticos cuando DNS y marketing no coinciden en el hostname canónico.

Las listas SAN de certificados del Comprobador SSL pueden mostrar Punycode mientras ejecutivos leen Unicode en diapositivas — convierta en ambos sentidos en el mismo ticket para que los CSR de renovación incluyan cada forma que espera la CA.

Las campañas typosquat registran lookalikes IDN minutos después de noticias de marca — el conversor acelera el triaje pero los playbooks de respuesta aún necesitan legal, abuso del registrador y comunicación al cliente más allá de cualquier herramienta DNS.

Las políticas de visualización de punycode en correo difieren: algunos clientes muestran Unicode, otros xn-- — forme al soporte para convertir en ambos sentidos antes de acusar typos cuando los mensajes citan URLs internacionalizadas.

Las redes de afiliados a veces pasan dominios de tracking Unicode — convierta antes del Comprobador de listas negras o WHOIS para que los sistemas de casos almacenen identificadores Punycode consistentes entre actualizaciones.

Los errores de entrada inválida suelen significar caracteres no permitidos, etiquetas vacías o puntos finales en el campo equivocado. Elimine rutas y esquemas — convierta solo etiquetas de host (no https://).

Las etiquetas de script mixto pueden rechazarse en navegadores aunque Punycode codifique — la política es del lado del cliente. No asuma que codificable equivale a registrable.

El round-trip Unicode → Punycode → Unicode debe coincidir tras normalización. Si no, revise joiners Unicode invisibles o diferencias de normalización homóglifo entre herramientas.

El Comprobador DNS acepta Unicode y normaliza internamente — aun así verifique que la salida codificada coincida con registros del registrador al depurar disputas de delegación.

Las etiquetas Punycode son case-insensitive en DNS — compare siempre formas xn-- en minúsculas al comparar exportaciones WHOIS con la salida del conversor para evitar falsos desajustes.

Los nombres de dominio internacionalizados existen porque las etiquetas DNS eran históricamente ASCII. Punycode es codificación reversible, no cifrado — cualquiera puede decodificar cadenas xn-- con esta herramienta o bibliotecas estándar.

Los ataques homógrafos explotan caracteres visualmente similares entre scripts. Convierta URLs sospechosas, compárelas con Punycode de marca conocida y escale por canales de abuso del registrador con evidencia WHOIS. DN01 no mantiene allowlists de marca ni puntuaciones automáticas de phishing.

Los parsers de correo y URL a veces dejan IDN en Unicode mientras sus herramientas DNS necesitan A-labels — estandarice en Punycode antes de trazas DIG MX en dominios de correo internacionalizados.

El acceso API soporta conversión por lotes en scripts tras registro de token — la UI del navegador sigue siendo mejor para copias rápidas con etiquetas localizadas.

Los fabricantes de navegadores mantienen blocklists de caracteres confusibles — codificable en DN01 no significa renderizable en todo user agent. Pruebe navegadores reales de clientes tras el go-live DNS.

Los motores de búsqueda indexan canónicos IDN — los equipos SEO deben alinear URLs del sitemap con la forma Punycode que rastrean los crawlers, mientras el microcopy de marketing permanece Unicode.

Los deep links móviles con hosts Unicode deben coincidir con el manejo IDN de la app — convierta antes de probar universal links; las reglas de normalización iOS y Android difieren ligeramente de la rigidez Punycode DNS.

WHOIS en Punycode sigue siendo autoritativo en disputas de registro — adjunte la salida del conversor al escalar dominios lookalike a registradores.

El correo internacionalizado (EAI) introduce Unicode en cabeceras de correo — el DNS para MX sigue usando Punycode; convierta dominios de buzón antes de DIG al depurar certificados TLS SMTP en hosts de correo IDN.

Los registros publican tablas IDN por TLD — caracteres válidos en IDN .com pueden diferir de reglas ccTLD; el conversor codifica el Unicode que usted proporciona sin juzgar política del registro.

Los playbooks de respuesta a phishing deben listar el conversor Punycode DN01 junto a WHOIS y Comprobador DNS — los primeros respondedores convierten URLs antes de bloquear en proxy, reduciendo falsos bloqueos a comerciantes IDN legítimos.

Las primas de registro de dominios Unicode difieren por registrador — el conversor no cotiza precios ni comprueba disponibilidad; WHOIS responde registro tras codificar correctamente.

Los proxies empresariales a veces bloquean URLs xn-- como sospechosas — el Unicode decodificado puede pasar revisión de política mientras Punycode dispara filtros; documente ambas formas al solicitar excepciones de firewall para socios IDN legítimos.

Los certificados TLS para sitios IDN listan Punycode en SAN — la salida del Comprobador SSL debe convertirse para informes ejecutivos junto a la verificación del Comprobador DNS de los mismos A-labels.

El conversor DN01 es gratuito para uso manual; los límites de API aplican a pipelines de conversión masiva — la misma honestidad que otras herramientas de red DN01 sin mapas de propagación.

idn2/idnkit en línea de comandos funciona en scripts pero falta en muchas imágenes corporativas Windows. DN01 ofrece conversión bidireccional instantánea con enlaces DNS y WHOIS — no sustituye integración de biblioteca en su código de aplicación.

Los navegadores muestran Unicode en la barra de direcciones mientras copian Punycode — confuso durante triaje de incidentes. Las páginas de conversor dedicadas documentan ambas formas explícitamente para tickets.

No registramos IDN, filtramos marcas ni detectamos todos los combos homógrafos automáticamente. Alcance honesto: codificación/decodificación precisa, ocho idiomas con EN/RU en profundidad completa, guías localizadas en otros idiomas, solo historial local.

No afirmamos validar SSL en nombres convertidos automáticamente — ejecute usted el Comprobador SSL tras confirmar resolución con Comprobador DNS.

Las formas de normalización Unicode (NFC vs NFD) pueden cambiar apariencia sin cambiar significado — si falla el round-trip, inspeccione puntos de código en una herramienta Unicode dedicada; DN01 se centra en Punycode DNS, no educación completa de normalización Unicode.

Los registradores a veces muestran ambas formas en facturas — adjunte salida del conversor a tickets de finanzas para que pagos de renovación coincidan con la delegación técnica que verifica en WHOIS y DIG.

Los servicios de protección de marca monitorizan registros homógrafos — el conversor DN01 ayuda a analistas a decodificar etiquetas sospechosas antes de escalar a registros; no alertamos automáticamente sobre nuevos registros ni sustituimos suites comerciales de monitoreo de marca.

Las matrices de prueba IDN de desarrolladores deben incluir etiquetas de script mixto que su producto debe rechazar — el conversor produce A-labels esperados para pruebas unitarias sin mantener fixtures xn-- a mano en el repo.

Los portales gubernamentales y bancarios a veces exigen scripts IDN específicos — la revisión legal precede al lanzamiento técnico; el conversor no certifica aprobación regulatoria para su vertical.

Las claves de caché CDN pueden usar cabeceras Host Punycode — cuando el purge falla para URLs de marketing Unicode, convierta y purgue la variante A-label; el comprobador de cabeceras HTTP confirma qué cabecera Host vio el edge.