Convertidor de Normalización Unicode | Vista paralela de las cuatro formas

Pega cualquier cadena y observa cómo se normaliza simultáneamente a NFC, NFD, NFKC y NFKD, con el recuento de caracteres, los bytes UTF-8 y la diferencia de bytes respecto al original para cada forma. La herramienta está pensada para personas que aprenden i18n a fondo: ingeniería backend, equipos de búsqueda, y cualquiera que necesite ver exactamente qué hace cada normalización antes de decidir qué guardar en base de datos.

💡 Sobre esta herramienta

La normalización Unicode existe porque el mismo carácter "visible" puede escribirse de varias formas diferentes en bytes. La é puede ser un único code point U+00E9 (forma precompuesta) o dos code points, e (U+0065) más una tilde aguda combinante (U+0301) (forma descompuesta). Las dos se renderizan idénticas en pantalla, pero === en JavaScript, WHERE en SQL y equals() en Java devuelven false cuando se comparan entre sí. Ese es el origen real del 90% de los bugs "el nombre existe pero no lo encuentro".

Esta herramienta toma tu texto, lo pasa por String.prototype.normalize() en las cuatro formas oficiales del estándar Unicode, y las muestra en paralelo: el texto resultante, el número de caracteres (contados como code points perceptibles), el tamaño en bytes UTF-8 y la variación respecto al original. El indicador "forma de entrada" te dice además a cuál de las cuatro formas pertenece ya tu texto, lo cual ahorra una conversión innecesaria cuando el origen ya está en la forma correcta.

NFKC y NFKD son las descomposiciones de compatibilidad: hacen cosas como convertir letras latinas de ancho completo en sus equivalentes ASCII, expandir ligaduras tipográficas (fi → fi) y reescribir números en círculo (① → 1). Esto es lo que quieres para una clave de búsqueda o un hash de deduplicación. No es lo que quieres para almacenar el nombre real de una persona.

🧐 Preguntas Frecuentes

Q. ¿Qué forma debería usar para almacenar texto? A. NFC, casi siempre. El W3C, en su documento "Character Model for the World Wide Web", recomienda NFC para HTML, URLs, atributos del DOM y cualquier texto que cruce un límite de proceso. NFD se usa puntualmente como representación intermedia (por ejemplo, para quitar acentos antes de una búsqueda fuzzy), pero la canonical de almacenamiento debe ser NFC.

Q. ¿Es cierto que macOS guarda los nombres de archivo en NFD? A. Era cierto en HFS+ (con una variante específica llamada "NFD with reserved range"). APFS, que es el sistema de archivos por defecto en cualquier Mac fabricado desde 2017, ya no normaliza: guarda exactamente los bytes que la aplicación le pase. Por tanto "macOS = NFD" es una media verdad. Lo que sí sigue pasando es que archivos viejos provenientes de Time Machine, de rsync sobre HFS+, o de discos externos formateados con HFS+, llegan en NFD y rompen comparaciones en Linux. Esta herramienta sirve precisamente para confirmar en qué forma está realmente el texto que tienes en mano.

Q. ¿Cuándo conviene usar NFKC? A. Para construir claves de búsqueda o hashes de comparación donde la tipografía no importa. Wikipedia normaliza títulos con NFKC + casefold(), los motores full-text como Elasticsearch normalizan al indexar, y los sistemas de autenticación que comparan nombres de usuario suelen aplicar NFKC para evitar confusión entre Admin con A latina y Аdmin con А cirílica. La regla práctica: NFKC para la clave de búsqueda, NFC (o los bytes originales) para el valor.

Q. ¿Qué diferencia hay entre canónica (NFC/NFD) y compatibilidad (NFKC/NFKD)? A. Las normalizaciones canónicas son reversibles: NFC(NFD(s)) === s. No pierden información ni cambian semántica. Las de compatibilidad descartan distinciones tipográficas que el estándar considera "secundarias": ancho completo vs medio, superíndices vs base, ligaduras vs caracteres separados. Si vas a aplicar NFKC, hazlo a la clave de búsqueda, no al texto que el usuario verá.

Q. ¿Por qué algunos caracteres tienen dos bytes en NFC y tres en NFD? A. Porque la forma descompuesta usa más code points, y cada code point ocupa entre 1 y 4 bytes en UTF-8. Una á precompuesta es U+00E1 (2 bytes en UTF-8). La misma á descompuesta es U+0061 (1 byte) más U+0301 (2 bytes), total 3 bytes. La columna "delta" en la tabla refleja esta diferencia directamente.

Q. ¿Cómo manejan los emojis las cuatro formas? A. Los emojis "modernos" (familia, banderas, modificadores de tono de piel) son secuencias ZWJ o pares de indicadores regionales, no code points únicos, por lo que ninguna de las cuatro normalizaciones los modifica. Lo que sí cambia con NFKC son ciertos caracteres matemáticos decorativos (𝒜, 𝓗) que se aplanan a ASCII normal — útil para deduplicación, dañino si los guardas como nombre de marca.

Q. ¿Funciona con textos largos? A. Sí. normalize() es nativo del motor JavaScript (ICU debajo) y procesa megabytes en milisegundos. El cuello de botella suele ser el área de texto del navegador, no la normalización. Para depurar logs muy grandes, recorta una muestra representativa y úsala como entrada.

📚 Datos Curiosos

Una decisión técnica sorprendentemente importante de la historia reciente de la web fue cómo IDN (Internationalized Domain Names) trató la normalización de compatibilidad. La primera versión del estándar, IDNA2003, exigía aplicar NFKC y casefolding a todo nombre de dominio (un proceso llamado "Nameprep"). Esto significaba que ①.example resolvía a 1.example, y casi todos los caracteres con apariencia similar a ASCII colapsaban entre sí. Resultó ser un desastre de seguridad: los ataques de homógrafos se volvieron triviales. La revisión IDNA2008 eliminó Nameprep por completo, obligando a que los nombres de host se almacenen en NFC y rechazando cualquier etiqueta que NFKC hubiera modificado. La barra de direcciones del navegador es hoy una de las pocas superficies del software que explícitamente prohíbe la normalización de compatibilidad.

En español hay una sutileza interesante: la ñ precompuesta (U+00F1) y la descompuesta n + tilde combinante (U+0303) suelen llegar mezcladas en bases de datos antiguas, porque algunos sistemas Mac de los 90 grababan en NFD y muchas migraciones a UTF-8 desde Latin-1 no normalizaron el resultado. El síntoma típico es una consulta WHERE nombre LIKE '%Núñez%' que devuelve cero filas aun cuando "ves" el apellido en los datos. Pasar la cadena de búsqueda y los datos por la misma forma (NFC, normalmente) antes de comparar es la solución estándar — y exactamente lo que esta herramienta te ayuda a confirmar en cinco segundos.