LINUX.ORG.RU
ФорумAdmin

Порядок сортировки локали

 


0

1

Здравствуйте.

От предшествующего админа остался сервер slackware 13.37.0.

1.
LC_COLLATE=ru_RU.cp1251
sort test.txt (файл из двух строк в кодировке 1251)
Порядок выдачи:
Антонов Сергей
Антонова Юлия

2.
LC_COLLATE=ru_RU.UTF-8
sort test2.txt (файл из двух строк в unicode)
Порядок выдачи:
Антонова Юлия
Антонов Сергей

В первом случае учитывает пробелы при сравнении строк, во втором случае - нет, при этом sort идет безо всяких доп. ключей.

Вопрос: как воспроизвести такой порядок сортировки для win1251 на другом сервере? (По воспоминаниям персонала что-то патчилось специально для этого).

Ноги растут от сортировки в postgre, который использует системные функции сортировки, поэтому до получения аналогичного результата не можем перевезти базу на новый сервер.



Последнее исправление: a_aleksandr_ru (всего исправлений: 1)

Ответ на: комментарий от bormant

Не учитывает ё (хотя и Бог бы с ней) Хуже, что сначала сортирует все заглавные, а потом все строчные.

На «волшебном» сервере в работающем варианте базы (и sort) сортируется так:
борисовский
Палисадный
ПЕТРОВСКИЙ
пешеходный

LC_COLLATE=C получим:
ПЕТРОВСКИЙ
Палисадный
борисовский
пешеходный

Поэтому не устраивает. Переписывать во всех запросах order by Upper(..) тоже не фонтан (((

a_aleksandr_ru
() автор топика
Ответ на: комментарий от a_aleksandr_ru

Вы уверены, что влияет именно системный LC_COLLATE, а не в базе прописан свой особый?
В любом случае, ничто не мешает посмотреть переменные окружения процесса сервера БД, чтобы понять, с какой LC_COLLATE он стартует. С какой?

Не исключено ли, что могли быть исправлены параметры исходника локали, тот же COLLATE, и пересобрана локаль?

bormant ★★★★★
()
Последнее исправление: bormant (всего исправлений: 1)
Ответ на: комментарий от a_aleksandr_ru

В (1) точно LC_COLLATE=ru_RU.cp1251 или все же ru_RU (синоним ru_RU.ISO-8859-5), в таком случае будет по факту:

$ iconv -t cp1251 test.txt | \
LANG=ru_RU.cp1251 LC_COLLATE=ru_RU.ISO-8859-5 sort | \
iconv -f cp1251

Антонов Сергей
Антонова Юлия
борисовский
Палисадный
ПЕТРОВСКИЙ
пешеходный

Но это, скорее, эффект несовпадения положения символов в кодировках:
https://ru.wikipedia.org/wiki/ISO_8859-5
https://ru.wikipedia.org/wiki/Windows-1251

bormant ★★★★★
()
Последнее исправление: bormant (всего исправлений: 3)
Ответ на: комментарий от a_aleksandr_ru

Исходники локалей смотреть там:
/usr/share/i18n/locales/
ru_RU — в ней ссылка на ...
iso14651_t1 — в ней ссылка на ...
iso14651_t1_common — тут основной порядок сортировки

bormant ★★★★★
()
Ответ на: комментарий от bormant

нет на рабочем сервере в postgres и LC_LOCALE=win1251, и LC_COLLATE=win1251

Пытался на новом создать базу create database my_new_db LC_CTYPE='ru_RU.cp1251' LC_collate='ru_RU.ISO-8859-5' ENCODING = 'WIN1251'

даже не дает: ERROR: encoding WIN1251 does not match locale ru_RU.ISO-8859-5

a_aleksandr_ru
() автор топика
Ответ на: комментарий от bormant

Пытаюсь ковыряться в iso14651_t1 не совсем понимаю order_start пример скудный в доке

И еще мне не ясна связь между
i18n/charmaps/ - там есть как раз разные файлы для кодовых страниц
а в i18n/locales/ - только ru_RU

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

a_aleksandr_ru
() автор топика
Ответ на: комментарий от a_aleksandr_ru

Локаль компилится из исходника в /usr/share/i18n/locales/ и заданного charmap при помощи localedef, готовый результат в бинарном виде укладывается в /usr/lib*/locale/локаль.кодировка/ и, при желании, в /usr/lib*/locale/locale-archive, где .кодировка — необязательная часть.

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

bormant ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.