std :: wstring VS std :: string

Je ne peux pas comprendre les différences entre std::stringet std::wstring. Je sais que wstringprend en charge les caractères larges tels que les caractères Unicode. J'ai les questions suivantes:

1. Quand devrais-je utiliser std::wstringplus std::string?
2. Peut std::stringcontenir l'ensemble du jeu de caractères ASCII, y compris les caractères spéciaux?
3. Est std::wstringpris en charge par tous les compilateurs C ++ populaires?
4. Qu'est-ce qu'un " caractère large " exactement ?

string? wstring?

std::stringest un basic_stringmodèle sur un char, et std::wstringsur un wchar_t.

char contre. wchar_t

charest censé contenir un caractère, généralement un caractère 8 bits.
wchar_test censé contenir un caractère large, puis les choses se compliquent:
sous Linux, a wchar_tvaut 4 octets, tandis que sous Windows, c'est 2 octets.

Et Unicode alors?

Le problème est que ni l'un charni l'autre wchar_tn'est directement lié à l'unicode.

Sous Linux?

Prenons un système d'exploitation Linux: mon système Ubuntu est déjà compatible avec l'Unicode. Lorsque je travaille avec une chaîne de caractères, elle est encodée en natif en UTF-8 (c'est -à- dire une chaîne de caractères Unicode). Le code suivant:

#include <cstring>
#include <iostream>

int main(int argc, char* argv[])
{
   const char text[] = "olé" ;


   std::cout << "sizeof(char)    : " << sizeof(char) << std::endl ;
   std::cout << "text            : " << text << std::endl ;
   std::cout << "sizeof(text)    : " << sizeof(text) << std::endl ;
   std::cout << "strlen(text)    : " << strlen(text) << std::endl ;

   std::cout << "text(ordinals)  :" ;

   for(size_t i = 0, iMax = strlen(text); i < iMax; ++i)
   {
      std::cout << " " << static_cast<unsigned int>(
                              static_cast<unsigned char>(text[i])
                          );
   }

   std::cout << std::endl << std::endl ;

   // - - - 

   const wchar_t wtext[] = L"olé" ;

   std::cout << "sizeof(wchar_t) : " << sizeof(wchar_t) << std::endl ;
   //std::cout << "wtext           : " << wtext << std::endl ; <- error
   std::cout << "wtext           : UNABLE TO CONVERT NATIVELY." << std::endl ;
   std::wcout << L"wtext           : " << wtext << std::endl;

   std::cout << "sizeof(wtext)   : " << sizeof(wtext) << std::endl ;
   std::cout << "wcslen(wtext)   : " << wcslen(wtext) << std::endl ;

   std::cout << "wtext(ordinals) :" ;

   for(size_t i = 0, iMax = wcslen(wtext); i < iMax; ++i)
   {
      std::cout << " " << static_cast<unsigned int>(
                              static_cast<unsigned short>(wtext[i])
                              );
   }

   std::cout << std::endl << std::endl ;

   return 0;
}

affiche le texte suivant:

sizeof(char)    : 1
text            : olé
sizeof(text)    : 5
strlen(text)    : 4
text(ordinals)  : 111 108 195 169

sizeof(wchar_t) : 4
wtext           : UNABLE TO CONVERT NATIVELY.
wtext           : ol�
sizeof(wtext)   : 16
wcslen(wtext)   : 3
wtext(ordinals) : 111 108 233

Vous verrez que le texte "olé" dans charest vraiment construit par quatre caractères: 110, 108, 195 et 169 (sans compter le zéro de fin). (Je vous laisse étudier le wchar_tcode comme un exercice)

Donc, lorsque vous travaillez avec un charsous Linux, vous devriez généralement utiliser Unicode sans même le savoir. Et comme std::stringfonctionne avec char, il std::stringest donc déjà prêt pour Unicode.

Notez que std::string, comme l'API de chaîne C, considérera la chaîne "olé" comme ayant 4 caractères, pas trois. Vous devez donc être prudent lorsque vous tronquez / jouez avec des caractères unicode car certaines combinaisons de caractères sont interdites en UTF-8.

Sous Windows?

Sous Windows, c'est un peu différent. Win32 devait prendre en charge de nombreuses applications fonctionnant avec charet sur différents jeux de caractères / pages de codes produites dans le monde entier, avant l'avènement d'Unicode.

Leur solution était donc intéressante: si une application fonctionne avec char, alors les chaînes de caractères sont encodées / imprimées / affichées sur les étiquettes GUI en utilisant le jeu de caractères / page de code local sur la machine. Par exemple, "olé" serait "olé" dans un Windows localisé en français, mais serait quelque chose de différent sur un Windows localisé cyrillique ("olé" si vous utilisez Windows-1251 ). Ainsi, les "applications historiques" fonctionnent généralement toujours de la même manière.

Pour les applications basées sur Unicode, Windows utilise wchar_t, qui est large de 2 octets, et est codé en UTF-16 , qui est codé en Unicode sur des caractères de 2 octets (ou à tout le moins, le UCS-2 le plus compatible, qui est presque le même chose IIRC).

Les applications utilisant charsont dites "multi-octets" (car chaque glyphe est composé d'un ou plusieurs chars), tandis que les applications utilisant wchar_tsont dites "widechar" (car chaque glyphe est composé d'un ou deux wchar_t. Voir MultiByteToWideChar et WideCharToMultiByte Win32 API de conversion pour plus d'informations.

Ainsi, si vous travaillez sous Windows, vous souhaitez absolument l' utiliser wchar_t(sauf si vous utilisez un framework qui le cache, comme GTK + ou QT ...). Le fait est que dans les coulisses, Windows fonctionne avec des wchar_tchaînes, donc même les applications historiques auront leurs charchaînes converties wchar_tlors de l'utilisation de l'API comme SetWindowText()(fonction API de bas niveau pour définir l'étiquette sur une interface graphique Win32).

Problèmes de mémoire?

UTF-32 est de 4 octets par caractère, donc il n'y a pas grand-chose à ajouter, si seulement qu'un texte UTF-8 et UTF-16 utiliseront toujours moins ou la même quantité de mémoire qu'un texte UTF-32 (et généralement moins ).

S'il y a un problème de mémoire, vous devez savoir que pour la plupart des langues occidentales, le texte UTF-8 utilisera moins de mémoire que le même UTF-16.

Pourtant, pour les autres langues (chinois, japonais, etc.), la mémoire utilisée sera soit la même, soit légèrement plus grande pour UTF-8 que pour UTF-16.

Dans l'ensemble, UTF-16 utilisera principalement 2 et parfois 4 octets par caractère (à moins que vous n'ayez affaire à une sorte de glyphe de langage ésotérique (Klingon? Elfique?), Tandis que UTF-8 dépensera de 1 à 4 octets.

Voir http://en.wikipedia.org/wiki/UTF-8#Compared_to_UTF-16 pour plus d'informations.

Conclusion

1. Quand dois-je utiliser std :: wstring sur std :: string?

   Sous Linux? Presque jamais (§).
   Sous Windows? Presque toujours (§).
   Sur le code multiplateforme? Cela dépend de votre boîte à outils ...

   (§): sauf indication contraire

2. Peut std::stringcontenir tous les jeux de caractères ASCII, y compris les caractères spéciaux?

   Remarque: A std::stringconvient pour contenir un tampon «binaire», où a std::wstringne l'est pas!

   Sous Linux? Oui.
   Sous Windows? Seuls les caractères spéciaux disponibles pour les paramètres régionaux actuels de l'utilisateur Windows.

   Edit (après un commentaire de Johann Gerell ):
   un std::stringsuffira pour gérer toutes les charchaînes de base (chacune charétant un nombre de 0 à 255). Mais:

   1. ASCII est censé aller de 0 à 127. Les chars supérieurs ne sont PAS ASCII.
   2. un charde 0 à 127 sera tenu correctement
   3. un charde 128 à 255 aura une signification en fonction de votre encodage (unicode, non-unicode, etc.), mais il pourra contenir tous les glyphes Unicode tant qu'ils sont encodés en UTF-8.

3. Est std::wstringpris en charge par presque tous les compilateurs C ++ populaires?

   Généralement, à l'exception des compilateurs basés sur GCC qui sont portés sur Windows.
   Cela fonctionne sur mon g ++ 4.3.2 (sous Linux), et j'ai utilisé l'API Unicode sur Win32 depuis Visual C ++ 6.

4. Qu'est-ce qu'un caractère large exactement?

   Sur C / C ++, c'est un type de caractère écrit wchar_tqui est plus grand que le chartype de caractère simple . Il est censé être utilisé pour mettre à l'intérieur des caractères dont les indices (comme les glyphes Unicode) sont supérieurs à 255 (ou 127, selon ...).

Je recommande d'éviter std::wstringsur Windows ou ailleurs, sauf lorsque requis par l'interface, ou n'importe où près des appels d'API Windows et des conversions d'encodage respectives comme sucre syntaxique.

Mon point de vue est résumé dans http://utf8everywhere.org dont je suis co-auteur.

À moins que votre application ne soit centrée sur l'API, par exemple principalement une application d'interface utilisateur, la suggestion est de stocker les chaînes Unicode dans std :: string et encodées en UTF-8, en effectuant une conversion près des appels d'API. Les avantages décrits dans l'article l'emportent sur la gêne apparente de la conversion, en particulier dans les applications complexes. C'est doublement le cas pour le développement multi-plateforme et bibliothèque.

Et maintenant, répondant à vos questions:

1. Quelques raisons faibles. Il existe pour des raisons historiques, où les widechars étaient considérés comme le bon moyen de prendre en charge Unicode. Il est désormais utilisé pour interfacer les API qui préfèrent les chaînes UTF-16. Je les utilise uniquement à proximité directe de ces appels API.
2. Cela n'a rien à voir avec std :: string. Il peut contenir tout l'encodage que vous y mettez. La seule question est de savoir comment vous traitez son contenu. Ma recommandation est UTF-8, donc il pourra contenir correctement tous les caractères Unicode. C'est une pratique courante sous Linux, mais je pense que les programmes Windows devraient le faire aussi.
3. Non.
4. Le caractère large est un nom déroutant. Dans les premiers jours d'Unicode, on croyait qu'un caractère peut être codé sur deux octets, d'où le nom. Aujourd'hui, il représente "n'importe quelle partie du caractère de deux octets". UTF-16 est considéré comme une séquence de telles paires d'octets (également appelées caractères larges). Un personnage en UTF-16 prend une ou deux paires.

Donc, chaque lecteur ici devrait maintenant avoir une compréhension claire des faits, de la situation. Sinon, vous devez lire la réponse remarquablement complète de paercebal [btw: merci!].

Ma conclusion pragmatique est d'une simplicité choquante: tout ce qui est "l'encodage de caractères" en C ++ (et STL) est substantiellement cassé et inutile. Blâmez-le sur Microsoft ou non, cela n'aidera pas de toute façon.

Ma solution, après une enquête approfondie, beaucoup de frustration et les expériences consécutives sont les suivantes:

1. Acceptez, que vous devez être responsable de vous-même pour l'encodage et la conversion (et vous verrez qu'une grande partie est plutôt triviale)

