Как мне записать файлы MBCS из приложения UNICODE?

К сожалению, это огромная тема, которая заслуживает небольшой книги, посвященной ей. И этой книге, в основном, понадобится специальная глава для каждой целевой платформы, для которой она нужна (Linux, Windows [flavour], Mac и т. Д.).

Мой ответ будет касаться только настольных приложений Windows, скомпилированных для C ++ с или без MFC.
Обратите внимание: это относится к желанию считывать и записывать файлы MBCS (узкие) из сборки UNICODE, используя системную кодовую страницу по умолчанию (то есть кодовую страницу для программного обеспечения, отличного от Unicode). Если вы хотите читать и записывать файлы Unicode из сборки UNICODE, вы должны открыть файлы в двоичном режиме и вручную обработать преобразования спецификации и перевода строки (т. Е. При вводе, вы должны пропустить спецификацию (если есть), и оба преобразовать внешнюю кодировку в Windows Unicode [т.е. UTF-16LE], а также преобразовать любые последовательности CR + LF только в LF, а для вывода необходимо записать спецификацию (если есть) и преобразовать из UTF-16LE в любую целевую кодировку вы хотите, плюс вы должны конвертировать LF в CR + LF последовательности, чтобы это был правильно отформатированный текстовый файл ПК).

ОСТЕРЕГАЙТЕСЬ, что MS-библиотека std C устанавливает и получает, fwrite и т. Д., Которая при открытии в текстовом / переведенном режиме преобразует любой 0x0D в последовательность 0x0A 0x0D при записи и наоборот при чтении, независимо от того, читаете вы или запись одного байта, или широкого символа, или потока случайных двоичных данных — это не волнует, и все эти функции сводятся к выполнению слепых байтовых преобразований в режиме текста / перевода !!!

Также имейте в виду, что многие функции Windows API используют CP_ACP внутри, без какого-либо внешнего контроля за их поведением (например, WritePrivateProfileString()). Отсюда причина, по которой можно захотеть убедиться, что все библиотеки работают с одним и тем же языковым стандартом: CP_ACP, а не с какой-либо другой, поскольку вы не можете управлять некоторыми функциями поведения, вы вынуждены соответствовать их выбору или не использовать их вообще.

При использовании MFC необходимо:

// force CP_ACP *not* CP_THREAD_ACP for MFC CString auto-conveters!!!
// this makes MFC's CString and CStdioFile and other interfaces use the
// system default code page, instead of the thread default code page (which is normally "c")
#define _CONVERSION_DONT_USE_THREAD_LOCALE

Для библиотек C ++ и C необходимо указать библиотекам использовать системную кодовую страницу:

// force C++ and C libraries based on setlocale() to use system locale for narrow strings
// (this automatically calls setlocale() which makes the C library do the same thing as C++ std lib)
// we only change the LC_CTYPE, not collation or date/time formatting
std::locale::global(std::locale(str(boost::format(".%||") % GetACP()).c_str(), LC_CTYPE));

Я делаю #define во всех моих предварительно скомпилированных заголовках, прежде чем включать любые другие заголовки. Я установил глобальную локаль в main (или ее моральный эквивалент), один раз для всей программы (вам может потребоваться вызывать ее для каждого потока, который будет выполнять ввод / вывод или преобразование строк).

Цель сборки — UNICODE, и для большинства наших операций ввода-вывода мы используем явные преобразования строк перед выводом через CStringA(my_wide_string),

Еще одна вещь, о которой следует помнить, это два разных набора многобайтовых функций в стандартной библиотеке C под VS C ++ — те, которые используют локаль потока для своих операций, и другой набор, который использует то, что называется _setmbcp() (который вы можете запросить через _getmbcp(), Это фактическая кодовая страница (не локаль), которая используется для интерпретации всех узких строк (ПРИМЕЧАНИЕ: это всегда инициализируется как CP_ACPт.е. GetACP() кодом запуска VS C ++).

Полезные справочные материалы:
— секретные семьи сплит-в-окна-кодовые страницы-функций
— Разбираемся (объясняется, что в Windows действуют четыре разных локали)
— MS предлагает некоторые функции, которые позволяют установить кодировку для непосредственного использования, но я их не изучал
— Важное замечание об изменении в MFC, которое привело к тому, что оно больше не уважает CP_ACP, а скорее CP_THREAD_ACP по умолчанию, начиная с MFC 7.0
— Исследование того, почему консольные приложения в Windows крайне неудачны, когда дело доходит до ввода-вывода Unicode
— Макросы преобразования узкой / широкой строки в MFC / ATL (которые я не использую, но вы можете найти полезными)
— Маркер порядка байтов, который необходимо записать для файлов Unicode любой кодировки, понятной для другого программного обеспечения Windows