codigo - unicode vs ascii
¿Por qué existe UTF-32 mientras que solo se necesitan 21 bits para codificar cada carácter? (4)
Dos razones que se me ocurren:
- Permite una futura expansión.
- (Más importante aún) Las computadoras generalmente son mucho mejores para manejar datos en límites de 4 bytes. Los beneficios en términos de menor consumo de memoria son relativamente pequeños en comparación con el dolor de trabajar en límites de 3 bytes.
Creo que esto es un poco como preguntar por qué a menudo tenemos tipos de datos enteros de 8 bits, 16 bits, 32 bits y 64 bits (byte, int, long, lo que sea) pero no los de 24 bits. Estoy seguro de que hay muchas ocasiones en las que sabemos que un número nunca irá más allá de 2 21 , pero es más simple de usar int que crear un tipo de 24 bits.
Sabemos que los puntos de código pueden estar en este intervalo 0..10FFFF que es menor que 2 ^ 21. Entonces, ¿por qué necesitamos UTF-32 cuando todos los puntos de código pueden representarse por 3 bytes? UTF-24 debería ser suficiente.
Es cierto que solo se requieren 21 bits ( reference ), pero las computadoras modernas son buenas para mover unidades de 32 bits de cosas y generalmente interactúan con ellas. No creo que haya usado un lenguaje de programación que tuviera un entero o tipo de caracteres de 24 bits, ni una plataforma en la que fuera un múltiplo del tamaño de palabra del procesador (no desde la última vez que utilicé una computadora de 8 bits; UTF -24 sería razonable en una máquina de 8 bits), aunque naturalmente ha habido algunos.
Primero hubo 2 esquemas de codificación de caracteres: UCS-4 que codificaba cada carácter en 32 bits, como un entero sin signo en el rango 0x00000000 - 0x7FFFFFFF, y UCS-2 que usaba 16 bits para cada punto de código.
Más tarde, se descubrió que el uso de solo los 65536 puntos de código de UCS-2 daría problemas a uno de todos modos, pero muchos programas (Windows, tos ) se basaban en caracteres anchos de 16 bits de ancho, por lo que se creó UTF-16. UTF-16 codifica el valor U+0000 - U+FFFF normalmente; y U+10000 - U+10FFFF utilizando pares sustitutos , es decir, un par de dos valores de 16 bits.
Como esto fue un poco complicado, se introdujo UTF-32, como un mapeo uno a uno simple para caracteres más allá de U+FFFF . Ahora, dado que UTF-16 solo puede codificar hasta U+10FFFF , se decidió que este será el valor máximo que se asignará, de modo que no habrá más problemas de compatibilidad, por lo que UTF-32 solo usa 21 pedacitos Como bono adicional, UTF-8, que inicialmente fue planeado para ser una codificación de 1-6 bytes, ahora nunca necesita más de 4 bytes para cada punto de código. Por lo tanto, se puede probar fácilmente que nunca requiere más almacenamiento que UTF-32.
Es cierto que un hipotético formato UTF-24 ahorraría memoria. Sin embargo, sus ahorros serían dudosos de todos modos, ya que consumirían más espacio de almacenamiento que UTF-8, a excepción de solo explosiones de emoji o similares, y no muchos textos interesantes de longitud significativa consisten únicamente en emojis.
Pero, UTF-32 se usa como en la representación de memoria para el texto en programas que necesitan tener acceso simplemente indexado a puntos de código: es la única codificación donde el elemento Nth en una matriz de C también es el punto de código Nth: UTF-24 haría lo mismo para un ahorro de memoria del 25% pero accesos de elementos más complicados.
UTF-32 es un múltiplo de 16 bits. Trabajar con cantidades de 32 bits es mucho más común que trabajar con cantidades de 24 bits y generalmente se admite mejor. También ayuda a mantener cada carácter alineado en 4 bytes (asumiendo que toda la cadena está alineada en 4 bytes). Pasar de 1 byte a 2 bytes a 4 bytes es la procesión más "lógica".
Aparte de eso: el estándar Unicode está en constante crecimiento. Podrían asignarse puntos de código fuera de ese rango (aunque es poco probable en un futuro próximo, sin embargo, debido a la gran cantidad de puntos de código sin asignar disponibles).