Unicode 18.0: 13.000 Caracteres Nuevos Que Ya Están Llegando a Tu Navegador

Cita anual con el caos: Unicode 18

El 16 de septiembre se publicó Unicode 18.0: unos 13.000 caracteres nuevos que llevan el total por encima de los 172.000, incluyendo tres símbolos de moneda nuevos, varios scripts adicionales y la consiguiente actualización de datos de ordenación en CLDR e ICU.

Hace poco más de un año te explicábamos cómo Unicode 16 rompía normalizadores y comparaciones. El patrón se repite, así que en lugar de repetir la teoría vamos a lo práctico: qué revisar esta vez.

---

Lo que realmente te puede romper

1. Contadores de caracteres

Nada nuevo bajo el sol: .length sigue contando unidades UTF-16, no caracteres ni grafemas. Cada emoji nuevo es un surrogate pair más que tu validador de "máximo 50 caracteres" cuenta como 2 — o más si lleva modificadores de tono o ZWJ sequences.

'🫩'.length;      // 2 — unidades UTF-16
[...'🫩'].length; // 1 — code points
new Intl.Segmenter().segment('🫩').containing(0);
// el grapheme cluster real

Si cuentas caracteres "de verdad", Intl.Segmenter es la única respuesta correcta desde hace años.

2. Ordenaciones

'ä'.localeCompare('z') depende de los datos de collation de CLDR/ICU que tenga el runtime del usuario. Unicode 18 actualiza esas tablas vía CLDR 48.x e ICU 78.x: entre un Chrome actualizado y uno que no, dos clientes pueden ordenar la misma lista de forma distinta durante meses.

Si el orden importa —leaderboards, exports deterministas, diffs— fija collation con new Intl.Collator(locale) o hazlo server-side.

3. Regex y clases de caracteres

Con el flag u, p{L} (cualquier letra) depende de la versión de Unicode del engine: los caracteres nuevos de la 18 simplemente no matchean en un runtime con datos antiguos. Validar nombres de usuario, slugs o tokens con p{} significa aceptar que "válido" depende del navegador.

4. Dedupe y normalización

Los caracteres nuevos traen nuevas equivalencias de normalización NFC/NFKC. Si tu lógica de deduplicación normaliza antes de comparar —como hace nuestro eliminador de duplicados— recuerda que dos strings que parecen iguales pueden diferir a nivel de code point según el runtime.

---

El desfase de siempre

Unicode release ≠ soporte inmediato. El consorcio publica el estándar; los engines lo absorben meses después vía ICU. Mientras tanto conviven navegadores que ven el emoji nuevo y navegadores que ven cuadrados — igual que pasó con Unicode 16, 17 y todas las anteriores.

Recomendación práctica:

• Define qué versión de Unicode aceptas en validaciones de contenido de usuario, y documéntalo.
• Usa p{} con flag u, nunca rangos manuales tipo [a-zA-Záéíóúñ] que se quedan obsoletos con cada release.
• Para ordenar, Intl.Collator explícito o sorting en servidor: pruébalo en nuestro ordenador de texto si quieres ver cómo se comporta localeCompare con tus datos reales.
• Para mayúsculas/minúsculas, recuerda que el case folding de Unicode es más rico que toUpperCase() a secas — algo que puedes comprobar en nuestro conversor de mayúsculas.

Unicode 18 no va a romper tu app mañana. Pero la acumulación de "versiones de Unicode distintas por cliente" es exactamente el tipo de bug que aparece en producción un martes y nadie sabe reproducir.