utf8 c++ encoding utf-8 stdstring ucs2

c++ - std:: string utf8



Cadenas de C++: ¿UTF-8 o codificación de 16 bits? (8)

Todavía estoy tratando de decidir si mi proyecto (doméstico) 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 algunos deseos / restricciones:

  • Sería genial si pudiera funcionar con hardware limitado, como computadoras con memoria limitada.
  • Quiero que el código se ejecute en Windows, Mac y (si los recursos lo permiten) Linux.
  • Utilizaré wxWidgets como mi capa de 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 de GUI).
  • Me gustaría evitar trabajar con dos tipos diferentes de cadenas cuando se trabaja con texto visible para 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 es: UTF-16 ? UCS-2 ? ¿Otro?

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

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

Tenga en cuenta que std :: wstring es Unicode nativo en la Mac (no se necesita UTF-16 para los caracteres por encima de U + 10000) y, por lo tanto, usa 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 en mayúscula en 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 otro asunto. 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).

MicroATX es prácticamente el formato estándar de una placa base para 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.

Nunca he encontrado razones para usar algo más que UTF-8 para ser honesto.

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 personaje

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

Recomendaría UTF-16 para cualquier tipo de manipulación de datos y UI. La API 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 sea lo que sea que elija, definitivamente recomendaría std :: string con UTF-8 "solo cuando sea necesario".

Siga todo el camino con UTF-16 o UTF-8, pero no mezcle y combine, eso es buscar problemas.

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 realizar 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 es de longitud fija, a costa de prohibir cualquier punto de código superior a 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.