UTF-32

Almacenamiento de Unicode como 4 bytes por punto de código

UTF-32 ( formato de transformación Unicode de 32 bits ) es una codificación de longitud fija que se utiliza para codificar puntos de código Unicode que utiliza exactamente 32 bits (cuatro bytes ) por punto de código (pero un número de bits iniciales debe ser cero, ya que hay muchos menos más de 2 ³² puntos de código Unicode, que en realidad solo necesitan 21 bits). ^[1] UTF-32 es una codificación de longitud fija, a diferencia de todos los demás formatos de transformación Unicode, que son codificaciones de longitud variable. Cada valor de 32 bits en UTF-32 representa un punto de código Unicode y es exactamente igual al valor numérico de ese punto de código.

La principal ventaja de UTF-32 es que los puntos de código Unicode se indexan directamente. Encontrar el enésimo punto de código en una secuencia de puntos de código es una operación de tiempo constante . Por el contrario, un código de longitud variable requiere acceso secuencial para encontrar el punto de código N en una secuencia. Esto hace que UTF-32 sea un reemplazo simple en el código que usa números enteros que se incrementan en uno para examinar cada ubicación en una cadena, como se hacía comúnmente para ASCII .

La principal desventaja de UTF-32 es que no es eficiente en el espacio, utiliza cuatro bytes por punto de código, incluidos 11 bits que siempre son cero. Los caracteres más allá del BMP son relativamente raros en la mayoría de los textos y, por lo general, se pueden ignorar para estimar el tamaño. Esto hace que UTF-32 sea casi el doble del tamaño de UTF-16 . Puede ser hasta cuatro veces el tamaño de UTF-8 dependiendo de cuántos caracteres estén en el subconjunto ASCII .

Historia

El estándar ISO 10646 original define una forma de codificación de 32 bits llamada UCS-4 , en la que cada punto de código en el juego de caracteres universal (UCS) está representado por un valor de 31 bits de 0 a 0x7FFFFFFF (el bit de signo no se usó y fue cero ). En noviembre de 2003, Unicode fue restringido por RFC 3629 para coincidir con las restricciones de la codificación UTF-16 : prohibiendo explícitamente los puntos de código mayores que U + 10FFFF (y también los sustitutos alto y bajo U + D800 a U + DFFF). Este subconjunto limitado define UTF-32. ^{[2] [1]} Aunque la norma ISO tenía (a partir de 1998 en Unicode 2.1) "reservado para uso privado" 0xE00000 a 0xFFFFFF y 0x60000000 a 0x7FFFFFFF ^[3]estas áreas se eliminaron en versiones posteriores. Debido a que el documento de Principios y Procedimientos de ISO / IEC JTC 1 / SC 2 Working Group 2 establece que todas las asignaciones futuras de puntos de código estarán limitadas al rango Unicode, UTF-32 podrá representar todos los puntos de código UCS y UTF-32 y UCS-4 son idénticos.

Análisis

Aunque parece conveniente un número fijo de bytes por punto de código, no es tan útil como parece. Hace que el truncamiento sea más fácil, pero no tanto en comparación con UTF-8 y UTF-16 (los cuales pueden buscar hacia atrás el punto que se truncará observando 2–4 unidades de código como máximo).

Es extremadamente raro ^{[ cita requerida ]} que el código desee encontrar el enésimo punto de código sin examinar antes los puntos de código 0 a N – 1. Por ejemplo, el análisis de XML no puede hacer nada con un carácter sin primero mirar todos los caracteres anteriores. ^[4] Por lo tanto, un índice entero que se incrementa en 1 para cada carácter se puede reemplazar con un desplazamiento entero, medido en unidades de código e incrementado por el número de unidades de código a medida que se examina cada carácter. Esto elimina las ventajas de velocidad percibidas ^{[ cita requerida ]} de UTF-32.

UTF-32 no facilita el cálculo del ancho mostrado de una cadena, ya que incluso con una fuente de "ancho fijo" puede haber más de un punto de código por posición de carácter ( combinación de caracteres ) o más de una posición de carácter por punto de código (" grupos de grafemas "para ideogramas CJK ). Los editores que se limitan a idiomas de izquierda a derecha y caracteres precompuestos pueden aprovechar las unidades de código de tamaño fijo, pero es poco probable que dichos editores admitan caracteres que no sean BMP y, por lo tanto, pueden funcionar igualmente bien con UTF-16 .

