Многобайтовый набор символов в приложении MFC
У меня есть приложение MFC, в которое я хочу добавить поддержку интернационализации. Проект настроен на использование «многобайтового набора символов» («набор символов Юникода» в моей ситуации не подходит).
Теперь я ожидаю, что функция CWnd :: OnChar () отправит мне многобайтовые символы, если я установлю на клавиатуре какой-либо иностранный язык, но, похоже, это не работает. Функция OnChar () всегда отправляет мне 1-байтовый символ в своей переменной nChar.
Я думал, что функция _getmbcp () даст мне текущую кодовую страницу для приложения, но эта функция всегда возвращает 0.
Любой совет будет принят во внимание.
Инструмент зависит от многих других библиотек, которые даже близко не поддерживают Unicode. Обновить все можно было бы, но очень долго. Если есть решение с использованием многобайтов, возьму.
«многобайтовый набор символов» - это что-то вроде «языка». Какой из них «тот»? Если приложение использует многобайтовые наборы символов, оно будет использовать любую кодовую страницу, действующую при запуске. Unicode позволяет избежать этой проблемы.
Ответы 5
И здесь помочь? Многобайтовые функции в среде выполнения Microsoft C
Что ж, я надеялся, что изменение локальной клавиатуры автоматически изменит кодовую страницу в моем приложении. Мое предположение неверно? Неужели нам действительно нужно всегда устанавливать кодовую страницу вручную? Если да, то как сделать так, чтобы кодовая страница соответствовала раскладке клавиатуры?
При изменении раскладки клавиатуры изменяются значения или значения значений (т.е. какие символы какие), которые отправляются с клавиатуры. Каждый байт - это числовое значение. Приложение интерпретирует значения в соответствии с кодовой страницей приложения.
Хорошо, вот чего я боялся.
Сайт сейчас недоступен
Что касается изменения кодовой страницы по умолчанию:
Кодовая страница по умолчанию для пользователя (для WinXP - не знаю, как в Vista) устанавливается в апплете «Региональные и языковые параметры» панели управления на вкладке «Дополнительно».
«Язык для программ, не поддерживающих Юникод» устанавливает кодовую страницу по умолчанию для текущего пользователя. К сожалению, он на самом деле не сообщает вам номер настраиваемой кодовой страницы - он просто указывает язык (который может быть дополнительно указан с вариантом региона). Это имеет смысл с точки зрения конечного пользователя, потому что я думаю, что номера кодовых страниц не имеют значения для 99,999% конечных пользователей. Вам необходимо перезагрузить компьютер, чтобы изменения вступили в силу. Если вы используете regmon, чтобы определить, какие изменения вы, вероятно, можете придумать что-то, что задает кодовую страницу по умолчанию несколько проще.
У Microsoft также есть неподдерживаемая утилита AppLocale для тестирования локализации, которая изменяет кодовую страницу для определенных приложений: http://www.microsoft.com/globaldev/tools/apploc.mspx
Также вы можете изменить кодовую страницу для потока, вызвав SetThreadLocale(), но вам также необходимо вызвать функцию setlocale() среды выполнения C, потому что некоторые функции CRT не взаимодействуют с функциями локали Win API (и наоборот). Подробнее см. "Windows SetThreadLocale и CRT setlocale" Криса Граймса.
Для _getmbcp MSDN сообщает: «Возвращаемое значение 0 указывает, что используется однобайтовая кодовая страница». Конечно, это делает его не очень полезным. Попробуйте одно из следующих: GetUserDefaultLCID GetSystemDefaultLCID GetACP. (Почему же для GetACP нет «пользовательского» эквивалента?)
В любом случае, если вы хотите, чтобы _getmbcp возвращал фактическое значение, установите язык по умолчанию для вашей системы на китайский, японский или корейский.
Как всегда в сценариях, отличных от Unicode, вы получите надежный результат только в том случае, если системный языковой стандарт (также известный в Панели управления, как «язык для приложений, отличных от Unicode») установлен соответствующим образом. Если нет, не ждите ничего хорошего.
Например, если языковой стандарт системы - традиционный китайский, вы получите 2 последовательных сообщения WM_CHAR (по одному на каждый байт, если пользователь создал 2-символьный символ).
isleadbyte () должен помочь вам определить, скоро ли появится второй байт.
Если локаль вашей системы НЕ установлена на китайский язык, не ожидайте получения правильных сообщений даже при использовании китайской клавиатуры / IME. Заблуждение заключается в том, что некоторые сценарии работают. например используя греческую клавиатуру, вы получите значения символов WM_CHAR на основе греческой кодовой страницы, даже если ваш системный языковой стандарт основан на латинице. Но вам действительно следует избегать попыток справиться с такими сценариями: успех не гарантируется и, вероятно, будет зависеть от версии Windows и локали.
Как писал MikeB, MS AppLocale - ваш друг для проведения базовых тестов.
[ad] и appTranslator - ваш друг, если вам нужно перевести интерфейс [/ ad]
На самом деле существует очень простой (но странный) способ заставить функцию OnChar отправлять символы Unicode в приложение, даже если оно настроено в многобайтовом наборе символов:
SetWindowLongW( m_hWnd, GWL_WNDPROC, GetWindowLong( m_hWnd, GWL_WNDPROC ) );
Просто вызывая unicode-версию SetWindowLong, он заставляет приложение получать символы Unicode.
Мартин, ради интереса, почему Unicode не подходит? Политический или технический? Раньше я использовал библиотеку UnicoWS, чтобы заставить Unicode работать для Win9x FWIW.