2. utilisez std :: string pour toutes les chaînes encodées en UTF-8 (juste a typedef std::string UTF8String)

3. accepter qu'un tel objet UTF8String est juste un conteneur stupide mais bon marché. N'y accédez jamais et / ou ne manipulez jamais directement des caractères (pas de recherche, remplacement, etc.). Vous pourriez, mais vous ne voulez vraiment pas vraiment, vraiment perdre votre temps à écrire des algorithmes de manipulation de texte pour des chaînes multi-octets! Même si d'autres personnes ont déjà fait des choses aussi stupides, ne faites pas ça! Laisse faire! (Eh bien, il y a des scénarios où cela a du sens ... utilisez simplement la bibliothèque ICU pour ceux-ci).

4. utilisez std :: wstring pour les chaînes encodées UCS-2 ( typedef std::wstring UCS2String) - c'est un compromis et une concession au bordel que l'API WIN32 a introduit). UCS-2 est suffisant pour la plupart d'entre nous (plus à ce sujet plus tard ...).

5. utiliser des instances UCS2String chaque fois qu'un accès caractère par caractère est requis (lecture, manipulation, etc.). Tout traitement basé sur des caractères doit être effectué dans une représentation NON multi-octets. C'est simple, rapide, facile.

6. ajoutez deux fonctions utilitaires pour convertir en va-et-vient entre UTF-8 et UCS-2:

   UCS2String ConvertToUCS2( const UTF8String &str );
   UTF8String ConvertToUTF8( const UCS2String &str );

