Unicode

Unicode es el estándar universal de codificación de caracteres mantenido por el Consorcio Unicode. Asigna un número único (un “punto de código”) a cada carácter en cada sistema de escritura que ha sido formalmente propuesto y aceptado — actualmente alrededor de 150.000 caracteres en 161 escrituras, incluyendo idiomas modernos, escrituras históricas, símbolos matemáticos, notación técnica y emoji.

Los puntos de código se escriben como U+XXXX (4-6 dígitos hexadecimales). La letra A es U+0041; la i sin punto turca es U+0131; el emoji de cohete es U+1F680.

Unicode en sí no especifica cómo se serializan los puntos de código en bytes — eso es trabajo de las codificaciones. Las tres codificaciones principales:

• UTF-8 — ancho variable de 1-4 bytes por punto de código. Compatible con ASCII. La codificación web dominante.
• UTF-16 — 2 o 4 bytes por punto de código. Usado internamente por Java, strings de JavaScript y Windows.
• UTF-32 — exactamente 4 bytes por punto de código. Simple pero derrochador; rara vez se usa para almacenamiento.

Las herramientas de Convertitive manejan Unicode completo donde corresponde — el codificador Base64 maneja UTF-8 correctamente, el contador de palabras cuenta puntos de código y grafemas, el conversor de mayúsculas respeta las reglas de mayúsculas específicas del turco (el problema de la I con y sin punto).

Punto de código ≠ carácter ≠ grafema — la distinción que rompe cada biblioteca de strings: la letra “é” puede representarse de dos formas en Unicode — como el punto de código único U+00E9 (precompuesto) o como U+0065 (e) seguido de U+0301 (acento agudo combinatorio). Ambos se renderizan de forma idéntica; ambos cuentan como “un carácter” para un humano; uno es un punto de código, el otro son dos. Los emoji son peores: 👨‍👩‍👧 (familia) es una secuencia ZWJ de siete puntos de código pero un grafema. Los recuentos de longitud en JavaScript (str.length) devuelven unidades de código UTF-16, no grafemas — el emoji de familia tiene una longitud de string de 11. Use Intl.Segmenter (navegadores modernos, Node 16+) para recuentos de grafemas precisos.

Formas de normalización Unicode — cuando el texto no coincide consigo mismo: dos strings visualmente idénticos pueden tener diferentes representaciones de bytes debido a la división precompuesto-vs-descompuesto mencionada anteriormente. El Estándar Unicode define cuatro formas de normalización (NFC, NFD, NFKC, NFKD) que canonicalizan esto. NFC (compuesto) es el predeterminado para HTML y la mayoría de los sistemas de archivos; NFD (descompuesto) es el predeterminado de macOS HFS+ y la razón por la que las rutas de archivos a veces parecen idénticas pero se comparan como desiguales entre sistemas. Las búsquedas de igualdad de strings y de índices de búsqueda en bases de datos deben normalizar a NFC al escribir para evitar el bug de “la consulta idéntica no devuelve resultados”. Referencia: El Estándar Unicode, Versión 15.

Ejemplo práctico

Tome el string “café”. Dos representaciones Unicode igualmente válidas: NFC = U+0063 U+0061 U+0066 U+00E9 (4 puntos de código), NFD = U+0063 U+0061 U+0066 U+0065 U+0301 (5 puntos de código, “e” + acento agudo combinatorio). Ambos se renderizan de forma idéntica. Ahora considere cómo se ve cada uno en diferentes recuentos: en UTF-8, NFC son 5 bytes (63 61 66 C3 A9); NFD son 6 bytes (63 61 66 65 CC 81). En JavaScript: "café".length = 4 para NFC, 5 para NFD. Comparar la igualdad sin normalizar: nfc === nfd es false. Ejecute ambos a través de String.prototype.normalize("NFC") primero: se vuelven idénticos. Bug corregido. Esta es la causa raíz exacta de “busqué a José y el registro existe pero no aparece” en bases de datos que almacenan nombres enviados por usuarios desde clientes mixtos de Mac y Windows.

Cuándo y por qué importa

Cada aplicación internacionalizada toca casos extremos de Unicode en algún momento: nombres de usuario con marcas combinatorias, rutas de archivos copiadas entre macOS (NFD) y Linux (NFC), vietnamita con diacríticos apilados, reglas de mayúsculas turcas (la minúscula de “I” es “ı” no “i” — el “problema de la I turca” causó bloqueos reales en iOS en 2018), renderizado de derecha a izquierda en árabe y hebreo, y emoji basados en ZWJ cuyos puntos de código componentes evolucionan más rápido que las actualizaciones de fuentes del teléfono. Las reglas defensivas: normalizar a NFC en la entrada, usar Intl.Collator para ordenación con conciencia local (no el orden de puntos de código de Array.sort), usar Intl.Segmenter para truncación con conciencia de grafemas, y dejar que CLDR (la base de datos de configuraciones regionales de Unicode) impulse el comportamiento específico de la configuración regional en lugar de codificar reglas. Referencia: Informe Técnico Unicode #15 — Formas de Normalización.