UTF-32 - UTF-32

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 32 puntos de código Unicode, que en realidad solo necesitan 21 bits). 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 (pero las letras en general, es decir, " grupos de grafemas ", o algunos emojis no se pueden indexar directamente, ni tampoco es más fácil calcular el ancho mostrado de una cadena). 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 (excepto, por ejemplo, textos con algunos emojis populares) 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 : prohibir 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. Aunque el estándar ISO tenía (a partir de 1998 en Unicode 2.1) "reservado para uso privado" 0xE00000 a 0xFFFFFF y 0x60000000 a 0x7FFFFFFF, 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 restringidas 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). En la práctica, debido, por ejemplo, a las secuencias de emoji ZWJ (y / o modificadores de emoji que posiblemente cambian el color de la piel ), algunos emojis ya no son un solo punto de código, como "👨‍🦲 Hombre: Calvo" y "👩‍🦰 Mujer: Cabello rojo". y, por lo tanto, no se puede confiar en que el texto sea una lista de símbolos, cada uno representado por un punto de código.

Es extremadamente raro 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. 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 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 .

Usar

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.

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. Se pueden compilar versiones de Python hasta 3.2 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 que todos los puntos de código tengan ese tamaño . Los lenguajes de programación Seed7 y Lasso codifican todas las cadenas con UTF-32, en la creencia de que la indexación directa es importante, mientras que el lenguaje de programación Julia se alejó del soporte UTF-32 incorporado con su versión 1.0, simplificando el lenguaje para tener solo cadenas UTF-8 (con todas las demás codificaciones consideradas heredadas y trasladadas de la biblioteca estándar al paquete) siguiendo el "Manifiesto UTF-8 Everywhere".

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

Referencias

enlaces externos