Chaînes C ++: codage UTF-8 ou 16 bits?

Question

J'essaie toujours de décider si mon projet (d'origine) doit utiliser UTF-8 strings (implémenté en termes de std :: string avec des fonctions supplémentaires spécifiques à UTF-8 si nécessaire) ou une chaîne de 16 bits (implémentée en tant que std :: wstring). Le projet est un langage de programmation et un environnement (comme VB, c'est une combinaison des deux).

Il y a quelques souhaits / contraintes:

• Il serait intéressant de pouvoir utiliser un matériel limité, tel que des ordinateurs avec une mémoire limitée.
• Je souhaite que le code s'exécute sous Windows, Mac et (si les ressources le permettent) sous Linux.
• Je vais utiliser wxWidgets comme couche d'interface graphique, mais je veux le code qui interagit avec cette couche. boîte à outils confinée dans un coin de la base de code (j'aurai des exécutables non graphiques).
• J'aimerais éviter de travailler avec deux types de chaînes différents lorsque vous travaillez avec du texte visible par l'utilisateur et avec les données de l'application.

Actuellement, je travaille avec std :: string, avec l'intention d'utiliser les fonctions de manipulation UTF-8 uniquement lorsque cela est nécessaire. Il nécessite moins de mémoire et semble être la direction prise par de nombreuses applications.

Si vous recommandez un codage 16 bits, lequel: UTF-16 ? UCS-2 ? Un autre?

Answer 1

Je recommanderais UTF-16 pour tout type de manipulation de données et d’interface utilisateur. Les API Mac OS X et Win32 utilisent UTF-16, la même chose pour wxWidgets, Qt, ICU, Xerces, etc. UTF-8 pourrait être meilleur pour l'échange et le stockage de données. Voir http://unicode.org/notes/tn12/ .

Mais quoi que vous choisissiez, je recommande vivement de ne pas utiliser std :: string avec UTF-8 & seulement lorsque nécessaire & ";.

Allez jusqu'au bout avec UTF-16 ou UTF-8, mais ne mélangez pas et faites correspondre, cela pose problème.

Answer 2

UTF-16 est toujours un codage de caractères de longueur variable (il y a plus de 2 ^ 16 codes codés Unicode), vous ne pouvez donc pas effectuer d'opérations d'indexation de chaînes O (1). Si vous faites beaucoup de ce genre de choses, vous n'enregistrez rien en vitesse par rapport à UTF-8. Par contre, si votre texte comprend de nombreux points de code dans la plage 256-65535, la taille de l’utilitaire UTF-16 peut constituer une amélioration substantielle de la taille. UCS-2 est une variante de la valeur UTF-16 qui est de longueur fixe, au prix de l’interdiction des points de code supérieurs à 2 ^ 16.

Sans en savoir plus sur vos besoins, je choisirais personnellement le format UTF-8. C’est la plus facile à traiter pour toutes les raisons déjà énumérées par d’autres.

Answer 3

Pour être honnête, je n'ai jamais trouvé de raison d'utiliser autre chose que UTF-8.

Answer 4

Si vous décidez d'utiliser le codage UTF-8, consultez cette bibliothèque: http://utfcpp.sourceforge.net /

Cela peut vous rendre la vie beaucoup plus facile.

Answer 5

J'ai en fait écrit une application très utilisée (plus de 5 millions d'utilisateurs), de sorte que chaque kilo-octet ajouté s'additionne littéralement. Malgré cela, je me suis contenté de wxString. Je l'ai configuré pour être dérivé de std :: wstring, afin que je puisse les transmettre aux fonctions qui attendent un wstring const &.

Veuillez noter que std :: wstring est unicode natif sur Mac (aucun UTF-16 n'est nécessaire pour les caractères supérieurs à U + 10000) et qu'il utilise donc 4 octets / wchar_t. Le gros avantage de ceci est que i ++ vous obtient toujours le prochain caractère. Sous Win32, cela n’est vrai que dans 99,9% des cas. En tant que programmeur, vous comprendrez à quel point 99,9% du temps est petit.

Mais si vous n'êtes pas convaincu, écrivez la fonction en majuscule: std :: string [UTF-8] et std :: wstring. Ces 2 fonctions vous indiqueront quel est le sens de la folie.

Votre format sur disque est une autre affaire. Pour la portabilité, cela devrait être UTF-8. Il n’ya pas de problème d’endianisme dans UTF-8, ni de discussion sur la largeur (2/4). C’est peut-être pour cette raison que de nombreux programmes semblent utiliser UTF-8.

Sur une note légèrement différente, veuillez vous reporter à la comparaison et à la normalisation de chaînes Unicode. Ou vous allez vous retrouver avec le même bogue que .NET, où vous pouvez avoir deux variables f & # 246; & # 246; et f & # 246; & # 246; ne différant que par la normalisation (invisible).

Answer 6

MicroATX est en gros un format de carte mère PC standard, capable de 4 à 8 Go de RAM. Si vous parlez de picoATX, vous êtes peut-être limité à 1 à 2 Go de RAM. Même dans ce cas, cela suffit pour un environnement de développement. Je resterais toujours avec UTF-8 pour les raisons mentionnées ci-dessus, mais la mémoire ne devrait pas vous préoccuper.

Answer 7

D'après ce que j'ai lu, il est préférable d'utiliser un codage 16 bits en interne, sauf si vous manquez de mémoire. Il convient à presque toutes les langues vivantes dans un seul caractère

Je voudrais aussi regarder ICU . Si vous n'utilisez pas certaines fonctionnalités STL des chaînes, il peut être préférable d’utiliser les types de chaîne ICU.

Answer 8

Avez-vous envisagé d’utiliser wxStrings? Si je me souviens bien, ils peuvent faire utf-8 & Lt; - & Gt; Conversions Unicode et cela facilitera un peu la tâche lorsque vous devez passer des chaînes vers et depuis l'interface utilisateur.