въведение

Всичко започна с кратък скрипт, който трябваше да комбинира информация за адреси електронна поща служители, получени от списъка с потребители на пощенския списък с позиции на служители, получени от базата данни за човешки ресурси. И двата списъка бяха експортирани в текстови файлове с Unicode. UTF-8 и се съхраняват с окончания на редове на Unix.

съдържание mail.txt

Иванов Андрей;[email protected]

съдържание buhg.txt

Иванова Алла;маляр
Ёлкина Элла;крановщица
Иванов Андрей;слесарь
Абаканов Михаил;маляр

За да се слеят, файловете бяха сортирани чрез командата Unix вид и се изпраща на входа на Unix програмата присъединят към, който неочаквано завърши с грешката:

$> sort buhg.txt > buhg.srt
$> sort mail.txt > mail.srt
$> join buhg.srt mail.srt > result
join: buhg.srt:4: is not sorted: Иванов Андрей;слесарь

Разглеждането на резултата от сортирането с очите показа, че като цяло сортирането е правилно, но при съвпадение на мъжки и женски фамилни имена женските са пред мъжките:

$> sort buhg.txt
Абаканов Михаил;маляр
Ёлкина Элла;крановщица
Иванова Алла;маляр
Иванов Андрей;слесарь

Изглежда като бъг при сортиране в Unicode или като проява на феминизъм в алгоритъма за сортиране. Първото, разбира се, е по-правдоподобно.

Нека го отложим засега присъединят към и се фокусирайте върху вид. Нека се опитаме да разрешим проблема по метода на научното мушкане. Първо променете локала от en_US на ru_ru. За сортиране би било достатъчно да зададете променливата на средата LC_COLLATE, но няма да губим време за дреболии:

$> LANG=ru_RU.UTF-8 sort buhg.txt
Абаканов Михаил;маляр
Ёлкина Элла;крановщица
Иванова Алла;маляр
Иванов Андрей;слесарь

Нищо не се промени.

Нека се опитаме да прекодираме файловете в еднобайтово кодиране:

$> iconv -f UTF-8 -t KOI8-R buhg.txt 
 | LANG=ru_RU.KOI8-R sort 
 | iconv -f KOI8-R -t UTF8

Отново нищо не се е променило.

Нищо не може да се направи, трябва да търсите решение в интернет. Няма нищо директно за руските фамилни имена, но има въпроси относно други странности на сортирането. Например, ето един проблем: сортирането в unix третира символите '-' (тире) като невидими. Накратко, низовете "ab", "aa", "ac" се сортират като "aa", "ab", "ac".

Отговорът е стандартен навсякъде: използвайте локала на програмиста "° С" и ще бъдете щастливи. Опитваме:

$> LANG=C sort buhg.txt
Ёлкина Элла;крановщица
Абаканов Михаил;маляр
Иванов Андрей;слесарь
Иванова Алла;адвокат

Нещо се е променило. Иванови се подредиха в правилния ред, въпреки че Йолкина се подхлъзна някъде. Да се върнем към първоначалния проблем:

$> LANG=C sort buhg.txt > buhg.srt
$> LANG=C sort mail.txt > mail.srt
$> LANG=C join buhg.srt mail.srt > result

Работи без грешки, както обещава интернет. И това въпреки Йолкина в първия ред.

Проблемът изглежда решен, но за всеки случай нека опитаме друго руско кодиране - Windows CP1251:

$> iconv -f UTF-8 -t CP1251 buhg.txt 
 | LANG=ru_RU.CP1251 sort 
 | iconv -f CP1251 -t UTF8

Резултатът от сортирането, колкото и да е странно, ще съответства на локала "° С", и целият пример, съответно, минава без грешки. Някаква мистика.

Не харесвам мистицизма в програмирането, защото обикновено прикрива грешките. Ще трябва да се заемем сериозно с това как работи. вид и какво влияние LC_COLLATE .

Накрая ще се опитам да отговоря на въпросите:

защо фамилните имена на жените са сортирани неправилно
защо LANG=ru_RU.CP1251 се оказа еквивалентът LANG=C
защо ти вид и присъединят към различни идеи за реда на сортираните низове
защо има грешки във всички мои примери
накрая как да сортирате низове по ваш вкус