Les conversions sont simples, Google devrait vous aider ici ...

C'est ça. Utilisez UTF8String partout où la mémoire est précieuse et pour toutes les E / S UTF-8. Utilisez UCS2String partout où la chaîne doit être analysée et / ou manipulée. Vous pouvez convertir à tout moment entre ces deux représentations.

Alternatives et améliorations

• les conversions de et vers les codages de caractères à un octet (par exemple ISO-8859-1) peuvent être réalisées à l'aide de tables de traduction simples, par exemple const wchar_t tt_iso88951[256] = {0,1,2,...};et du code approprié pour la conversion vers et depuis UCS2.

• si UCS-2 ne suffit pas, passez à UCS-4 ( typedef std::basic_string<uint32_t> UCS2String)

ICU ou autres bibliothèques Unicode?

Pour des trucs avancés.

1. Lorsque vous souhaitez stocker des caractères larges dans votre chaîne. widedépend de la mise en œuvre. Visual C ++ par défaut à 16 bits si je me souviens bien, tandis que GCC par défaut dépend de la cible. C'est 32 bits de long ici. Veuillez noter que wchar_t (type de caractère large) n'a rien à voir avec l'unicode. Il est simplement garanti qu'il peut stocker tous les membres du plus grand jeu de caractères pris en charge par l'implémentation par ses paramètres régionaux, et au moins aussi longtemps que char. Vous pouvez également stocker correctement les chaînes unicode en std::stringutilisant l' utf-8encodage. Mais il ne comprendra pas la signification des points de code unicode. Doncstr.size()ne vous donnera pas la quantité de caractères logiques dans votre chaîne, mais simplement la quantité d'éléments char ou wchar_t stockés dans cette chaîne / chaîne de caractères. Pour cette raison, les gens du wrapper gtk / glib C ++ ont développé une Glib::ustringclasse qui peut gérer utf-8.

   Si votre wchar_t a une longueur de 32 bits, vous pouvez l'utiliser utf-32comme encodage unicode et vous pouvez stocker et gérer des chaînes unicode à l'aide d'un codage fixe (utf-32 est de longueur fixe). Cela signifie que la s.size()fonction de votre wstring retournera alors la bonne quantité d'éléments wchar_t et de caractères logiques.

