El apóstrofe tipográfico + la cadena ancha ancha rompió mi wofstream (C ++)

Question

Acabo de encontrar un comportamiento extraño al tratar con el siniestro apóstrofe tipográfico (& # 8217;) & # 8211; no el apóstrofe de la máquina de escribir ('). Utilizado con literal de cadena ancha, el apóstrofe rompe wofstream.

Este código funciona

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

== > A & # 8217; B

Este código funciona

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

== > A & # 8217; B

Este código falla

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

== > A

Este código falla ...

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

== > A

¿Alguna idea?

Answer 1

Debes " habilitar " locale antes de usar wofstream:

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

Por lo tanto, si tiene la configuración regional del sistema en_US.UTF-8 , el archivo test.txt incluirá datos codificados utf8 (4 byes), si tiene la configuración regional del sistema en_US.ISO8859-1 , la codificará como codificación de 8 bits (3 bytes), a menos que ISO 8859-1 pierda ese carácter.

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

Este código funciona porque " A & # 8217; B " es en realidad una cadena utf-8 y usted guarda utf-8 cadena a archivo byte por byte.

Nota: supongo que estás utilizando POSIX como sistema operativo, y tienes una configuración regional predeterminada diferente de " C " esa es la configuración regional predeterminada.

Answer 2

¿Está seguro de que no es su soporte del compilador para los caracteres Unicode en los archivos de origen que está "roto"? ¿Qué sucede si utiliza \ x o similar para codificar el carácter en el literal de cadena? ¿Es su archivo fuente incluso en cualquier codificación que pueda tener un wchar_t para su compilador?

Answer 3

Intente envolver el carácter de inserción de la secuencia en un bloque try-catch y díganos qué excepción, si alguna, produce.

No estoy seguro de lo que está pasando aquí, pero acosaré una suposición de todos modos. El apóstrofe tipográfico probablemente tiene un valor que cabe en un byte. Esto funciona con " A’B " ya que copia a ciegas los bytes sin preocuparse por la codificación subyacente. Sin embargo, con L " A’B " , un factor de codificación dependiente de la implementación entra en juego. Probablemente no encuentre el valor UTF-16 adecuado (si está en Windows) o UTF-32 (si está en * nix / Mac) para almacenar este carácter en particular.