Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.GOLDED
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.GOLDED с датами от 16 Jul 13 03:28:02 до 16 Nov 24 03:28:00, всего сообщений: 3632
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 3508 из 3632 ======================================== RU.GOLDED =
От   : Vitaliy Aksyonov                 1:104/117          15 Mar 24 19:23:06
Кому : Stas Mishchenkov                                    15 Mar 24 19:23:06
Тема : Re: В консольном режиме Linux даже при выборе кодировки UTF-8 вместо ки
FGHI : area://RU.GOLDED?msgid=1:104/117+65f4f7c1
На   : area://RU.GOLDED?msgid=2:460/5858+65f47128
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.GOLDED?msgid=2:460/5858+65f55d7c
Ответ: area://RU.GOLDED?msgid=2:460/5858+65f55f7c
Ответ: area://RU.GOLDED?msgid=2:460/5858+65f56388
==============================================================================
Привет, Stas!

15 Mar 24 18:51, ты писал(а) мне:

SM>>> setlocale(LC_CTYPE, "");
SM>>> # LC_CTYPE now reset to the default defined by the
SM>>> # LC_ALL/LC_CTYPE/LANG environment variables, or to the system
SM>>> # default.

VA>> Это именно то, что надо. Когда вызываешь setlocale(LC_CTYPE,
VA>> NULL), то оно возвращает ранее выставленную локаль. А так, как ты
VA>> её явно не выставлял, то и возвращается "C".

SM> А GoldEd как-то иначе делает?

Они использует именно setlocale(LC_CTYPE, ""); И в некоторых местах LC_ALL. Но это неважно.

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 != g_tolower(c)) || (c != g_toupper(c));
}
====

to_lower/to_upper не будут работать корректно для русских букв в "чужой" локали.

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

В целом алгоритм имеет право на жизнь, но мне кажется, проще было бы просто разрезать текст по пробелам/табам.

Best regards,
Vitaliy Aksyonov.

... Экипаж прощается с вами, желает вам счастливого полета.
--- GoldED+/LNX 1.1.5-b20240305-beta
* Origin: Aurora, Colorado (1:104/117)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.079466 секунды