2. Oui, char est toujours d'au moins 8 bits, ce qui signifie qu'il peut stocker toutes les valeurs ASCII.
3. Oui, tous les grands compilateurs le prennent en charge.

J'utilise fréquemment std :: string pour contenir les caractères utf-8 sans aucun problème. Je recommande vivement de le faire lors de l'interfaçage avec des API qui utilisent également utf-8 comme type de chaîne natif.

Par exemple, j'utilise utf-8 lors de l'interface de mon code avec l'interpréteur Tcl.

La mise en garde majeure est la longueur de la chaîne std ::, n'est plus le nombre de caractères dans la chaîne.

1. Lorsque vous souhaitez stocker des caractères "larges" (Unicode).
2. Oui: 255 d'entre eux (hors 0).
3. Oui.
4. Voici un article d'introduction: http://www.joelonsoftware.com/articles/Unicode.html

1. lorsque vous souhaitez utiliser des chaînes Unicode et pas seulement ascii, utile pour l'internationalisation
2. oui, mais ça ne fonctionne pas bien avec 0
3. pas au courant de ceux qui ne le font pas
4. le caractère large est la manière spécifique au compilateur de gérer la représentation de longueur fixe d'un caractère unicode, pour MSVC, il s'agit d'un caractère à 2 octets, pour gcc, je comprends qu'il est de 4 octets. et un +1 pour http://www.joelonsoftware.com/articles/Unicode.html

Les applications qui ne sont pas satisfaites avec seulement 256 caractères différents ont la possibilité d'utiliser des caractères larges (plus de 8 bits) ou un codage de longueur variable (un codage multi-octets dans la terminologie C ++) tel que UTF-8. Les caractères larges nécessitent généralement plus d'espace qu'un encodage de longueur variable, mais sont plus rapides à traiter. Les applications multilingues qui traitent de grandes quantités de texte utilisent généralement des caractères larges lors du traitement du texte, mais le convertissent en UTF-8 lors du stockage sur disque.

