NLS от Microsoft.

← →
Тимохов © (2004-04-20 19:12) [0]

Хочу поднять такую тему.

Прочел тут от начала до конца раздел мсдн, посвященный National Language Support. Сложные мысли продят после этого в голове моей.

Вопросы:
1. Кто-нибудь вообще пишет на Дельфи полностью Unicode приложения?
2. Если пишет, то какими компонентами пользуется?
3. Задумывался ли кто-нибудь, что функция AnsiUpperCase будет работать, только если основным языком системы выбран именно русский? Запросто может быть по другому - на русском все рисутеся (т.е. шрифты есть), но!!! AnsiUpperCase не работает. Или этого вообще никого не волнует, т.к. идет исключительное нацеливание на российский рынок?

← →
Тимохов © (2004-04-20 19:12) [0]

← →
Игорь Шевченко © (2004-04-20 20:32) [1]

> 1. Кто-нибудь вообще пишет на Дельфи полностью Unicode приложения?

Я демки писал, без компонент(ов). В инете есть два варианта иерархии Uniсode-контролов, насколько они доделанные или нет, я не знаю. Одна ветка называется True Unicode Controls - можно поискать.

> 3. Задумывался ли кто-нибудь, что функция AnsiUpperCase
> будет работать, только если основным языком системы выбран
> именно русский?

Windows NT/2000/XP: To make the conversion, the function uses the language driver for the current language selected by the user at setup or by using Control Panel. If no language has been selected, the system completes the conversion by using internal default mapping. The conversion is made based on the code page associated with the process locale.

Перевести ?

← →
Игорь Шевченко © (2004-04-20 20:32) [1]

← →
Nikolay M. © (2004-04-20 20:36) [2]

> 2. Если пишет, то какими компонентами пользуется?

TNT-Unicode. Поигрался, вроде работают. Реально использовать пока только предстоит, посмотрим по ходу пьесы.

← →
Nikolay M. © (2004-04-20 20:36) [2]

← →
Тимохов © (2004-04-21 11:34) [3]

> Игорь Шевченко © (20.04.04 20:32) [1]

Переводить в общем то не надо, т.к. вродя и это и сказал.

Перефразирую вопрос: при установке своей программы (или при запуске, не важно) проверяет ли значение функции GetSystemDefaultLangId? Если не будет 1049, то работать AnsiUpperCase просто не будет. Этот факт я проверял установив сильно не русский язык (что-то типа турецкого).

← →
Тимохов © (2004-04-21 11:34) [3]

← →
Игорь Шевченко © (2004-04-21 11:47) [4]

"The conversion is made based on the code page associated with the process locale"

> Если не будет 1049, то работать AnsiUpperCase просто не
> будет

А можно вопрос ? Ты случаем, не русский текст пытался привести к верхнему регистру при установленном турецком языке ?

← →
Игорь Шевченко © (2004-04-21 11:47) [4]

← →
Тимохов © (2004-04-21 12:03) [5]

Конечно русский.
И конечно же я понимаю что в турецком языке русский текст переводится не будет. И мой вопрос не был - как это сделать.

Все, что я спрашивал задумывался ли кто о проверке языка при запуске программы?

← →
Тимохов © (2004-04-21 12:03) [5]

← →
Игорь Шевченко © (2004-04-21 12:12) [6]

Тимохов © (21.04.04 12:03)

> задумывался ли кто о проверке языка при запуске программы

А зачем ? Если ты устанавливаешь программу на турецкую Windows, то почему ты решил, что автоматически должен поддерживаться русский язык, если он не установлен в качестве языка по умолчанию для пользователя ?
В таком случае настройки языка должны быть записаны в требованиях к среде, в которой работает программа.
Или надо использовать локализации под каждый конкретный язык, например с помощью Integrated Translation Environment

← →
Игорь Шевченко © (2004-04-21 12:12) [6]

← →
Тимохов © (2004-04-21 12:18) [7]

> Игорь Шевченко © (21.04.04 12:12) [6]

> если он не установлен в качестве языка по умолчанию для
> пользователя ?

Я вроде как понял, что не для пользователя, а для системы - именно эти настройки влияют на функции CharXXXX (CharUpper, CharToOem). Умолчательный язык пользователя на это вроде как не влияет, по крайней мере у меня не получилось - только смена языка системы привела к неправильной работе AnsiUpperCase.

