tabla letras consorcio unicode

consorcio - unicode letras



¿Las codificaciones UTF-8, UTF-16 y UTF-32 Unicode difieren en la cantidad de caracteres que pueden almacenar? (6)

Bueno. Sé que esto parece el típico "¿Por qué no acaba de buscarlo en Google o ir a www.unicode.org y buscarlo?" pregunta, pero para una pregunta tan simple, la respuesta aún se me escapa después de verificar ambas fuentes.

Estoy bastante seguro de que estos tres sistemas de codificación admiten todos los caracteres Unicode, pero debo confirmarlo antes de hacer ese reclamo en una presentación.

Pregunta de bonificación: ¿difieren estas codificaciones en el número de caracteres que pueden ampliarse para admitir?

Como todos han dicho, UTF-8, UTF-16 y UTF-32 pueden codificar todos los puntos de código Unicode. Sin embargo, la variante UCS-2 (a veces denominada erróneamente como UCS-16) no puede , y esta es la que encuentras, por ejemplo, en Windows XP / Vista .

Ver Wikipedia para más información.

Editar: estoy equivocado sobre Windows, NT fue el único que admitió UCS-2. Sin embargo, muchas aplicaciones de Windows asumirán una sola palabra por punto de código como en UCS-2, por lo que es probable que encuentre errores. Ver otro artículo de Wikipedia . (Gracias Jason True)

No hay caracteres Unicode que se puedan almacenar en una codificación, pero no en otra. Esto es simplemente porque los caracteres Unicode válidos se han restringido a lo que se puede almacenar en UTF-16 (que tiene la capacidad más pequeña de las tres codificaciones). En otras palabras, UTF-8 y UTF-32 podrían usarse para representar una gama más amplia de caracteres que UTF-16, pero no lo son . Sigue leyendo para más detalles.

UTF-8

UTF-8 es un código de longitud variable. Algunos caracteres requieren 1 byte, algunos requieren 2, algunos 3 y algunos 4. Los bytes de cada carácter se escriben simplemente uno tras otro como un flujo continuo de bytes.

Mientras que algunos caracteres UTF-8 pueden tener 4 bytes de longitud, UTF-8 no puede codificar 2 ^ 32 caracteres . Ni siquiera está cerca. Trataré de explicar los motivos de esto.

El software que lee una secuencia UTF-8 solo obtiene una secuencia de bytes: cómo se supone que debe decidir si los siguientes 4 bytes son un solo carácter de 4 bytes, o dos caracteres de 2 bytes, o cuatro caracteres de 1 byte (o alguna otra combinación)? Básicamente, esto se hace decidiendo que ciertas secuencias de 1 byte no son caracteres válidos, y ciertas secuencias de 2 bytes no son caracteres válidos, y así sucesivamente. Cuando aparecen estas secuencias no válidas, se supone que forman parte de una secuencia más larga .

Has visto un ejemplo bastante diferente de esto, estoy seguro: se llama escapar. En muchos lenguajes de programación, se decide que el carácter / del código fuente de una cadena no se traduce en ningún carácter válido en la forma "compilada" de la cadena. Cuando a / se encuentra en la fuente, se supone que forma parte de una secuencia más larga, como /n o /xFF . Tenga en cuenta que /x es una secuencia inválida de 2 caracteres, y /xF es una secuencia inválida de 3 caracteres, pero /xFF es una secuencia válida de 4 caracteres.

Básicamente, hay una compensación entre tener muchos personajes y tener caracteres más cortos. Si desea 2 ^ 32 caracteres, deben tener un promedio de 4 bytes. Si desea que todos sus caracteres tengan 2 bytes o menos, no podrá tener más de 2 ^ 16 caracteres. UTF-8 ofrece un compromiso razonable: todos ASCII caracteres ASCII (ASCII 0 a 127) tienen representaciones de 1 byte, lo que es excelente para la compatibilidad, pero se permiten muchos más caracteres.

Al igual que la mayoría de las codificaciones de longitud variable, incluidos los tipos de secuencias de escape que se muestran arriba, UTF-8 es un código instantáneo . Esto significa que, el decodificador simplemente lee byte por byte y tan pronto como alcanza el último byte de un caracter, sabe lo que es el caracter (y sabe que no es el comienzo de un caracter mas largo).

Por ejemplo, el carácter ''A'' se representa utilizando el byte 65, y no hay caracteres de dos / tres / cuatro bytes cuyo primer byte es 65. De lo contrario, el decodificador no podría distinguir esos caracteres de un ''A ''seguido de otra cosa.

Pero UTF-8 está restringido aún más. Asegura que la codificación de un carácter más corto nunca aparece en ningún lugar dentro de la codificación de un personaje más largo. Por ejemplo, ninguno de los bytes en un carácter de 4 bytes puede ser 65.

Como UTF-8 tiene 128 caracteres diferentes de 1 byte (cuyos valores de byte son 0-127), todos los caracteres de 2, 3 y 4 bytes deben estar compuestos únicamente por bytes en el rango 128-256. Esa es una gran restricción. Sin embargo, permite que las funciones de cadena orientadas a bytes funcionen con poca o ninguna modificación. Por ejemplo, la función strstr() C siempre funciona como se espera si sus entradas son cadenas UTF-8 válidas.