Сортиране в Unicode

Първата спирка ще бъде озаглавен технически доклад №10 Алгоритъм за сортиране на Unicode онлайн unicode.org. Докладът съдържа много технически подробности, така че ще си позволя да дам обобщение на основните идеи.

Сверка - "сравняването" на низове е в основата на всеки алгоритъм за сортиране. Самите алгоритми може да се различават ("балон", "сливане", "бързо"), но всички те ще използват сравнение на чифт низове, за да определят своя ред.

Сортирането на низове на естествен език е доста труден проблем. Дори и в най-простите еднобайтови кодировки, редът на буквите в азбуката, дори и да е малко по-различен от английската латиница, вече няма да съвпада с реда на числовите стойности, с които са кодирани тези букви. Така че в немската азбука буквата Ö стои между О и P, и в кодирането CP850 тя попада между ÿ и Ü.

Можете да опитате да се абстрахирате от конкретното кодиране и да разгледате „идеалните“ букви, които са подредени в някакъв ред, както се прави в Unicode. Кодировки UTF8, UTF16 или един байт KOI8-R (ако е необходимо ограничено подмножество на Unicode) ще даде различни цифрови представяния на буквите, но ще се отнася до едни и същи елементи на базовата таблица.

Оказва се, че дори да изградим таблица със символи от нулата, не можем да й присвоим универсален ред на символите. В различните национални азбуки, които използват едни и същи букви, редът на тези букви може да се различава. Например на френски Æ ще се третира като лигатура и сортира като низ AE. На норвежки език Æ ще бъде отделна буква, която се намира след Z. Между другото, освен лигатури като Æ има букви, написани с няколко знака. Така че в чешката азбука има буква Ch, който стои между H и I.

В допълнение към разликата в азбуките, има и други национални традиции, които влияят на сортирането. По-специално възниква въпросът: в какъв ред трябва да се появяват в речника думите, състоящи се от главни и малки букви? Също така, сортирането може да бъде повлияно от особеностите на използването на препинателни знаци. На испански обърнат въпросителен знак се поставя в началото на въпросително изречение (Харесваш ли музика?). В този случай е очевидно, че въпросителните изречения не трябва да се групират в отделен клъстер извън азбуката, но как да сортирате редовете с различни препинателни знаци?

Няма да се спирам на сортирането на низове на езици, много различни от европейските. Обърнете внимание, че езиците с писане отдясно наляво или отгоре надолу са склонни да съхраняват знаци в редове в ред на четене и дори неазбучните скриптове имат свой собствен начин за подреждане на редовете символ по знак. Например, йероглифите могат да бъдат подредени по стил (Ключове с китайски символи) или по произношение. Как трябва да се поръчват емотикони, честно казано нямам идея, но можете да измислите нещо за тях.

Въз основа на характеристиките, изброени по-горе, бяха формулирани основните изисквания за сравняване на низове, базирани на Unicode таблици:

сравнението на низове не зависи от позицията на знаците в кодовата таблица;
последователности от символи, които образуват един знак, се редуцират до каноничната форма (A + горният кръг е същият като Å);
когато се сравняват низове, знак се разглежда в контекста на низ и, ако е необходимо, се комбинира със съседи в една единица за сравнение (Ch на чешки) или разделена на няколко (Æ на френски език);
всички национални характеристики (азбука, главни/малки букви, препинателни знаци, ред на видовете писане) трябва да бъдат конфигурирани до ръчно задаване на реда (емоджи);
сравнението е важно не само за сортиране, но и на много други места, например за указване на диапазони от низове (заместване на {A ... z} в тряскам);
сравнението трябва да е достатъчно бързо.

В допълнение, авторите на доклада формулираха свойства за сравнение, на които разработчиците на алгоритми не трябва да разчитат:

