UTF-8

UTF-8
Estándar	ISO 10646 (Unicode)
Idioma	plurilingüe
Estado	En uso
Anterior	UTF-1
[editar datos en Wikidata]

UTF-8 (8-bit Unicode Transformation Format) es un formato de codificación de caracteres Unicode e ISO 10646 que utiliza 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 carácter 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]​

UTF-8 fue ideado por Kenneth L. Thompson bajo los criterios de diseño de Rob 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]​

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. Se incluye también la codificación UTF-16 para ver la diferencia con una codificación de número fijo de bytes.

Rango de puntos UNICODE	Valor escalar	UTF-16	UTF-8	Notas
000000-00007F	00000000 0xxxxxxx	00000000 0xxxxxxx	0xxxxxxx	Rango equivalente a US-ASCII. Símbolos de un único byte donde el bit más significativo es 0
000080-0007FF	00000yyy yyxxxxxx	00000yyy yyxxxxxx	110yyyyy 10xxxxxx	Símbolos de dos bytes. El primer byte comienza con 110, el segundo byte comienza con 10
000800-00FFFF	zzzzyyyy yyxxxxxx	zzzzyyyy yyxxxxxx	1110zzzz 10yyyyyy 10xxxxxx	Símbolos de tres bytes. El primer byte comienza con 1110, los bytes siguientes comienzan con 10
010000-10FFFF	000uuuuu zzzzyyyy yyxxxxxx	110110ww wwzzzzyy 110111yy yyxxxxxx (wwww = uuuuu - 1)	11110uuu 10uuzzzz 10yyyyyy 10xxxxxx	Símbolos de cuatro bytes. El primer byte comienza con 11110, los bytes siguientes comienzan con 10

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]​

Veamos, a modo de ejemplo, cómo se codifica en UTF-8 el carácter eñe (ñ), que en Unicode corresponde con el punto de código U+00F1:

• Su valor se sitúa en el rango de U+0080 a U+07FF. Una consulta a la tabla permite ver que debe ser codificado usando 2 bytes, con el formato 110xxxxx 10xxxxxx.
• El valor hexadecimal 00F1 es equivalente al binario 0000 0000 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.

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.
• Valores 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.

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.

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

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]}

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]}

• UTF-8 permite codificar cualquier carácter Unicode.^[1]​
• Es compatible con US-ASCII, la codificación del repertorio de 7 bits es directa.
• 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.

• 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 solo 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 coste de computación,^[8]​ por ejemplo en operaciones de ordenación.

• El estándar Unicode
• UTF-16

• 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).