UTF-32

UTF-32 (formato de transformación Unicode de 32 bits) es una codificación de longitud fija utilizada para codificar puntos de código Unicode que utiliza exactamente 32 bits (cuatro bytes) por punto de código (pero una cantidad de los bits iniciales deben ser cero, ya que hay mucho menos de 2³² 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. Encontrar el punto de código Nth 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 un tiempo lineal para contar N puntos de código desde el comienzo de la cadena. 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. Sin embargo, los puntos de código Unicode rara vez se procesan de forma completamente aislada, como la combinación de secuencias de caracteres y emoji.

La principal desventaja de UTF-32 es que no ocupa espacio, ya que usa 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, los textos con algunos emojis populares) y, por lo general, se pueden ignorar para calcular el tamaño. Esto hace que UTF-32 sea casi el doble del tamaño de UTF-16. Puede tener hasta cuatro veces el tamaño de UTF-8 según la cantidad de caracteres que haya en el subconjunto ASCII.

Historia

El estándar ISO/IEC 10646 original define un formulario de codificación de 32 bits llamado UCS-4, en el que cada punto de código en el conjunto de caracteres universales (UCS) es representado por un valor de 31 bits de 0 a 0x7FFFFFFF (el bit de signo no se usó y era cero). En noviembre de 2003, RFC 3629 restringió Unicode para que coincidiera con las restricciones de la codificación UTF-16: prohibiendo explícitamente los puntos de código superiores a 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 del Grupo de Trabajo 2 de ISO/IEC JTC 1/SC 2 establece que todas las futuras asignaciones 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 un número fijo de bytes por punto de código parece conveniente, no es tan útil como parece. Hace que el truncamiento sea más fácil, pero no significativamente, en comparación con UTF-8 y UTF-16 (ambos pueden buscar hacia atrás el punto para truncar mirando de 2 a 4 unidades de código como máximo).

Es extremadamente raro que el código desee encontrar el N-ésimo carácter en una cadena sin tener que calcular primero N examinando todos los caracteres entre esta posición y un extremo de la cuerda. Por ejemplo, cualquier analizador LALR (como para XML) necesita mirar todos los puntos de código anteriores antes de poder hacer algo con el punto de código Nth. Un índice de número entero que se incrementa en 1 para cada carácter se puede reemplazar con un desplazamiento de número 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 cualquier ventaja de velocidad de UTF-32.

Incluso con un "ancho fijo" font encontrar el ancho de la cadena a partir de un recuento de puntos de código es imposible. Hay formas combinadas como 'é' como se expresa utilizando dos puntos de código 'e' + ' ́ ' (y emoji de múltiples puntos de código, debido a los modificadores de emoji y las secuencias de combinación de ancho cero de emoji, por ejemplo, ambos emoji son 3 puntos de código: "👨🦲 Hombre: Calvo" y " 👩🦰 Mujer: Pelirroja".). También "ancho fijo" puede asignar un ancho de 2 a los ideogramas CJK, y algunos puntos de código toman varias posiciones de carácter por punto de código ("grupos de grafemas" para CJK).

Usar

El uso principal de UTF-32 es en las API internas donde los datos son puntos de código únicos 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 la carpeta "no utilizada" 11 bits 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 UTF-32 a veces, pero rara vez, se usan internamente en las aplicaciones, debido a que el tipo wchar_t se define como de 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 hacer todos los puntos de código de 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 sacadas de la biblioteca estándar para empaquetarlas) siguiendo el "Manifiesto UTF-8 Everywhere".

Variantes

Aunque técnicamente no es válido, las mitades sustitutas a menudo se codifican y permiten. Esto permite que UTF-16 no válido (como los nombres de archivo de Windows) se traduzca a UTF-32, de forma similar a cómo funciona la variante WTF-8 de UTF-8. A veces, se codifican sustitutos emparejados 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 conservar 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.