алгоритъмът за сравнение не трябва да изисква отделен набор от знаци за всеки език (руските и украинските езици споделят повечето кирилски знаци);
сравнението не трябва да се основава на реда на знаците в Unicode таблиците;
теглото на низа не трябва да бъде атрибут на низа, тъй като един и същ низ в различни културни контексти може да има различни тегла;
теглата на редовете могат да се променят при сливане или разделяне (от x < y това не следва xz < yz);
различни низове, които имат еднакви тегла, се считат за равни по отношение на алгоритъма за сортиране. Въвеждането на допълнително подреждане на такива низове е възможно, но може да влоши производителността;
редове с еднакви тегла могат да се разменят по време на многократно сортиране. Устойчивостта е свойство на определен алгоритъм за сортиране, а не свойство на алгоритъма за сравнение на низове (вижте предишната точка);
правилата за сортиране могат да се променят с времето, тъй като културните практики се усъвършенстват/променят.

Посочено е също, че алгоритъмът за сравнение не знае нищо за семантиката на обработените низове. Така че низовете, състоящи се само от числа, не трябва да се сравняват като числа, а в списъците с английски имена членът не трябва да се премахва (Бийтълс, The).

За да се изпълнят всички тези изисквания, се предлага многостепенен (всъщност четиристепенен) табличен алгоритъм за сортиране.

Преди това знаците в низа се преобразуват в канонична форма и се групират в единици за сравнение. На всяка единица за сравнение се присвояват няколко тегла, съответстващи на няколко нива на сравнение. Теглата на единиците за сравнение са елементи от подредени набори (в този случай цели числа), които могат да бъдат сравнени за повече или по-малко. специално значение ИГНОРИРАНО (0x0) означава, че тази единица не участва в сравнението на съответното ниво на сравнение. Сравнението на низовете може да се повтори многократно, като се използват теглата на съответните нива. На всяко ниво теглата на сравнителните единици на два низа се сравняват последователно един с друг.

В различни реализации на алгоритъма за различни национални традиции стойностите на коефициентите могат да се различават, но стандартът Unicode включва основна таблица за тегло - „Таблица на елемента за сортиране на Unicode по подразбиране“ (ДУЦЕТ). Искам да отбележа, че настройката на променливата LC_COLLATE всъщност е индикация за избора на таблицата с тегло във функцията за сравнение на низове.

Тегловни коефициенти ДУЦЕТ подредени както следва:

на първо ниво всички букви се свеждат до един и същи регистър, диакритичните знаци се изхвърлят, препинателните знаци (не всички) се игнорират;
на второ ниво се вземат предвид само диакритичните знаци;
третото ниво е само за регистър;
на четвърто ниво се вземат предвид само препинателните знаци.

Сравнението се извършва в няколко преминавания: първо се сравняват коефициентите от първото ниво; ако теглата съвпадат, то се сравнява отново с теглата от второ ниво; след това може би трети и четвърти.

Сравнението приключва, когато низовете съдържат съответстващи единици за сравнение с различни тегла. Редове, които имат еднакви тегла на четирите нива, се считат за равни един на друг.

Този алгоритъм (с куп допълнителни технически подробности) даде името на доклад #10 - Алгоритъм за съпоставяне на Unicode (ACU).

Тук поведението на сортиране от нашия пример става малко по-ясно. Би било хубаво да го сравним със стандарта Unicode.

За тестови реализации ACU има специален тестизползвайки файл за тегло, осъзнавайки ДУЦЕТ. Във файла с тежести можете да намерите различни забавления. Например, има ред на маджонг и европейски плочки за домино, както и ред на бои в тесте карти (символ 1F000 и по-нататък). Боите на картите се поставят според правилата на бриджа - PCBT, а картите в боята - в последователността T,2,3 ... K.

Ръчна проверка на правилното сортиране на низове в съответствие с ДУЦЕТ би било доста досадно, но за наше щастие има имплементация на референтна библиотека за работа с Unicode - "Международни компоненти за Unicode"(ICU).

На сайта на тази библиотека, разработена през IBM, има демо страници, включително страница с алгоритъм за сравнение на низове. Въвеждаме нашите тестови низове с настройки по подразбиране и, ето, получаваме перфектното сортиране на руски.

Абаканов Михаил;маляр
Ёлкина Элла;крановщица
Иванов Андрей;слесарь
Иванова Алла;адвокат

Между другото, уебсайтът ICU можете да намерите усъвършенстване на алгоритъма за сравнение при обработка на препинателни знаци. В примерите ЧЗВ за съпоставяне апострофът и тирето се игнорират.

Unicode ни помогна, но потърсете причините за странното поведение вид в Linux ще трябва да отиде някъде другаде.

