UTF-8

UTF-8 (8-bit Unicode Transformation Format) es un formato de codificación de caracteres Unicode e ISO 10646 utilizando símbolos de longitud variable. UTF-8 fue creado por Robert C. Pike y Kenneth L. Thompson. Está definido como estándar por la RFC 3629 de la Internet Engineering Task Force (IETF).^[1] Actualmente es una de las tres posibilidades de codificación reconocidas por Unicode y lenguajes web, o cuatro en ISO 10646.

Sus características principales son:

• Es capaz de representar cualquier carácter Unicode.
• Usa símbolos de longitud variable (de 1 a 4 bytes por carácter Unicode).
• Incluye la especificación US-ASCII de 7 bits, por lo que cualquier mensaje ASCII se representa sin cambios.
• Incluye sincronía. Es posible determinar el inicio de cada símbolo sin reiniciar la lectura desde el principio de la comunicación.
• No superposición. Los conjuntos de valores que puede tomar cada byte de un caracter multibyte, son disjuntos, por lo que no es posible confundirlos entre sí.

Estas características lo hacen atractivo en la codificación de correos electrónicos y páginas web.^{[2] [3]} El IETF requiere que todos los protocolos de Internet indiquen qué codificación utilizan para los textos y que UTF-8 sea una de las codificaciones contempladas.^[4] El Internet Mail Consortium (IMC) recomienda que todos los programas de correo electrónico sean capaces de crear y mostrar mensajes codificados utilizando UTF-8.^[5]

Historia

UTF-8 fue ideado por Kenneth L. Thompson bajo los criterios de diseño de Robert C. Pike el 2 de septiembre de 1992. Ambos lo implementaron e implantaron en su sistema operativo Plan 9 from Bell Labs. Posteriormente fue oficialmente presentado en la conferencia USENIX en San Diego en enero de 1993. Fue promovido a estándar con el patrocinio de X/Open Joint Internationalization Group (XOJIG) y durante el proceso recibió diferentes nombres como FSS/UTF y UTF-2.^[1]

Descripción

UTF-8 divide los caracteres Unicode en varios grupos, en función del número de bytes necesarios para codificarlos. El número de bytes depende exclusivamente del código de carácter asignado por Unicode y del número de bytes necesario para representarlo. La distribución de caracteres es la siguiente:

• Caracteres codificados con un byte: Los incluidos en US-ASCII, un total de 128 caracteres.
• Caracteres codificados con dos bytes: Un total de 1920 caracteres. Este grupo incluye los caracteres romances más signos diacríticos, y los alfabetos griego, cirílico, copto, armenio, hebreo, árabe, siríaco y Thaana entre otros.
• Caracteres codificados con tres bytes: Caracteres del plano básico multilingüe de Unicode, que unido al grupo anterior, incluye la práctica totalidad de caracteres de uso común, entre ellos los caracteres del grupo CJK: Chino, japonés y coreano.
• Caracteres codificados con cuatro bytes: Caracteres del plano suplementario multilingüe. Símbolos matemáticos y alfabetos clásicos para uso principalmente académico: Lineal B silábico e ideográfico, alfabeto persa, fenicio... Y el plano suplementario ideográfico: caracteres Han de uso poco común.

Una propiedad importante de la codificación es que los bits más significativos del primer byte de una secuencia multi-byte determinan la longitud de la secuencia. Estos bits más significativos 110 para secuencias de dos bytes; 1110 para secuencias de tres bytes, etc. Estos bits además proporcionan la información de sincronía que permite identificar el inicio de un símbolo.

La tabla siguiente muestra la forma en que se codifican los caracteres. Los valores fijos al principio de cada byte garantizan el cumplimento del principio de no superposición, pues son distintos en función de la posición del byte en la cadena.

Siguiendo el esquema anterior, sería posible incrementar el tamaño máximo del símbolo de 4 a 6 bytes. La definición de UTF-8 dada por Unicode no admite esta posibilidad que sí es admitida por ISO/IEC.^[6]

Ejemplo: Codificación del carácter Unicode ñ.

Veamos, a modo de ejemplo, cómo se codifica en UTF-8 el carácter eñe ('ñ'), que se representa en Unicode como 0x00F1:

• Su valor se sitúa en el rango de 0x0080 a 0x07FF. Una consulta a la tabla permite ver que debe ser codificado usando 2 bytes, con el formato 110xxxxx 10xxxxxx.
• El valor hexadecimal 0x00F1 es equivalente al binario (0000-0)000-1111-0001 (los primeros 5 bits se ignoran, ya que no son necesarios para representar valores en el rango especificado).
• Los 11 bits requeridos se sitúan ordenados en la posición marcada por las equis: 11000011 10110001.
• El resultado final son dos bytes con los valores hexadecimales 0xC3 0xB1. Ese es el código de la letra eñe en UTF-8.

Para recuperar el punto de código original se realiza el proceso inverso, descomponiendo las secuencias de bits en sus componentes y tomando solo los bits necesarios.

Errores de codificación

