1. Inicio
  2. Pregunta y respuesta
  3. Unicode - generalmente trabajando con él en C++

Unicode - generalmente trabajando con él en C++

2010-02-24 20 views
16

Supongamos que tenemos una cadena arbitraria, s.Unicode - generalmente trabajando con él en C++

s tiene la propiedad de ser de casi cualquier parte del mundo. Las personas de EE. UU., Japón, Corea, Rusia, China y Grecia escriben de vez en cuando en s. Afortunadamente, no tenemos viajeros en el tiempo que usen Linear A, sin embargo.

Por el bien de discusión, vamos a suponer que queremos hacer operaciones de cadena tales como:

  • inversa
  • longitud
  • capitalizar
  • minúsculas índice
  • en

y, solo por el motivo de la discusión, supongamos que queremos escribir estas rutinas nosotros mismos (en lugar de ocupar una biblioteca), y no tenemos ningún software heredado para mantener.

Hay 3 estándares para Unicode: utf-8, utf-16 y utf-32, cada uno con pros y contras. Pero digamos que soy muy tonto, y quiero un Unicode que los gobierne a todos (porque suena difícil rodar una biblioteca de adaptación dinámica para 3 tipos diferentes de codificaciones de cadena que oculta la diferencia del usuario de API).

  • ¿Qué codificación es la más general?
  • ¿Qué codificación es compatible con wchar_t?
  • ¿Qué codificación es compatible con el STL?
  • ¿Están estas codificaciones todas (o nada) anuladas?

-

El objetivo de esta pregunta es para educar a mí mismo y otros en información útil y utilizable para Unicode: leer los RFC está muy bien, pero hay una 'pila' de la información relacionada con compiladores, lenguajes , y sistemas operativos que los RFC no cubren, pero es vital saber que realmente usan Unicode en una aplicación real.

Fuente

2010-02-24 Paul Nathan

+0

No es exactamente una tontería sino que también lee http://stackoverflow.com/questions/114611/what-is-the-best-unicode-library-for-c –

+0

@Martin: No estoy realmente interesado - en esto tiempo: cuál es la mejor biblioteca. Estoy más interesado en ponerme al día con la información sobre Unicode en general y sobre cómo escribiré un reverso (o posiblemente una rutina más oscura) en Unicode y no haré que explote en, digamos, Turquía. :-) –

+0

sí, es por eso que no cerré como una víctima, pero alguien que encuentre esta pregunta PODRÍA estar interesado en solo usar una biblioteca. Si este hilo obtiene buenas respuestas, haré una referencia cruzada en el otro hilo. –

Respuesta

9

  1. Qué codificación es más general
    Probablemente UTF-32, aunque los tres formatos pueden almacenar cualquier carácter. UTF-32 tiene la propiedad de que cada carácter se puede codificar en un solo punto de código.

  2. qué codificación está soportado por wchar_t
    Ninguno. Esa es la implementación definida. En la mayoría de las plataformas Windows es UTF-16, en la mayoría de las plataformas Unix es su UTF-32.

  3. qué codificación es compatible con el STL
    Ninguno realmente.El STL puede almacenar cualquier tipo de carácter que desee. Simplemente use la plantilla std::basic_string<t> con un tipo lo suficientemente grande como para contener su punto de código. La mayoría de las operaciones (por ejemplo, std::reverse) no conocen ningún tipo de codificación unicode.

  4. ¿Están todas estas codificaciones (o nada) anuladas?
    No. Null es un valor legal en cualquiera de esas codificaciones. Técnicamente, NULL es un personaje legal en ASCII simple también. La terminación NULL es una cosa C, no una cosa de codificación.

Elegir cómo hacerlo tiene mucho que ver con su plataforma. Si está en Windows, use cadenas UTF-16 y wchar_t, porque eso es lo que usa la API de Windows para admitir unicode. No estoy del todo seguro de cuál es la mejor opción para las plataformas UNIX, pero sí sé que la mayoría usa UTF-8.

Fuente

2010-02-24 17:21:59

+2

Incluso con UTF-32 no puede almacenar cada carácter como un único punto de código. Esa codificación simplemente asegura la asignación 1: 1 entre las unidades de código y los puntos de código (para los detalles sobre la terminología, echa un vistazo a unicode.org) –

+0

Err ... en realidad, sí puede. Unicode requiere 21 bits para el conjunto completo de caracteres. UTF-32 proporciona 32 bits en un solo punto de código. Los personajes nunca deberían necesitar ser divididos en UTF-32. Estás pensando en UTF-16. –

+3

Aquí está hablando de puntos de código, no de caracteres. Algunos (de hecho, muchos) caracteres deben describirse con múltiples puntos de código, independientemente de la codificación.Eche un vistazo a este enlace, por ejemplo: http://www.unicode.org/faq/char_combmark.html –

5

Eche un vistazo a la biblioteca de código abierto ICU, especialmente en el Docs & Papers section. Es una biblioteca extensa que trata con todo tipo de rarezas Unicode.

Fuente

2010-02-24 18:04:51

+1

El OP pidió explícitamente una respuesta que no fuera de la biblioteca. –

+2

Es por eso que me referí a su sección de Documentos y Documentos. Si el OP realmente quiere aprender sobre el manejo de unicode, no debe abstenerse de buscar soluciones existentes. ICU proporciona no solo código fuente de grado de producción, sino también documentos de diseño. –

+0

Ah, ya veo. +1 entonces. –

1

definir la "aplicación real" :)

En serio, la decisión realmente depende mucho del tipo de software que está desarrollando. Si su plataforma de destino es Win32 API (con o sin envoltorios como MFC, WTL, etc.) probablemente desee utilizar los tipos wstring con el texto codificado como UTF-16. Eso es simplemente porque todas las API Win32 usan internamente esa codificación de todos modos.

Por otro lado, si su salida es algo así como XML/HTML y/o necesita ser entregado a través de Internet, UTF-8 es bastante el estándar - generalmente se transmite bien a través de protocolos que hacen suposiciones sobre caracteres que tienen 8 bits.

En cuanto a UTF-32, no puedo pensar en una sola razón para usarlo, a menos que necesite mapeo 1: 1 entre unidades de código y puntos de código (eso aún no significa mapeo 1: 1 entre unidades de código y ¡caracteres!).

Para obtener más información, asegúrese de mirar Unicode.org. This FAQ puede ser un buen punto de partida.

Fuente

2010-02-24 18:24:32

+0

Una cosa que no tengo claro es: ¿puede alguna de las codificaciones UTF representar todos los glifos usados ​​en todas las escrituras de lenguaje vivo de hoy? Es decir, si selecciono UTF-8 o UTF-16, ¿me excluiría de ciertos mercados? –

+2

@Paul. UTF-8, UTF-16 y UTF-32 describen exactamente los mismos datos (puntos de código Unicode) codificados de manera diferente, y estrictamente hablando técnicamente puede usar cualquiera de ellos para almacenar cualquier texto cubierto por el estándar Unicode (todos los idiomas vivos están cubiertos) . Una vez dicho esto, deberá tener en cuenta los problemas no técnicos: por ejemplo, China exige el uso de GB18030 incluso si los formularios de codificación Unicode estándar también cubren las letras chinas. –

2

En respuesta a su viñeta final, UTF-8 garantiza que no tiene bytes NULL en su codificación de ningún carácter (excepto NULL en sí mismo, por supuesto). Como resultado, muchas funciones que funcionan con cadenas terminadas en NULL también funcionan con cadenas codificadas UTF-8.

Fuente

2010-02-24 22:08:26

Cuestiones relacionadas

 Cuestiones relacionadas