Сортиране в glibc

Бърз преглед на изходните кодове на помощните програми вид на GNU Core Utils показа, че в самата помощна програма локализацията се свежда до отпечатване на текущата стойност на променливата LC_COLLATE когато се изпълнява в режим на отстраняване на грешки:

$ sort --debug buhg.txt > buhg.srt
sort: using ‘en_US.UTF8’ sorting rules

Сравнението на низове се извършва от стандартната функция strcoll, което означава, че всичко интересно е в библиотеката НЬс.

На уики проект НЬс посветен на сравнение на низове един параграф. От този параграф може да се разбере, че НЬс сортирането се основава на вече познатия ни алгоритъм ACU (Алгоритъмът за сортиране на Unicode) и/или по близък до него стандарт ISO 14651 (Международно подреждане и сравнение на низове). По отношение на най-новия стандарт, трябва да се отбележи, че на сайта standards.iso.org ISO 14651 официално обявена за публична, но съответният линк води към несъществуваща страница. Google предоставя няколко страници с връзки към официални сайтове, които предлагат закупуване на електронно копие на стандарта за сто евро, но на третата или четвъртата страница от резултатите от търсенето има и директни връзки към PDF. Като цяло стандартът практически не се различава от ACU, но се чете по-скучно, защото не съдържа ярки примери за национални характеристики на сортирането на низове.

Най-интересната информация уики имаше линк към програма за проследяване на грешки с обсъждане на прилагането на сравнение на низове в НЬс. От дискусията се вижда, че НЬс за сравнение на низове се използва ISOшная маса Общата шаблонна таблица (CTT), чийто адрес можете да намерите в приложението A стандартен ISO 14651. Между 2000 и 2015 г. тази таблица в НЬс нямаше поддръжка и беше доста различен (поне външно) от текущата версия на стандарта. От 2015 до 2018 г. имаше адаптация към новата версия на таблицата и в момента имате шанс да се срещнете в реалния живот като нова версия на таблицата (CentOS 8) и старата (CentOS 7).

Сега, когато разполагаме с цялата информация за алгоритъма и помощните таблици, можем да се върнем към първоначалния проблем и да разберем как правилно да сортираме низове в руския локал.

ISO 14651 / 14652

Изходният код на таблицата, която ни интересува CTT на повечето дистрибуции Linux е в указателя /usr/share/i18n/locales/. Самата таблица е във файла iso14651_t1_common. Тогава този файл е директива копие iso14651_t1_common включени във файла iso14651_t1, което от своя страна е включено в национални досиета, в т.ч en_US и ru_ru. В повечето дистрибуции Linux всички изходни файлове са включени в основната инсталация, но ако не са, тогава ще трябва да инсталирате допълнителен пакет от дистрибуцията.

Файлова структура iso14651_t1 може да изглежда ужасно многословно, с неочевидни правила за конструиране на имена, но ако го разберете, всичко е съвсем просто. Структурата е описана в стандарта ISO 14652, чието копие можете да изтеглите от сайта open-std.org. Друго описание на файловия формат можете да намерите в спецификации POSIX от отворена група. Като алтернатива на четенето на стандарта, можете да изучавате изходните текстове на функцията collate_read в glibc/locale/programs/ld-collate.c.

Файловата структура изглежда така:

По подразбиране знакът се използва като екраниращ знак, а краят на реда след знака # е коментар. И двата символа могат да бъдат предефинирани, което е направено в новата версия на таблицата:

escape_char /
comment_char %

Файлът ще съдържа жетони във формат или (Където x е шестнадесетична цифра). Това е шестнадесетичното представяне на Unicode кодовите точки в кодирането UCS-4 (UTF-32). Всички други елементи в ъглови скоби (включително , <2> и други подобни) се считат за прости низови константи, които нямат много смисъл извън контекста.

ред LC_COLLATE ни казва, че данните, описващи сравнението на низове, започват следващи.

Първо се дават имена за тегла в таблицата за сравнение и имена за комбинации от знаци. Най-общо казано, два вида имена принадлежат на две различни единици, но те са смесени в действителния файл. Имената на теглата се дават от ключовата дума съпоставяне символ (знак за сравнение), тъй като Unicode знаците, които имат еднакви тегла, ще бъдат третирани като еквивалентни знаци, когато се сравняват.

