2008-09-25 15 views
10

Tenemos un conjunto de aplicaciones que fueron desarrolladas para el juego de caracteres ASCII. Ahora, estamos tratando de instalarlo en Islandia, y estamos teniendo problemas donde los personajes islandeses se están jodiendo.¿Cómo se escribe el código que es seguro para UTF-8?

Estamos trabajando en nuestros problemas, pero me preguntaba: ¿existe una buena "guía" para escribir código C++ diseñado para caracteres de 8 bits y que funcionará correctamente cuando se le den datos UTF-8 a ¿eso?

No puedo esperar que todos lean todo el estándar Unicode, pero si hay algo más digerible disponible, me gustaría compartirlo con el equipo para que no nos topemos con estos problemas nuevamente.

Volver a escribir todas las aplicaciones para usar wchar_t o alguna otra representación de cadena no es posible en este momento. También notaré que estas aplicaciones se comunican a través de redes con servidores y dispositivos que usan caracteres de 8 bits, por lo que incluso si hiciéramos Unicode internamente, todavía tendríamos problemas con la traducción en los límites. En su mayor parte, estas aplicaciones solo pasan datos; no "procesan" el texto de ninguna otra forma que no sea copiarlo de un lugar a otro.

Los sistemas operativos utilizados son Windows y Linux. Usamos std :: string y strings simples de C. (Y no me pida para defender cualquiera de las decisiones de diseño Sólo estoy tratando de ayudar a solucionar el lío..)


Aquí es una lista de lo que se ha sugerido:

+0

¿Podría confirmarnos el sistema operativo de su aplicación? ¿Estás programando para Windows? ¿Está usando masivamente std :: string o el encabezado C de de nivel más bajo? – paercebal

+0

Si te gusta una respuesta, por favor la resumes, no hay razón para ser mezquino. –

+0

¿Solo hace 30 minutos y ya está exigiendo un impulso de representante? :) –

Respuesta

-1

Es posible que desee utilizar amplia c haracters (wchar_t en lugar de char y std :: wstring en lugar de std :: string). Esto no resuelve automáticamente el 100% de tus problemas, pero es un buen primer paso.

También use funciones de cadena que sean compatibles con Unicode (consulte la documentación). Si algo manipula caracteres anchos o cadenas, generalmente es consciente de que son anchos.

+0

Volver a escribir todas las aplicaciones para usar representaciones de caracteres diferentes no es factible. –

1

Sé consciente de que Unicode no encaja en caracteres de 16 bits; por lo tanto, utilice caracteres de 32 bits o codificación de ancho variable (UTF-8 es el más popular).

0

islandés usa ISO Latin 1, por lo que ocho bits deberían ser suficientes. Necesitamos más detalles para descubrir qué está pasando.

+0

No le pido a nadie que me ayude a descubrir qué sucede. Estoy buscando orientación general y "mejores prácticas" para lidiar con UTF-8. –

1

UTF-8 fue diseñado exactamente teniendo en cuenta sus problemas. Una cosa que tendría cuidado es que ASCII es realmente una codificación de 7 bits, por lo que si alguna parte de su infraestructura está utilizando la octava parte para otros fines, puede ser complicado.

+0

Sí, es por eso que estamos sorprendidos de que UTF-8 haya provocado problemas. No estamos haciendo nada especial con el octavo bit, pero parece que estamos haciendo cosas en algunos lugares que hacen que el texto sea malinterpretado o modificado de alguna manera. –

+1

Tenga en cuenta que ASCII es de 1 byte por char. UTF-8 es un byte múltiple por carácter (cuando no es ASCII, entonces Iclandic cuenta). Entonces cualquier método que asuma 1 byte por char no funcionará. p.ej.length() –

10

Simplemente tenga 8 bits de limpieza, en su mayor parte. Sin embargo, deberá tener en cuenta que cualquier carácter que no sea ASCII se divide en varios bytes, por lo que debe tener en cuenta esto si se trata de texto de línea o truncado para su visualización.