La seule différence entre a stringet a wstringest le type de données des caractères qu'ils stockent. Une chaîne stocke des chars dont la taille est garantie d'être d'au moins 8 bits, vous pouvez donc utiliser des chaînes pour traiter par exemple du texte ASCII, ISO-8859-15 ou UTF-8. La norme ne dit rien sur le jeu de caractères ou l'encodage.

Pratiquement tous les compilateurs utilisent un jeu de caractères dont les 128 premiers caractères correspondent à ASCII. C'est également le cas avec les compilateurs qui utilisent le codage UTF-8. La chose importante à savoir lorsque vous utilisez des chaînes en UTF-8 ou un autre codage de longueur variable, c'est que les indices et les longueurs sont mesurés en octets, pas en caractères.

Le type de données d'un wstring est wchar_t , dont la taille n'est pas définie dans la norme, sauf qu'elle doit être au moins aussi grande qu'un caractère, généralement 16 bits ou 32 bits. wstring peut être utilisé pour traiter du texte dans le codage à caractères larges défini par l'implémentation. Étant donné que l'encodage n'est pas défini dans la norme, il n'est pas simple de convertir entre chaînes et wstrings. On ne peut pas non plus supposer que wstrings a un codage de longueur fixe.

Si vous n'avez pas besoin de prise en charge multilingue, vous pourriez être en mesure d'utiliser uniquement des chaînes régulières. En revanche, si vous écrivez une application graphique, il arrive souvent que l'API ne prenne en charge que les caractères larges. Ensuite, vous souhaiterez probablement utiliser les mêmes caractères larges lors du traitement du texte. Gardez à l'esprit que UTF-16 est un encodage de longueur variable, ce qui signifie que vous ne pouvez pas supposer length()renvoyer le nombre de caractères. Si l'API utilise un encodage de longueur fixe, tel que UCS-2, le traitement devient facile. La conversion entre des caractères larges et UTF-8 est difficile à faire de manière portable, mais là encore, votre interface utilisateur API prend probablement en charge la conversion.

Une bonne question! Je pense que le CODAGE DES DONNÉES (parfois un CHARSET est également impliqué) est une EXPRESSION DE MÉMOIRE MÉCANISME D' DE afin d'enregistrer des données dans un fichier ou de transférer des données via un réseau, donc je réponds à cette question comme suit:

1. Quand dois-je utiliser std :: wstring sur std :: string?

Si la plate-forme de programmation ou la fonction API est un octet unique, et que nous voulons traiter ou analyser certaines données Unicode, par exemple, lire à partir du fichier Windows'.REG ou du flux réseau de 2 octets, nous devons déclarer la variable std :: wstring facilement les traiter. par exemple: wstring ws = L "中国 a" (mémoire de 6 octets: 0x4E2D 0x56FD 0x0061), nous pouvons utiliser ws [0] pour obtenir le caractère '中' et ws [1] pour obtenir le caractère '国' et ws [2] pour obtenir le caractère «a», etc.

2. std :: string peut-il contenir tout le jeu de caractères ASCII, y compris les caractères spéciaux?

Oui. Mais remarquez: ASCII américain, signifie que chaque octet 0x00 ~ 0xFF représente un caractère, y compris le texte imprimable tel que "123abc & * _ &" et vous en avez dit un spécial, l'imprimant principalement sous la forme d'un '.' éviter de confondre les éditeurs ou les terminaux. Et certains autres pays étendent leur propre jeu de caractères "ASCII", par exemple le chinois, utilise 2 octets pour représenter un caractère.

3. std :: wstring est-il pris en charge par tous les compilateurs C ++ populaires?

Peut-être, ou surtout. J'ai utilisé: VC ++ 6 et GCC 3.3, YES

4. Qu'est-ce qu'un "caractère large" exactement?