Общата дължина на раздела в текущата версия на файла е около 900 реда. Извадих примери от няколко места, за да покажа произволни имена и няколко вида синтаксис.

LC_COLLATE

collating-symbol <RES-1>
collating-symbol <BLK>
collating-symbol <MIN>
collating-symbol <WIDE>
...
collating-symbol <ARABIC>
collating-symbol <ETHPC>
collating-symbol <OSMANYA>
...
collating-symbol <S1D000>..<S1D35F>
collating-symbol <SFFFF> % Guaranteed largest symbol value. Keep at end of this list
...
collating-element <U0413_0301> from "<U0413><U0301>"
collating-element <U0413_0341> from "<U0413><U0341>"

съпоставяне символ регистрира низ ОСМАНЯ в таблицата с имена на везни
съпоставяне символ .. регистрира поредица от имена, състояща се от префикс S и шестнадесетичен цифров суфикс от 1D000 до 1D35F.
FFFF в съпоставяне символ изглежда като голямо цяло число без знак в шестнадесетична система, но това е просто име, което може да изглежда така
име означава кодова точка в кодирането UCS-4
съпоставящ елемент от" " регистрира ново име за двойка уникод точки.

След като са дефинирани имената на теглата, се уточняват действителните тегла. Тъй като само съотношенията по-голямо-по-малко имат значение при сравнение, теглата се определят чрез проста последователност от изброяване на имена. Първо са изброени "по-леките" тежести, след това "по-големите" тежести. Напомняме, че на всеки Unicode символ се присвояват четири различни тегла. Тук те са обобщени в една подредена последователност. Теоретично всяко символично име може да се използва на всяко от четирите нива, но коментарите показват, че разработчиците мислено разделят имената на нива.

% Symbolic weight assignments

% Third-level weight assignments
<RES-1>
<BLK>
<MIN>
<WIDE>
...
% Second-level weight assignments
<BASE>
<LOWLINE> % COMBINING LOW LINE
<PSILI> % COMBINING COMMA ABOVE
<DASIA> % COMBINING REVERSED COMMA ABOVE
...
% First-level weight assignments
<S0009> % HORIZONTAL TABULATION 
<S000A> % LINE FEED
<S000B> % VERTICAL TABULATION
...
<S0434> % CYRILLIC SMALL LETTER DE
<S0501> % CYRILLIC SMALL LETTER KOMI DE
<S0452> % CYRILLIC SMALL LETTER DJE
<S0503> % CYRILLIC SMALL LETTER KOMI DJE
<S0453> % CYRILLIC SMALL LETTER GJE
<S0499> % CYRILLIC SMALL LETTER ZE WITH DESCENDER
<S0435> % CYRILLIC SMALL LETTER IE
<S04D7> % CYRILLIC SMALL LETTER IE WITH BREVE
<S0454> % CYRILLIC SMALL LETTER UKRAINIAN IE
<S0436> % CYRILLIC SMALL LETTER ZHE

И накрая, таблицата с действителното тегло.

Разделът за теглото е ограден в редове с ключови думи поръчка_начало и поръчка_край. Допълнителни опции поръчка_начало определя в каква посока се сканират редовете на всяко ниво на сравнение. Настройката по подразбиране е напред. Тялото на раздела се състои от редове, които съдържат кода на знака и неговите четири тегла. Код на знак може да бъде представен от самия знак, кодова точка или символно име, дефинирано преди това. Тегла могат да бъдат дадени и на символни имена, кодови точки или самите символи. Ако се използват кодови точки или знаци, тяхното тегло е същото като числената стойност на кодовата точка (позиция в Unicode таблицата). Символите, които не са посочени изрично (доколкото разбирам), се считат за присвоени на таблицата с основно тегло, което съответства на позицията в таблицата Unicode. Специална стойност на теглото ИГНОРИРАЙТЕ означава, че даден знак се игнорира на съответното ниво на сравнение.

За да демонстрирам структурата на теглата, избрах три доста очевидни фрагмента:

знаци, които са напълно игнорирани
знаци, еквивалентни на числото три в първите две нива
началото на кирилицата, която не съдържа диакритични знаци, поради което е подредена основно по първо и трето ниво.