UTF-16

UTF-16 es también un código de longitud variable; sus caracteres consumen 2 o 4 bytes. Los valores de 2 bytes en el rango 0xD800-0xDFFF están reservados para construir caracteres de 4 bytes, y todos los caracteres de 4 bytes consisten en dos bytes en el rango 0xD800-0xDBFF seguidos por 2 bytes en el rango 0xDC00-0xDFFF. Por esta razón, Unicode no asigna ningún carácter en el rango U + D800-U + DFFF.

UTF-32

UTF-32 es un código de longitud fija, con cada carácter tiene 4 bytes de longitud. Si bien esto permite la codificación de 2 ^ 32 caracteres diferentes, solo se permiten valores entre 0 y 0x10FFFF en este esquema.

Comparación de capacidad:

  • UTF-8: 2,097,152 (en realidad 2,166,912 pero debido a detalles de diseño, algunos de ellos se asignan a la misma cosa)
  • UTF-16: 1,112,064
  • UTF-32: 4,294,967,296 (pero restringido a los primeros 1,114,112)

¡El más restringido es por lo tanto UTF-16! La definición formal de Unicode ha limitado los caracteres Unicode a aquellos que pueden codificarse con UTF-16 (es decir, el rango U + 0000 a U + 10FFFF excluyendo U + D800 a U + DFFF). UTF-8 y UTF-32 admiten todos estos caracteres.

El sistema UTF-8 está de hecho "artificialmente" limitado a 4 bytes. Se puede extender a 8 bytes sin violar las restricciones que describí anteriormente, y esto daría una capacidad de 2 ^ 42. La especificación original UTF-8 de hecho permitía hasta 6 bytes, lo que da una capacidad de 2 ^ 31. Pero RFC 3629 lo limitó a 4 bytes, ya que eso es cuánto se necesita para cubrir todo lo que hace UTF-16.

Existen otros esquemas de codificación Unicode (principalmente históricos), notablemente UCS-2 (que solo es capaz de codificar U + 0000 a U + FFFF).

No, simplemente son diferentes métodos de codificación. Todos admiten la codificación del mismo conjunto de caracteres.

UTF-8 usa de uno a cuatro bytes por carácter, dependiendo del personaje que está codificando. Los caracteres dentro del rango ASCII toman solo un byte mientras que los caracteres muy inusuales toman cuatro.

UTF-32 utiliza cuatro bytes por carácter, independientemente del carácter que sea, por lo que siempre utilizará más espacio que UTF-8 para codificar la misma cadena. La única ventaja es que puede calcular el número de caracteres en una cadena UTF-32 contando solo bytes.

UTF-16 utiliza dos bytes para la mayoría de los caracteres, cuatro bytes para los más inusuales.

http://en.wikipedia.org/wiki/Comparison_of_Unicode_encodings

Todas las codificaciones UTF-8/16/32 pueden mapear todos los caracteres Unicode. Ver http://en.wikipedia.org/wiki/Comparison_of_Unicode_encodings .

Este artículo de IBM Codifica sus documentos XML en UTF-8 es muy útil, e indica que si tiene la opción, es mejor elegir UTF-8. Principalmente, los motivos son un amplio soporte de herramientas, y UTF-8 generalmente puede pasar a través de sistemas que no conocen el Unicode.

De la sección Qué dicen las especificaciones en el artículo de IBM :

Tanto el W3C como el IETF se han vuelto más inflexibles a la hora de elegir UTF-8 primero, último y, a veces, solo. El modelo de caracteres W3C para World Wide Web 1.0: Fundamentals establece: "Cuando se requiere una codificación de caracteres única, la codificación de caracteres DEBE ser UTF-8, UTF-16 o UTF-32. US-ASCII es compatible con UTF- 8 (una cadena US-ASCII también es una cadena UTF-8, ver [RFC 3629]), y UTF-8 es por lo tanto apropiado si se desea compatibilidad con US-ASCII. " En la práctica, la compatibilidad con US-ASCII es tan útil que es casi un requisito. El W3C sabiamente explica: "En otras situaciones, como las API, UTF-16 o UTF-32 pueden ser más apropiadas. Las posibles razones para elegir una de estas incluyen la eficiencia del procesamiento interno y la interoperabilidad con otros procesos".

UTF-8, UTF-16 y UTF-32 son compatibles con el conjunto completo de puntos de código Unicode. No hay personajes que sean compatibles con uno, pero no con otro.

En cuanto a la pregunta de bonificación, "¿difieren estas codificaciones en el número de caracteres que pueden ampliarse para admitir?" Si y no. La forma en que se codifican UTF-8 y UTF-16 limita el número total de puntos de código que pueden admitir a menos de 2 ^ 32. Sin embargo, el Consorcio Unicode no agregará puntos de código a UTF-32 que no se puedan representar en UTF-8 o UTF-16. Hacerlo violaría el espíritu de los estándares de codificación y haría imposible garantizar un mapeo uno a uno desde UTF-32 a UTF-8 (o UTF-16).