Проблема с буфером обмена при использовании расширенных символов ASCII (chars > 127) в японских версиях windows
После дополнительных исследований и написания нескольких демонстрационных приложений как на C++, так и на C#, я пересматриваю этот вопрос, чтобы лучше ориентироваться на проблему, которую я видел.
Problem statement: I have a (Visual Studio) MFC Unicode app that is used by some people in Japan. One of the app's functions outputs an enhanced metafile to the clipboard for pasting into other applications. The MFC app is an OLE server app and uses COleServerItem::CopyToClipboard to add the metafile to the clipboard. Some of the text in the metafile use glyphs with character codes > 127. On a Japanese version of Windows (with a en-US language pack installed), those glyphs do not render properly when pasted into another application. Instead of the expected symbols, they are rendered as some latin chars in some other font. Doesn't make any difference what font is used.
Ниже приводится то, что демонстрационное приложение MFC рисует на экране с помощью специальных символов из шрифта символов: https://horoscope.blob.core.windows.net/japanese-os-clipboard-problem/FaithfulRendering-cropped-50%25.png[^]
При копировании и вставке вышеуказанного расширенного метафайла в WordPad на японской версии windows результат будет следующим: https://horoscope.blob.core.windows.net/japanese-os-clipboard-problem/RenderedImproperly-cropped-33%25.png[^]
Если я изменю строки, использующие глифы, с CString(wchar_t) на CStringA (char) и использую TextOutA вместо версии Unicode, то глифы будут отображаться правильно!
Дополнительный обходной путь, вместо использования COleServerItem::CopyToClipboard, заключается в том, чтобы "вручную" поместить данные в буфер обмена с помощью стандартных функций буфера обмена C++, таких как OpenClipboard, EmptyClipboard, SetClipboardData, CloseClipboard. Это также устраняет проблему без необходимости изменять строки в метафайле на ANSI. Поэтому можно подумать, что проблема кроется в COleServerItem::CopyToClipboard.
Однако существует связанная с этим проблема, которая не связана с буфером обмена. Приложение использует устаревший MSFlexGrid OCX. Com-объект использует OLE, который является Unicode, но в японской системе Windows, когда сетки отображаются на экране, специальные глифы (расширенные коды символов ascii > 127) также отображаются неправильно.
Обратите внимание, что если вы просто копируете и вставляете обычный текст любым шрифтом, то это не проблема.
Я создал репозиторий Git с решением Visual Studio MFC, которое демонстрирует эту проблему в GitHub - brewerpm/JapaneseWinClipboardUnicodeProblem: VS MFC решение для демонстрации использования расширенных символов ASCII с буфером обмена и OLE в японской версии Windows[^] .
Другие вещи, которые я пробовал (1) Добавить запись CF_LOCALE в буфер обмена, указывающую "en-US"; (2) указать локаль как "en-US" с помощью _wsetlocale(LC_ALL, L"en-US") в начале программы (InitInstance) и (3) установить кодовую страницу на Western 1252.
пмбревер
Что я уже пробовал:
(1) добавление записи CF_LOCALE в буфер обмена, указывающей "en-US"; (2) указание локали как "en-US" с помощью _wsetlocale(LC_ALL, L"en-US") в начале программы (InitInstance) и (3) Установка кодовой страницы на Western 1252.
phil.o
Интересный вопрос :)
Что касается Wordpad с буфером обмена, то буфер обмена содержит только байты, представляющие строку в кодовой странице приложения. Он не несет никакой информации о шрифте; таким образом, при вставке Wordpad отображает скопированный текст со своим собственным настроенным шрифтом. Я не думаю, что вы можете обойти это (кроме ручного изменения шрифта для соответствующих символов, но я почти уверен, что это неприемлемо для вас).
К сожалению, я не могу дать ответ на остальные вопросы, хотя меня очень интересуют возможные решения.
RockyMu
Спасибо за ваш ответ. На самом деле WordPad действительно сохраняет информацию о шрифте, и вставка из буфера обмена со специальными глифами шрифтов работает нормально (в западных версиях Windows). Возможно, WordPad был плохим примером, который я использовал только потому, что он доступен на японской виртуальной машине Windows, которую я создал для тестирования. Главное, что copy and paste производит неправильный шрифт в японских (вероятно, всех восточноазиатских) версиях Windows.
KarstenK
Мой лучший совет заключается в том, что вы должны сами кодировать эти специальные символы с помощью некоторого эскейп-кода unicode и копировать обычный текст. (как-то похоже на HTML)
RockyMu
Спасибо, Карстен. Я думаю, что просто кодирование их как ANSI-это самый простой обходной путь. Предполагается, что Unicode решает все эти типы проблем. Вот что меня озадачило.
RockyMu
Эта проблема в настоящее время находится в Сортировке в сообществе разработчиков Microsoft https://developercommunity.visualstudio.com/content/problem/992225/problem-with-clipboard-when-using-extended-ascii-c.html.