order_start forward;forward;forward;forward,position
<U0000> IGNORE;IGNORE;IGNORE;IGNORE % NULL (in 6429)
<U0001> IGNORE;IGNORE;IGNORE;IGNORE % START OF HEADING (in 6429)
<U0002> IGNORE;IGNORE;IGNORE;IGNORE % START OF TEXT (in 6429)
...
<U0033> <S0033>;<BASE>;<MIN>;<U0033> % DIGIT THREE
<UFF13> <S0033>;<BASE>;<WIDE>;<UFF13> % FULLWIDTH DIGIT THREE
<U2476> <S0033>;<BASE>;<COMPAT>;<U2476> % PARENTHESIZED DIGIT THREE
<U248A> <S0033>;<BASE>;<COMPAT>;<U248A> % DIGIT THREE FULL STOP
<U1D7D1> <S0033>;<BASE>;<FONT>;<U1D7D1> % MATHEMATICAL BOLD DIGIT THREE
...
<U0430> <S0430>;<BASE>;<MIN>;<U0430> % CYRILLIC SMALL LETTER A
<U0410> <S0430>;<BASE>;<CAP>;<U0410> % CYRILLIC CAPITAL LETTER A
<U04D1> <S04D1>;<BASE>;<MIN>;<U04D1> % CYRILLIC SMALL LETTER A WITH BREVE
<U0430_0306> <S04D1>;<BASE>;<MIN>;<U04D1> % CYRILLIC SMALL LETTER A WITH BREVE
...
<U0431> <S0431>;<BASE>;<MIN>;<U0431> % CYRILLIC SMALL LETTER BE
<U0411> <S0431>;<BASE>;<CAP>;<U0411> % CYRILLIC CAPITAL LETTER BE
<U0432> <S0432>;<BASE>;<MIN>;<U0432> % CYRILLIC SMALL LETTER VE
<U0412> <S0432>;<BASE>;<CAP>;<U0412> % CYRILLIC CAPITAL LETTER VE
...
order_end

Сега можете да се върнете към сортирането на примерите от началото на статията. Засадата е в тази част от таблицата с теглото:

<U0020> IGNORE;IGNORE;IGNORE;<U0020> % SPACE
<U0021> IGNORE;IGNORE;IGNORE;<U0021> % EXCLAMATION MARK
<U0022> IGNORE;IGNORE;IGNORE;<U0022> % QUOTATION MARK
...

Вижда се, че в тази таблица препинателните знаци от табл ASCII (включително интервал) почти винаги се игнорира при сравняване на низове. Единствените изключения са низовете, които съвпадат във всичко, с изключение на препинателните знаци, които се срещат в съвпадащи позиции. Редовете от моя пример (след сортиране) за алгоритъма за сравнение изглеждат така:

АбакановМихаилмаляр
ЁлкинаЭллакрановщица
ИвановаАлламаляр
ИвановАндрейслесарь

Като се има предвид, че в таблицата с тегло главни букви на руски идват след малки букви (на трето ниво по-трудно от ), сортирането изглежда абсолютно правилно.

Когато задавате променлива LC_COLLATE=C зарежда се специална таблица, която определя сравнението байт по байт

static const uint32_t collseqwc[] =
{
  8, 1, 8, 0x0, 0xff,
  /* 1st-level table */
  6 * sizeof (uint32_t),
  /* 2nd-level table */
  7 * sizeof (uint32_t),
  /* 3rd-level table */
  L'x00', L'x01', L'x02', L'x03', L'x04', L'x05', L'x06', L'x07',
  L'x08', L'x09', L'x0a', L'x0b', L'x0c', L'x0d', L'x0e', L'x0f',

...
  L'xf8', L'xf9', L'xfa', L'xfb', L'xfc', L'xfd', L'xfe', L'xff'
};

Тъй като Unicode кодовата точка Ё идва преди A, низовете се сортират съответно.

Текстови и двоични таблици

Очевидно сравнението на низове е изключително често срещана операция и анализирането на таблица CTT доста скъпа процедура. За да се оптимизира достъпът до таблицата, тя се компилира в двоична форма с командата localdef.

