stringtranslate.com

UTF-8

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 . [9] Prácticamente todos los países e idiomas tienen un 95% o más de uso de codificaciones UTF-8 en la web.

Nombrar

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-8se 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_UTF8en el código fuente).

En MySQL , UTF-8 se llama utf8mb4[13] (siendo utf8mb3y su alias utf8un 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]

Codificación

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]

Proceso de codificación

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.

  1. El punto del código Unicode para el signo del euro € es U+20AC.
  2. Como este punto de código se encuentra entre U+0800 y U+FFFF, se necesitarán tres bytes para codificarlo.
  3. El hexadecimal 20AC es binario 0010 0000 10 10 1100 . Los dos ceros iniciales se añaden porque una codificación de tres bytes necesita exactamente dieciséis bits del punto de código.
  4. Debido a que la codificación tendrá una longitud de tres bytes, el byte inicial comienza con tres unos y luego un 0 ( 1110... ).
  5. Los cuatro bits más significativos del punto de código se almacenan en los cuatro bits restantes de orden inferior de este byte ( 1110 0010 ), dejando 12 bits del punto de código aún por codificar ( ... 0000 10 10 1100 ).
  6. Todos los bytes de continuación contienen exactamente seis bits del punto de código. Entonces, los siguientes seis bits del punto de código se almacenan en los seis bits de orden inferior del siguiente byte, y 10 se almacena en los dos bits de orden superior para marcarlo como un byte de continuación (por lo tanto, 10 000010 ).
  7. Finalmente, los últimos seis bits del punto de código se almacenan en los seis bits de orden inferior del byte final, y nuevamente 10 se almacena en los dos bits de orden superior ( 10 101100 ).

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.

Ejemplo

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:

Diseño de página de códigos

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.

  Puntos de código de 7 bits (un solo byte). No deben ir seguidos de un byte de continuación. [20]
  Bytes de continuación. [21] La celda muestra en hexadecimal el valor de los 6 bits que suman. [d]
  Los bytes iniciales de una secuencia de varios bytes deben ir seguidos exactamente de N −1 bytes de continuación. [22] La información sobre herramientas muestra el rango de puntos de código y los bloques Unicode codificados por secuencias que comienzan con este byte.
  Bytes iniciales donde no todas las disposiciones de bytes de continuación son válidas. E0 y F0 podrían iniciar codificaciones demasiado largas. F4 puede iniciar puntos de código mayores que U+10FFFF. ED puede iniciar puntos de código en el rango U+D800–U+DFFF, que son mitades sustitutas UTF-16 no válidas . [23]
  No aparezca en una secuencia UTF-8 válida. C0 y C1 sólo se pueden utilizar para una codificación "demasiado larga" de un carácter de 1 byte. [24] F5 a FD son bytes iniciales de secuencias de 4 bytes o más que solo pueden codificar puntos de código mayores que U+10FFFF. [23] A FE y FF nunca se les asignó ningún significado. [25]

Codificaciones demasiado largas

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.

Secuencias no válidas y manejo de errores.

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]

Marca de orden de bytes

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]

Adopción

Conjunto de caracteres declarado para los 10 millones de sitios web más populares desde 2010
Uso de las principales codificaciones en la web entre 2001 y 2012 según lo registrado por Google, [36] con UTF-8 superando a todas las demás en 2008 y más del 60% de la web en 2012 (desde entonces acercándose al 100%). UTF-8 es la única codificación de Unicode (explícitamente) que figura allí, y el resto sólo proporciona subconjuntos de Unicode. La cifra de solo ASCII incluye todas las páginas web que solo contienen caracteres ASCII, independientemente del encabezado declarado.

UTF-8 ha sido la codificación más común para la World Wide Web desde 2008. [37] En febrero de 2024 , 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 , 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]

Historia

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]

FSS-UTF

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.

Estándares

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.

Comparación con otras codificaciones

Algunas de las características importantes de esta codificación son las siguientes:

Un solo byte

Otro multibyte

UTF-16

Derivados

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.