Utilice

El uso principal de UTF-32 es en API internas donde los datos son puntos de código único o glifos, en lugar de cadenas de caracteres. Por ejemplo, en la representación de texto moderna, es común que el último paso sea crear una lista de estructuras, cada una de las cuales contiene coordenadas (x, y) , atributos y un único punto de código UTF-32 que identifica el glifo que se va a dibujar. A menudo, la información que no es Unicode se almacena en los 11 bits "no utilizados" de cada palabra. ^{[ cita requerida ]}

El uso de cadenas UTF-32 en Windows (donde wchar_t es de 16 bits) es casi inexistente. En los sistemas Unix, las cadenas de caracteres UTF-32 a veces, pero rara vez, se utilizan internamente por las aplicaciones, debido a que el tipo wchar_t se define como 32 bits. Las versiones de Python hasta 3.2 se pueden compilar para usarlas en lugar de UTF-16 ; desde la versión 3.3 en adelante, todas las cadenas Unicode se almacenan en UTF-32 pero con cero bytes iniciales optimizados "dependiendo del [punto de código] con el ordinal Unicode más grande (1, 2 o 4 bytes)" para hacer que todos los puntos de código tengan ese tamaño . ^[5] Seed7 ^[6] y Lasso ^{[ cita requerida ]}Los lenguajes de programación codifican todas las cadenas con UTF-32, en la creencia de que la indexación directa es importante, mientras que el lenguaje Julia (antes de la versión 1.0) tenía UTF-32 como una de las codificaciones nativas para cadenas (además de UTF-8 y UTF- 16) en la biblioteca estándar, pero simplificado para tener solo cadenas UTF-8 (con todas las demás codificaciones consideradas heredadas y movidas de la biblioteca estándar al paquete ^[7] ); siguiendo el "Manifiesto UTF-8 Everywhere". ^[8]

Variantes

Aunque técnicamente no es válido, las mitades sustitutas a menudo están codificadas y permitidas. Esto permite que UTF-16 no válido (como los nombres de archivo de Windows) se traduzcan a UTF-32, de forma similar a como funciona la variante WTF-8 de UTF-8. A veces, los sustitutos emparejados se codifican en lugar de caracteres que no son BMP, similar a CESU-8 . Debido a la gran cantidad de valores de 32 bits no utilizados, también es posible preservar UTF-8 no válido mediante el uso de valores que no sean Unicode para codificar errores UTF-8, aunque no existe un estándar para esto.

Ver también

• Comparación de codificaciones Unicode

Referencias

1. código de asignación apunta a formas de codificación Unicode , § 1: UTF-32
2. ISO / IEC 10646: 2014 Cláusula 9.4: "Debido a que los puntos de código sustitutos no son valores escalares UCS, las unidades de código UTF-32 en el rango 0000 D800-0000 DFFF están mal formadas". Cláusula 4.57: "[Espacio de código UCS] que consta de los números enteros de 0 a 10 FFFF (hexadecimal)". Cláusula 4.58: "[Valor escalar UCS] cualquier punto de código UCS excepto los puntos de código sustituto alto y sustituto bajo".
3. EL CONJUNTO DE CARACTERES UNIVERSAL (UCS)
4. https://www.ibm.com/developerworks/xml/library/x-utf8/
5. Löwis, Martin. "PEP 393 - Representación de cadenas flexible" . python.org . Python . Consultado el 26 de octubre de 2014 .
6. "El uso de UTF-32 tiene varias ventajas" .
7. JuliaStrings / LegacyStrings.jl: tipos de cadenas Unicode heredados , JuliaStrings, 2019-05-17 , consultado el 2019-10-15
8. "Manifiesto UTF-8 en todas partes" .

Enlaces externos

• El estándar Unicode 5.0.0, capítulo 3  - define formalmente UTF-32 en § 3.9, D90 (PDF página 40) y § 3.10, D99-D101 (PDF página 45)
• Anexo # 19 del estándar Unicode  - UTF-32 formalmente definido para Unicode 3.x (marzo de 2001; última actualización de marzo de 2002)
• Registro de nuevos conjuntos de caracteres: UTF-32, UTF-32BE, UTF-32LE  - anuncio de la adición de UTF-32 al registro de conjuntos de caracteres de la IANA (abril de 2002)