Отбор localdef приема като параметри файл с таблица с национални характеристики (опция -i), в който всички знаци са представени от Unicode точки, и Unicode файл за съпоставяне на точки за знаци с конкретно кодиране (опция -f). В резултат на работата се създават двоични файлове за локала с името, посочено в последния параметър.

glibc поддържа два двоични файлови формата: "традиционен" и "модерен".

Традиционният формат предполага, че името на локала е името на поддиректория в /usr/lib/locale/. Тази поддиректория съдържа двоичните файлове LC_COLLATE, LC_CTYPE, LC_TIME и така нататък. Файл LC_ИДЕНТИФИКАЦИЯ съдържа официалното име на локал (което може да е различно от името на директорията) и коментари.

Модерният формат включва съхраняване на всички локали в един архив /usr/lib/locale/locale-archive, който е картографиран към виртуалната памет на всички процеси, които използват НЬс. Името на локала в съвременния формат претърпява известна канонизация - в името на кодирането остават само цифри и букви, намалени до малки букви. Така en_RU.KOI8-R, ще бъдат запазени като ru_RU.koi8r.

Входните файлове се търсят в текущата директория, както и в директории /usr/share/i18n/locales/ и /usr/share/i18n/charmaps/ за файлове CTT и файлове за кодиране, съответно.

Например командата

localedef -i ru_RU -f MAC-CYRILLIC ru_RU.MAC-CYRILLIC

ще компилира файла /usr/share/i18n/locales/ru_RU използвайки файл за кодиране /usr/share/i18n/charmaps/MAC-CYRILLIC.gz и запазете резултата в /usr/lib/locale/locale-archive под името en_RU.maccyrillic

Ако зададете променлива LANG = en_US.UTF-8 то НЬс ще търси локални двоични файлове в следната последователност от файлове и директории:

/usr/lib/locale/locale-archive
/usr/lib/locale/en_US.UTF-8/
/usr/lib/locale/en_US/
/usr/lib/locale/enUTF-8/
/usr/lib/locale/en/

Ако даден локал се среща както в традиционния, така и в модерния формат, тогава модерният има предимство.

Можете да видите списъка с компилираните локали с командата locale -a.

Подготовка на вашата сравнителна таблица

Сега, въоръжени със знания, можете да създадете своя собствена идеална таблица за сравнение на низове. Тази таблица трябва правилно да сравнява руските букви, включително буквата Ё, и в същото време да вземе предвид препинателните знаци в съответствие с таблицата ASCII.

Процесът на подготовка на вашата таблица за сортиране се състои от два етапа: редактиране на таблицата с теглото и нейното компилиране в двоична форма с командата localdef.

За да може сравнителната таблица да се коригира с минимални разходи за редакция, във формат ISO 14652 предвидени са секции за регулиране на теглата на съществуваща маса. Разделът започва с ключова дума пренареждане-след и уточняване на позицията, след която се извършва подмяната. Завършва секцията с линия пренареждане-край. Ако е необходимо да се коригират няколко раздела от таблицата, тогава се създава раздел за всеки такъв раздел.

Копирах новите версии на файловете iso14651_t1_common и ru_ru от хранилището НЬс във вашата домашна директория ~/.local/share/i18n/locales/ и леко редактирахте раздела LC_COLLATE в ru_ru. Новите версии на файловете са напълно съвместими с моята версия НЬс. Ако искате да използвате по-стари версии на файлове, тогава ще трябва да промените символните имена и мястото, където започва замяната в таблицата.

LC_COLLATE
% Copy the template from ISO/IEC 14651
copy "iso14651_t1"
reorder-after <U000D>
<U0020> <S0020>;<BASE>;<MIN>;<U0020> % SPACE
<U0021> <S0021>;<BASE>;<MIN>;<U0021> % EXCLAMATION MARK
<U0022> <S0022>;<BASE>;<MIN>;<U0022> % QUOTATION MARK
...
<U007D> <S007D>;<BASE>;<MIN>;<U007D> % RIGHT CURLY BRACKET
<U007E> <S007E>;<BASE>;<MIN>;<U007E> % TILDE
reorder-end
END LC_COLLATE

