Unicode конвертирует проблемы C ++ - PullRequest
Новая
       3

Unicode конвертирует проблемы C ++

1 голос
/ 25 октября 2011

У меня странные проблемы с юникодом, которые я не могу понять.

По сути, у меня есть приложение для командной строки, которое при ручном запуске из командной строки успешно вызывает mbtowcs () для различных входных данных (http://www.cplusplus.com/reference/clibrary/cstdlib/mbstowcs/) управляет строками и возвращает правильный вывод.

Всякий раз, когда приложение запускается автоматически с помощью monit, эта функция больше не преобразует правильное число байтов, а вывод в основном искажается и перемежается с бриллиантами ошибки Unicode. Я проверил это для тех же самых входов.

Я подозреваю, что это связано с локалью или некоторыми настройками на машине (Ubuntu server 11.04). Я звоню setlocale (LC_CTYPE, ""); успешно в моей функции запуска.

Кто-нибудь может мне посоветовать, какие настройки системы мне следует изменить, чтобы заставить мой код работать правильно?

Обновление: похоже на изменение 

setlocale(LC_CTYPE, "");

до 

setlocale(LC_CTYPE, "en_US.UTF-8");

Возможно, проблема решена. Кто-нибудь может предоставить какую-либо информацию о том, почему это необходимо, или как я могу изменить настройки системы, чтобы избежать этого?

1 Ответ

0 голосов
/ 25 октября 2011

Дело в том, что преобразование байтовых строк в wchar_t строки должно зависеть от локали. Это потому, что функция mbstowcs должна знать кодировку символов для ввода байтовой строки и обычно использует локаль, чтобы помочь ей угадать.

например. Если ваши входные байты: 

C3 B6

Тогда, если интерпретируется как UTF-8, это строка ö, которая является wchar_t последовательностью 

00F6

Но если интерпретировать как iso-8859-1, это строка ö, которая является wchar_t последовательностью 

00C3 00B6

Теперь некоторые последовательности байтов недопустимы для определенных кодировок, что, вероятно, объясняет ваши ошибки в кодировке Unicode. Если вы не хотите связываться с локалью, вы можете использовать библиотеку iconv. Тип wchar_t обычно соответствует одному из кодировок UTF-32 (LE или BE), но я не уверен, насколько это будет переносимым.

...