После дополнительных исследований и написания нескольких демонстрационных приложений на C ++ и C# я пересматриваю этот вопрос, чтобы лучше ориентироваться на проблему, с которой я столкнулся.
Формулировка проблемы: У меня есть приложение (Visual Studio) MF C Unicode, которое используется некоторыми людьми в Японии. Одна из функций приложения выводит расширенный метафайл в буфер обмена для вставки в другие приложения. Приложение MF C является приложением OLE-сервера и использует COleServerItem :: CopyToClipboard для добавления метафайла в буфер обмена. В некотором тексте метафайла используются глифы с кодами символов> 127. В японской версии Windows (с установленным языковым пакетом en-US) эти глифы неправильно отображаются при вставке в другое приложение. Вместо ожидаемых символов они отображаются в виде латинских букв другого шрифта. Не имеет значения, какой шрифт используется.
Ниже приводится демонстрация MF C app dr aws на экране с использованием специальных символов из шрифта Symbol: 
При копировании и вставке вышеуказанного расширенного метафайла в WordPad в японской версии windows результат будет: 
Если я изменю строки, использующие глифы, из CString (wchar_t) в CStringA (char) и используйте TextOutA вместо версии Unicode, тогда глифы отображаются правильно!
Дополнительный обходной путь, вместо использования COleServerItem :: CopyToClipboard, заключается в том, чтобы «вручную» помещать данные в буфер обмена, используя стандартные Буфер обмена C ++ функционирует как OpenClipboard, EmptyClipboard, SetClipboardData, CloseClipboard. Это также устраняет проблему, не меняя строки в метафайле на ANSI. Так что можно подумать, что проблема в COleServerItem :: CopyToClipboard. Однако есть связанная проблема, которая не связана с буфером обмена. Приложение использует устаревшую версию MSFlexGrid OCX. Объект com использует OLE, который является Unicode, но в системе Japanes Windows, когда сетки отображаются на экране, специальные глифы (расширенные коды символов ascii> 127) также отображаются неправильно. Обратите внимание: если вы просто копируете и вставляете простой текст любым шрифтом, проблем не возникает.
Я создал Git репозиторий (этот) с решением Visual Studio MF C, которое демонстрирует проблему на https://github.com/brewerpm/JapaneseWinClipboardUnicodeProblem.git. Действия по воспроизведению проблемы с помощью демонстрационного приложения:
Построение решения.
Скопируйте .exe в японскую версию Windows .
Запустите программу для отображения вывода.
Выберите метод, который будет использоваться для создания метафайла:
a , Используйте CClipboardDemoSrvrItem :: CopyToClipboard со строками Unicode.
b. Используйте CClipboardDemoSrvrItem :: CopyToClipboard со строками ANSI.
c. Используйте функции буфера обмена C ++ OpenClipboard, EmptyClipboard, SetClipboardData, CloseClipboard со строками Unicode.
Используйте Edit-> Copy или ctrl- c, чтобы скопировать вывод в буфер обмена как расширенный метафайл.
Вставьте в WordPad (или Word, если он установлен) и убедитесь, что «расширенные» символы из шрифта Symbol отображаются неправильно в каком-либо другом (резервном) шрифте при использовании метода (a), но отображаются правильно при использовании метода (b) или (c).
Другие вещи, которые я пробовал:
Добавление записи CF_LOCALE в буфер обмена, в котором указано «en-US» с использованием следующего кода:
Установка кодовой страницы в Western 1252.