Si entiendo correctamente, UTF-32 puede manejar todos los caracteres del universo. Lo mismo ocurre con UTF-16, a través del uso de pares sustitutos. Entonces, ¿hay alguna buena razón para usar UTF-32 en lugar de UTF-16?¿Por qué UTF-32 en lugar de UTF-16 si tenemos pares de sustitución?
En UTF-32, un carácter Unicode siempre estaría representado por 4 bytes, por lo que sería más fácil escribir el código de análisis que el de una cadena UTF-16 porque en UTF-16 un carácter se representa por un número variable de bytes. En la parte inferior, un chatacter UTF-32 sería siempre requiere 4 bytes, lo que puede ser un desperdicio si está trabajando principalmente con decir caracteres ingleses. Por lo tanto, es una opción de diseño según sus requisitos, ya sea que use UTF-16 o UTF-32.
En realidad, UTF-32 es un desperdicio para la mayoría de los textos, no solo para los caracteres ingleses. Porque la mayoría de los lenguajes vivos tienen todos (o al menos la mayoría) de sus glifos dentro del rango que no requiere pares suplentes en UTF-16. –
Hubo otra razón para que el Consorcio Unicode agregue la codificación UTF-32: ayuda a tener una asignación simple de punto de código a cadena que es uno a uno. Con los pares de sustitución (UTF-16) y el UTF-8 más complejo no existe un mapeo de uno a uno, se requiere un cálculo.Usando las tablas Unicode y los puntos de código mencionados, es trivial, de hecho, un no-op, para llegar a la representación del personaje. Por supuesto, esto es práctico en teoría y en documentación, pero en la práctica el desperdicio de espacio suele ser demasiado grande para recurrir a UTF-32. – Abel
Respuesta corta: no.
Respuesta más larga: sí, por compatibilidad con otras cosas que no recibieron la nota.
respuesta Menos sarcástico: Cuando se preocupan más por la velocidad de indexación que aproximadamente el uso del espacio, o como un formato intermedio de algún tipo, o en máquinas en las que los problemas de alineación eran más importantes que los problemas de caché, o ...
¡UTF-8 también puede representar cualquier carácter Unicode!
Si su texto es en su mayoría inglés, puede ahorrar mucho espacio utilizando utf-8, pero los caracteres de indexación no son O (1), porque algunos caracteres ocupan más de un byte.
Si el espacio no es tan importante para su situación como la velocidad es, UTF-32 ¿Quieres que se adapte mejor, debido a la indexación es O (1)
UTF-16 puede ser mejor que UTF-8 para los no-Inglés texto porque en utf-8 tienes una situación donde algunos personajes ocupan 3 bytes, donde como en utf16 solo tomarían dos bytes.
Aparentemente UTF-32 es programáticamente más rápido, incluso si ahorraras mucho espacio usando UTF-8, debido a que puedes procesar usando un tamaño de palabra más eficiente (es decir, 32 bits, en lugar de manejar cada fragmento de 8 bits en un tiempo) -aunque, con una biblioteca (sustancialmente) más compleja de UTF-8, eso no es un problema. – Arafangion
Alguien podría preferir lidiar con UTF-32 en lugar de UTF-16 porque tratar con parejas sustitutas es casi siempre manejar 'casos especiales', y tener que lidiar con esos casos especiales significa que tiene áreas donde los errores pueden arrastrarse porque tratas con ellos incorrectamente (o más bien simplemente te olvidas de tratar con ellos en absoluto).
Si el aumento en el uso de memoria de UTF-32 no es un problema, la complejidad reducida puede ser una ventaja suficiente para elegirlo.
Probablemente existan algunas buenas razones, pero una sería acelerar la indexación/búsqueda, es decir, en bases de datos y similares.
Con UTF-32, usted sabe que cada carácter tiene 4 bytes. Con UTF-16 no sabes qué longitud tendrá un personaje en particular.
Por ejemplo, usted tiene una función que devuelve el carbón enésimo de la cadena:
char getChar(int index, String s);
Si está codificando en un idioma que tiene acceso directo a la memoria, por ejemplo C, a continuación, en UTF-32 esta función puede ser tan simple como algunos punteros aritmáticos (s+(4*index)), que serían algunas cantidades O (1).
Sin embargo, si está utilizando UTF-16, tendría que caminar la cuerda, decodificando sobre la marcha, que sería O (n).
Aquí hay una buena documentación del Consorcio Unicode también.
Comparison of the Advantages of UTF-32, UTF-16, and UTF-8
Copyright © 1991-2009 Unicode, Inc. El estándar Unicode, versión 5.2
En vista de ello, UTF-32 parece ser la opción obvia de Unicode formas de codificación para un código de procesamiento interno porque es un formulario de codificación de ancho fijo. Puede ajustarse de forma congruente a C y C++
wchar_t, lo que significa que dichos lenguajes de programación pueden ofrecer compatibilidad incorporada y cadenas API preparadas que los programadores pueden aprovechar. Sin embargo, UTF-16 tiene muchas ventajas compensatorias que pueden llevar a los implementadores a elegir, en cambio, como un código de procesamiento interno. Mientras que las tres formas de codificación necesitan como máximo 4 bytes (o 32 bits) de datos para cada carácter, en la práctica UTF-32 en casi todos los casos para conjuntos de datos reales ocupa el doble del almacenamiento que requiere UTF-16. Por lo tanto, una estrategia común es utilizar el almacenamiento interno de cadenas UTF-16 o UTF-8, pero usar UTF-32 al manipular caracteres individuales.UTF-32 Versus UTF-16. En promedio, más del 99 por ciento de todos los datos de UTF-16 se expresan usando unidades de código único. Esto incluye casi todos los caracteres típicos que el software necesita manejar con operaciones especiales en el texto, por ejemplo, caracteres de control de formato. Como consecuencia, la mayoría de las operaciones de escaneo de texto no necesitan descomprimir en absoluto los pares suplentes UTF-16, sino que pueden tratarlos de forma segura como una parte opaca de una cadena de caracteres. Para muchas operaciones, UTF-16 es tan fácil de manejar como UTF-32, y el rendimiento de UTF-16 como código de procesamiento tiende a ser bastante bueno. UTF-16 es el código de procesamiento interno preferido para la mayoría de las implementaciones que admiten Unicode. Aparte de las plataformas Unix, UTF-16 proporciona la combinación correcta de tamaño compacto con la capacidad de manejar el carácter ocasional fuera del BMP. UTF-32 tiene algo de una ventaja cuando se trata de la simplicidad del diseño y mantenimiento de la codificación del software. Debido a que el manejo de caracteres es de ancho fijo, el procesamiento UTF-32 no requiere mantener ramas en el software para probar y procesar los elementos de unidad de código doble requeridos para caracteres suplementarios por UTF-16. Por el contrario, los índices de 32 bits en tablas grandes no son particularmente eficientes en memoria. Para evitar las grandes penalizaciones de memoria de dichos índices, las tablas Unicode a menudo se manejan como tablas de varias etapas (consulte "Tablas de varias etapas" en la Sección 5.1, Transcodificación a otras normas). En tales casos, los valores del punto de código de 32 bits se cortan en rangos más pequeños para permitir el acceso segmentado a las tablas. Esto es cierto incluso en las implementaciones UTF-32 típicas. El rendimiento de UTF-32 como código de procesamiento puede ser peor que el rendimiento de UTF-16 para los mismos datos, porque la sobrecarga de memoria adicional significa que los límites de caché se excederán más a menudo y la paginación de memoria ocurrirá con más frecuencia . Para sistemas con diseños de procesador que imponen penalizaciones para el acceso alineado de 16 bits pero que tienen memorias muy grandes, este efecto puede ser menos notorio. En cualquier caso, los puntos de código Unicode no necesariamente coinciden con las expectativas del usuario para "caracteres". Por ejemplo, los siguientes no están representados por un solo punto de código: una secuencia de caracteres combinada como; una secuencia conjunta de jamo para coreano; o el devanagari en conjunción "ksha". Debido a que algunos procesamientos de texto Unicode deben conocer y manejar tales secuencias de caracteres como elementos de texto, la ventaja de la forma de codificación de ancho fijo de UTF-32 se ve contrarrestada por la variable intrínsecamente variable. naturaleza de ancho de procesamiento de elementos de texto. Consulte el estándar técnico n. ° 18 de Unicode "Descifrar expresiones regulares" para obtener un ejemplo donde los procesos comúnmente implementados tratan con elementos de texto de ancho variable inherentes debido a las expectativas del usuario de la identidad de un "carácter". UTF-8. UTF-8 es razonablemente compacto en términos de la cantidad de bytes utilizados. En realidad, solo se encuentra en una desventaja de tamaño significativo cuando se usa para implementaciones de Asia oriental como China, Japón y Corea, que usan ideogramas Han o sílabas de Hangul que requieren secuencias de unidad de código de tres bytes en UTF-8. UTF-8 también es significativamente menos eficiente en términos de procesamiento que las otras formas de codificación. Clasificación binaria.Un tipo binario de cadenas UTF-8 da el mismo orden que un tipo binario de puntos de código Unicode. Obviamente, este es el mismo orden que para un tipo binario de cadenas UTF-32.
Estructura general
Las tres formas de codificación dan los mismos resultados para las comparaciones de cadenas binarias o cadena de ING Sort- cuando se trata únicamente con caracteres BMP (en el rango U + 0000..U + FFFF). Sin embargo, cuando se trata de caracteres suplementarios (en el rango U + 10000..U + 10FFFF), el orden binario UTF-16 no coincide con el orden del punto de código Unicode. Esto puede provocar complicaciones cuando intente interoperar con listas clasificadas binarias, por ejemplo, entre sistemas UTF-16 y sistemas UTF-8 o UTF-32. Sin embargo, para los datos que se ordenan de acuerdo con las convenciones de un idioma o localidad específico en lugar de utilizar un orden binario, los datos se ordenarán de la misma forma, independientemente de la forma de codificación.
@ c4lil Resuma su respuesta. Se desaconsejan las respuestas de solo enlace. –
En general, sólo tiene que utilizar la cadena de tipo de datos/codificación de la plataforma subyacente, que es a menudo (Windows, Java, cacao ...) UTF-16 y, a veces UTF-8 o UTF-32. Esto es principalmente por razones históricas; hay poca diferencia entre las tres codificaciones Unicode: las tres están bien definidas, son rápidas y robustas, y todas ellas pueden codificar cada secuencia de punto de código Unicode. La característica única de UTF-32 que es una codificación de ancho fijo (lo que significa que cada punto de código está representado exactamente por una unidad de código) es de poca utilidad en la práctica: la capa de administración de la memoria necesita conocer el número y ancho del código unidades, y los usuarios están interesados en caracteres abstractos y grafemas. Como se menciona en el estándar Unicode, las aplicaciones Unicode tienen que tratar con caracteres combinados, ligaduras, etc. de todos modos, y el manejo de los pares sustituidos, a pesar de ser conceptualmente diferentes, se puede hacer dentro del mismo marco técnico.
Si tuviera que reinventar el mundo, probablemente iría por UTF-32 porque es simplemente la codificación menos compleja, pero tal como está, las diferencias son demasiado pequeñas como para ser una preocupación práctica.
Otra buena pregunta es por qué UTF-16 en lugar de UTF-8 ... –
UTF-16 es útil si la mayoría de sus caracteres están en el rango 800-FFFF que UTF-8 necesita un byte adicional. UTF-32 no tiene mucho sentido. –
No "en el Universo", solo "en la Tierra" (y ni siquiera, consulte las preguntas frecuentes de Unicode). – PhiLho