CESU-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 UTF8juego de caracteres utiliza codificación CESU-8 y está en desuso. El AL32UTF8juego 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]

MySQL utf8mb3

En MySQL , el utf8mb3conjunto 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. utf8mb3está en desuso en favor del utf8mb4juego de caracteres, que utiliza codificación UTF-8 compatible con los estándares. utf8es un alias de utf8mb3, pero está previsto que se convierta en un alias de utf8mb4en 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

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 InputStreamReadery 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 DataInputy 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.

WTF-8

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]

PEP 383

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]

Ver también

Notas

  1. ^ 17 aviones multiplicados por 2 16 puntos de código por avión, menos 2 11 sustitutos técnicamente inválidos .
  2. ^ Hay suficientes x bits para codificar hasta 0x1FFFFF, pero el RFC 3629 §3 actual limita la codificación UTF-8 al punto de código U+10FFFF, para que coincida con los límites de UTF-16. El obsoleto RFC 2279 permitía la codificación UTF-8 hasta el punto de código (entonces legal) U+7FFFFFF.
  3. ^ Algunos caracteres emoji complejos pueden requerir incluso más que esto; el emoji de la bandera transgénero (🏳️‍⚧️), que consta de la secuencia de cinco puntos de código U+1F3F3 U+FE0F U+200D U+26A7 U+FE0F, requiere dieciséis bytes para codificarse, mientras que el de la bandera de Escocia (🏴ڠ ڠڠڠڠڠ) requiere un total de veintiocho bytes para la secuencia de siete puntos de código U+1F3F4 U+E0067 U+E0062 U+E0073 U+E0063 U+E0074 U+E007F.
  4. ^ Por ejemplo, la celda 9D dice +1D. El número hexadecimal 9D en binario es 10011101 , y dado que los 2 bits más altos ( 10 ) están reservados para marcarlo como byte de continuación, los 6 bits restantes ( 011101 ) tienen un valor hexadecimal de 1D.
  5. ^ La encuesta de W3Techs.com [9] se basa en la codificación declarada en la respuesta del servidor, consulte https://w3techs.com/forum/topic/22994
  6. ^ Python utiliza varias codificaciones para lo que llama "Unicode", sin embargo, ninguna de estas codificaciones es UTF-8. Python 2 y la primera versión 3 usaban UTF-16 en Windows y UTF-32 en Unix. Las implementaciones más recientes de Python 3 utilizan tres codificaciones de longitud fija: ISO-8859-1 , UCS-2 y UTF-32, según el punto de código máximo necesario. [60]

