forum.wfido.ru  

Вернуться   forum.wfido.ru > Прочие эхи > RU.GOLDED

Ответ
 
Опции темы Опции просмотра
  #101  
Старый 14.03.2024, 18:02
Nil A
Guest
 
Сообщений: n/a
По умолчанию В консольном режиме 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  
Старый 14.03.2024, 20:41
Vitaliy Aksyonov
Guest
 
Сообщений: n/a
По умолчанию 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  
Старый 15.03.2024, 11:11
Stas Mishchenkov
Guest
 
Сообщений: n/a
По умолчанию В консольном режиме 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  
Старый 15.03.2024, 11:31
Stas Mishchenkov
Guest
 
Сообщений: n/a
По умолчанию В консольном режиме 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  
Старый 15.03.2024, 18:51
Vitaliy Aksyonov
Guest
 
Сообщений: n/a
По умолчанию 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  
Старый 15.03.2024, 18:51
Vitaliy Aksyonov
Guest
 
Сообщений: n/a
По умолчанию 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  
Старый 15.03.2024, 20:21
Stas Mishchenkov
Guest
 
Сообщений: n/a
По умолчанию В консольном режиме 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  
Старый 16.03.2024, 05:41
Vitaliy Aksyonov
Guest
 
Сообщений: n/a
По умолчанию 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  
Старый 16.03.2024, 13:03
Stas Mishchenkov
Guest
 
Сообщений: n/a
По умолчанию В консольном режиме 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  
Старый 16.03.2024, 13:11
Stas Mishchenkov
Guest
 
Сообщений: n/a
По умолчанию В консольном режиме 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.

--- Ты не нищий, ты просто отрицательно богатый.
Ответить с цитированием
Ответ

Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 00:14. Часовой пояс GMT +4.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc. Перевод: zCarot