В общем я с вам согласен - писать в требованиях к програме и дело с концом.

← →
Тимохов © (2004-04-21 12:18) [7]

← →
Игорь Шевченко © (2004-04-21 12:22) [8]

> Я вроде как понял, что не для пользователя, а для системы
>

"The conversion is made based on the code page associated
with the process locale"

← →
Игорь Шевченко © (2004-04-21 12:22) [8]

> Я вроде как понял, что не для пользователя, а для системы
>

"The conversion is made based on the code page associated
with the process locale"

← →
Тимохов © (2004-04-21 12:31) [9]

> Игорь Шевченко © (21.04.04 12:22) [8]

Даже если так (я правда не нашел откуда это фраза) поменять это из программы и без перезагрузки никак не получится - менять может только пользователь.

← →
Тимохов © (2004-04-21 12:31) [9]

← →
Игорь Шевченко © (2004-04-21 12:37) [10]

> я правда не нашел откуда это фраза

Из MSDN.

> поменять это из программы и без перезагрузки никак не получится

А за такое надо руки отрывать и программу сносить.

← →
Игорь Шевченко © (2004-04-21 12:37) [10]

← →
Тимохов © (2004-04-21 12:48) [11]

> Игорь Шевченко © (21.04.04 12:37) [10]

Руки отрывать не нужно.

Последовательность высказываний:
1. Мое "Я вроде как понял, что не для пользователя, а для системы - именно эти настройки влияют на функции CharXXXX (CharUpper, CharToOem)."
2. Ваше "The conversion is made based on the code page associated with the process locale" - вы мне эту фразу два раза приводили - не пойму на что она является возражением.
3. Мое "Даже если так поменять это из программы и без перезагрузки никак не получится" - ясно, что речь идет про process locale.

Поэтому вывод - не имея правильное значение GetSystemDefaultLangId (которое может поменять только пользователь и которое становится умолчательным для потока) функция AnsiUpperCase работать правильно не будет.

Вообще мне совершенно не понятно почему microsoft не сделала так:
1. Есть thread locale в котором можно изменить язык таким образом, чтобы функции CharXXXX в данном потоке начали работать с теми таблицами перекодировки, которые нужны программисту, пишущему данную программу.
2. Возражения - ты представляешь сколько бы пришлось устанавливать лишних codepage"ов не принимаются - у вас на компе и так их больше сотни (примерно 140). Никто не запрещал MS сделать так, чтобы можно было настраивать CharXXXX на работу с этми codepage"ами.

ВЫВОД (для меня)
MS на с очередной раз пои...ло - всеми силами они толкают правильную с их точки зрения технологию - unicode. При этом жизнь приложений не поддреживающих польностю unicode становится более тягостная.

Буду раз, если меня кто-то в этом разубедит.
Например, я могу ошибаться в том, что фунции charXXXX (в дельфи AnsiUpperCase например) нельзя настраивать из приложения.

← →
Тимохов © (2004-04-21 12:48) [11]

← →
DiamondShark © (2004-04-21 12:59) [12]

А вот мне тоже интересно. Thread locale можно установить "на лету". Но строковые функции ссылаются на process locale, который нельзя изменить. Чача какая-то получается...

← →
DiamondShark © (2004-04-21 12:59) [12]

← →
Тимохов © (2004-04-21 13:15) [13]

> Чача какая-то получается...

Эту чачу я описал в ВЫВОДЕ в предыдущем посте.

← →
Тимохов © (2004-04-21 13:15) [13]

> Чача какая-то получается...

Эту чачу я описал в ВЫВОДЕ в предыдущем посте.

← →
Игорь Шевченко © (2004-04-21 13:28) [14]

Вывод уже для меня - LMD

← →
Игорь Шевченко © (2004-04-21 13:28) [14]

Вывод уже для меня - LMD

← →
Игорь Шевченко © (2004-04-21 13:32) [15]

DiamondShark © (21.04.04 12:59)

А почему бы не использовать LCMapString ?

← →
Игорь Шевченко © (2004-04-21 13:32) [15]

DiamondShark © (21.04.04 12:59)

А почему бы не использовать LCMapString ?