un caractère large indique principalement l'utilisation de 2 octets ou 4 octets pour contenir tous les caractères des pays. 2 octets UCS2 est un échantillon représentatif, et en outre par exemple en anglais 'a', sa mémoire est de 2 octets de 0x0061 (vs en ASCII 'la mémoire de a est de 1 octet 0x61)

Il y a de très bonnes réponses ici, mais je pense qu'il y a quelques choses que je peux ajouter concernant Windows / Visual Studio. C'est basé sur mon expérience avec VS2015. Sous Linux, la solution consiste essentiellement à utiliser UTF-8 encodé std::stringpartout. Sous Windows / VS, cela devient plus complexe. Voici pourquoi. Windows attend des chaînes stockées à l'aidechar s soient encodées à l'aide de la page de codes locale. Il s'agit presque toujours du jeu de caractères ASCII suivi de 128 autres caractères spéciaux selon votre emplacement. Permettez-moi de préciser que cela ne se produit pas uniquement lors de l'utilisation de l'API Windows, il existe trois autres endroits majeurs où ces chaînes interagissent avec le C ++ standard. Ce sont des littéraux de chaîne, sortis en std::coututilisant <<et en passant un nom de fichier àstd::fstream .

Je dirai ici que je suis programmeur, pas spécialiste des langues. J'apprécie que USC2 et UTF-16 ne sont pas les mêmes, mais à mes fins, ils sont suffisamment proches pour être interchangeables et je les utilise comme tels ici. Je ne sais pas vraiment quel Windows utilise, mais je n'ai généralement pas besoin de le savoir non plus. J'ai indiqué UCS2 dans cette réponse, donc désolé à l'avance si je contrarie quelqu'un avec mon ignorance de cette question et je suis heureux de le changer si je me trompe.

Littéraux de chaîne