UTF-8 tiene la ventaja de que se puede decir siempre dónde se encuentra en un carácter multi-byte: si el bit 7 se establece y el bit 6 de reinicio (byte es 0x80-0xBF) este es un byte final, mientras que si los bits 7 y 6 se configuran y 5 se reinicia (0xC0-0xDF) es un byte principal con un byte final; si se configuran 7, 6 y 5 y se restablece 4 (0xE0-0xEF), se trata de un byte inicial con dos bytes finales, y así sucesivamente. La cantidad de bits consecutivos configurados en el bit más significativo es la cantidad total de bytes que componen el carácter. Es decir:

110x xxxx = dos bytes carácter
1110 xxxx = tres bytes carácter
1111 0xxx = cuatro bytes carácter
etc

El alfabeto islandés todo está contenido en la norma ISO 8859-1 y por lo tanto, Windows-1252. Si se trata de una aplicación en modo consola, tenga en cuenta que la consola utiliza páginas de códigos de IBM, por lo que (según la configuración regional del sistema) podría mostrarse en 437, 850 o 861. Windows no tiene soporte de visualización nativo para UTF-8; debe transformar a UTF-16 y usar las API Unicode.

Llamar SetConsoleCP y SetConsoleOutputCP, especificando la página de códigos 1252, ayudará con su problema, si se trata de una aplicación de modo de consola. Lamentablemente, la fuente de la consola seleccionada debe ser una fuente que admita la página de códigos, y no veo la forma de establecer la fuente. Las fuentes de mapa de bits estándar solo admiten la página de códigos OEM predeterminada del sistema.

1

Es posible que desee comprobar icu. Podrían tener funciones disponibles que facilitarían el trabajo con cadenas UTF-8.

0

El islandés, como el francés, el alemán y la mayoría de los demás idiomas de Europa occidental, puede admitirse utilizando un conjunto de caracteres de 8 bits (CP1252 en Windows, ISO 8859-1 también conocido como Latin1 en * x). Este fue el enfoque estándar antes de que se inventara Unicode, y todavía es bastante común. Como dices, tienes una limitación: no puedes volver a escribir tu aplicación para usar wchar, y no es necesario.

No debería sorprender que UTF-8 esté causando problemas; UTF-8 codifica los caracteres que no son ASCII (por ejemplo, los caracteres latinos acentuados, thorn, eth, etc.) como DOS BYTES cada uno.

El único consejo general que se puede dar es bastante simple (en teoría): (1) decidir qué conjunto de caracteres que se va a apoyar (Unicode, Latin1, CP1252, ...) en su sistema (2) si se le están suministrando datos codificados de alguna otra forma (por ejemplo, UTF-8) y luego transcodifíquelos a su estándar (p. ej. CP1252) en el borde del sistema (3) si necesita suministrar datos codificados de alguna otra forma, ..

+1

UTF-8 utiliza 3 bytes para caracteres chinos, en realidad, y puede que para caracteres raros incluso requiera 4 bytes. Mejor arreglarlo correctamente si lo estás abordando. El primer byte le dirá cuántos le siguen: 110xxxxx significa char de 2 bytes, 1110xxxx significa char de 3 bytes, y 11110xxx significa char de 4 bytes. – MSalters

+1

UTF-8 utiliza tres bytes para caracteres de U + 0800 a U + FFFF, en realidad ... que abarca no solo el chino, sino los scripts utilizados en varios países/idiomas: India, Sri Lanka, Myanmar, alias Birmania, Tailandia, Laos, Tibetano, georgiano, coreano, etc. etc. Mi referencia a "DOS BYTES" está relacionada con los caracteres utilizados en islandés. Lea sus labios: no va a volver a escribir esta aplicación para admitir caracteres de más de 8 bits. Entonces él no puede apoyar chino, punto. Hong Kong con sus personajes no raros no BMP HKSCS definitivamente está fuera de discusión. –

Cuestiones relacionadas