Las normas de codificación establecen, por lo tanto, límites a las cadenas que se pueden formar. Según la norma, un intérprete de cadenas debe rechazar como inválidos, y no tratar de interpretar, las caracteres mal formados. Un intérprete de cadenas UTF-8 puede cancelar el proceso señalando un error, omitir los caracteres mal formados o reemplazarlos por un carácter U+FFFD (REPLACEMENT CHARACTER).

Los siguientes son errores de codificación:

• Secuencias truncadas, cuando un carácter de inicio multi-byte no está seguido por suficientes bytes.
• Bytes de datos (comenzados por 10) sin el correspondiente inicio de carácter.
• Caracteres anómalamente largos: Por ejemplo, representar con 2 bytes un carácter del rango ASCII de un byte. Los bytes 0xC0, 0xC1 no se admiten.
• Bytes de inicio de carácter que especifican un largo anómalo de 5 o 6 bytes. Los bytes 0xF8 a 0xFD no se admiten.
• Caracteres fuera del rango Unicode: Los bytes 0xF5 y 0xF7 no se admiten.
• Caracteres inválidos. Los caracteres en el rango de pares subrogados de UTF-16, con código de 0xD800 a 0xDFFF, no son caracteres reales y no deben codificarse en UTF-8.

Byte order mark (BOM)

Cuando se sitúa al inicio de una cadena UTF-8, un carácter 0xFEFF, codificado en UTF-8 como 0xEF,0xBB,0xBF, se denomina Byte Order Mark (BOM) e identifica el contenido como una cadena de caracteres Unicode. Cuando este carácter se encuentra en otro lugar de la cadena debe ser interpretado con su significado original Unicode (ZWNBSP). Al ser UTF-8 una codificación en la que la unidad de información es el byte, no tiene la utilidad que sí tiene en UTF-16 y UTF-32 de identificar el orden de bytes en una palabra (endianness).

La especificación no recomienda o desaconseja la utilización de BOM, aunque sí desaconseja eliminarlo si existe como medida de seguridad, previendo errores en aplicaciones de firma digital, etc. También advierte que debe ser eliminado en operaciones de concatenación para impedir que se mantenga en posiciones no iniciales.

Derivaciones de UTF-8

Las siguientes normas de codificación presentan diferencias con la especificación UTF-8 y son, por lo tanto, incompatibles con ella.

CESU-8

Esta implementación realiza una traducción directa de la cadena de caracteres representada con UTF-16 en lugar de codificar los puntos de código Unicode. El resultado es codificaciones diferentes para caracteres Unicode con código superior a 0xFFFF.^[1] Oracle, a partir de la versión 8, implementa CESU-8 con el alias UTF8 y, a partir de la versión 9, UTF-8 estándar con otro alias.^[7] Java y Tcl utilizan esta codificación.^{[cita requerida]}

UTF-8 modificado

Con UTF-8 modificado, el carácter nulo se codifica como 0xC080 en lugar de 0x00. De esta forma un texto que contenga el carácter nulo no contendrá el byte 0x00 y, por lo tanto, no se truncará en lenguajes como C que consideran 0x00 un final de cadena.

Todas las implementaciones conocidas de UTF-8 modificado cumplen, además, con CESU-8^{[cita requerida]}.

Ventajas y desventajas

Ventajas

• UTF-8 permite codificar cualquier carácter Unicode.^[1]
• Fácil identificación. Es posible identificar claramente una muestra de datos como UTF-8 mediante un sencillo algoritmo. La probabilidad de una identificación correcta aumenta con el tamaño de la muestra.^[1]
• UTF-8 ahorrará espacio de almacenamiento para textos en caracteres latinos, donde los caracteres incluidos en US-ASCII son comunes, cuando se compara con otros formatos como UTF-16.^[8]
• Una secuencia de bytes para un carácter jamás será parte de una secuencia más larga de otro carácter por contener información de sincronización.
• Al ser compatible con US-ASCII se puede utilizar en shell scripts y en llamadas a procedimientos que esperan strings terminados en bytes nulos.
• No es necesario el uso del Byte order mask ya que UTF-8 trabaja con bytes y no palabras.

Desventajas

• UTF-8 utiliza símbolos de longitud variable; eso significa que diferentes caracteres pueden codificarse con distinto número de bytes. Es necesario recorrer la cadena desde el inicio para encontrar el carácter que ocupa una determinada posición.

• Los caracteres ideográficos usan 3 bytes en UTF-8, pero sólo 2 en UTF-16. Así, los textos chinos, japoneses o coreanos ocupan más espacio cuando se representan en UTF-8.^[8]

• UTF-8 ofrece peor rendimiento que UTF-16 y UTF-32 en cuanto a carga computacional.^[8]

Referencias

Véase también

• El estándar Unicode
• UTF-16
• UTF-32

Enlaces externos

• RFC 3629. Estándar UTF-8 (en inglés).
• Hello World Presentación de UTF-8 en USENIX winter 1993 por Rob C. Pike y Ken Thompson (en inglés).
• Diseño de UTF-8 comentado por Robert C. Pike (en inglés).
• Mapa de caracteres UTF-8