...when altering one's mind becomes as easy as programming a computer, what does it mean to be human?..
| Культура | Формат |
|---|---|
| Соединённые Штаты | 1,234,567.89 |
| Франция | 1 234 567,89 |
| Германия | 1.234.567,89 |
| Швеция | 1'234'567.89 |
В контексте ansi (не unicode) приложения: как общие элементы управления (к примеру, listview) решают, какую использовать кодовую страницу для перевода многобайтовых строк в widestring?Хотя я редко, если вообще когда-нибудь, не соглашусь с чем-то, что исходит из лагеря команды Оболочки, конкретно в этом случае я знаю два конкретных исключения из правила CP_ACP, которое вы обычно видите, хотя эти отличия могут иметь мало общего с кодом Shell / comctl32, так что Реймонд может быть прав в своей области :-)
Мне пришлось отлаживать ansi приложение, которое показывало испорченные строки на системе с традиционным китайским, потому что шрифт диалога привёл к тому, что listview использовал иную кодовую страницу, нежели системную ACP, при переводи multibyte в widechar.
Привет, Майкл.Постоянные читатели могут вспомнить, почему я не люблю локаль потока.
Я встретился с чем-то, что, как я считаю, является багом вMultibyteToWideCharиWideCharToMultibyte, когда параметр кодовой страницы устанавливается вCP_THREAD_ACP, 'язык по-умолчанию для не-Unicode приложений' - установленный в иврит. Это видно, когда используется вспомогательный макрос изatlconv.hвродеT2WC.
Я создал простое тестовое приложение, которое показывает неожиданные результаты на некоторых системах. Кодовая страница отCP_THREAD_ACPполучается не той же самой, чтоGetACP. Я воспроизвёл это на двух системах с ивритом, но не на системах, где стоит традиционный китайский - одна из которым имеет полностью локализированный в традиционном китайском UI. Исходник является частью консольного проекта .NET 2003 по умолчанию.#include "stdafx.h" #include <ostream> int _tmain(int argc, _TCHAR* argv[]) { std::cout << "default code page is " << GetACP() << std::endl; std::cout << "_AtlGetConversionACP code page is " << ATL::_AtlGetConversionACP() << std::endl; CPINFOEX cpinfo = {}; GetCPInfoEx(ATL::_AtlGetConversionACP(), 0, &cpinfo); std::cout << "Thread code page is " << cpinfo.CodePage << std::endl; return 0; }Мои результаты:default code page is 1255 _AtlGetConversionACP code page is 3 Thread code page is 1252Когда моё приложение вызываетT2WC, оно получает неверный результаты, а кодовые точки расширяются до 16-ти бит, но не конвертируются в кодовые точки иврита. Мы обходим это использованием_CONVERSION_DONT_USE_THREAD_LOCALE, но мне любопытно, сталкивался ли кто-то ещё с этой проблемой ранее.
Спасибо за потраченное на меня время,
Ken
shell32.dll и shlwapi.dll - наверное, скоро я за это засяду!)GetThreadLocale и SetThreadLocale являются двумя из многих NLS функций, которыми владеет команда GIFT.SetLocaleInfo - тоже отстой).SetLocaleInfo, которая появилась в NT 3.1 просто воняет.Привет, Майкл.Это звучит очень знакомо.
Я погуглил по твоему блогу, но не нашёл ответа на такой вопрос. Этот вопрос довольно популярен (по крайней мере, в России), и я был удивлён, что ты его ещё не покрыл. Так что, быть может, ты расскажешь историю за этим вопросом. Это вопрос про буфер обмена, текст и не Unicode приложения.
Возьми старое не Unicode приложение (вроде блокнота из Win9x) и запусти его на новых Windows (вроде XP), которая имеет два установленных языка (скажем, английский и русский). Предположим, что "Язык для не Unicode приложений" установлен в "Русский".
В Win9x ты мог без проблем скопировать текст через буфер обмена из любого приложения в любое другое. Конечно, старые приложения не заботились об установке CF_LOCALE вместе с CF_TEXT, но всё работало довольно прилично, поскольку приложениями использовалась одна и та же кодовая страница (ладно: почти всеми).
Теперь, возьми современную, "юникодную" ОС, вроде XP. Ты берёшь своё старое приложение, которое верой и правдой служило тебе много лет, копируешь текст в буфер и вставляешь в другое приложение (скажем, блокнот из Windows XP) и... ух ты: ты получаешь вопросительные знаки или белиберду. Что не так? Чёрт, ты забыл переключить клавиатуру на "Русский". Как только ты это сделаешь - всё начнёт работать нормально.
Верхний ряд: слева - блокнот из Win98, справа - блокнот из XP. Нижний ряд: слева - блокнот из XP, справа - из Win98. Текущий язык стоит в "English (United states)" (ну, т.е. мы не переключили на русский). Красные линии указывают операцию копирования текста через буфер обмена (я специально взял два приложения от Microsoft, чтобы указать, что это не баг в каком-то конректном стороннем приложении).
Проблема (как я её вижу) заключается в получении Unicode-текста из ANSI-текста. Почему Windows использует для этого метод ввода, а не "Язык для не Unicode приложений"?
Это ужасное нарушение в опыте использования. Большинство людей считают, что это баг. Я очень часто слышу эту жалобу (чёрт, да я слышу проклятия Microsoft почти всегда в таких случаях). Особенно тяжело объяснить, что это не баг в твоём приложении, написанном много лет назад - оно не виновато.
Не мог бы ты пролить немного света на эту проблему? Почему Microsoft решила (ладно, не сломать, но) усложнить жизнь базилионам существующих приложений? Если Microsoft так заботится об обратной совместимости, то почему было сделано такое решение?
LCMapString, когда вы используете её для создания ключей сортировки, а также о путанице в параметрах к GetLocaleInfo, когда она возвращала числа.LCMapString при создании ключей сортировки.TranslateCharsetInfo:
У моего клиента есть проблемы с APIРезультаты двух значений LCID на самом деле вызваны двумя совершенно различными причинами.TranslateCharsetInfo. Они указывают флагTCI_SRCLOCALEдля использования LCID как источника:fResult := TranslateCharsetInfo(langid, csi, TCI_SRCLOCALE);Они обнаружили, что результаты этого вызова не всегда соответствуют значениям, указанным в http://www.microsoft.com/globaldev/nlsweb/default.mspx
В частности:
LCID$0C04– Chinese (Hong Kong S.A.R.) - возвращает кодовую страницу 936 вместо ожидаемой 950
LCID$0004- Chinese (Simplified) – возвращает кодовую страницу 950 вместо ожидаемой 936
То, что я вижу - это ожидаемое поведение или нет? Если нет, то какой есть другой способ?
Мы также попробовали:GetLocaleInfo(langid, LOCALE_IDEFAULTANSICODEPAGE, szLocaleData, SizeOf(szLocaleData)/SizeOf(Char));Хотя этот способ возвращает 950 для LCID$0C04(уже лучше), но LCID$0004всё ещё возвращает 950 вместо 936.
Или я что-то упускаю?
Many thanks,
Colin
LCMapString работает с ключами сортировки.LCMAP_SORTKEY, то она возвращала вам двоичное представление строки (подходящее для использования в качестве индекса).