Referencias

  1. ^ "Capítulo 2. Estructura general". El estándar Unicode (6.0 ed.). Mountain View, California, EE. UU.: El Consorcio Unicode . ISBN 978-1-936213-01-6.
  2. ^ ab Pike, Rob (30 de abril de 2003). "Historia de UTF-8".
  3. ^ Lucio, Rob; Thompson, Ken (1993). "Hola mundo o Καλημέρα κόσμε o こんにちは 世界" (PDF) . Actas de la conferencia USENIX de invierno de 1993 .
  4. ^ "UCS seguro para el sistema de archivos - Formato de transformación (FSS-UTF) - Especificación preliminar X/Open" (PDF) . unicode.org .
  5. ^ "Actas de la conferencia USENIX de invierno de 1993". usenix.org .
  6. ^ ab Alvestrand, Harald T. (enero de 1998). Política del IETF sobre conjuntos de caracteres e idiomas. IETF . doi : 10.17487/RFC2277 . BCP 18. RFC 2277.
  7. ^ abc "Compatibilidad con UTF-8 en el kit de desarrollo de juegos de Microsoft (GDK): kit de desarrollo de juegos de Microsoft". aprender.microsoft.com . Consultado el 5 de marzo de 2023 . 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.
  8. ^ ab "Estándar de codificación". codificación.spec.whatwg.org . Consultado el 15 de abril de 2020 .
  9. ^ abc "Encuesta de uso de codificaciones de caracteres desglosada por clasificación". W3Techs . Consultado el 13 de febrero de 2024 .
  10. ^ "Estándar de codificación § 4.2. Nombres y etiquetas". QUÉ WG . Consultado el 29 de abril de 2018 .
  11. ^ "Conjuntos de caracteres". Autoridad de asignación de números de Internet . 23 de enero de 2013 . Consultado el 8 de febrero de 2013 .
  12. ^ Liviu (7 de febrero de 2014). "Página de códigos UTF-8 65001 en Windows 7 - parte I" . Consultado el 30 de enero de 2018 . 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
  13. ^ "MySQL :: Manual de referencia de MySQL 8.0 :: 10.9.1 El juego de caracteres utf8mb4 (codificación Unicode UTF-8 de 4 bytes)". Manual de referencia de MySQL 8.0 . Corporación Oráculo . Consultado el 14 de marzo de 2023 .
  14. ^ ab "MySQL :: Manual de referencia de MySQL 8.0 :: 10.9.2 El juego de caracteres utf8mb3 (codificación Unicode UTF-8 de 3 bytes)". Manual de referencia de MySQL 8.0 . Corporación Oráculo . Consultado el 24 de febrero de 2023 .
  15. ^ "Conjuntos de símbolos HP PCL | Blog de soporte del lenguaje de control de la impresora (PCL y PXL)". 2015-02-19. Archivado desde el original el 19 de febrero de 2015 . Consultado el 30 de enero de 2018 .
  16. ^ "Guía de soporte para la globalización de bases de datos". docs.oracle.com . Consultado el 16 de marzo de 2023 .
  17. ^ "Lista de materiales". suikawiki (en japonés). Archivado desde el original el 17 de enero de 2009.
  18. ^ Davis, marca . "Formas de Unicode". IBM . Archivado desde el original el 6 de mayo de 2005 . Consultado el 18 de septiembre de 2013 .
  19. ^ "Cuerda". Desarrollador de Apple . Consultado el 15 de marzo de 2021 .
  20. ^ "Capítulo 3" (PDF) , El estándar Unicode , p. 54
  21. ^ "Capítulo 3" (PDF) , El estándar Unicode , p. 55
  22. ^ "Capítulo 3" (PDF) , El estándar Unicode , p. 55
  23. ^ abc Yergeau, F. (noviembre de 2003). UTF-8, un formato de transformación de ISO 10646. IETF . doi : 10.17487/RFC3629 . ETS 63. RFC 3629 . Consultado el 20 de agosto de 2020 .
  24. ^ "Capítulo 3" (PDF) , El estándar Unicode , p. 54
  25. ^ "Capítulo 3" (PDF) , El estándar Unicode , p. 55
  26. ^ Marín, Marvin (17 de octubre de 2000). "Preguntas frecuentes sobre malware: Análisis de vulnerabilidad UNICODE de Windows NT | Recorrido de carpetas del servidor web MS00-078". Instituto SANS . Archivado desde el original el 27 de agosto de 2014.
  27. ^ "CVE-2008-2938". Base de datos nacional de vulnerabilidad .
  28. ^ "PEP 529: cambie la codificación del sistema de archivos de Windows a UTF-8". Python.org . Consultado el 10 de mayo de 2022 . 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.
  29. ^ "Entrada de datos (plataforma Java SE 8)". docs.oracle.com . Consultado el 24 de marzo de 2021 .
  30. ^ "Bytes no decodificables en interfaces de caracteres del sistema". python.org . 22 de abril de 2009 . Consultado el 13 de agosto de 2014 .
  31. ^ "Unicode 6.0.0".
  32. ^ 128 de 1 byte, (16+5) × 64 de 2 bytes y 5 × 64 × 64 de 3 bytes. Puede que haya algo menos si se realizan pruebas más precisas para cada byte de continuación.
  33. ^ abc von Löwis, Martín (22 de abril de 2009). "Bytes no decodificables en interfaces de caracteres del sistema". Fundación de software Python . PEP 383.
  34. ^ "Capítulo 2" (PDF) , El estándar Unicode - Versión 15.0.0 , p. 39
  35. ^ "Preguntas frecuentes sobre UTF-8 y Unicode para Unix/Linux".
  36. ^ Davis, Mark (3 de febrero de 2012). "Unicode en más del 60 por ciento de la web". Blog oficial de Google . Archivado desde el original el 9 de agosto de 2018 . Consultado el 24 de julio de 2020 .
  37. ^ Davis, Mark (5 de mayo de 2008). "Pasar a Unicode 5.1". Blog oficial de Google . Consultado el 13 de marzo de 2023 .
  38. ^ "Estadísticas de uso y cuota de mercado de ASCII para sitios web, enero de 2024". W3Techs . Consultado el 1 de enero de 2024 .
  39. ^ Bray, Tim (diciembre de 2017). Bray, T. (ed.). El formato de intercambio de datos de notación de objetos JavaScript (JSON). IETF. doi : 10.17487/RFC8259 . RFC 8259 . Consultado el 16 de febrero de 2018 .
  40. ^ "Uso de caracteres internacionales en el correo de Internet". Consorcio de correo de Internet. 1998-08-01. Archivado desde el original el 26 de octubre de 2007 . Consultado el 8 de noviembre de 2007 .
  41. ^ "Estándar de codificación". codificación.spec.whatwg.org . Consultado el 15 de noviembre de 2018 .
  42. ^ "Especificar la codificación de caracteres del documento". HTML 5.2 (Informe). Consorcio Mundial de la red . 14 de diciembre de 2017 . Consultado el 3 de junio de 2018 .
  43. ^ "Elija la codificación de texto al abrir y guardar archivos". Soporte de Microsoft . Consultado el 1 de noviembre de 2021 .
  44. ^ "utf 8 - ¿Codificación de caracteres de archivos DOC y DOCX de Microsoft Word?". Desbordamiento de pila . Consultado el 1 de noviembre de 2021 .
  45. ^ "Exportación de un archivo .txt UTF-8 desde Word".
  46. ^ "excel: ¿los archivos XLSX están codificados en UTF-8 por definición?". Desbordamiento de pila . Consultado el 1 de noviembre de 2021 .
  47. ^ "¿Cómo abrir un archivo CSV UTF-8 en Excel sin una conversión errónea de caracteres en japonés y chino tanto para Mac como para Windows?". respuestas.microsoft.com . Consultado el 1 de noviembre de 2021 .
  48. ^ "¿Cómo puedo hacer que el Bloc de notas guarde texto en UTF-8 sin la lista de materiales?". Desbordamiento de pila . Consultado el 24 de marzo de 2021 .
  49. ^ Galloway, Matt (octubre de 2012). "Codificación de caracteres para desarrolladores de iOS. ¿O UTF-8 y ahora qué?". www.galloway.me.uk . Consultado el 2 de enero de 2021 . en realidad, normalmente se asume UTF-8 ya que es, con diferencia, la codificación más común.
  50. ^ "El Bloc de notas de Windows 10 está mejorando la compatibilidad con la codificación UTF-8". Computadora que suena . Consultado el 24 de marzo de 2021 . Microsoft ahora guarda de forma predeterminada los nuevos archivos de texto como UTF-8 sin BOM, como se muestra a continuación.
  51. ^ "Personaliza el menú Inicio de Windows 11". docs.microsoft.com . Consultado el 29 de junio de 2021 . Asegúrese de que su LayoutModification.json utilice codificación UTF-8.
  52. ^ "JEP 400: UTF-8 por defecto". openjdk.java.net . Consultado el 30 de marzo de 2022 .
  53. ^ "Característica n.° 16604: establezca el valor predeterminado para Encoding.default_external en UTF-8 en Windows". bugs.ruby-lang.org . Ruby master: sistema de seguimiento de problemas de Ruby . Consultado el 1 de agosto de 2022 .
  54. ^ "Característica n.º 12650: utilice codificación UTF-8 para ENV en Windows". bugs.ruby-lang.org . Ruby master: sistema de seguimiento de problemas de Ruby . Consultado el 1 de agosto de 2022 .
  55. ^ "Nuevas funciones en R 4.2.0". El blog de Jumping Rivers . R blogueros. 2022-04-01 . Consultado el 1 de agosto de 2022 .
  56. ^ "PEP 540: agregue un nuevo modo UTF-8". peps.python.org . Consultado el 23 de septiembre de 2022 .
  57. ^ "PEP 686: establecer el modo UTF-8 como predeterminado | peps.python.org". peps.python.org . Consultado el 26 de julio de 2023 .
  58. ^ "PEP 597: agregue EncodingWarning opcional". Python.org . Consultado el 24 de agosto de 2021 .
  59. ^ "Compatibilidad con UTF-8 como codificación de archivo fuente portátil" (PDF) .
  60. ^ ab "PEP 393: representación de cadenas flexibles". Python.org . Consultado el 18 de mayo de 2022 . 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.
  61. ^ "Representación del código fuente". La especificación del lenguaje de programación Go. golang.org (Informe) . Consultado el 10 de febrero de 2021 .
  62. ^ Tsai, Michael J. (21 de marzo de 2019). "Cadena UTF-8 en Swift 5" (blog) . Consultado el 15 de marzo de 2021 . 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.
  63. ^ "Lanzamiento de PyPy v7.1; ahora usa UTF-8 internamente para cadenas Unicode". Mattip. Blog de estado de PyPy . 2019-03-24 . Consultado el 21 de noviembre de 2020 .
  64. ^ "Códecs y objetos Unicode". Documentación de Python . Consultado el 19 de agosto de 2023 . La representación UTF-8 se crea bajo demanda y se almacena en caché en el objeto Unicode.
  65. ^ "PEP 623: eliminar wstr de Unicode". Python.org . Consultado el 21 de noviembre de 2020 . 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.
  66. ^ Wouters, Thomas (11 de julio de 2023). "Python Insider: Python 3.12.0 beta 4 lanzado". Información privilegiada de Python . Consultado el 26 de julio de 2023 . Los miembros obsoletos wstr y wstr_length de la implementación C de objetos Unicode fueron eliminados, según PEP 623.
  67. ^ "/validate-charset (validar caracteres compatibles)". docs.microsoft.com . Consultado el 19 de julio de 2021 . 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.
  68. ^ "Presentación de compatibilidad con UTF-8 para SQL Server". techcommunity.microsoft.com . 2019-07-02 . Consultado el 24 de agosto de 2021 . 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.
  69. ^ "Utilice la página de códigos UTF-8 de Windows: aplicaciones para UWP". docs.microsoft.com . Consultado el 6 de junio de 2020 . 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_ACPCP_UTF8CP_UTF8
  70. ^ "Apéndice F. FSS-UTF/Formato de transformación UCS seguro del sistema de archivos" (PDF) . El estándar Unicode 1.1 . Archivado (PDF) desde el original el 7 de junio de 2016 . Consultado el 7 de junio de 2016 .
  71. ^ Whistler, Kenneth (12 de junio de 2001). "FSS-UTF, UTF-2, UTF-8 y UTF-16". Archivado desde el original el 7 de junio de 2016 . Consultado el 7 de junio de 2006 .
  72. ^ ab Pike, Rob (30 de abril de 2003). "Historia de UTF-8" . Consultado el 7 de septiembre de 2012 .
  73. ^ Pike, Rob (6 de septiembre de 2012). «UTF-8 cumplió ayer 20 años» . Consultado el 7 de septiembre de 2012 .
  74. ^ ISO/IEC 10646:2014 §9.1, 2014.
  75. ^ El estándar Unicode, versión 15.0 §3.9 D92, §3.10 D95, 2021.
  76. ^ Anexo n.º 27 del estándar Unicode: Unicode 3.1, 2001.
  77. ^ El estándar Unicode, versión 5.0 §3.9–§3.10 cap. 3, 2006.
  78. ^ El estándar Unicode, versión 6.0 §3.9 D92, §3.10 D95, 2010.
  79. ^ McGowan, Rick (19 de diciembre de 2011). "Esquema de codificación de compatibilidad para UTF-16: 8 bits (CESU-8)". Consorcio Unicode . Informe técnico Unicode n.º 26.
  80. ^ "Compatibilidad con conjuntos de caracteres". Documentación de Oracle Database 19c, referencia del lenguaje SQL . Corporación Oráculo .
  81. ^ "Soporte de bases de datos multilingües con Unicode § Soporte para el estándar Unicode en la base de datos Oracle". Guía de soporte para la globalización de bases de datos . Corporación Oráculo .
  82. ^ "8.2.2.3. Codificaciones de caracteres". Estándar HTML 5.1 . W3C .
  83. ^ "8.2.2.3. Codificaciones de caracteres". Estándar HTML 5 . W3C .
  84. ^ "12.2.3.3 Codificaciones de caracteres". Estándar de vida HTML . QUÉ WG .
  85. ^ "Documentación de Java SE para la interfaz java.io.DataInput, subsección sobre UTF-8 modificado". Corporación Oráculo . 2015 . Consultado el 16 de octubre de 2015 .
  86. ^ "La especificación de la máquina virtual Java, sección 4.4.7:" La estructura CONSTANT_Utf8_info"". Corporación Oráculo . 2015 . Consultado el 16 de octubre de 2015 .
  87. ^ "Especificación de serialización de objetos Java, capítulo 6: Protocolo de secuencia de serialización de objetos, sección 2: Elementos de secuencia". Corporación Oráculo . 2010 . Consultado el 16 de octubre de 2015 .
  88. ^ "Especificación de interfaz nativa de Java, capítulo 3: Tipos JNI y estructuras de datos, sección: Cadenas UTF-8 modificadas". Corporación Oráculo . 2015 . Consultado el 16 de octubre de 2015 .
  89. ^ "La especificación de la máquina virtual Java, sección 4.4.7:" La estructura CONSTANT_Utf8_info"". Corporación Oráculo . 2015 . Consultado el 16 de octubre de 2015 .
  90. ^ "ARTE y Dalvik". Proyecto de código abierto de Android . Archivado desde el original el 26 de abril de 2013 . Consultado el 9 de abril de 2013 .
  91. ^ "UTF-8 poco a poco". Wiki de Tcler . 2001-02-28 . Consultado el 3 de septiembre de 2022 .
  92. ^ Sapin, Simon (11 de marzo de 2016) [25 de septiembre de 2014]. "La codificación WTF-8". Archivado desde el original el 24 de mayo de 2016 . Consultado el 24 de mayo de 2016 .
  93. ^ Sapin, Simon (25 de marzo de 2015) [25 de septiembre de 2014]. "La codificación WTF-8 § Motivación". Archivado desde el original el 16 de agosto de 2020 . Consultado el 26 de agosto de 2020 .
  94. ^ "WTF-8.com". 2006-05-18 . Consultado el 21 de junio de 2016 .
  95. ^ Speer, Robyn (21 de mayo de 2015). "ftfy (corrige texto por usted) 4.0: cambiar menos y arreglar más". Archivado desde el original el 30 de mayo de 2015 . Consultado el 21 de junio de 2016 .
  96. ^ "WTF-8, un formato de transformación de la página de códigos 1252". Archivado desde el original el 13 de octubre de 2016 . Consultado el 12 de octubre de 2016 .
  97. ^ "PEP 540: agregue un nuevo modo UTF-8". Python.org . Consultado el 24 de marzo de 2021 .
  98. ^ "RTFM optu8to16 (3), optu8to16vis (3)". www.mirbsd.org .
  99. ^ ab Davis, Mark ; Suignard, Michel (2014). "3.7 Habilitación de la conversión sin pérdidas". Consideraciones de seguridad Unicode . Informe técnico Unicode n.º 36.

enlaces externos