Si vous entrez des littéraux de chaîne qui ne contiennent que des caractères pouvant être représentés par votre page de code, VS les stocke dans votre fichier avec un codage de 1 octet par caractère basé sur votre page de code. Notez que si vous changez votre page de code ou donnez votre source à un autre développeur en utilisant une page de code différente, je pense (mais je n'ai pas testé) que le personnage finira différent. Si vous exécutez votre code sur un ordinateur en utilisant une page de codes différente, je ne sais pas si le caractère changera également.

Si vous entrez des littéraux de chaîne qui ne peuvent pas être représentés par votre page de code, VS vous demandera d'enregistrer le fichier en Unicode. Le fichier sera ensuite encodé en UTF-8. Cela signifie que tous les caractères non ASCII (y compris ceux qui se trouvent sur votre page de code) seront représentés par 2 octets ou plus. Cela signifie que si vous donnez votre source à quelqu'un d'autre, la source sera la même. Cependant, avant de transmettre la source au compilateur, VS convertit le texte codé UTF-8 en texte codé de page de code et tous les caractères manquants de la page de code sont remplacés par? .

La seule façon de garantir une représentation correcte d'un littéral de chaîne Unicode dans VS est de faire précéder le littéral de chaîne d'un en Lfaisant un littéral de chaîne large. Dans ce cas, VS convertira le texte encodé UTF-8 du fichier en UCS2. Vous devez ensuite passer ce littéral de chaîne dans un std::wstringconstructeur ou vous devez le convertir en utf-8 et le mettre dans a std::string. Ou si vous le souhaitez, vous pouvez utiliser les fonctions de l'API Windows pour l'encoder en utilisant votre page de codes pour le mettre dans unstd::string , mais vous pouvez aussi ne pas avoir utilisé un littéral de chaîne large.

std :: cout

Lors de la sortie vers la console à l'aide de, <<vous pouvez uniquement utiliser std::string, non std::wstringet le texte doit être codé à l'aide de votre page de code locale. Si vous en avez un, std::wstringvous devez le convertir à l'aide de l'une des fonctions de l'API Windows et tous les caractères ne figurant pas sur votre page de code seront remplacés par ?(vous pouvez peut-être changer le caractère, je ne me souviens pas).

std :: fstream noms de fichiers

Le système d'exploitation Windows utilise UCS2 / UTF-16 pour ses noms de fichiers, quelle que soit votre page de code, vous pouvez avoir des fichiers avec n'importe quel caractère Unicode. Mais cela signifie que pour accéder ou créer des fichiers avec des caractères ne figurant pas sur votre page de code, vous devez utiliser std::wstring. Il n'y a pas d'autre moyen. Il s'agit d'une extension spécifique à Microsoft std::fstreamqui ne se compilera donc probablement pas sur d'autres systèmes. Si vous utilisez std :: string, vous ne pouvez utiliser que des noms de fichiers qui incluent uniquement des caractères sur votre page de code.

Vos options

Si vous travaillez uniquement sur Linux, vous n'êtes probablement pas allé aussi loin. Utilisez simplement UTF-8 std::stringpartout.

Si vous travaillez uniquement sur Windows, utilisez simplement UCS2 std::wstringpartout. Certains puristes peuvent dire utiliser UTF8 puis convertir au besoin, mais pourquoi s'embêter avec les tracas.

Si vous êtes multiplateforme, c'est un gâchis d'être franc. Si vous essayez d'utiliser UTF-8 partout sur Windows, vous devez être très prudent avec vos littéraux de chaîne et la sortie vers la console. Vous pouvez facilement y corrompre vos chaînes. Si vous utilisez std::wstringpartout sur Linux, vous n'aurez peut-être pas accès à la version large de std::fstream, vous devez donc effectuer la conversion, mais il n'y a aucun risque de corruption. Personnellement, je pense que c'est une meilleure option. Beaucoup seraient en désaccord, mais je ne suis pas seul - c'est le chemin emprunté par wxWidgets par exemple.

Une autre option pourrait être de taper unicodestringcomme std::stringsous Linux et std::wstringsous Windows, et d'avoir une macro appelée UNI () qui préfixe L sous Windows et rien sous Linux, puis le code

#include <fstream>
#include <string>
#include <iostream>
#include <Windows.h>

#ifdef _WIN32
typedef std::wstring unicodestring;
#define UNI(text) L ## text
std::string formatForConsole(const unicodestring &str)
{
    std::string result;
    //Call WideCharToMultiByte to do the conversion
    return result;
}
#else
typedef std::string unicodestring;
#define UNI(text) text
std::string formatForConsole(const unicodestring &str)
{
    return str;
}
#endif

int main()
{

    unicodestring fileName(UNI("fileName"));
    std::ofstream fout;
    fout.open(fileName);
    std::cout << formatForConsole(fileName) << std::endl;
    return 0;
}

serait bien sur l'une ou l'autre plate-forme, je pense.

Réponses

Alors pour répondre à vos questions

1) Si vous programmez pour Windows, alors tout le temps, si multiplateforme, peut-être tout le temps, à moins que vous ne vouliez faire face à d'éventuels problèmes de corruption sur Windows ou écrire du code avec une plate-forme spécifique #ifdefspour contourner les différences, si vous utilisez simplement Linux alors jamais.

2) Oui. De plus, sous Linux, vous pouvez également l'utiliser pour tous les Unicode. Sous Windows, vous ne pouvez l'utiliser pour tous les Unicode que si vous choisissez de coder manuellement en utilisant UTF-8. Mais l'API Windows et les classes C ++ standard s'attendent std::stringà ce qu'elles soient encodées à l'aide de la page de codes locale. Cela inclut tous les caractères ASCII et 128 autres caractères qui changent en fonction de la page de codes que votre ordinateur est configuré pour utiliser.

3) Je le crois, mais sinon, ce n'est qu'un simple typedef d'un 'std :: basic_string' utilisant wchar_tau lieu dechar

4) Un caractère large est un type de caractère plus grand que le chartype standard à 1 octet . Sous Windows, il est de 2 octets, sous Linux, il est de 4 octets.

1) Comme l'a mentionné Greg, wstring est utile pour l'internationalisation, c'est à ce moment-là que vous publierez votre produit dans des langues autres que l'anglais

4) Vérifiez ceci pour un caractère large http://en.wikipedia.org/wiki/Wide_character

Quand ne devez-vous PAS utiliser de caractères larges?

Lorsque vous écrivez du code avant l'année 1990.

Évidemment, je suis en train de flip, mais vraiment, c'est le 21e siècle maintenant. 127 caractères ont depuis longtemps cessé d'être suffisants. Oui, vous pouvez utiliser UTF8, mais pourquoi vous embêter avec les maux de tête?