UTF-8

UTF-8 (Unicode Transformation Format, 8 bits) es una codificación de ancho variable para caracteres Unicode. Cada punto de código se codifica en 1-4 bytes dependiendo de su valor: los caracteres ASCII (U+0000 a U+007F) ocupan un byte; las extensiones latinas comunes, el griego y el cirílico, dos; los ideogramas CJK, tres; los emoji y los scripts raros, cuatro.

Diseñado por Ken Thompson y Rob Pike en 1992, principalmente para Plan 9. Propiedades clave:

• Compatible con ASCII. El texto ASCII puro es UTF-8 válido byte a byte.
• Autosincronizante. Si un flujo de datos se corrompe en medio de un carácter, el decodificador puede encontrar el siguiente límite de carácter sin retroceder.
• Sin problema de orden de bytes. Los bytes se procesan de izquierda a derecha; no hay distinción entre big-endian y little-endian.
• Compacto para scripts latinos, menos compacto que UTF-16 para contenido con predominio de CJK (3 bytes por carácter frente a 2).

UTF-8 es la codificación dominante en la web — más del 98 % de las páginas en 2024. Es el predeterminado para HTML5, JSON (donde la especificación RFC 8259 exige UTF-8) y prácticamente todos los protocolos modernos. Las codificaciones antiguas (Windows-1252, ISO-8859-1, Shift-JIS) sobreviven en sistemas heredados, pero deben convertirse al ingresar a cualquier pila moderna.

La controversia del BOM (marca de orden de bytes): UTF-16 y UTF-32 usan un BOM de 2 o 4 bytes al inicio de un archivo para declarar el orden de bytes, pero UTF-8 no tiene orden de bytes que marcar. Las herramientas de Microsoft habitualmente añaden un BOM UTF-8 de 3 bytes (EF BB BF) de todas formas, mientras que las herramientas de Unix típicamente no lo hacen. El resultado: los scripts de shell guardados desde Notepad fallan, las importaciones de CSV muestran basura invisible en la primera celda y los analizadores YAML/JSON rechazan el archivo. El estándar Unicode tolera pero no exige un BOM UTF-8; la recomendación moderna es “no añadir uno.” Si recibes un archivo con uno, elimínalo al leerlo.

Longitud de cadena frente a longitud en bytes — la trampa siempre relevante: en la mayoría de los lenguajes, "hello".length devuelve 5 (caracteres) pero Buffer.byteLength("hello", "utf8") devuelve 5 (bytes, iguales para ASCII). Para "café", la longitud en caracteres es 4 pero la longitud en bytes es 5 (la é ocupa 2 bytes). Para "🎉", la longitud en caracteres en JavaScript es 2 (par sustituto), pero la longitud en bytes es 4 y la longitud en grafemas es 1. Truncar cadenas UTF-8 por número de bytes sin conciencia de grafemas produce regularmente mojibake — la solución estándar es usar la API Intl.Segmenter (navegadores modernos) o el paquete npm graphemer. Referencia: RFC 3629 — UTF-8, un formato de transformación de ISO 10646.

Ejemplo práctico

Codifica la cadena “A€🎉”. El punto de código de cada carácter y su secuencia de bytes UTF-8: A (U+0041) → 1 byte 0x41. € (U+20AC) → 3 bytes 0xE2 0x82 0xAC (los bits altos codifican la longitud: 1110xxxx 10xxxxxx 10xxxxxx). 🎉 (U+1F389) → 4 bytes 0xF0 0x9F 0x8E 0x89. Total: 8 bytes para 3 caracteres. En una columna de base de datos declarada como VARCHAR(10) con semántica de caracteres UTF-8 (PostgreSQL moderno, MySQL con utf8mb4), cabe perfectamente. En una columna de bytes fijos declarada como VARCHAR(10) BYTES (MySQL antiguo con utf8, que en realidad estaba limitado a 3 bytes), la codificación de 4 bytes del emoji no cabe en absoluto — el modo de fallo canónico de “no se pueden almacenar emoji en MySQL”. La solución en MySQL desde 5.5.3 es usar utf8mb4 como conjunto de caracteres de la columna y la conexión.

Cuándo y por qué importa

Cada byte que procesas en la web moderna es probablemente UTF-8, pero varias capas aún lo gestionan mal. Las solicitudes HTTP sin un Content-Type: text/...; charset=utf-8 explícito pueden usar ISO-8859-1 de forma predeterminada en proxies más antiguos; los trabajos ETL de mainframe heredados entregan archivos EBCDIC que deben transcodificarse al ingresar; la salida de la consola de Windows usa de forma predeterminada la página de códigos del sistema (CP-1252 en la mayoría de las instalaciones en inglés de EE. UU.) y corrompe el texto canalizado sin un chcp 65001 previo. La práctica defensiva: declarar UTF-8 explícitamente en todas partes (HTML <meta charset="utf-8">, encabezados HTTP, pragmas de codificación de archivos, conjuntos de caracteres de conexión a bases de datos) y validar cualquier byte entrante contra la gramática UTF-8 — las secuencias de bytes inválidas son una señal fiable de una discrepancia de charset aguas arriba. Referencia: Estándar de codificación WHATWG.