UTF-8 es un estándar de codificación de caracteres utilizado para la comunicación electrónica. Definido por el estándar Unicode , el nombre deriva de Unicode Transformation Format – 8-bit . [1] Casi todas las páginas web se almacenan en UTF-8.
UTF-8 es capaz de codificar los 1.112.064 [2] puntos de código Unicode válidos utilizando una codificación de ancho variable de una a cuatro unidades de código de un byte (8 bits). Los puntos de código con valores numéricos más bajos, que tienden a aparecer con mayor frecuencia, se codifican utilizando menos bytes. Fue diseñado para la compatibilidad con versiones anteriores de ASCII : los primeros 128 caracteres de Unicode, que se corresponden uno a uno con ASCII, se codifican utilizando un solo byte con el mismo valor binario que ASCII, de modo que un archivo codificado en UTF-8 que utilice solo esos caracteres es idéntico a un archivo ASCII, y la mayoría del software diseñado para cualquier ASCII extendido puede leer y escribir UTF-8. Esto genera menos problemas de internacionalización que cualquier codificación de texto alternativa [3] [4] y rápidamente se ha convertido en el método más popular para almacenar texto, representando el 98,3% de todas las páginas web, el 99,1% de las 100.000 páginas principales y hasta el 100% para muchos idiomas, a partir de 2024. [actualizar][ 5]
La Organización Internacional de Normalización (ISO) se propuso componer un conjunto de caracteres multibyte universal en 1989. El borrador de la norma ISO 10646 contenía un anexo no obligatorio llamado UTF-1 que proporcionaba una codificación de secuencia de bytes de sus puntos de código de 32 bits . Esta codificación no era satisfactoria por razones de rendimiento, entre otros problemas, y el mayor problema era probablemente que no tenía una separación clara entre ASCII y no ASCII: las nuevas herramientas UTF-1 serían compatibles con versiones anteriores con texto codificado en ASCII, pero el texto codificado en UTF-1 podría confundir al código existente que esperaba ASCII (o ASCII extendido ), porque podría contener bytes de continuación en el rango 0x21–0x7E que significaran algo más en ASCII, por ejemplo, 0x2F para /, el separador de directorio de ruta de Unix .
En julio de 1992, el comité X/Open XoJIG buscaba una codificación mejor. Dave Prosser de Unix System Laboratories presentó una propuesta para una que tuviera características de implementación más rápidas e introdujo la mejora de que los caracteres ASCII de 7 bits solo se representarían a sí mismos; las secuencias multibyte solo incluirían bytes con el bit alto establecido. El nombre File System Safe UCS Transformation Format ( FSS-UTF ) [6] y la mayor parte del texto de esta propuesta se conservaron posteriormente en la especificación final. [7] [8] [9] En agosto de 1992, un representante de IBM X/Open circuló esta propuesta a las partes interesadas. Una modificación de Ken Thompson del grupo de sistema operativo Plan 9 en Bell Labs lo hizo autosincronizable , lo que permite que un lector comience en cualquier lugar y detecte inmediatamente los límites de los caracteres, a costa de ser algo menos eficiente en bits que la propuesta anterior. También abandonó el uso de sesgos que impedían codificaciones demasiado largas. El diseño de Thompson fue esbozado el 2 de septiembre de 1992, en un mantel individual en un restaurante de Nueva Jersey con Rob Pike . En los días siguientes, Pike y Thompson lo implementaron y actualizaron Plan 9 para usarlo en todo el sistema, [10] y luego comunicaron su éxito a X/Open, que lo aceptó como especificación para FSS-UTF. [9]
UTF-8 se presentó oficialmente por primera vez en la conferencia USENIX en San Diego , del 25 al 29 de enero de 1993. [11] El Grupo de trabajo de ingeniería de Internet adoptó UTF-8 en su Política sobre conjuntos de caracteres e idiomas en RFC 2277 ( BCP 18) para futuros trabajos de estándares de Internet en enero de 1998, reemplazando conjuntos de caracteres de un solo byte como Latin-1 en RFC más antiguos. [12]
En noviembre de 2003, el RFC 3629 restringió UTF-8 para que coincidiera con las restricciones de la codificación de caracteres UTF-16 : al prohibir explícitamente los puntos de código correspondientes a los caracteres sustitutos alto y bajo, se eliminaron más del 3% de las secuencias de tres bytes, y al terminar en U+10FFFF se eliminaron más del 48% de las secuencias de cuatro bytes y todas las secuencias de cinco y seis bytes. [13]
El nombre oficial de la codificación es UTF-8 , la ortografía que se utiliza en todos los documentos del Consorcio Unicode. La mayoría de los estándares también lo incluyen oficialmente en mayúsculas, pero todos los que lo hacen no distinguen entre mayúsculas y minúsculas y utf-8se suele utilizar en el código. [ cita requerida ]
Algunas otras grafías también pueden ser aceptadas por los estándares, por ejemplo, los estándares web (que incluyen CSS , HTML , XML y encabezados HTTP ) permiten explícitamente utf8 (y rechazan "unicode") y muchos alias para codificaciones. [14] Las grafías con un espacio, por ejemplo, "UTF 8", no deben usarse. La Autoridad de Números Asignados de Internet oficial también incluye csUTF8 como el único alias, [15] que rara vez se usa.
En Windows , UTF-8 es la página de códigos 65001[16] (es decir, CP_UTF8en el código fuente).
En MySQL , UTF-8 se denomina utf8mb4[17] (siendo utf8mb3, y su alias utf8, una codificación de subconjunto para caracteres en el plano multilingüe básico [18] ).
En HP PCL , el identificador de símbolo para UTF-8 es 18N. [19]
En Oracle Database (desde la versión 9.0), AL32UTF8[20] significa UTF-8. Oracle anteriormente utilizaba el nombre UTF-8 para referirse a CESU-8 , una variante en desuso.
UTF-8-BOM y UTF-8-NOBOM se utilizan a veces para archivos de texto que contienen o no una marca de orden de bytes (BOM), respectivamente. [ cita requerida ] En Japón especialmente, la codificación UTF-8 sin una BOM a veces se denomina UTF-8N. [21] [22]
UTF-8 codifica puntos de código en uno a cuatro bytes, según el valor del punto de código. En la siguiente tabla, los caracteres u a z se reemplazan por los bits del punto de código, desde las posiciones U+uvwxyz :
Los primeros 128 puntos de código (ASCII) necesitan 1 byte. Los siguientes 1.920 puntos de código necesitan dos bytes para codificarse, lo que cubre el resto de casi todos los alfabetos de escritura latina , y también las extensiones IPA , los alfabetos griego , cirílico , copto , armenio , hebreo , árabe , siríaco , thaana y n'ko , así como la combinación de marcas diacríticas . Se necesitan tres bytes para los 61.440 puntos de código restantes del plano multilingüe básico (BMP), que incluyen la mayoría de los caracteres chinos, japoneses y coreanos . Se necesitan cuatro bytes para los 1.048.576 puntos de código en los otros planos de Unicode , que incluyen emoji (símbolos pictográficos), caracteres CJK menos comunes , varias escrituras históricas y símbolos matemáticos .
Este es un código de prefijo y no es necesario leer más allá del último byte de un punto de código para decodificarlo. A diferencia de muchas codificaciones de texto de múltiples bytes anteriores, como Shift-JIS , se sincroniza automáticamente , por lo que es posible buscar cadenas o caracteres cortos y se puede encontrar el comienzo de un punto de código desde una posición aleatoria retrocediendo como máximo 3 bytes (esto funciona incluso si hay errores en la cadena). Los valores elegidos para los bytes iniciales significan que ordenar una lista de cadenas UTF-8 las coloca en el mismo orden que ordenar cadenas UTF-32 .
El uso de una fila de la tabla anterior para codificar un punto de código menor que el "Primer punto de código" (es decir, utilizando más bytes de los necesarios) se denomina codificación demasiado larga . Estas codificaciones son un problema de seguridad porque permiten que el mismo punto de código se codifique de múltiples maneras. Las codificaciones demasiado largas ( ../por ejemplo, de) se han utilizado para eludir las validaciones de seguridad en productos de alto perfil, incluido el servidor web IIS de Microsoft [23] y el contenedor de servlets Tomcat de Apache [24] . Por lo tanto, las codificaciones demasiado largas deben considerarse un error y nunca deben decodificarse.
Las primeras versiones de lo que se convirtió en UTF-8 utilizaban sesgos por fila que se restaban del punto de código antes de la codificación, lo que hacía imposible realizar codificaciones demasiado largas. Esta técnica se abandonó en 1992 porque en ese momento la resta era más lenta que la lógica de bits en muchas computadoras.
El UTF-8 modificado permite una codificación demasiado larga de U+0000 .
La siguiente tabla muestra el significado detallado de cada byte en una secuencia codificada en UTF-8.
No todas las secuencias de bytes son válidas en formato UTF-8. Un decodificador UTF-8 debe estar preparado para:
Muchos de los primeros decodificadores UTF-8 los decodificaban, ignorando los bits incorrectos y aceptando resultados demasiado largos. Un UTF-8 no válido cuidadosamente diseñado podía hacer que se saltasen o crearan caracteres ASCII como NUL , barras o comillas. La RFC 3629 establece que "las implementaciones del algoritmo de decodificación DEBEN proteger contra la decodificación de secuencias no válidas". [25] El estándar Unicode requiere que los decodificadores: "... traten cualquier secuencia de unidad de código mal formada como una condición de error. Esto garantiza que no interpretará ni emitirá una secuencia de unidad de código mal formada".
Lanzar una excepción o truncar una cadena cuando se encuentra un error alguna vez fue algo común. [26] Esto es un agujero de seguridad ya que puede convertir lo que de otra manera serían errores inofensivos (como un error de "no existe dicho archivo") en una denegación de servicio . Por ejemplo, las primeras versiones de Python 3.0 salían inmediatamente si la línea de comandos o las variables de entorno contenían UTF-8 no válido. [27] El estándar ahora recomienda reemplazar cada error con el carácter de reemplazo "�" (U+FFFD).
Algunos decodificadores consideran la secuencia E1,A0,20 (un código truncado de 3 bytes seguido de un espacio) como un único error. Esto no es una buena idea, ya que una búsqueda de un carácter de espacio encontraría el que está oculto en el error. Desde Unicode 6 (octubre de 2010) [28], el estándar (capítulo 3) ha recomendado una "mejor práctica" en la que el error tiene una longitud de un byte o termina en el primer byte que no está permitido, por lo que E1,A0,20 es un error de dos bytes seguido de un espacio. Esto significa que un error no tiene más de tres bytes de longitud y nunca contiene el comienzo de un carácter válido, y hay21.952 posibles errores diferentes. Algunos decodificadores consideran que cada byte es un error, en cuyo caso E1,A0,20 son dos errores seguidos de un espacio. Esto significa que solo hay 128 errores diferentes, lo que hace que sea práctico almacenar los errores en la cadena de salida [29] o reemplazarlos con caracteres de una codificación heredada.
Solo un pequeño subconjunto de posibles cadenas de bytes son UTF-8 libres de errores: no pueden aparecer varios bytes; un byte con el bit alto establecido no puede estar solo; y en una cadena verdaderamente aleatoria, un byte con un bit alto establecido tiene solo una probabilidad de 1 ⁄ 15 de iniciar un carácter UTF-8 válido. Esto tiene la consecuencia (posiblemente no deseada) de hacer que sea fácil detectar si se usa accidentalmente una codificación de texto heredada en lugar de UTF-8, lo que hace que la conversión de un sistema a UTF-8 sea más fácil y evita la necesidad de requerir una marca de orden de bytes o cualquier otro metadato.
Desde RFC 3629 (noviembre de 2003), los sustitutos altos y bajos utilizados por UTF-16 ( U+D800 a U+DFFF ) no son valores Unicode legales, y sus codificaciones UTF-8 deben tratarse como una secuencia de bytes no válida. [25] Todas estas codificaciones comienzan con 0xED seguido de 0xA0 o superior. Esta regla a menudo se ignora ya que los sustitutos están permitidos en los nombres de archivo de Windows y esto significa que debe haber una forma de almacenarlos en una cadena. [30] UTF-8 que permite estas mitades sustitutas se ha llamado (informalmente) WTF-8 , mientras que otra variación que también codifica todos los caracteres que no son BMP como dos sustitutos (6 bytes en lugar de 4) se llama CESU-8 .
Si la marca de orden de bytes Unicode U+FEFF está al comienzo de un archivo UTF-8, los primeros tres bytes serán 0xEF , 0xBB , 0xBF .
El estándar Unicode no exige ni recomienda el uso de la BOM para UTF-8, pero advierte que puede encontrarse al comienzo de un archivo transcodificado a partir de otra codificación. [31] Si bien el texto ASCII codificado con UTF-8 es compatible con versiones anteriores de ASCII, esto no es así cuando se ignoran las recomendaciones del estándar Unicode y se agrega una BOM. Una BOM puede confundir al software que no está preparado para ello pero que, de otro modo, puede aceptar UTF-8, por ejemplo, lenguajes de programación que permiten bytes no ASCII en literales de cadena pero no al comienzo del archivo. Sin embargo, hubo y todavía hay software que siempre inserta una BOM al escribir UTF-8 y se niega a interpretar correctamente UTF-8 a menos que el primer carácter sea una BOM (o el archivo solo contenga ASCII). [32]
Durante mucho tiempo hubo una discusión considerable sobre si era mejor procesar texto en UTF-16 o en UTF-8.
La principal ventaja de UTF-16 es que la API de Windows requería que se utilizara para obtener acceso a todos los caracteres Unicode (esto se solucionó recientemente). Esto provocó que varias bibliotecas, como Qt, también utilizaran cadenas UTF-16, lo que propaga este requisito a plataformas que no son Windows.
En los primeros tiempos de Unicode no había caracteres mayores que U+FFFF y rara vez se utilizaban caracteres combinados , por lo que la codificación de 16 bits era de tamaño fijo. Esto hizo que el procesamiento de texto fuera más eficiente, aunque las ventajas no son tan grandes como los programadores novatos pueden imaginar. Todas estas ventajas se perdieron tan pronto como UTF-16 también pasó a tener ancho variable.
Los puntos de código U+0800 – U+FFFF ocupan 3 bytes en UTF-8, pero solo 2 en UTF-16. Esto llevó a la idea de que el texto en chino y otros idiomas ocuparía más espacio en UTF-8. Sin embargo, el texto solo es más grande si hay más de estos puntos de código que puntos de código ASCII de 1 byte, y esto rara vez sucede en los documentos del mundo real debido a los espacios, las nuevas líneas, los dígitos, la puntuación, las palabras en inglés y el marcado HTML.
UTF-8 tiene las ventajas de ser fácil de adaptar a cualquier sistema que pueda manejar un ASCII extendido , no tener problemas de orden de bytes y ocupar aproximadamente la mitad del espacio que ocuparía cualquier idioma que use principalmente letras latinas.
UTF-8 ha sido la codificación más común para la World Wide Web desde 2008. [34] A partir de septiembre de 2024 [actualizar], el 98,3% de los sitios web encuestados utilizan UTF-8. [5] Aunque muchas páginas solo usan caracteres ASCII para mostrar contenido, muy pocos sitios web declaran ahora que su codificación es solo ASCII en lugar de UTF-8. [35] Más del 50% de los idiomas rastreados tienen un uso 100% de UTF-8.
Muchos estándares sólo admiten UTF-8, por ejemplo, el intercambio de JSON lo requiere (sin una marca de orden de bytes (BOM)). [36] UTF-8 también es la recomendación del WHATWG para las especificaciones HTML y DOM , y afirma que "la codificación UTF-8 es la codificación más apropiada para el intercambio de Unicode " [4] y el Consorcio de Correo de Internet recomienda que todos los programas de correo electrónico puedan mostrar y crear correo utilizando UTF-8. [37] [38] El Consorcio World Wide Web recomienda UTF-8 como la codificación predeterminada en XML y HTML (y no sólo usar UTF-8, también declararlo en metadatos), "incluso cuando todos los caracteres están en el rango ASCII ... El uso de codificaciones que no sean UTF-8 puede tener resultados inesperados". [39]
Muchos programas tienen la capacidad de leer y escribir UTF-8. Sin embargo, puede requerir que el usuario cambie las opciones de la configuración normal o que se requiera una marca de orden de bytes (BOM) como primer carácter para leer el archivo. Algunos ejemplos de programas que admiten UTF-8 son Microsoft Word , [40] [41] [42] Microsoft Excel (2016 y posteriores), [43] [44] Google Drive , LibreOffice y la mayoría de las bases de datos.
El software que "predeterminadamente" usa UTF-8 (lo que significa que lo escribe sin que el usuario cambie la configuración y lo lee sin una BOM) se ha vuelto más común desde 2010. [45] El Bloc de notas de Windows , en todas las versiones de Windows compatibles actualmente, escribe de forma predeterminada UTF-8 sin una BOM (un cambio con respecto al Bloc de notas de Windows 7 ), lo que lo pone en línea con la mayoría de los demás editores de texto. [46] Algunos archivos del sistema en Windows 11 requieren UTF-8 [47] sin ningún requisito de una BOM, y casi todos los archivos en macOS y Linux deben ser UTF-8 sin una BOM. [ cita requerida ] Los lenguajes de programación que usan UTF-8 de forma predeterminada para E/S incluyen Ruby 3.0 [48] [49] y R 4.2.2. [50] Java 18 tiene como valor predeterminado leer y escribir archivos como UTF-8, [51] aunque las versiones LTS más antiguas solo lo hacen para la API NIO . Aunque la versión actual de Python requiere una opción en Windows para soportar UTF-8, [52] existen planes para hacer que la E/S UTF-8 sea la predeterminada en Python 3.15 en todas las plataformas. [53] C++23 adopta UTF-8 como el único formato de archivo de código fuente portable (sorprendentemente, antes no había ninguno). [54] open()
La compatibilidad con versiones anteriores es un impedimento serio para cambiar el código para usar UTF-8 en lugar de una codificación de 16 bits, pero esto está sucediendo. La primitiva de cadena predeterminada en Go , [55] Julia , Rust , Swift 5 , [56] y PyPy [57] usa UTF-8 internamente en todos los casos. Python 3.3 usa UTF-8 internamente para extensiones de API de Python C [58] [59] y, a veces, para cadenas [58] [60] y se planea una versión futura de Python para almacenar cadenas como UTF-8 de forma predeterminada. [61] [62] Las versiones modernas de Microsoft Visual Studio usan UTF-8 internamente. [63] SQL Server 2019 de Microsoft agregó soporte para UTF-8, y su uso da como resultado un aumento de velocidad del 35% y "una reducción de casi el 50% en los requisitos de almacenamiento". [64]
A partir de mayo de 2019 [actualizar], Microsoft agregó la capacidad para que una aplicación establezca UTF-8 como la "página de códigos" para la API de Windows, eliminando la necesidad de usar UTF-16; y más recientemente recomendó a los programadores que usen UTF-8, [65] e incluso afirma que "UTF-16 [...] es una carga única que Windows coloca en el código que apunta a múltiples plataformas". [3]
El lenguaje de programación Java incluye Modified UTF-8 (MUTF-8), en el que el carácter nulo U+0000 utiliza la codificación de dos bytes demasiado larga 0xC0 , 0x80 , en lugar de solo 0x00 . [66] Las cadenas Modified UTF-8 nunca contienen ningún byte nulo real, pero pueden contener todos los puntos de código Unicode, incluido U+0000, [67] lo que permite que dichas cadenas (con un byte nulo añadido) sean procesadas por funciones de cadena terminadas en nulo tradicionales . Todas las implementaciones de Modified UTF-8 conocidas también tratan los pares sustitutos como en CESU-8 . En el uso normal, el lenguaje admite UTF-8 estándar al leer y escribir cadenas a través de y (si es el conjunto de caracteres predeterminado de la plataforma o según lo solicite el programa). Sin embargo, utiliza Modified UTF-8 para la serialización de objetos [68] entre otras aplicaciones de y , para la interfaz nativa de Java , [69] y para incrustar cadenas constantes en archivos de clase . [70] El formato dex definido por Dalvik también utiliza el mismo UTF-8 modificado para representar valores de cadena. [71] Tcl también utiliza el mismo UTF-8 modificado [72] que Java para la representación interna de datos Unicode, pero utiliza CESU-8 estricto para datos externos.InputStreamReaderOutputStreamWriterDataInputDataOutput
La versión 3 del lenguaje de programación Python trata cada byte de un flujo de bytes UTF-8 no válido como un error (ver también los cambios con el nuevo modo UTF-8 en Python 3.7 [73] ); esto da 128 posibles errores diferentes. Se han creado extensiones para permitir que cualquier secuencia de bytes que se asuma como UTF-8 se transforme sin pérdida a UTF-16 o UTF-32, traduciendo los 128 bytes de error posibles a puntos de código reservados y transformando esos puntos de código nuevamente a bytes de error para generar UTF-8. El enfoque más común es traducir los códigos a U+DC80...U+DCFF que son valores sustitutos bajos (finales) y, por lo tanto, UTF-16 "no válido", como se usa en el enfoque PEP 383 (o "surrogateescape") de Python . [29] Otra codificación llamada MirBSD OPTU-8/16 los convierte a U+EF80...U+EFFF en un Área de uso privado . [74] En cualquiera de los dos enfoques, el valor del byte se codifica en los ocho bits inferiores del punto de código de salida. Estas codificaciones son necesarias para que el UTF-8 no válido sobreviva a la traducción y luego vuelva a la UTF-16 utilizada internamente por Python, y como los nombres de archivo de Unix pueden contener UTF-8 no válido, es necesario que esto funcione. [75]
Existen varias definiciones actuales de UTF-8 en varios documentos de estándares:
Sustituyen las definiciones dadas en las siguientes obras obsoletas:
Todos son iguales en su mecánica general, y las principales diferencias están en cuestiones como el rango permitido de valores de puntos de código y el manejo seguro de entradas no válidas.
Anteriormente, en XP (y, no verificado, pero probablemente también en Vista), los bucles for simplemente no funcionaban mientras la página de códigos 65001 estaba activa
... en realidad, normalmente se asume que se trata de UTF-8, ya que es, con diferencia, la codificación más común.
Microsoft ahora guarda de forma predeterminada los archivos de texto nuevos como UTF-8 sin BOM, como se muestra a continuación.
Asegúrate de que LayoutModification.json use codificación UTF-8.
La representación UTF-8 se crea a pedido y se almacena en caché en el objeto Unicode.
Se eliminaron los miembros y
obsoletos
de la implementación C de objetos Unicode, según PEP 623.
wstrwstr_length
Visual Studio utiliza UTF-8 como codificación de caracteres interna durante la conversión entre el conjunto de caracteres de origen y el conjunto de caracteres de ejecución.