UTF-8 es un estándar de codificación de caracteres de longitud variable que se utiliza para las comunicaciones electrónicas. Definido por el estándar Unicode , el nombre se deriva del formato de transformación Unicode: 8 bits . [1]
UTF-8 es capaz de codificar los 1.112.064 [a] puntos de código Unicode válidos utilizando 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 ocurrir con más frecuencia, se codifican utilizando menos bytes. Fue diseñado para ser compatible con versiones anteriores de ASCII : los primeros 128 caracteres de Unicode, que corresponden uno a uno con ASCII, se codifican utilizando un único byte con el mismo valor binario que ASCII, de modo que el texto ASCII válido sea UTF-8 válido. -Codificado Unicode también.
UTF-8 fue diseñado como una alternativa superior a UTF-1 , una codificación de longitud variable propuesta con compatibilidad ASCII parcial que carecía de algunas características, incluida la autosincronización y el manejo de caracteres totalmente compatible con ASCII, como las barras diagonales. Ken Thompson y Rob Pike produjeron la primera implementación para el sistema operativo Plan 9 en septiembre de 1992. [2] [3] Esto llevó a su adopción por parte de X/Open como su especificación para FSS-UTF , [4] que sería la primera en ser oficialmente presentado en USENIX en enero de 1993 [5] y posteriormente adoptado por el Grupo de Trabajo de Ingeniería de Internet (IETF) en RFC 2277 ( BCP 18 ) [6] para futuros trabajos de estándares de Internet, reemplazando los conjuntos de caracteres de un solo byte como Latin-1 en RFC más antiguos. .
UTF-8 genera menos problemas de internacionalización [7] [8] que cualquier codificación de texto alternativa, y se ha implementado en todos los sistemas operativos modernos , incluido Microsoft Windows , y en estándares como JSON , donde, como es cada vez más frecuente, es la única forma permitida de Unicode .
UTF-8 es la codificación dominante para la World Wide Web (y las tecnologías de Internet), y representa el 98,2% de todas las páginas web, el 99,0% de las 10.000 páginas principales y hasta el 100% para muchos idiomas, a partir de 2024 [actualizar]. [9] Prácticamente todos los países e idiomas tienen un 95% o más de uso de codificaciones UTF-8 en la web.
El nombre oficial de la codificación es UTF-8 , la ortografía utilizada en todos los documentos del Consorcio Unicode. La mayoría de los estándares también lo enumeran oficialmente en mayúsculas, pero todo lo que lo hace tampoco distingue entre mayúsculas y minúsculas y utf-8
se usa a menudo en el código. [ cita necesaria ]
Los estándares también pueden aceptar otras ortografías, por ejemplo, los estándares web (que incluyen encabezados CSS , HTML , XML y HTTP ) permiten explícitamente utf8 (y no permiten "unicode") y muchos alias para codificaciones. [10] No se deben utilizar ortografías con un espacio, por ejemplo, "UTF 8". La Autoridad de Números Asignados de Internet oficial también incluye csUTF8 como el único alias, [11] que rara vez se utiliza.
En Windows , UTF-8 es la página de códigos 65001
[12] (es decir, CP_UTF8
en el código fuente).
En MySQL , UTF-8 se llama utf8mb4
[13] (siendo utf8mb3
y su alias utf8
un subconjunto de codificación para caracteres en el plano multilingüe básico [14] ). En HP PCL , el ID de símbolo para UTF-8 es 18N
. [15]
En Oracle Database (desde la versión 9.0), AL32UTF8
[16] significa UTF-8. Consulte también CESU-8 para obtener un casi sinónimo de UTF-8 que rara vez debería usarse.
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 necesaria ] Especialmente en Japón, la codificación UTF-8 sin una lista de materiales a veces se llama UTF-8N . [17] [18]
UTF-8 codifica puntos de código de uno a cuatro bytes, según el valor del punto de código. En la siguiente tabla, los caracteres x se reemplazan por los bits del punto de código:
Los primeros 128 puntos de código (ASCII) necesitan un 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 , como así como combinar signos diacríticos . Se necesitan tres bytes para los 61.440 puntos de código restantes del plano multilingüe básico (BMP), incluida 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 .
Un "carácter" puede ocupar más de 4 bytes porque está formado por más de un punto de código. Por ejemplo, un carácter de bandera nacional ocupa 8 bytes ya que está "construido a partir de un par de valores escalares Unicode", ambos externos al BMP. [19] [c]
En los siguientes ejemplos, los dígitos rojo, verde y azul indican cómo se distribuyen los bits del punto de código entre los bytes UTF-8. Los bits adicionales agregados mediante el proceso de codificación UTF-8 se muestran en negro.
Los tres bytes 1110 0010 10 000010 10 101100 se pueden escribir de forma más concisa en hexadecimal , como E2 82 AC .
La siguiente tabla resume esta conversión, así como otras con diferentes longitudes en UTF-8.
En estos ejemplos, los dígitos de colores indican secuencias de varios bytes utilizadas para codificar caracteres más allá de ASCII, mientras que los dígitos en negro son ASCII.
Como ejemplo, la frase vietnamita Mình nói tiếng Việt ( 𨉟呐㗂越, "Hablo vietnamita") está codificada de la siguiente manera:
La siguiente tabla resume el uso de unidades de código UTF-8 ( bytes u octetos individuales ) en un formato de página de códigos . La mitad superior es para bytes utilizados sólo en códigos de un solo byte, por lo que parece una página de códigos normal; la mitad inferior es para bytes de continuación y bytes iniciales y se explica con más detalle en la leyenda siguiente.
En principio, sería posible inflar el número de bytes en una codificación rellenando el punto de código con ceros a la izquierda. Para codificar el signo del euro € del ejemplo anterior en cuatro bytes en lugar de tres, podría rellenarse con ceros a la izquierda hasta que tenga 21 bits de longitud: 000 000010 000010 101100 y codificarse como 11110 000 10 000010 10 000010 10 101100 (o F0 82 82 AC en hexadecimal). Esto se llama codificación demasiado larga .
El estándar especifica que la codificación correcta de un punto de código utiliza sólo el número mínimo de bytes necesarios para contener los bits significativos del punto de código. [ cita necesaria ] Las codificaciones más largas se denominan demasiado largas y no son representaciones UTF-8 válidas del punto de código. Esta regla mantiene una correspondencia uno a uno entre los puntos de código y sus codificaciones válidas, de modo que existe una codificación válida única para cada punto de código. Esto garantiza que las comparaciones y búsquedas de cadenas estén bien definidas.
No todas las secuencias de bytes son UTF-8 válidas. Se debe preparar un decodificador UTF-8 para:
Muchos de los primeros decodificadores UTF-8 los decodificarían, ignorando bits incorrectos y aceptando resultados demasiado largos. UTF-8 no válido cuidadosamente diseñado podría hacer que omitan o creen caracteres ASCII como NUL, barra diagonal o comillas. Se ha utilizado UTF-8 no válido para eludir validaciones de seguridad en productos de alto perfil, incluido el servidor web IIS de Microsoft [26] y el contenedor de servlets Tomcat de Apache. [27] RFC 3629 establece que "Las implementaciones del algoritmo de decodificación DEBEN proteger contra la decodificación de secuencias no válidas". [23] El estándar Unicode requiere que los decodificadores "... traten cualquier secuencia de unidades de código mal formada como una condición de error. Esto garantiza que no interpretará ni emitirá una secuencia de unidades de código mal formada".
Desde RFC 3629 (noviembre de 2003), las mitades sustitutas alta y baja utilizadas por UTF-16 (U+D800 a U+DFFF) y los puntos de código no codificables por UTF-16 (aquellos después de U+10FFFF) no son valores Unicode legales. y su codificación UTF-8 debe tratarse como una secuencia de bytes no válida. No decodificar mitades sustitutas no emparejadas hace imposible almacenar UTF-16 no válido (como nombres de archivos de Windows o UTF-16 que se ha dividido entre los sustitutos) como UTF-8, [28] mientras que es posible con WTF-8.
Algunas implementaciones de decodificadores arrojan excepciones en caso de errores. [29] Esto tiene la desventaja de que puede convertir lo que de otro modo serían errores inofensivos (como un error "no existe tal archivo") en una denegación de servicio . Por ejemplo, las primeras versiones de Python 3.0 saldrían inmediatamente si la línea de comando o las variables de entorno contuvieran UTF-8 no válido. [30]
Desde Unicode 6 [31] (octubre de 2010), 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 antes del primer byte no permitido. En estos decodificadores E1,A0,C0 son dos errores (2 bytes en el primero). Esto significa que un error no tiene más de tres bytes de longitud y nunca contiene el inicio de un carácter válido, y hay 21.952 errores posibles diferentes. [32] El estándar también recomienda reemplazar cada error con el carácter de reemplazo "�" (U+FFFD).
Estas recomendaciones no suelen seguirse. Es común considerar que cada byte es un error, en cuyo caso E1,A0,C0 son tres errores (cada uno de 1 byte de longitud). Esto significa que sólo hay 128 errores diferentes, y también es común reemplazarlos con 128 caracteres diferentes, para que la decodificación sea "sin pérdidas". [33]
Si la marca de orden de bytes Unicode (BOM, U+FEFF, técnicamente el carácter U+FEFF ZERO WIDTH NO-BREAK SPACE ) está al comienzo de un archivo UTF-8, los primeros tres bytes serán 0xEF , 0xBB , 0xBF .
El estándar Unicode no requiere ni recomienda el uso de la BOM para UTF-8, pero advierte que puede encontrarse al comienzo de un archivo transcodificado desde otra codificación. [34] Si bien el texto ASCII codificado usando UTF-8 es compatible con ASCII, esto no es cierto cuando se ignoran las recomendaciones del estándar Unicode y se agrega una lista de materiales. Una lista de materiales puede confundir al software que no está preparado para ello pero que puede aceptar UTF-8, por ejemplo, lenguajes de programación que permiten bytes no ASCII en cadenas literales pero no al inicio del archivo. Sin embargo, existía y todavía existe 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). [35]
UTF-8 ha sido la codificación más común para la World Wide Web desde 2008. [37] En febrero de 2024 [actualizar], el 98,2% de los sitios web encuestados utilizan UTF-8. [9] [e] Aunque muchas páginas solo usan caracteres ASCII para mostrar contenido, muy pocos sitios web ahora declaran que su codificación solo es ASCII en lugar de UTF-8. [38] 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 JSON lo requiere (sin una marca de orden de bytes (BOM)). [39] UTF-8 es también la recomendación de WHATWG para las especificaciones HTML y DOM , y establece que "la codificación UTF-8 es la codificación más apropiada para el intercambio de Unicode " [8] y el Internet Mail Consortium recomienda que todos los correos electrónicos Los programas podrán mostrar y crear correo utilizando UTF-8. [40] [41] El World Wide Web Consortium recomienda UTF-8 como codificación predeterminada en XML y HTML (y no solo usar UTF-8, sino que también lo declara 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". [42]
Gran cantidad de software tiene la capacidad de leer/escribir UTF-8. Sin embargo, puede requerir que el usuario cambie las opciones de la configuración normal, o puede requerir una BOM (marca de orden de bytes) como primer carácter para leer el archivo. Ejemplos de software que admiten UTF-8 incluyen Microsoft Word , [43] [44] [45] Microsoft Excel (2016 y posteriores), [46] [47] Google Drive , LibreOffice y la mayoría de las bases de datos.
Sin embargo, para los archivos de texto locales, el uso de UTF-8 es menos frecuente, donde se siguen utilizando codificaciones heredadas de un solo byte (y algunas CJK de varios bytes ). La causa principal de esto son los editores de texto obsoletos que se niegan a leer UTF-8 a menos que los primeros bytes del archivo codifiquen una marca de orden de bytes (BOM). [48]
Algunos software recientes solo pueden leer y escribir UTF-8 o al menos no requieren una lista de materiales. [49] El Bloc de notas de Windows , en todas las versiones actualmente compatibles de Windows, escribe de forma predeterminada UTF-8 sin una lista de materiales (un cambio con respecto al Bloc de notas de Windows 7 obsoleto/no compatible ), lo que lo alinea con la mayoría de los otros editores de texto. [50] Algunos archivos del sistema en Windows 11 requieren UTF-8 [51] sin necesidad de una BOM, y casi todos los archivos en macOS y Linux deben ser UTF-8 sin una BOM. [ cita necesaria ] Java 18 por defecto lee y escribe archivos como UTF-8, [52] y en versiones anteriores (por ejemplo, versiones LTS ) solo se cambió la API NIO para hacerlo. Muchos otros lenguajes de programación utilizan de forma predeterminada UTF-8 para E/S , incluidos Ruby 3.0 [53] [54] y R 4.2.2. [55] Todas las versiones actualmente admitidas de Python admiten UTF-8 para E/S, incluso en Windows (donde está habilitada para la open()
función [56] ), y existen planes para hacer que UTF-8 E/S sea el valor predeterminado en Python 3.15 en todas las plataformas. [57] [58] C++23 adopta UTF-8 como el único formato de archivo de código fuente portátil (sorprendentemente no había ninguno antes). [59]
El uso de UTF-8 en la memoria es mucho menor que en otras áreas; en su lugar, a menudo se usa UTF-16 . Esto ocurre particularmente en Windows, pero también en JavaScript , Python, [f] Qt y muchas otras bibliotecas de software multiplataforma. La compatibilidad con la API de Windows es la razón principal de esto; esa elección se hizo inicialmente debido a la creencia de que la indexación directa del BMP mejoraría la velocidad. La traducción desde/hacia texto externo que está en UTF-8 ralentiza el software y, lo que es más importante, introduce errores cuando diferentes fragmentos de código no realizan exactamente la misma traducción.
La retrocompatibilidad es un serio impedimento 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 , [61] Julia , Rust , Swift 5 , [62] y PyPy [63] usa UTF-8 internamente en todos los casos, mientras que Python, desde Python 3.3, usa UTF-8 internamente en algunos casos ( para extensiones de API de Python C); [60] [64] Se planea una versión futura de Python para almacenar cadenas como UTF-8 de forma predeterminada; [65] [66] y las versiones modernas de Microsoft Visual Studio utilizan UTF-8 internamente. [67] 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". [68]
Todas las versiones de Windows actualmente compatibles admiten UTF-8 de alguna manera (incluida Xbox ); [7] Ha existido soporte parcial desde al menos Windows XP . En mayo de 2019 [actualizar], Microsoft revirtió su posición anterior de recomendar únicamente UTF-16; se introdujo la capacidad de configurar UTF-8 como la "página de códigos" para la API de Windows; y Microsoft recomienda que los programadores utilicen UTF-8, [69] e incluso afirma que "UTF-16 [...] es una carga única que Windows impone al código destinado a múltiples plataformas". [7]
La Organización Internacional de Normalización (ISO) se propuso componer un juego de caracteres multibyte universal en 1989. El borrador del estándar ISO 10646 contenía un anexo no obligatorio llamado UTF-1 que proporcionaba una codificación de flujo de bytes de sus puntos de código de 32 bits. . Esta codificación no era satisfactoria por motivos de rendimiento, entre otros problemas, y el mayor problema probablemente era que no tenía una separación clara entre ASCII y no ASCII: las nuevas herramientas UTF-1 serían compatibles con versiones anteriores del texto codificado en ASCII, pero El texto codificado en UTF-1 podría confundir el código existente que espera ASCII (o ASCII extendido ), porque podría contener bytes de continuación en el rango 0x21–0x7E que significan algo más en ASCII, por ejemplo, 0x2F para '/', el separador de directorio de ruta de Unix . , y este ejemplo se refleja en el nombre y el texto introductorio de su reemplazo. El cuadro siguiente se obtuvo de una descripción textual contenida en el anexo.
En julio de 1992, el comité X/Open XoJIG buscaba una mejor codificación. Dave Prosser de Unix System Laboratories presentó una propuesta para uno 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; todas las secuencias de varios bytes incluirían solo bytes en los que se estableció el bit alto. El nombre Formato de transformación UCS seguro del sistema de archivos (FSS-UTF) y la mayor parte del texto de esta propuesta se conservaron posteriormente en la especificación final. [70] [71] [72] [73]
En agosto de 1992, un representante de IBM X/Open hizo circular esta propuesta entre las partes interesadas. Una modificación realizada por Ken Thompson del grupo de sistemas operativos Plan 9 en Bell Labs lo hizo autosincronizable , permitiendo al lector comenzar en cualquier lugar e inmediatamente detectar límites de caracteres, a costa de ser algo menos eficiente en bits que la propuesta anterior. También abandonó el uso de sesgos y en su lugar agregó la regla de que sólo se permite la codificación más corta posible; la pérdida adicional de compacidad es relativamente insignificante, pero los lectores ahora deben estar atentos a codificaciones no válidas para evitar problemas de confiabilidad y especialmente de seguridad. 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 el Plan 9 para usarlo en todo momento, y luego comunicaron su éxito a X/Open, que lo aceptó como la especificación para FSS-UTF. [72]
UTF-8 se presentó oficialmente por primera vez en la conferencia USENIX en San Diego , del 25 al 29 de enero de 1993. 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 el futuro Internet. Los estándares funcionan, reemplazando los conjuntos de caracteres de un solo byte como Latin-1 en RFC más antiguos. [6]
En noviembre de 2003, UTF-8 fue restringido por RFC 3629 para que coincidiera con las restricciones de la codificación de caracteres UTF-16 : prohibir explícitamente los puntos de código correspondientes a los caracteres sustitutos alto y bajo eliminó más del 3% de las secuencias de tres bytes, y finalizó en U+10FFFF eliminó más del 48% de las secuencias de cuatro bytes y todas las secuencias de cinco y seis bytes.
Existen varias definiciones actuales de UTF-8 en varios documentos estándar:
Reemplazan las definiciones dadas en las siguientes obras obsoletas:
Todos son iguales en su mecánica general, con las principales diferencias en cuestiones como el rango permitido de valores de puntos de código y el manejo seguro de entradas no válidas.
Algunas de las características importantes de esta codificación son las siguientes:
Las siguientes implementaciones muestran ligeras diferencias con respecto a la especificación UTF-8. Son incompatibles con la especificación UTF-8 y pueden ser rechazados por aplicaciones conformes a UTF-8.
El Informe técnico Unicode n.° 26 [79] asigna el nombre CESU-8 a una variante no estándar de UTF-8, en la que los caracteres Unicode en planos suplementarios se codifican utilizando seis bytes, en lugar de los cuatro bytes requeridos por UTF-8. La codificación CESU-8 trata cada mitad de un par sustituto UTF-16 de cuatro bytes como un carácter UCS-2 de dos bytes, lo que produce dos caracteres UTF-8 de tres bytes, que juntos representan el carácter suplementario original. Los caracteres Unicode dentro del plano multilingüe básico aparecen como lo harían normalmente en UTF-8. El Informe fue escrito para reconocer y formalizar la existencia de datos codificados como CESU-8, a pesar de que el Consorcio Unicode desaconseja su uso, y señala que una posible razón intencional para la codificación CESU-8 es la preservación de la intercalación binaria UTF-16.
La codificación CESU-8 puede resultar de la conversión de datos UTF-16 con caracteres suplementarios a UTF-8, utilizando métodos de conversión que asumen datos UCS-2, lo que significa que desconocen los caracteres suplementarios UTF-16 de cuatro bytes. Es principalmente un problema en los sistemas operativos que utilizan ampliamente UTF-16 internamente, como Microsoft Windows . [ cita necesaria ]
En Oracle Database , el UTF8
juego de caracteres utiliza codificación CESU-8 y está en desuso. El AL32UTF8
juego de caracteres utiliza codificación UTF-8 compatible con los estándares y es el preferido. [80] [81]
Está prohibido el uso de CESU-8 en documentos HTML5 . [82] [83] [84]
En MySQL , el utf8mb3
conjunto de caracteres se define como datos codificados en UTF-8 con un máximo de tres bytes por carácter, lo que significa que solo se admiten caracteres Unicode en el plano multilingüe básico (es decir, de UCS-2 ). Los caracteres Unicode en planos suplementarios no se admiten explícitamente. utf8mb3
está en desuso en favor del utf8mb4
juego de caracteres, que utiliza codificación UTF-8 compatible con los estándares. utf8
es un alias de utf8mb3
, pero está previsto que se convierta en un alias de utf8mb4
en una versión futura de MySQL. [14] Es posible, aunque no es compatible, almacenar datos codificados CESU-8 en formato utf8mb3
, manejando datos UTF-16 con caracteres suplementarios como si fueran UCS-2.
UTF-8 modificado (MUTF-8) se originó en el lenguaje de programación Java . En UTF-8 modificado, el carácter nulo (U+0000) utiliza la codificación demasiado larga de dos bytes 110 00000 10 000000 (hexadecimal C0 80 ), en lugar de 00000000 (hexadecimal 00 ). [85] Las cadenas UTF-8 modificadas nunca contienen bytes nulos reales, pero pueden contener todos los puntos de código Unicode, incluido U+0000, [86] , lo que permite que dichas cadenas (con un byte nulo añadido) se procesen mediante funciones de cadena tradicionales terminadas en nulo. . Todas las implementaciones UTF-8 modificadas conocidas también tratan los pares sustitutos como en CESU-8 .
En uso normal, el lenguaje admite el estándar UTF-8 al leer y escribir cadenas a través de InputStreamReader
y OutputStreamWriter
(si es el juego de caracteres predeterminado de la plataforma o según lo solicite el programa). Sin embargo, utiliza UTF-8 modificado para la serialización de objetos [87] entre otras aplicaciones de DataInput
y DataOutput
, para la interfaz nativa de Java , [88] y para incrustar cadenas constantes en archivos de clase . [89]
El formato dex definido por Dalvik también utiliza el mismo UTF-8 modificado para representar valores de cadena. [90] Tcl también usa el mismo UTF-8 modificado [91] que Java para la representación interna de datos Unicode, pero usa CESU-8 estricto para datos externos.
En WTF-8 (formato de transformación tambaleante, 8 bits), se permiten mitades sustitutas no emparejadas (U+D800 a U+DFFF). [92] Esto es necesario para almacenar archivos UTF-16 posiblemente no válidos, como nombres de archivos de Windows. Muchos sistemas que trabajan con UTF-8 funcionan de esta manera sin considerarlo una codificación diferente, ya que es más simple. [93]
El término "WTF-8" también se ha utilizado con humor para referirse a UTF-8 doblemente codificado erróneamente [94] [95], a veces con la implicación de que los bytes CP1252 son los únicos codificados. [96]
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 (consulte también los cambios con el nuevo modo UTF-8 en Python 3.7 [97] ); esto da 128 errores posibles diferentes. Se han creado extensiones para permitir que cualquier secuencia de bytes que se supone que es UTF-8 se transforme sin pérdidas 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 en errores. bytes 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 los usa PEP 383 de Python (o "escape sustituto") acercarse. [33] Otra codificación llamada MirBSD OPTU-8/16 los convierte a U+EF80...U+EFFF en un Área de Uso Privado . [98] En cualquier enfoque, el valor del byte se codifica en los ocho bits inferiores del punto de código de salida.
Estas codificaciones son muy útiles porque evitan la necesidad de lidiar con cadenas de bytes "no válidas" hasta mucho más tarde, en todo caso, y permiten que las matrices de bytes de "texto" y "datos" sean el mismo objeto. Si un programa desea utilizar UTF-16 internamente, es necesario conservar y utilizar nombres de archivos que puedan utilizar UTF-8 no válido; [99] dado que la API del sistema de archivos de Windows utiliza UTF-16, la necesidad de admitir UTF-8 no válido es menor allí. [33]
Para que la codificación sea reversible, las codificaciones estándar UTF-8 de los puntos de código utilizados para los bytes erróneos deben considerarse inválidas. Esto hace que la codificación sea incompatible con WTF-8 o CESU-8 (aunque sólo para 128 puntos de código). Al volver a codificar, es necesario tener cuidado con las secuencias de puntos de código de error que se convierten nuevamente a UTF-8 válido, que puede ser utilizado por software malicioso para obtener caracteres inesperados en la salida, aunque esto no puede producir caracteres ASCII, por lo que se considera comparativamente seguro, ya que las secuencias maliciosas (como los scripts entre sitios ) generalmente se basan en caracteres ASCII. [99]
Al operar en UTF-8, puede garantizar la máxima compatibilidad [..] Windows opera de forma nativa en UTF-16 (o WCHAR), lo que requiere conversiones de páginas de códigos mediante el uso de MultiByteToWideChar y WideCharToMultiByte. Esta es una carga única que Windows impone al código destinado a múltiples plataformas. [..] El kit de desarrollo de juegos de Microsoft (GDK) y Windows en general están avanzando para admitir UTF-8 para eliminar esta carga única de Windows en cuanto a la orientación o el intercambio de código con múltiples plataformas y la web. Además, esto da como resultado menos problemas de internacionalización en aplicaciones y juegos y reduce la matriz de prueba necesaria para hacerlo bien.
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
Este PEP propone cambiar la codificación predeterminada del sistema de archivos en Windows a utf-8 y cambiar todas las funciones del sistema de archivos para usar las API Unicode para las rutas del sistema de archivos. [..] puede realizar un recorrido de ida y vuelta correctamente con todos los caracteres utilizados en las rutas (en POSIX con manejo de escape sustituto; en Windows porque str se asigna a la representación nativa). En Windows, los bytes no pueden recorrer todos los caracteres utilizados en las rutas.
en realidad, normalmente se asume UTF-8 ya que es, con diferencia, la codificación más común.
Microsoft ahora guarda de forma predeterminada los nuevos archivos de texto como UTF-8 sin BOM, como se muestra a continuación.
Asegúrese de que su LayoutModification.json utilice codificación UTF-8.
Como la interacción con otras bibliotecas a menudo requerirá algún tipo de representación interna, la especificación elige UTF-8 como la forma recomendada de exponer cadenas al código C. [..] Los punteros de datos y utf8 apuntan a la misma memoria si la cadena usa solo caracteres ASCII (usar solo Latin-1 no es suficiente). [..] La forma recomendada de crear un objeto Unicode es utilizar la función PyUnicode_New [..] Se proporciona una nueva función PyUnicode_AsUTF8 para acceder a la representación UTF-8.
El cambio a UTF-8 cumple uno de los objetivos a largo plazo de string, permitir el procesamiento de alto rendimiento, [...] también sienta las bases para proporcionar API con aún más rendimiento en el futuro.
La representación UTF-8 se crea bajo demanda y se almacena en caché en el objeto Unicode.
Hasta que eliminemos [el] objeto Unicode heredado, es muy difícil probar otras implementaciones Unicode, como la implementación basada en UTF-8 en PyPy.
Los miembros obsoletos wstr y wstr_length de la implementación C de objetos Unicode fueron eliminados, según PEP 623.
Visual Studio utiliza UTF-8 como codificación de caracteres interna durante la conversión entre el juego de caracteres de origen y el juego de caracteres de ejecución.
Por ejemplo, cambiar el tipo de datos de una columna existente de NCHAR(10) a CHAR(10) mediante una intercalación habilitada para UTF-8 se traduce en una reducción de casi el 50 % en los requisitos de almacenamiento. [..] En el rango ASCII, al realizar E/S intensivas de lectura/escritura en UTF-8, medimos una mejora promedio del rendimiento del 35% con respecto a UTF-16 usando tablas agrupadas con un índice no agrupado en la columna de cadena, y una mejora de rendimiento promedio del 11% con respecto a UTF-16 usando un montón.
A partir de la versión 1903 de Windows (actualización de mayo de 2019), puede usar la propiedad ActiveCodePage en appxmanifest para aplicaciones empaquetadas, o el manifiesto de fusión para aplicaciones no empaquetadas, para forzar que un proceso use UTF-8 como página de códigos de proceso. [...]
equivale a
solo si se ejecuta en la versión 1903 de Windows (actualización de mayo de 2019) o superior y la propiedad ActiveCodePage descrita anteriormente está configurada en UTF-8. De lo contrario, respeta la página de códigos del sistema heredado. Recomendamos usar
explícitamente.
CP_ACP
CP_UTF8
CP_UTF8