Всъщност би било необходимо да промените полетата в LC_ИДЕНТИФИКАЦИЯ така че да сочат към локала en_MY, но в моя пример това не беше необходимо, тъй като изключих архива от търсенето на локали локал-архив.

Че localdef работи с файлове в папката ми чрез променлива I18NPATH можете да добавите допълнителна директория за търсене на входни файлове, а директорията за запазване на двоични файлове може да бъде посочена като път с наклонени черти:

$> I18NPATH=~/.local/share/i18n localedef -i ru_RU -f UTF-8 ~/.local/lib/locale/ru_MY.UTF-8

POSIX предполага, че в ЕЗИК можете да напишете абсолютни пътища към директории с локални файлове, като започнете с наклонена черта, но НЬс в Linux всички пътища се броят от основната директория, която може да бъде заменена чрез променлива LOCPATH... След монтажа LOCPATH=~/.local/lib/locale/ всички файлове, свързани с локализацията, ще се търсят само в моята папка. Архив на локала, когато е зададена променлива LOCPATH игнориран.

Ето и финалния тест:

$> LANG=ru_MY.UTF-8 LOCPATH=~/.local/lib/locale/ sort buhg.txt
Абаканов Михаил;маляр
Ёлкина Элла;крановщица
Иванов Андрей;слесарь
Иванова Алла;адвокат

Ура! Успяхме!

Някои грешки

Вече отговорих на въпросите за сортирането на низове, поставени в началото, но има още няколко въпроса за грешките - видими и невидими.

Да се върнем към първоначалния проблем.

И програмата вид и програма присъединят към използвайте същите функции за сравнение на низове от НЬс. Как стана така, че присъединят към даде грешка при сортиране на редове, сортирани от командата вид в локал en_US.UTF-8? Отговорът е прост: вид сравнява целия низ и присъединят към сравнява само ключа, който по подразбиране е началото на низа до първия празен знак. В моя пример това доведе до съобщение за грешка, тъй като сортирането на първите думи в редовете не съвпада със сортирането на пълните редове.

локал "° С" гарантира, че в сортираните низове, водещите поднизове до първия интервал също ще бъдат сортирани, но това само маскира грешката. Можете да вземете такива данни (хора с едно и също фамилно име, но различни имена), които без съобщение за грешка биха дали неправилен резултат от обединяването на файлове. Ако искаме присъединят към комбинирани файлови редове по пълно име, тогава правилният начин би бил изрично да посочите разделителя на полето и да сортирате по ключовото поле, а не по целия ред. В този случай сливането също ще работи правилно и няма да има грешки в нито един локал:

$> sort -t ; -k 1 buhg.txt > buhg.srt
$> sort -t ; -k 1 mail.txt > mail.srt
$> join -t ; buhg.srt mail.srt > result

Успешно изпълнен кодиран пример CP1251 съдържа друга грешка. Факт е, че във всички разпределения, които са ми известни Linux пакети без компилиран локал en_RU.CP1251. Ако компилираният локал не бъде намерен, тогава вид безшумно използва сравнение байт по байт, което наблюдавахме.

Между другото, има още един малък проблем, свързан с недостъпността на компилираните локали. Екип LOCPATH=/tmp локал -a ще върне списък с всички локали в локал-архив, но с набор от променливи LOCPATH за всички програми (включително повечето място) тези локали няма да бъдат налични.

$> LOCPATH=/tmp locale -a | grep en_US
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_COLLATE to default locale: No such file or directory
en_US
en_US.iso88591
en_US.iso885915
en_US.utf8

$> LC_COLLATE=en_US.UTF-8 sort --debug
sort: using ‘en_US.UTF-8’ sorting rules

$> LOCPATH=/tmp LC_COLLATE=en_US.UTF-8 sort --debug
sort: using simple byte comparison

Заключение

Ако сте програмист, който е свикнал да мисли, че низовете са колекция от байтове, тогава вашият избор е LC_COLLATE=C.

Ако сте лингвист или съставител на речник, тогава по-добре компилирайте своя локал.

Ако сте обикновен потребител, тогава просто трябва да свикнете с факта, че командата ls -a отпечатва файлове, започващи с точка, осеяни с файлове, започващи с буква, и Среднощният командир, който използва вътрешните си функции за сортиране на имена, премества файлове, започващи с точка, в началото на списъка.