← →
Тимохов © (2004-04-21 13:39) [16]

> Игорь Шевченко © (21.04.04 13:28) [14]

Обидно как-то, я что-то сказал ложное, или что-то противоречащее разделу national developing документации msdn. В моих высказываний вроде как ошибок нет.

Я, конечно, могу ошибаться. Обратился я сюда не с целью получить печать на лоб LMD от старших товарищей. Моей целью было получить мнение о то, что думают старшие товарищи на тему, обозначенную в названии топика.

Хорошо. Пусть LMD.
Тогда ответте на вопрос (ну чтобы обосновать свое мнение о моей LMD) - как бы вы с помощью функций winapi реализовали гарантированный перевод в верхний регистр русских символов не зависимо от языка системы?

← →
Тимохов © (2004-04-21 13:39) [16]

← →
Тимохов © (2004-04-21 13:42) [17]

> LCMapString

Ну и что?
Как с помощью нее заставить работать CharUpperA для русских символов, если не установлен в качестве системного русский язык?

← →
Тимохов © (2004-04-21 13:42) [17]

← →
Игорь Шевченко © (2004-04-21 13:47) [18]

> как бы вы с помощью функций winapi реализовали гарантированный
> перевод в верхний регистр русских символов не зависимо от
> языка системы?

LCMapString

← →
Игорь Шевченко © (2004-04-21 13:47) [18]

← →
DiamondShark © (2004-04-21 13:47) [19]

> Игорь Шевченко © (21.04.04 13:32) [15]
> DiamondShark © (21.04.04 12:59)
>
> А почему бы не использовать LCMapString ?

Откровения не было :-)

← →
DiamondShark © (2004-04-21 13:47) [19]

> Игорь Шевченко © (21.04.04 13:32) [15]
> DiamondShark © (21.04.04 12:59)
>
> А почему бы не использовать LCMapString ?

Откровения не было :-)

← →
Игорь Шевченко © (2004-04-21 13:48) [20]

> Я, конечно, могу ошибаться. Обратился я сюда не с целью
> получить печать на лоб LMD от старших товарищей

> ВЫВОД (для меня)
> MS на с очередной раз пои...ло - всеми силами они толкают
> правильную с их точки зрения технологию - unicode. При этом
> жизнь приложений не поддреживающих польностю unicode становится
> более тягостная.

Когда собственное незнание матчасти выдается за происки MS печать на лоб получается незамедлительно.

← →
Игорь Шевченко © (2004-04-21 13:48) [20]

← →
Тимохов © (2004-04-21 13:54) [21]

> Игорь Шевченко © (21.04.04 13:47) [18]

Да знаю я :))
Можно еще в unicode перегнать (не помню точно, кажется через MultiBytoTo...) конвертнуть, а потом обратно (помню точно, кажется через WideCharTo...). Результат будет тот же - дома проверял.

Вопрос то не в этом.
Вы сказали LMD на мой ВЫВОД.
Теперь, пожалуйста, подумайте за MS и скажите почему они не сделали так, чтобы ANSI функции CharXXXXXA брали не системный язык (и соответсвенно codepage), а язык из thread local (и соответсвенно язык и codepage)?
Уверен это им ничего не стоило - просто не захотели, пользуйтесь unicode, даже Рихтера подкупили чтобы первой главой в 4ом издании сделал unicode (шутка :))). Но все же...

И вообще - может без этого обойтить (LMD) - не серьезно как то, общаешься с серьезным человеком, а он тебе так вежливо "ну и дурак же ты братец" :)))

← →
Тимохов © (2004-04-21 13:54) [21]

← →
Тимохов © (2004-04-21 13:56) [22]

> Когда собственное незнание матчасти выдается за происки
> MS печать на лоб получается незамедлительно.

Скорее природная неспособность ясно выразится (блин, всю жизнь от этого страдаю).
Думаю 21 лучше поясняет мою позицию...

← →
Тимохов © (2004-04-21 13:56) [22]

← →
Тимохов © (2004-04-21 14:05) [23]

Ладно задам более конкретный вопрос (с uppercase вроде все ясно):

как програмно заставить функцию OemToChar работать не с кодовыми страницами OEM и ANSI умолчательными для текущего системного языка, а с любими другими?

