L'apostrophe typographique + le littéral large de chaîne a brisé mon wofstream (C ++)

Question

Je viens de rencontrer un comportement étrange en ce qui concerne l'apostrophe sinistre et typographique (& # 8217;) & # 8211; pas l'apostrophe de la machine à écrire ('). Utilisée avec un littéral de chaîne large, l'apostrophe rompt le wofstream.

Ce code fonctionne

ofstream file("test.txt");
file << "A’B" ;
file.close();

== > A & # 8217; B

Ce code fonctionne

wofstream file("test.txt");
file << "A’B" ;
file.close();

== > A & # 8217; B

Ce code échoue

wofstream file("test.txt");
file << L"A’B" ;
file.close();

== > Un

Ce code échoue ...

wstring test = L"A’B";
wofstream file("test.txt");
file << test ;
file.close();

== > Un

Une idée?

Answer 1

Vous devez "activer". locale avant d'utiliser wofstream:

std::locale::global(std::locale()); // Enable locale support 
wofstream file("test.txt");
file << L"A’B";

Donc, si vous avez les paramètres régionaux du système en_US.UTF-8 , le fichier test.txt inclura utf8 encoded data (4 byes), si vous avez l'environnement local du système en_US.ISO8859-1 , il l'encodera en tant qu'encodage à 8 bits (3 octets), à moins que l'ISO 8859-1 ne prenne ce caractère.

wofstream file("test.txt");
file << "A’B" ;
file.close();

Ce code fonctionne car "A & # 8217; B" est en fait une chaîne utf-8 et vous enregistrez utf-8. chaîne de fichier octet par octet.

Remarque: je suppose que vous utilisez POSIX comme un système d'exploitation et que les paramètres régionaux par défaut sont différents de " C " c'est la locale par défaut.

Answer 2

Êtes-vous sûr que le support de votre compilateur pour les caractères unicode dans les fichiers source n'est pas "cassé"? Que faire si vous utilisez \ x ou similaire pour encoder le caractère dans le littéral de chaîne? Est-ce que votre fichier source, même quel que soit le codage, vers un wchar_t pour votre compilateur?

Answer 3

Essayez de placer le caractère d'insertion de flux dans un bloc try-catch et de nous indiquer quelle, le cas échéant, une exception est générée.

Je ne suis pas sûr de ce qui se passe ici, mais je vais harceler de toute façon. L'apostrophe typographique a probablement une valeur qui s'inscrit dans un octet. Cela fonctionne avec "A & # 8217; B" car il copie aveuglément des octets sans se soucier du codage sous-jacent. Cependant, avec L "A & # 8217; B" , un facteur de codage dépendant de la mise en oeuvre entre en jeu. Il ne trouve probablement pas la valeur UTF-16 (si vous êtes sous Windows) ou UTF-32 (si vous êtes sous * nix / Mac) appropriée à stocker pour ce caractère particulier.