cadenas de C++: codificación UTF-8 o 16 bits?

Question

Todavía estoy tratando de decidir si mi proyecto (inicio) debe usar cadenas UTF-8 (implementado en términos de std :: string con funciones específicas de UTF-8 adicionales cuando sea necesario) o alguna cadena de 16 bits (implementado como std: : wstring). El proyecto es un lenguaje de programación y entorno (como VB, es una combinación de ambos).

hay algunas limitaciones: deseos/

• Sería genial si pudiera ejecutarse en hardware limitada, tales como ordenadores con memoria limitada.
• Quiero que el código se ejecute en Windows, Mac y (si los recursos lo permiten) Linux.
• Usaré wxWidgets como capa de mi GUI, pero quiero que el código que interactúa con ese conjunto de herramientas quede confinado en una esquina de la base de código (tendré ejecutables que no sean GUI).
• Me gustaría evitar trabajar con dos tipos diferentes de cadenas cuando se trabaja con texto visible por el usuario y con los datos de la aplicación.

Actualmente, estoy trabajando con std :: string, con la intención de usar las funciones de manipulación UTF-8 solo cuando sea necesario. Requiere menos memoria, y parece ser la dirección en la que se dirigen muchas aplicaciones de todos modos.

Si recomienda una codificación de 16 bits, ¿cuál: UTF-16? UCS-2? ¿Otro?

Answer 1

Recomendaría UTF-16 para cualquier tipo de manipulación de datos y UI. La API de Mac OS X y Win32 usa UTF-16, lo mismo para wxWidgets, Qt, ICU, Xerces y otros. UTF-8 podría ser mejor para el intercambio de datos y el almacenamiento. Ver http://unicode.org/notes/tn12/.

Pero lo que elija, definitivamente recomendaría contra std :: string con UTF-8 "solo cuando sea necesario".

Vaya hasta el final con UTF-16 o UTF-8, pero no mezcle y combine, eso es un problema.

Answer 2

Por lo que he leído, es mejor usar una codificación de 16 bits internamente a menos que tenga poca memoria. Se adapta a casi todos los idiomas vivos en un solo personaje

También me gustaría ver ICU. Si no va a utilizar ciertas características STL de cadenas, usar los tipos de cadena ICU podría ser mejor para usted.

Answer 3

Nunca he encontrado ninguna razón para usar algo más que UTF-8 para ser sincero.

Answer 4

MicroATX es prácticamente el formato estándar de una placa base de PC, con capacidad para 4-8 GB de RAM. Si estás hablando de picoATX, quizás tengas de 1 a 2 GB de RAM. Incluso entonces eso es suficiente para un entorno de desarrollo. Todavía me quedaría con UTF-8 por las razones mencionadas anteriormente, pero la memoria no debería ser tu problema.

Answer 5

UTF-16 sigue siendo una codificación de caracteres de longitud variable (hay más de 2^16 puntos de código unicode), por lo que no puede hacer O (1) operaciones de indexación de cadenas. Si estás haciendo ese tipo de cosas, no estás guardando nada en velocidad con UTF-8. Por otro lado, si su texto incluye una gran cantidad de puntos de código en el rango 256-65535, UTF-16 puede ser una mejora sustancial de tamaño. UCS-2 es una variación de UTF-16 que tiene una longitud fija de, a costa de prohibir cualquier punto de código mayor que 2^16.

Sin saber más acerca de sus requisitos, yo personalmente iría por UTF-8. Es el más fácil de tratar por todas las razones que otros ya han enumerado.

Answer 6

¿Ha considerado usar wxStrings? Si recuerdo correctamente, pueden hacer utf-8 < -> conversiones Unicode y lo hará un poco más fácil cuando tenga que pasar cadenas hacia y desde la UI.

Answer 7

Si usted decide ir con codificación UTF-8, echa un vistazo a esta biblioteca: http://utfcpp.sourceforge.net/

Se puede hacer su vida mucho más fácil.

Answer 8

De hecho, he escrito una aplicación ampliamente utilizada (5 millones + usuarios) por lo que cada kilobyte usado se suma, literalmente. A pesar de eso, me limité a wxString. Lo configuré para que se derivara de std :: wstring, por lo que puedo pasarlos a funciones esperando una wstring const &.

Tenga en cuenta que std :: wstring es Unicode nativo en la Mac (no se necesita UTF-16 para caracteres superiores a U + 10000) y, por lo tanto, utiliza 4 bytes/wchar_t. La gran ventaja de esto es que i ++ te consigue el próximo personaje, siempre. En Win32 eso es cierto solo en el 99.9% de los casos. Como compañero programador, comprenderá qué tan poco 99.9% es.

Pero si no está convencido, escriba la función para mayúscula std :: string [UTF-8] y std :: wstring. Esas 2 funciones te dirán en qué dirección está la locura.

Su formato en el disco es otra cosa. Para la portabilidad, debería ser UTF-8. No hay preocupación de endianness en UTF-8, ni una discusión sobre el ancho (2/4). Esta puede ser la razón por la cual muchos programas parecen usar UTF-8.

En una nota poco relacionada, lea las comparaciones de cadenas Unicode y la normalización. O terminará con el mismo error que .NET, donde puede tener dos variables föö y föö que difieren solo en la normalización (invisible).