Если окажется, что можно, сам себе прилеплю lmd (маленький такой) на лоб.

← →
Тимохов © (2004-04-21 14:05) [23]

← →
Игорь Шевченко © (2004-04-21 14:05) [24]

> Теперь, пожалуйста, подумайте за MS и скажите почему они
> не сделали так, чтобы ANSI функции CharXXXXXA брали не системный
> язык

Зайдите в отладчик, посмотрите, как работает функция CharXXXXXA.
В случае одного символа вызывается упомянутая функция LCMapString с первым параметром LANG_USER_DEFAULT.

Читать до полного просветления раздел MSDN "National Language Support", после этого вопросы "почему MS не сделала", отпадут сами собой.

> И вообще - может без этого обойтить (LMD) - не серьезно
> как то, общаешься с серьезным человеком, а он тебе так вежливо
> "ну и дурак же ты братец"

Встречное предложение: не допускать ламерских высказываний. Прежде чем в чем-либо обвинять MS, убедиться, что аргументы для обвинения являются достаточно убедительными (как в случае с MLS-enumerators), что изучена вся документация матчасти по вопросу и что никакие пути решения не привели к желаемому результату.

> как програмно заставить функцию OemToChar работать не с
> кодовыми страницами OEM и ANSI умолчательными для текущего
> системного языка, а с любими другими?

Вопрос из серии: как заставить функцию CreateWindow проигрывать MP3-файл.

Поясни, пожалуйста, что имелось в виду в твоем вопросе ? Преобразование из одной произвольной кодовой страницы в другую ?

Игорь.
Я как всегда остаюсь не верно понятым.

Попытаюсь еще раз.
На странице http://msdn.microsoft.com/library/en-us/intl/nls_0ddl.asp?frame=true сказано следующее:
менять каким либо образом locale (соответственно язык) из программы можно только для threadlocale. Насколько я понимаю threadlocale влияет только на "Determines which settings are used for formatting dates, times, currency, and large numbers for a thread. Also determines the sort order for sorting text". Т.е. на работу функций CharXXXXA не влияет. Я этот факт проверял - что ни ставить в thread local - работает всегда одинаково.
На кодовые страницы влияет system locale, который из программы менять нельзя (даже только для данной программы).

Именно поэтому я и выражаю возмущения, почему MS не могла сделать так, чтобы для thread locale можно было бы устанавливать не только региональные настройки, но и язык для текущего потока. Опять же повторюсь - уверен MS это было не сложно.

По поводу OemToChar.
На работу этой функции повлиять нельзя. Она всегда переводит 866-1251, т.е. согласно языку из system locale. Но в других языках oem и ansi другие. Мне просто интересно как заставить эту функцию работать с другим языком. Например, переводить турецкий oem в туречкий ansi?

Ну докажите (очень хочу) где здесь ламерство?
Что я не прочел?
Тыкните носом, я уже запарился удовлетворять свой неудовлетворенный интерес.

2 Тимохов © (21.04.04 14:24) [26]

Игорь прав в
> Прежде чем в чем-либо обвинять MS, убедиться, что аргументы
> для обвинения являются достаточно убедительными (как в случае
> с MLS-enumerators), что изучена вся документация матчасти
> по вопросу и что никакие пути решения не привели к желаемому
> результату.

Так вы
> прочитали до полного просветления раздел MSDN "National Language Support"? Почему человек должен тратить свое время на пояснение того, что написано в документации? И я бы на его месте возможно скромно написал "RTFM" - намного лучше чем LMD.

2 Игорь Шевченко

Я тут перечитал твою вчерашнюю ссылку и со многим согласен. :-)
Кстати лаконичное RTFM намного лучше любых издевательств и приколов.

> почему MS не могла сделать так, чтобы для thread locale
> можно было бы устанавливать не только региональные настройки,
> но и язык для текущего потока. Опять же повторюсь - уверен
> MS это было не сложно.

1) Уже все сделано. Начиная с WinXP в системе присуствует функция SetThreadUILanguage.

> Но в других языках oem и ansi другие. Мне просто интересно
> как заставить эту функцию работать с другим языком. Например,
> переводить турецкий oem в туречкий ansi?

Очевидно установить другой системный язык ? Или использовать функцию перевода из одной кодовой страницы в другую, коих тоже есть.

