Проблема с буфером обмена при использовании расширенных символов ASCII (символы> 127) в японских версиях Windows - PullRequest
0 голосов
/ 28 марта 2020

После дополнительных исследований и написания нескольких демонстрационных приложений на C ++ и C# я пересматриваю этот вопрос, чтобы лучше ориентироваться на проблему, с которой я столкнулся.

Формулировка проблемы: У меня есть приложение (Visual Studio) MF C Unicode, которое используется некоторыми людьми в Японии. Одна из функций приложения выводит расширенный метафайл в буфер обмена для вставки в другие приложения. Приложение MF C является приложением OLE-сервера и использует COleServerItem :: CopyToClipboard для добавления метафайла в буфер обмена. В некотором тексте метафайла используются глифы с кодами символов> 127. В японской версии Windows (с установленным языковым пакетом en-US) эти глифы неправильно отображаются при вставке в другое приложение. Вместо ожидаемых символов они отображаются в виде латинских букв другого шрифта. Не имеет значения, какой шрифт используется.

Ниже приводится демонстрация MF C app dr aws на экране с использованием специальных символов из шрифта Symbol: enter image description here При копировании и вставке вышеуказанного расширенного метафайла в WordPad в японской версии windows результат будет: enter image description here Если я изменю строки, использующие глифы, из 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. Действия по воспроизведению проблемы с помощью демонстрационного приложения:

  1. Построение решения.

  2. Скопируйте .exe в японскую версию Windows .

  3. Запустите программу для отображения вывода.

  4. Выберите метод, который будет использоваться для создания метафайла:

    a , Используйте CClipboardDemoSrvrItem :: CopyToClipboard со строками Unicode.

    b. Используйте CClipboardDemoSrvrItem :: CopyToClipboard со строками ANSI.

    c. Используйте функции буфера обмена C ++ OpenClipboard, EmptyClipboard, SetClipboardData, CloseClipboard со строками Unicode.

  5. Используйте Edit-> Copy или ctrl- c, чтобы скопировать вывод в буфер обмена как расширенный метафайл.

  6. Вставьте в WordPad (или Word, если он установлен) и убедитесь, что «расширенные» символы из шрифта Symbol отображаются неправильно в каком-либо другом (резервном) шрифте при использовании метода (a), но отображаются правильно при использовании метода (b) или (c).

Другие вещи, которые я пробовал:

  • Добавление записи CF_LOCALE в буфер обмена, в котором указано «en-US» с использованием следующего кода:

  • Установка кодовой страницы в Western 1252.

...