#101
|
|||
|
|||
В консольном режиме Linux даже при выборе кодировки UTF-8 вместо ки
Nil A написал(а) к Vitaliy Aksyonov в Mar 24 16:55:08 по местному времени:
Нello, Vitaliy! Thursday March 14 2024 07:16, from Vitaliy Aksyonov -> Stas Mishchenkov: NA>>> Очень короткий файлик goldlib/gall/gcharset.cpp NA>>> В ДОСе через int21h NA>>> В Венде через GetOEMCP() SM>> Ага. И тут получает правильный ответ. NA>>> В Юниксах из $LANG, и я там починил недавно, но всё равно тупо NA>>> выдаёт /ru_RU/ -> CP866 иначе CP437. SM>> А тут в чём проблема получить верный ответ? SM>> [fido@brorabbit ~]$ echo $LANG SM>> ru_RU.IBM866 SM>> [ustasm@brorabbit ~]$ echo $LANG SM>> ru_RU.UTF-8 Ага, там $LANG может быть не установлен, а $LCALL очень даже, или $LCCOLLATE какой-нибудь. VA> Проблема в том, что например этой переменной может не быть, а локаль VA> есть. Да и в разных системах реализовано по-разному. А setlocale VA> работает одинаково. Присылай патч (c) Best Regards, Nil --- GoldED+/LNX 1.1.5 |
#102
|
|||
|
|||
Re: В консольном режиме Linux даже при выборе кодировки UTF-8 вместо ки
Vitaliy Aksyonov написал(а) к Nil A в Mar 24 10:33:26 по местному времени:
Привет, Nil! 14 Mar 24 16:55, ты писал(а) мне: NA>>>> Очень короткий файлик goldlib/gall/gcharset.cpp NA>>>> В ДОСе через int21h NA>>>> В Венде через GetOEMCP() SM>>> Ага. И тут получает правильный ответ. NA>>>> В Юниксах из $LANG, и я там починил недавно, но всё равно тупо NA>>>> выдаёт /ru_RU/ -> CP866 иначе CP437. SM>>> А тут в чём проблема получить верный ответ? SM>>> [fido@brorabbit ~]$ echo $LANG SM>>> ru_RU.IBM866 SM>>> [ustasm@brorabbit ~]$ echo $LANG SM>>> ru_RU.UTF-8 NA> Ага, там $LANG может быть не установлен, а $LC_ALL очень даже, или NA> $LC_COLLATE какой-нибудь. Именно. VA>> Проблема в том, что например этой переменной может не быть, а VA>> локаль есть. Да и в разных системах реализовано по-разному. А VA>> setlocale работает одинаково. NA> Присылай патч (c) Защем, начальнике? Меня устраивает текущее положение дел. :) А кого не устраивает - пусть присылает. ;) Best regards, Vitaliy Aksyonov. ... Последнее слово техники - No Carrier. --- GoldED+/LNX 1.1.5-b20240305-beta |
#103
|
|||
|
|||
В консольном режиме Linux даже при выборе кодировки UTF-8 вместо ки
Stas Mishchenkov написал(а) к Vitaliy Aksyonov в Mar 24 09:52:42 по местному времени:
Нi Vitaliy! 14 Mar 24 07:16, Vitaliy Aksyonov -> Stas Mishchenkov: NA>>> В Юниксах из $LANG, и я там починил недавно, но всё равно тупо NA>>> выдаёт /ru_RU/ -> CP866 иначе CP437. SM>> А тут в чём проблема получить верный ответ? SM>> [fido@brorabbit ~]$ echo $LANG SM>> ru_RU.IBM866 SM>> [ustasm@brorabbit ~]$ echo $LANG SM>> ru_RU.UTF-8 VA> Проблема в том, что например этой переменной может не быть, а локаль есть. VA> Да и в разных системах реализовано по-разному. Я спрашивал, в чём проблема взять правильную часть ответа. VA> А setlocale работает одинаково. Экспериментальным путём выясняется, что в венде оно тупо выдаёт "С", что не спроси, хоть LCCTYPE, хоть LC_NAME, хоть LC_IDENTIFICATION. Хотя, нет. В венде на запрос LC_IDENTIFICATION выдаёт "Your vendor has not defined POSIX macro LCIDENTIFICATION". Нave nice nights. Stas Mishchenkov. --- На халяву не только уксус сладок, но и свинина постна, халяльна и кошерна. |
#104
|
|||
|
|||
В консольном режиме Linux даже при выборе кодировки UTF-8 вместо ки
Stas Mishchenkov написал(а) к Vitaliy Aksyonov в Mar 24 10:04:18 по местному времени:
Нi Vitaliy! 14 Mar 24 07:17, Vitaliy Aksyonov -> Stas Mishchenkov: VA>>>>>> Интересно, как он определяет локальную кодировку на венде. :) SM>> [...skipped...] VA>>> Надо чтобы он брал из setlocale(LC_что-то, NULL). И это будет VA>>> работать везде, где есть setlocale. А есть оно почти везде. SM>> $locale = setlocale(LC_CTYPE); [...skipped...] SM>> Не работает. VA> Ты неправильно её готовишь. Я тоже на это наступил. Надо внимательнее VA> читать документацию. :) # query and save the old locale $oldlocale = setlocale(LCCTYPE); setlocale(LC_CTYPE, ""); # LC_CTYPE now reset to the default defined by the # LCALL/LCCTYPE/LANG environment variables, or to the system # default. VA> Попробуй так: setlocale(LC_CTYPE, ""); Та же фигня, только в левой руке. VA> В твоём варианте оно возвращает текущую для процесса. А так, как она VA> ранее не была выставлена, то и возвращает C. Мой вариант как раз VA> выставляет локаль используя LANG и другие переменные и возвращает тебе VA> то, что наделал. Судя по доке, пустая строка должна вызвать ресет локали на дефаулт. Да, это я проверял для D:\Fido\inbound>ver Microsoft Windows [Version 10.0.19045.4170] В семёрке оно, кажется, работало иначе. Нave nice nights. Stas Mishchenkov. --- Всё, что нас не убивает, потом об этом очень сильно пожалеет. |
#105
|
|||
|
|||
Re: В консольном режиме Linux даже при выборе кодировки UTF-8 вместо ки
Vitaliy Aksyonov написал(а) к Stas Mishchenkov в Mar 24 08:37:56 по местному времени:
Привет, Stas! 15 Mar 24 09:52, ты писал(а) мне: NA>>>> В Юниксах из $LANG, и я там починил недавно, но всё равно тупо NA>>>> выдаёт /ru_RU/ -> CP866 иначе CP437. SM>>> А тут в чём проблема получить верный ответ? SM>>> [fido@brorabbit ~]$ echo $LANG SM>>> ru_RU.IBM866 SM>>> [ustasm@brorabbit ~]$ echo $LANG SM>>> ru_RU.UTF-8 VA>> Проблема в том, что например этой переменной может не быть, а VA>> локаль есть. Да и в разных системах реализовано по-разному. SM> Я спрашивал, в чём проблема взять правильную часть ответа. Проблема в том, что эта переменная может отсутствовать, а локаль быть выставлена. VA>> А setlocale работает одинаково. SM> Экспериментальным путём выясняется, что в венде оно тупо выдаёт "С", SM> что не спроси, хоть LCCTYPE, хоть LC_NAME, хоть LCIDENTIFICATION. SM> Хотя, нет. В венде на запрос LC_IDENTIFICATION выдаёт "Your vendor has SM> not defined POSIX macro LC_IDENTIFICATION". Ты неправильно её готовишь. :) Best regards, Vitaliy Aksyonov. ... В здоровом теле здоровый пук. --- GoldED+/LNX 1.1.5-b20240305-beta |
#106
|
|||
|
|||
Re: В консольном режиме Linux даже при выборе кодировки UTF-8 вместо ки
Vitaliy Aksyonov написал(а) к Stas Mishchenkov в Mar 24 08:38:38 по местному времени:
Привет, Stas! 15 Mar 24 10:04, ты писал(а) мне: VA>>>>>>> Интересно, как он определяет локальную кодировку на венде. VA>>>>>>> :) SM>>> [...skipped...] VA>>>> Надо чтобы он брал из setlocale(LC_что-то, NULL). И это будет VA>>>> работать везде, где есть setlocale. А есть оно почти везде. SM>>> $locale = setlocale(LC_CTYPE); SM> [...skipped...] SM>>> Не работает. VA>> Ты неправильно её готовишь. Я тоже на это наступил. Надо VA>> внимательнее читать документацию. :) SM> # query and save the old locale SM> $oldlocale = setlocale(LCCTYPE); SM> setlocale(LC_CTYPE, ""); SM> # LC_CTYPE now reset to the default defined by the SM> # LCALL/LCCTYPE/LANG environment variables, or to the system SM> # default. Это именно то, что надо. Когда вызываешь setlocale(LC_CTYPE, NULL), то оно возвращает ранее выставленную локаль. А так, как ты её явно не выставлял, то и возвращается "C". VA>> Попробуй так: setlocale(LC_CTYPE, ""); SM> Та же фигня, только в левой руке. Этот вариант как раз меняет локаль с "C" на то, что настроено в системе. Почему оно у тебя возвращает "C", это вопрос. Я не перлом пробовал правда, но не думаю, что есть какая-то разница, ведь перл тупо вызывает ту же системную функцию. VA>> В твоём варианте оно возвращает текущую для процесса. А так, как VA>> она ранее не была выставлена, то и возвращает C. Мой вариант как VA>> раз выставляет локаль используя LANG и другие переменные и VA>> возвращает тебе то, что наделал. SM> Судя по доке, пустая строка должна вызвать ресет локали на дефаулт. Именно. А он берется из тех же $LANG и так далее. SM> Да, это я проверял для SM> D:\Fido\inbound>ver Microsoft Windows [Version 10.0.19045.4170] SM> В семёрке оно, кажется, работало иначе. Да одинаково оно работает. Просто в венде локаль странная. Пробовал тот же скрипт ради интереса под линуксом запустить? Что кажет? Best regards, Vitaliy Aksyonov. ... Почему все дуры такие женщины? --- GoldED+/LNX 1.1.5-b20240305-beta |
#107
|
|||
|
|||
В консольном режиме Linux даже при выборе кодировки UTF-8 вместо ки
Stas Mishchenkov написал(а) к Vitaliy Aksyonov в Mar 24 18:51:40 по местному времени:
Нi Vitaliy! 15 Mar 24 08:38, Vitaliy Aksyonov -> Stas Mishchenkov: SM>> setlocale(LC_CTYPE, ""); SM>> # LC_CTYPE now reset to the default defined by the SM>> # LCALL/LCCTYPE/LANG environment variables, or to the system SM>> # default. VA> Это именно то, что надо. Когда вызываешь setlocale(LC_CTYPE, NULL), то оно VA> возвращает ранее выставленную локаль. А так, как ты её явно не выставлял, VA> то и возвращается "C". А GoldEd как-то иначе делает? VA>>> Попробуй так: setlocale(LC_CTYPE, ""); SM>> Та же фигня, только в левой руке. VA> Этот вариант как раз меняет локаль с "C" на то, что настроено в системе. VA> Почему оно у тебя возвращает "C", это вопрос. Пробовал заслать \x00 - ваще тишину возвращает. VA> Я не перлом пробовал правда, но не думаю, что есть какая-то разница, VA> ведь перл тупо вызывает ту же системную функцию. Вот именно. Тот же POSIX locale_h. Запустил для чистоты эксперимента голый cmd.exe. Вот результат: Microsoft Windows [Version 10.0.19045.4170] (c) Корпорация Майкрософт (Microsoft Corporation). Все права защищены. D:\Fido\inbound>1_locale.pl C C D:\Fido\inbound>chcp Текущая кодовая страница: 866 VA>>> В твоём варианте оно возвращает текущую для процесса. А так, как VA>>> она ранее не была выставлена, то и возвращает C. Мой вариант как VA>>> раз выставляет локаль используя LANG и другие переменные и VA>>> возвращает тебе то, что наделал. SM>> Судя по доке, пустая строка должна вызвать ресет локали на дефаулт. VA> Именно. А он берется из тех же $LANG и так далее. Видимо, виндовс уже не такая уж и позикс совместимая. SM>> Да, это я проверял для SM>> D:\Fido\inbound>ver Microsoft Windows [Version 10.0.19045.4170] SM>> В семёрке оно, кажется, работало иначе. VA> Да одинаково оно работает. Просто в венде локаль странная. Я про то самое. Там так не получится. VA> Пробовал тот же скрипт ради интереса под линуксом запустить? Что VA> кажет? Да. Всё правильно кажет. Я уже здесь писал. [fido@brorabbit tests]$ ./1_locale.pl ru_RU.IBM866 [ustasm@brorabbit ~]$ /home/fido/perl/tests/1_locale.pl ru_RU.UTF-8 Нave nice nights. Stas Mishchenkov. --- А стоит ли идти к психиатру, спросил я себя. Мнения разделились. |
#108
|
|||
|
|||
Re: В консольном режиме Linux даже при выборе кодировки UTF-8 вместо ки
Vitaliy Aksyonov написал(а) к Stas Mishchenkov в Mar 24 19:23:06 по местному времени:
Привет, Stas! 15 Mar 24 18:51, ты писал(а) мне: SM>>> setlocale(LC_CTYPE, ""); SM>>> # LC_CTYPE now reset to the default defined by the SM>>> # LCALL/LCCTYPE/LANG environment variables, or to the system SM>>> # default. VA>> Это именно то, что надо. Когда вызываешь setlocale(LC_CTYPE, VA>> NULL), то оно возвращает ранее выставленную локаль. А так, как ты VA>> её явно не выставлял, то и возвращается "C". SM> А GoldEd как-то иначе делает? Они использует именно setlocale(LCCTYPE, ""); И в некоторых местах LCALL. Но это неважно. VA>>>> Попробуй так: setlocale(LC_CTYPE, ""); SM>>> Та же фигня, только в левой руке. Может это прикол перла? Попробуй накропать простенькую программу на голом си и посмотри, что выдаст. ------------- #include <locale.h> #include <stdio.h> int main() { printf("%s", setlocale(LC_ALL, ""); return 0; } Что скажет? :) VA>> Этот вариант как раз меняет локаль с "C" на то, что настроено в VA>> системе. Почему оно у тебя возвращает "C", это вопрос. SM> Пробовал заслать \x00 - ваще тишину возвращает. Венда, она вообще странная. VA>> Я не перлом пробовал правда, но не думаю, что есть какая-то VA>> разница, ведь перл тупо вызывает ту же системную функцию. SM> Вот именно. Тот же POSIX locale_h. Запустил для чистоты эксперимента SM> голый cmd.exe. Вот результат: SM> Microsoft Windows [Version 10.0.19045.4170] SM> (c) Корпорация Майкрософт (Microsoft Corporation). Все права защищены. SM> D:\Fido\inbound>1_locale.pl SM> C SM> C У меня программа на c выдаёт English_United States.1251 SM> D:\Fido\inbound>chcp SM> Текущая кодовая страница: 866 Самое интересное, что даже после chcp 866 выдаёт ту же английскую локаль. VA>>>> В твоём варианте оно возвращает текущую для процесса. А так, VA>>>> как она ранее не была выставлена, то и возвращает C. Мой VA>>>> вариант как раз выставляет локаль используя LANG и другие VA>>>> переменные и возвращает тебе то, что наделал. SM>>> Судя по доке, пустая строка должна вызвать ресет локали на SM>>> дефаулт. VA>> Именно. А он берется из тех же $LANG и так далее. SM> Видимо, виндовс уже не такая уж и позикс совместимая. Она никогда и не была POSIX совместимой. SM>>> Да, это я проверял для SM>>> D:\Fido\inbound>ver Microsoft Windows [Version 10.0.19045.4170] SM>>> В семёрке оно, кажется, работало иначе. VA>> Да одинаково оно работает. Просто в венде локаль странная. SM> Я про то самое. Там так не получится. VA>> Пробовал тот же скрипт ради интереса под линуксом запустить? Что VA>> кажет? SM> Да. Всё правильно кажет. Я уже здесь писал. Ну хоть там по-человечески. SM> [fido@brorabbit tests]$ ./1_locale.pl SM> ru_RU.IBM866 SM> [ustasm@brorabbit ~]$ /home/fido/perl/tests/1_locale.pl SM> ru_RU.UTF-8 Я тут накопал, почему когда локаль "неправильная" спеллчекер не срабатывает. В смысле, пропускает русские слова. Из-за того, как там строка на слова разбивается. Словом считается то, что состоит из букв, цифр и символов "-'." Причём определяется что символ - это буква вот таким мега алгоритмом: ==== int isxalnum(int c) { return isascii(c) ? isalnum(c) : (c != gtolower(c)) || (c != gtoupper(c)); } ==== tolower/toupper не будут работать корректно для русских букв в "чужой" локали. Вот и получается, что словарь загружен, но русские слова в него не попадают. И дед просто их все считает правильнымию В целом алгоритм имеет право на жизнь, но мне кажется, проще было бы просто разрезать текст по пробелам/табам. Best regards, Vitaliy Aksyonov. ... Экипаж прощается с вами, желает вам счастливого полета. --- GoldED+/LNX 1.1.5-b20240305-beta |
#109
|
|||
|
|||
В консольном режиме Linux даже при выборе кодировки UTF-8 вместо ки
Stas Mishchenkov написал(а) к Vitaliy Aksyonov в Mar 24 11:46:20 по местному времени:
Нi Vitaliy! 15 Mar 24 19:23, Vitaliy Aksyonov -> Stas Mishchenkov: VA>>>>> Попробуй так: setlocale(LC_CTYPE, ""); SM>>>> Та же фигня, только в левой руке. VA> Может это прикол перла? Возможно, у меня какой-то не такой POSIX/locale.h VA> Попробуй накропать простенькую программу на голом VA> си и посмотри, что выдаст. VA> ------------- VA> #include <locale.h> VA> #include <stdio.h> VA> int main() VA> { VA> printf("%s", setlocale(LC_ALL, ""); VA> return 0; VA> } VA> Что скажет? :) У меня под виндой нечем собрать. Совсем. У тебя ж есть бинарь? Кинь аттачем, плиз. VA>>> Этот вариант как раз меняет локаль с "C" на то, что настроено в VA>>> системе. Почему оно у тебя возвращает "C", это вопрос. SM>> Пробовал заслать \x00 - ваще тишину возвращает. VA> Венда, она вообще странная. Ага. VA>>> Я не перлом пробовал правда, но не думаю, что есть какая-то VA>>> разница, ведь перл тупо вызывает ту же системную функцию. SM>> Вот именно. Тот же POSIX locale_h. Запустил для чистоты эксперимента SM>> голый cmd.exe. Вот результат: SM>> Microsoft Windows [Version 10.0.19045.4170] SM>> (c) Корпорация Майкрософт (Microsoft Corporation). Все права защищены. SM>> D:\Fido\inbound>1_locale.pl SM>> C SM>> C VA> У меня программа на c выдаёт English_United States.1251 Хотя в консоли cp866? SM>> D:\Fido\inbound>chcp SM>> Текущая кодовая страница: 866 VA> Самое интересное, что даже после chcp 866 выдаёт ту же английскую локаль. http://st.g0x.ru/mustdie.png ;) SM>> Видимо, виндовс уже не такая уж и позикс совместимая. VA> Она никогда и не была POSIX совместимой. Прикинь? ;) VA>>> Пробовал тот же скрипт ради интереса под линуксом запустить? Что VA>>> кажет? SM>> Да. Всё правильно кажет. Я уже здесь писал. VA> Ну хоть там по-человечески. А могло быть как-то иначе? ;) SM>> [fido@brorabbit tests]$ ./1_locale.pl SM>> ru_RU.IBM866 SM>> [ustasm@brorabbit ~]$ /home/fido/perl/tests/1_locale.pl SM>> ru_RU.UTF-8 VA> Я тут накопал, почему когда локаль "неправильная" спеллчекер не VA> срабатывает. В смысле, пропускает русские слова. Из-за того, как там VA> строка на слова разбивается. Словом считается то, что состоит из букв, VA> цифр и символов "-'." VA> Причём определяется что символ - это буква вот таким мега алгоритмом: VA> ==== VA> int isxalnum(int c) VA> { VA> return isascii(c) ? isalnum(c) : (c != g_tolower(c)) || (c != VA> g_toupper(c)); } VA> ==== VA> tolower/toupper не будут работать корректно для русских букв в "чужой" VA> локали. VA> Вот и получается, что словарь загружен, но русские слова в него не VA> попадают. И дед просто их все считает правильнымию VA> В целом алгоритм имеет право на жизнь, но мне кажется, проще было бы VA> просто разрезать текст по пробелам/табам. Тоже не вариант. Я сталкивался с ошибочным разбиением именно в маздайке, кстати. Нave nice nights. Stas Mishchenkov. --- Нa opужейнoм зaвoдe заpплату дают дeнь в день, cекунда в секунду |
#110
|
|||
|
|||
В консольном режиме Linux даже при выборе кодировки UTF-8 вместо ки
Stas Mishchenkov написал(а) к Vitaliy Aksyonov в Mar 24 11:59:16 по местному времени:
Нi Vitaliy! 15 Mar 24 19:23, Vitaliy Aksyonov -> Stas Mishchenkov: VA>>>>> Попробуй так: setlocale(LC_CTYPE, ""); SM>>>> Та же фигня, только в левой руке. VA> Может это прикол перла? Попробуй накропать простенькую программу на голом VA> си и посмотри, что выдаст. VA> ------------- VA> #include <locale.h> VA> #include <stdio.h> VA> int main() VA> { VA> printf("%s", setlocale(LC_ALL, ""); VA> return 0; VA> } VA> Что скажет? :) В линуксе предсказуемо правильно. [fido@brorabbit locale]$ gcc -o local ./locale.c [fido@brorabbit locale]$ ./local ru_RU.IBM866 Нave nice nights. Stas Mishchenkov. --- Ты не нищий, ты просто отрицательно богатый. |