Разговоры по поводу того, почему MS сделала то, или не сделала это мне сильно напоминают дискуссии, почему Аллах сотворил восход солнца на востоке, а не на севере, ему наверняка проще было это сделать. Потому что так сделано, потому что большинство приложений пользуются CharXXXX функциями для того, для чего они предназначены, то есть, для работы с текущими языковыми настройками пользователя. Для работы с другими настройками есть другие функции, если так хочется, можно использовать их.

> Igorek ©

Вы очень граммотные мысли привнесли в данное обсуждение.
Только абсолютно не нужные. Т.е. правильные, но в данном контексте лишние.

Я не просил решить мою проблему - проблемы нет. Я изучаю. Обращаюсь к старшим товарищам. Можно? :)))

Так все таки про OemToChar?

> Игорь Шевченко © (21.04.04 14:39) [28]

> SetThreadUILanguage.

Знаем-знаем... Но раньше то не было...
Видать услышали мои возмущения :))))

По поводу того, почему MS сделал так а не иначе.
Полностью с Вами согласен.
Тем ни менее, чем это противоречит моему выводу, за который я получил lmd? :))

Спасибо за обсуждение.
Понял, что я понимаю и понимал все верно.
Снимать с меня LMD или нет - путь решает эмитент.

> Знаем-знаем... Но раньше то не было...

А теперь для чего сделали: "To make sure that your multilingual resources are displayed properly
in the console window, always set your console thread locale according
to console output code page by using SetThreadUILanguage"

> Тем ни менее, чем это противоречит моему выводу

Тем, что не зная матчасть ты бросился наезжать на MS.

> Игорь Шевченко © (21.04.04 14:49) [31]

Хоть убейте, не могу понять, что вы хотите мне показать.
Какое отношение указанная вами функция имеет к oemtochar?
Не могу сейчас открыть МСДН, но помню, что она относилась только к интерфейсу, а к не обсуждаемой функции.

> Тем, что не зная матчасть ты бросился наезжать на MS.

Игорь. Огромная просьба. Папишите хоть 20 своих слов, что я не знаю. Например, "ты не фига не просек, ты не понял, что язык для потока устанавливать можно так-то и так-то и oemtochar будет работать так-то и так-то".
Я удовлетворюсь этим полностью. Сейчас же что получается - вы мне даете куски msdn, которые я и так читал. Наверное пытаесесь сказать мне, что я не фига не понимаю. Ну напишите своими словами.

На MS я не бросался и не наезжал. Я констатировал факт, что в очередной раз MS выводят пользователей на удобный ей (МS) режим работы. Т.е. заставляет нас всех постепенно отказываться от однобайтовых строк и переходить на unicode. Это не наезд. Уважаю лидера - он имеет на это право.

В общем то я удовлетворен обсуждением (потирая лоб):)))

> Огромная просьба. Папишите хоть 20 своих слов, что я не
> знаю. Например, "ты не фига не просек, ты не понял, что
> язык для потока устанавливать можно так-то и так-то и oemtochar
> будет работать так-то и так-то".

Вместо CharXXXXX для перевода в верхний регистр символов в произвольной кодовой странице можно использовать LCMapString. Вместо OemToChar для перевода из турецкой Oem-кодировки (я не знаю, что у них за страница) в турецкую же ANSI-кодировку (опять же, не знаю, что у них там за страница) можно воспользоваться другим способом перевода (хоть через Unicode).

Кстати, информация для преобразования из OEM или в OEM-кодировку не зависит ни от чего, кроме системных кодовых страниц, и заполняется при загрузке системы. В дальнейшем изменить ее невозможно.

> Игорь Шевченко © (21.04.04 15:47) [33]

Отличный вывод из обсуждения. Со всем я полностью согласен.
И иного не утверждал (может быть совсем немного, но быстро исправился).

Самое главное, что я для себя услышал и подтвердил свое знание это "... информация для преобразования из OEM или в OEM-кодировку не зависит ни от чего, кроме системных кодовых страниц, и заполняется при загрузке системы. В дальнейшем изменить ее невозможно."

Поэтому разрешите повториться: "Понял, что я понимаю и понимал все верно".

Еще раз огромное спасибо за участие.

:))

NLS от Microsoft. Найти похожие ветки