შესავალი

ყველაფერი დაიწყო მოკლე სკრიპტით, რომელიც უნდა აერთიანებდა მისამართის ინფორმაციას ელ თანამშრომლები, რომლებიც მიღებულია საფოსტო სიის მომხმარებელთა სიიდან, თანამშრომელთა პოზიციებით მიღებული HR დეპარტამენტის მონაცემთა ბაზიდან. ორივე სია ექსპორტირებული იყო 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-ში ან ჰგავს ფემინიზმის გამოვლინებას დახარისხების ალგორითმში. პირველი, რა თქმა უნდა, უფრო დამაჯერებელია.

მოდით გადავდოთ ეს ახლა შეუერთდება და ფოკუსირება სახის. შევეცადოთ პრობლემის გადაჭრა მეცნიერული პოკინგის გამოყენებით. პირველი, მოდით შევცვალოთ ლოკალი jw.org ka on 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 sort განიხილავს '-' (ტირე) სიმბოლოებს, როგორც უხილავს. მოკლედ, სტრიქონები "ab", "aa", "ac" დალაგებულია "aa", "ab", "ac".

პასუხი ყველგან სტანდარტულია: გამოიყენეთ პროგრამისტის ლოკალი "C" და ბედნიერი იქნები. Მოდი ვცადოთ:

$> 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 

დახარისხების შედეგი, უცნაურად საკმარისი, დაემთხვევა ლოკალს "C"და მთელი მაგალითი, შესაბამისად, შეცდომების გარეშე მუშაობს. ერთგვარი მისტიკა.

მე არ მიყვარს მისტიკა პროგრამირებაში, რადგან ის ჩვეულებრივ ფარავს შეცდომებს. ჩვენ სერიოზულად უნდა შევხედოთ როგორ მუშაობს. სახის და რა გავლენას ახდენს? LC_COLLATE .

დასასრულს შევეცდები ვუპასუხო კითხვებს:

• რატომ იყო არასწორად დალაგებული ქალის გვარები?
• რატომ LANG=ru_RU.CP1251 ექვივალენტი აღმოჩნდა LANG=C
• რატომ სახის и შეუერთდება განსხვავებული იდეები დალაგებული სტრიქონების თანმიმდევრობის შესახებ
• რატომ არის შეცდომები ჩემს ყველა მაგალითში?
• და ბოლოს, როგორ დაალაგოთ სიმები თქვენი გემოვნებით

დახარისხება უნიკოდში

პირველი გაჩერება იქნება ტექნიკური ანგარიში No10 სათაურით უნიკოდის შეკრების ალგორითმი ონლაინ unicode.org. მოხსენება შეიცავს უამრავ ტექნიკურ დეტალს, ასე რომ, ნება მომეცით მოგაწოდოთ ძირითადი იდეების მოკლე შინაარსი.

შედარების — სტრიქონების „შედარება“ არის ნებისმიერი დახარისხების ალგორითმის საფუძველი. თავად ალგორითმები შეიძლება განსხვავდებოდეს ("ბუშტი", "შერწყმა", "სწრაფი"), მაგრამ ისინი ყველა გამოიყენებენ წყვილი სტრიქონების შედარებას, რათა დადგინდეს მათი გამოჩენის თანმიმდევრობა.

ბუნებრივ ენაზე სიმების დახარისხება საკმაოდ რთული პრობლემაა. უმარტივესი ერთბაიტიანი კოდირებითაც კი, ანბანში ასოების თანმიმდევრობა, თუნდაც გარკვეულწილად განსხვავებული ინგლისური ლათინური ანბანისგან, აღარ დაემთხვევა რიცხვითი მნიშვნელობების თანმიმდევრობას, რომლითაც ეს ასოებია დაშიფრული. ასე რომ, გერმანულ ანბანში ასო Ö შორის დგას О и Pდა კოდირებით CP850 ის ხვდება შორის ÿ и Ü.

შეგიძლიათ სცადოთ აბსტრაქცია კონკრეტული კოდირებიდან და განიხილოთ „იდეალური“ ასოები, რომლებიც დალაგებულია გარკვეული თანმიმდევრობით, როგორც ეს ხდება უნიკოდში. კოდირებები UTF8, UTF16 ან ერთი ბაიტი KOI8-R (თუ საჭიროა Unicode-ის შეზღუდული ქვეჯგუფი) მისცემს ასოების სხვადასხვა ციფრულ წარმოდგენას, მაგრამ ეხება საბაზისო ცხრილის ერთსა და იმავე ელემენტებს.

გამოდის, რომ თუნდაც ნულიდან ავაშენოთ სიმბოლოების ცხრილი, მას ვერ მივანიჭებთ უნივერსალურ სიმბოლოს. სხვადასხვა ეროვნულ ანბანში, რომლებიც იყენებენ ერთსა და იმავე ასოებს, ამ ასოების თანმიმდევრობა შეიძლება განსხვავდებოდეს. მაგალითად, ფრანგულად Æ ჩაითვლება ლიგატურად და დალაგდება სტრიქონად AE. ნორვეგიულად Æ იქნება ცალკე წერილი, რომელიც მდებარეობს შემდეგ Z. სხვათა შორის, ლიგატების გარდა, როგორიცაა Æ არის ასოები დაწერილი რამდენიმე სიმბოლოთი. ასე რომ, ჩეხურ ანბანში არის ასო Ch, რომელიც დგას შორის H и I.

გარდა ანბანში განსხვავებებისა, არსებობს სხვა ეროვნული ტრადიციები, რომლებიც გავლენას ახდენენ დახარისხებაზე. კერძოდ, ჩნდება კითხვა: რა თანმიმდევრობით უნდა გამოჩნდეს ლექსიკონში დიდი და პატარა ასოებისგან შემდგარი სიტყვები? დახარისხებაზე შესაძლოა გავლენა იქონიოს სასვენი ნიშნების გამოყენებამ. ესპანურად შებრუნებული კითხვის ნიშანი გამოიყენება კითხვითი წინადადების დასაწყისში (Მოგწონთ მუსიკა?). ამ შემთხვევაში აშკარაა, რომ კითხვითი წინადადებები არ უნდა იყოს დაჯგუფებული ცალკე კლასტერში ანბანის მიღმა, მაგრამ როგორ დავახარისხოთ ხაზები სხვა სასვენი ნიშნებით?

მე არ შევჩერდები სტრიქონების დახარისხებაზე ევროპულისგან ძალიან განსხვავებულ ენებზე. გაითვალისწინეთ, რომ ენებზე, რომლებსაც აქვთ წერის მიმართულება მარჯვნივ მარცხნივ ან ზემოდან ქვემოდან, ხაზებში სიმბოლოები, სავარაუდოდ, ინახება კითხვის თანმიმდევრობით, და არაანბანურ წერილობით სისტემებსაც კი აქვთ ხაზების დალაგების საკუთარი გზები სიმბოლოების მიხედვით. . მაგალითად, იეროგლიფების შეკვეთა შესაძლებელია სტილის მიხედვით (ჩინური სიმბოლოების გასაღებები) ან გამოთქმით. მართალი გითხრათ, წარმოდგენა არ მაქვს, როგორ უნდა იყოს აწყობილი ემოციები, მაგრამ თქვენც შეგიძლიათ მოიფიქროთ რამე მათთვის.

ზემოთ ჩამოთვლილ მახასიათებლებზე დაყრდნობით, ჩამოყალიბდა უნიკოდის ცხრილებზე დაფუძნებული სტრიქონების შედარების ძირითადი მოთხოვნები:

• სტრიქონების შედარება არ არის დამოკიდებული კოდების ცხრილში სიმბოლოების პოზიციაზე;
• სიმბოლოების თანმიმდევრობა, რომლებიც ქმნიან ერთ სიმბოლოს, დაყვანილია კანონიკურ ფორმამდე (A + ზედა წრე იგივეა რაც Å);
• სტრიქონების შედარებისას, სიმბოლო განიხილება სტრიქონის კონტექსტში და, საჭიროების შემთხვევაში, მისი მეზობლებთან ერთად შედარების ერთ ერთეულში (Ch ჩეხურად) ან იყოფა რამდენიმე (Æ ფრანგულად);
• ყველა ეროვნული მახასიათებელი (ანბანი, დიდი/პატარა, პუნქტუაცია, დამწერლობის ტიპების თანმიმდევრობა) უნდა იყოს კონფიგურირებული შეკვეთის ხელით მინიჭებამდე (ემოჯი);
• შედარება მნიშვნელოვანია არა მხოლოდ დახარისხებისთვის, არამედ ბევრ სხვა ადგილას, მაგალითად, მწკრივების დიაპაზონის მითითებისთვის (შეცვალეთ {A... z}-ში Bash);
• შედარება უნდა მოხდეს საკმაოდ სწრაფად.

გარდა ამისა, ანგარიშის ავტორებმა ჩამოაყალიბეს შედარების თვისებები, რომლებსაც ალგორითმის შემქმნელები არ უნდა დაეყრდნოთ:

• შედარების ალგორითმი არ უნდა მოითხოვდეს სიმბოლოების ცალკეულ კომპლექტს თითოეული ენისთვის (რუსული და უკრაინული ენები იზიარებენ კირიული სიმბოლოების უმეტესობას);
• შედარება არ უნდა ეყრდნობოდეს უნიკოდის ცხრილების სიმბოლოების თანმიმდევრობას;
• სიმებიანი წონა არ უნდა იყოს სტრიქონის ატრიბუტი, ვინაიდან ერთსა და იმავე სტრიქონს სხვადასხვა კულტურულ კონტექსტში შეიძლება ჰქონდეს განსხვავებული წონა;
• მწკრივის წონა შეიძლება შეიცვალოს შერწყმის ან გაყოფისას (დან x < y ამას არ მოჰყვება xz < yz);
• სხვადასხვა სტრიქონები, რომლებსაც აქვთ იგივე წონა, განიხილება თანაბარი დახარისხების ალგორითმის თვალსაზრისით. ასეთი სტრიქონების დამატებითი შეკვეთის შემოღება შესაძლებელია, მაგრამ ამან შეიძლება გააუარესოს შესრულება;
• განმეორებითი დახარისხების დროს შეიძლება შეიცვალოს ერთი და იგივე წონის მწკრივები. გამძლეობა არის სპეციფიკური დახარისხების ალგორითმის თვისება და არა სიმებიანი შედარების ალგორითმის თვისება (იხ. წინა აბზაცი);
• დახარისხების წესები შეიძლება შეიცვალოს დროთა განმავლობაში კულტურული ტრადიციების დახვეწა/ცვლილებასთან ერთად.

ასევე გათვალისწინებულია, რომ შედარების ალგორითმმა არაფერი იცის დამუშავებული სტრიქონების სემანტიკის შესახებ. ამრიგად, მხოლოდ ციფრებისგან შემდგარი სტრიქონები არ უნდა შევადაროთ რიცხვებს, ხოლო ინგლისური სახელების სიაში სტატია (ბითლზი, The).

ყველა მითითებული მოთხოვნის დასაკმაყოფილებლად, შემოთავაზებულია ცხრილების დახარისხების მრავალდონიანი (რეალურად ოთხდონიანი) ალგორითმი.

ადრე სტრიქონის სიმბოლოები შემცირდა კანონიკურ ფორმამდე და დაჯგუფებულია შედარების ერთეულებად. შედარების თითოეულ ერთეულს ენიჭება რამდენიმე წონა, რომელიც შეესაბამება შედარების რამდენიმე დონეს. შედარების ერთეულების წონები არის მოწესრიგებული სიმრავლების ელემენტები (ამ შემთხვევაში, მთელი რიცხვები), რომელთა შედარება შესაძლებელია მეტ-ნაკლებად. განსაკუთრებული მნიშვნელობა იგნორირებული (0x0) ნიშნავს, რომ შესაბამის შედარების დონეზე ეს ერთეული არ არის ჩართული შედარებაში. სიმების შედარება შეიძლება რამდენჯერმე განმეორდეს შესაბამისი დონის წონების გამოყენებით. თითოეულ დონეზე, ორი რიგის შედარების ერთეულების წონები თანმიმდევრულად ადარებენ ერთმანეთს.

სხვადასხვა ეროვნული ტრადიციების ალგორითმის სხვადასხვა განხორციელებაში, კოეფიციენტების მნიშვნელობები შეიძლება განსხვავდებოდეს, მაგრამ უნიკოდის სტანდარტი მოიცავს წონის ძირითად ცხრილს - "ნაგულისხმევი Unicode Collation Element Table" (DUCET). მინდა აღვნიშნო, რომ ცვლადის დაყენება LC_COLLATE ფაქტობრივად არის სტრიქონების შედარების ფუნქციაში წონის ცხრილის შერჩევის მითითება.

შეწონვის კოეფიციენტები DUCET მოწყობილი შემდეგნაირად:

• პირველ დონეზე, ყველა ასო მცირდება ერთსა და იმავე შემთხვევამდე, დიაკრიტიკა უგულებელყოფილია, პუნქტუაციის ნიშნები (ყველა არა) იგნორირებულია;
• მეორე დონეზე მხედველობაში მიიღება მხოლოდ დიაკრიტიკა;
• მესამე დონეზე მხედველობაში მიიღება მხოლოდ შემთხვევა;
• მეოთხე დონეზე მხედველობაში მიიღება მხოლოდ სასვენი ნიშნები.

შედარება ხდება რამდენიმე უღელტეხილში: ჯერ ხდება პირველი დონის კოეფიციენტების შედარება; თუ წონები ემთხვევა, მაშინ ტარდება განმეორებითი შედარება მეორე დონის წონებთან; შემდეგ ალბათ მესამე და მეოთხე.

შედარება მთავრდება, როდესაც რიგები შეიცავს შესატყვის ერთეულებს სხვადასხვა წონასთან. რიგები, რომლებსაც აქვთ თანაბარი წონა ოთხივე დონეზე, განიხილება ერთმანეთის ტოლი.

ამ ალგორითმმა (დამატებითი ტექნიკური დეტალების თაიგულით) დაარქვა სახელი მე-10 მოხსენებას - "უნიკოდის შეგროვების ალგორითმი" (ACU).

სწორედ აქ ხდება დახარისხების ქცევა ჩვენი მაგალითიდან ცოტა უფრო ნათელი. კარგი იქნებოდა მისი შედარება უნიკოდის სტანდარტთან.

განხორციელების შესამოწმებლად ACU არსებობს სპეციალური ტესტი, გამოყენებით წონის ფაილი, ახორციელებს DUCET. სასწორის ფაილში შეგიძლიათ იპოვოთ ყველანაირი სასაცილო რამ. მაგალითად, არის მაჰჯონგის და ევროპული დომინოს რიგი, ასევე სარჩელების რიგი ბანქოს დასტაში (სიმბოლო 1F000 და შემდგომ). საბარათე კოსტიუმები მოთავსებულია ბრიჯის წესების მიხედვით - PCBT, ხოლო კარტები კოსტიუმში არის თანმიმდევრობით T, 2,3, XNUMX... K.

ხელით შემოწმება, რომ რიგები დალაგებულია სწორად მიხედვით DUCET საკმაოდ დამღლელი იქნებოდა, მაგრამ, ჩვენთვის საბედნიეროდ, არსებობს ბიბლიოთეკის სამაგალითო დანერგვა უნიკოდთან მუშაობისთვის - "საერთაშორისო კომპონენტები უნიკოდისთვის"(ICU).

ამ ბიბლიოთეკის ვებსაიტზე, შემუშავებული ქ IBM, არის დემო გვერდები, მათ შორის სიმებიანი შედარების ალგორითმის გვერდი. ჩვენ შევდივართ ჩვენს სატესტო ხაზებში ნაგულისხმევი პარამეტრებით და, აჰა, ვიღებთ სრულყოფილ რუსულ დახარისხებას.

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

სხვათა შორის, საიტი ICU შეგიძლიათ იპოვოთ შედარების ალგორითმის განმარტება პუნქტუაციის ნიშნების დამუშავებისას. მაგალითებში FAQ აპოსტროფი და დეფისი იგნორირებულია.

Unicode დაგვეხმარა, მაგრამ მოძებნეთ უცნაური ქცევის მიზეზები სახის в Linux სხვაგან მოუწევს წასვლა.

დალაგება glibc-ში

კომუნალური წყაროს კოდების სწრაფი ნახვა სახის საქართველოს GNU Core Utils აჩვენა, რომ თავად პროგრამაში ლოკალიზაცია მოდის ცვლადის მიმდინარე მნიშვნელობის დაბეჭდვაზე LC_COLLATE გამართვის რეჟიმში მუშაობისას:

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

სტრიქონების შედარება ხორციელდება სტანდარტული ფუნქციის გამოყენებით strcoll, რაც იმას ნიშნავს, რომ ყველაფერი საინტერესო ბიბლიოთეკაშია glibc.

წლის ვიკი პროექტი glibc ეძღვნება სტრიქონების შედარებას ერთი აბზაცი. ამ პუნქტიდან შეიძლება გავიგოთ, რომ ქ glibc დახარისხება ეფუძნება ჩვენთვის უკვე ცნობილ ალგორითმს ACU (უნიკოდის შეკრების ალგორითმი) და/ან მასთან ახლოს სტანდარტზე ISO 14651 (სიმების საერთაშორისო შეკვეთა და შედარება). რაც შეეხება უახლეს სტანდარტს, უნდა აღინიშნოს, რომ საიტზე standards.iso.org ISO 14651 ოფიციალურად გამოცხადდა საჯაროდ ხელმისაწვდომი, მაგრამ შესაბამისი ბმული მივყავართ არარსებულ გვერდზე. Google აბრუნებს რამდენიმე გვერდს ოფიციალურ საიტებზე ბმულებით, რომლებიც გვთავაზობენ სტანდარტის ელექტრონული ასლის შეძენას ას ევროდ, მაგრამ ძიების შედეგების მესამე ან მეოთხე გვერდზე ასევე არის პირდაპირი ბმულები. PDF. ზოგადად, სტანდარტი პრაქტიკულად არ განსხვავდება ACU, მაგრამ უფრო მოსაწყენია წასაკითხად, რადგან არ შეიცავს სიმებიანი დახარისხების ეროვნული მახასიათებლების ნათელ მაგალითებს.

ყველაზე საინტერესო ინფორმაცია ვიკი იყო ბმული შეცდომების ტრეკერი სიმებიანი შედარების განხორციელების განხილვით glibc. დისკუსიიდან შეიძლება გავიგოთ, რომ glibc გამოიყენება სტრიქონების შესადარებლად ISOპირადი მაგიდა საერთო შაბლონის ცხრილი (CTT), რომლის მისამართი შეგიძლიათ იხილოთ განაცხადში A სტანდარტული ISO 14651. 2000-დან 2015 წლამდე ეს ცხრილი შევიდა glibc არ ჰყავდა დამჭერი და საკმაოდ განსხვავდებოდა (ყოველ შემთხვევაში გარეგნულად) სტანდარტის ამჟამინდელი ვერსიისგან. 2015 წლიდან 2018 წლამდე მოხდა ცხრილის ახალ ვერსიასთან ადაპტაცია და ახლა თქვენ გაქვთ შანსი რეალურ ცხოვრებაში შეხვდეთ ცხრილის ახალ ვერსიას (CentOS 8), და ძველი (CentOS 7).

ახლა, როდესაც ჩვენ გვაქვს ყველა ინფორმაცია ალგორითმისა და დამხმარე ცხრილების შესახებ, შეგვიძლია დავუბრუნდეთ საწყის პრობლემას და გავიგოთ, როგორ სწორად დაალაგოთ სტრიქონები რუსულ ლოკალში.

ISO 14651 / 14652

ჩვენ გვაინტერესებს ცხრილის წყარო კოდი CTT უმეტეს დისტრიბუციაზე Linux არის კატალოგში /usr/share/i18n/locales/. ცხრილი თავად არის ფაილში iso14651_t1_common. მაშინ ეს არის ფაილის დირექტივა დააკოპირეთ iso14651_t1_common ჩართულია ფაილში iso14651_t1, რომელიც, თავის მხრივ, შედის ეროვნულ ფაილებში, მათ შორის jw.org ka и ru_RU. უმეტეს დისტრიბუციაზე Linux ყველა წყაროს ფაილი შედის ძირითად ინსტალაციაში, მაგრამ თუ ისინი არ არის, თქვენ მოგიწევთ დამატებითი პაკეტის დაყენება დისტრიბუციიდან.

ფაილის სტრუქტურა iso14651_t1 შეიძლება საშინლად სიტყვიერად მოგეჩვენოთ, სახელების აგების არაცხადი წესებით, მაგრამ თუ დააკვირდებით, ყველაფერი საკმაოდ მარტივია. სტრუქტურა აღწერილია სტანდარტში ISO 14652, რომლის ასლის ჩამოტვირთვა შესაძლებელია ვებ გვერდიდან open-std.org. ფაილის ფორმატის კიდევ ერთი აღწერა შეგიძლიათ იხილოთ სპეციფიკაციები POSIX საწყისი OpenGroup. როგორც სტანდარტის წაკითხვის ალტერნატივა, შეგიძლიათ შეისწავლოთ ფუნქციის საწყისი კოდი შეკრება_წაკითხული в 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
• შეჯამება-ელემენტი საწყისი " " რეგისტრირებს ახალ სახელს უნიკოდის წერტილების წყვილისთვის.

მას შემდეგ რაც განისაზღვრება წონების სახელები, მითითებულია რეალური წონა. იმის გამო, რომ შედარებისთვის მნიშვნელოვანია მხოლოდ ნაკლებზე მეტი ურთიერთობა, წონები განისაზღვრება სახელების ჩამონათვალის მარტივი თანმიმდევრობით. ჯერ ჩამოთვლილია "მსუბუქი" წონა, შემდეგ "მძიმე". შეგახსენებთ, რომ უნიკოდის თითოეულ სიმბოლოს ენიჭება ოთხი განსხვავებული წონა. აქ ისინი გაერთიანებულია ერთ შეკვეთილ თანმიმდევრობაში. თეორიულად, ნებისმიერი სიმბოლური სახელი შეიძლება გამოყენებულ იქნას ოთხივე დონეზე, მაგრამ კომენტარები მიუთითებს იმაზე, რომ დეველოპერები გონებრივად გამოყოფენ სახელებს დონეებად.

% 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

და ბოლოს, რეალური წონის ცხრილი.

წონების განყოფილება ჩართულია საკვანძო სიტყვების ხაზებში შეკვეთა_დაწყება и შეკვეთა_დასრულება. დამატებითი პარამეტრები შეკვეთა_დაწყება დაადგინეთ, თუ რომელი მიმართულებით სკანირებულია რიგები შედარების თითოეულ დონეზე. ნაგულისხმევი პარამეტრი არის წინ. განყოფილების სხეული შედგება ხაზებისგან, რომლებიც შეიცავს სიმბოლოს კოდს და მის ოთხ წონას. სიმბოლოს კოდი შეიძლება წარმოდგენილი იყოს თავად სიმბოლოთი, კოდის წერტილით ან ადრე განსაზღვრული სიმბოლური სახელით. წონა ასევე შეიძლება მიენიჭოს სიმბოლურ სახელებს, კოდის წერტილებს ან თავად სიმბოლოებს. თუ გამოიყენება კოდის წერტილები ან სიმბოლოები, მათი წონა იგივეა, რაც კოდის წერტილის რიცხვითი მნიშვნელობა (პოზიცია უნიკოდის ცხრილში). სიმბოლოები, რომლებიც აშკარად არ არის მითითებული (როგორც მე მესმის) მიჩნეულია ცხრილში მინიჭებულად პირველადი წონით, რომელიც ემთხვევა უნიკოდის ცხრილის პოზიციას. სპეციალური წონის ღირებულება არ ვიცი ნიშნავს, რომ სიმბოლო იგნორირებულია შედარების შესაბამის დონეზე.

სასწორის სტრუქტურის დემონსტრირებისთვის მე ავირჩიე სამი საკმაოდ აშკარა ფრაგმენტი:

• პერსონაჟები, რომლებიც სრულიად იგნორირებულია
• პირველი ორი დონის სამი რიცხვის ექვივალენტური სიმბოლოები
• კირიული ანბანის დასაწყისი, რომელიც არ შეიცავს დიაკრიტიკას და, შესაბამისად, დალაგებულია ძირითადად პირველი და მესამე დონის მიხედვით.

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'
};

ვინაიდან უნიკოდში კოდის წერტილი Ё მოდის A-მდე, სტრიქონები დალაგებულია შესაბამისად.

ტექსტური და ორობითი ცხრილები

ცხადია, სტრიქონების შედარება ძალზე გავრცელებული ოპერაციაა და ცხრილის ანალიზი CTT საკმაოდ ძვირადღირებული პროცედურა. ცხრილზე წვდომის ოპტიმიზაციის მიზნით, იგი ფორმდება ორობით ფორმაში ბრძანებით ლოკალდეფი.

გუნდი ლოკალდეფი პარამეტრებად იღებს ფაილს ეროვნული მახასიათებლების ცხრილით (ვარიანტი -i), რომელშიც ყველა სიმბოლო წარმოდგენილია უნიკოდის წერტილებით და უნიკოდის წერტილებსა და კონკრეტული კოდირების სიმბოლოებს შორის შესაბამისობის ფაილი (ვარიანტი -f). სამუშაოს შედეგად იქმნება ბინარული ფაილები ლოკალისთვის ბოლო პარამეტრში მითითებული სახელით.

გლიბცი მხარს უჭერს ორ ბინარული ფაილის ფორმატს: "ტრადიციული" და "თანამედროვე".

ტრადიციული ფორმატი ნიშნავს, რომ ლოკალის სახელი არის ქვედირექტორიის სახელი /usr/lib/locale/. ეს ქვეცნობარი ინახავს ორობით ფაილებს LC_COLLATE, LC_CTYPE, LC_TIME და ასე შემდეგ. ფაილი LC_IDENTIFICATION შეიცავს ლოკალის ოფიციალურ სახელს (რომელიც შეიძლება განსხვავდებოდეს დირექტორიას სახელისგან) და კომენტარებს.

თანამედროვე ფორმატი გულისხმობს ყველა ლოკალის ერთ არქივში შენახვას /usr/lib/locale/locale-archive, რომელიც ასახულია ყველა პროცესის ვირტუალურ მეხსიერებაში, რომლებიც გამოიყენება glibc. ლოკალური სახელწოდება თანამედროვე ფორმატში ექვემდებარება გარკვეულ კანონიზაციას - კოდირების სახელებში რჩება მხოლოდ მცირე ასოებით შემცირებული რიცხვები და ასოები. Ისე ru_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 სახელის ქვეშ ru_RU.მაკირილის

თუ დააყენეთ ცვლადი LANG = ge_US.UTF-8 რომ glibc მოძებნის ლოკალური ორობითი ფაილების და დირექტორიების შემდეგი თანმიმდევრობით:

/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.

საკუთარი დახარისხების ცხრილის მომზადების პროცესი შედგება ორი ეტაპისგან: წონების ცხრილის რედაქტირება და მისი ორობითი ფორმით შედგენა ბრძანებით. ლოკალდეფი.

იმისათვის, რომ შედარების ცხრილი მორგებული იყოს მინიმალური რედაქტირების ხარჯებით, ფორმატში ISO 14652 მოწოდებულია არსებული ცხრილის წონების კორექტირების სექციები. განყოფილება იწყება საკვანძო სიტყვით ხელახლა შეკვეთა-შემდეგ და მიუთითებს პოზიციაზე, რომლის შემდეგაც ხდება ჩანაცვლება. განყოფილება მთავრდება ხაზით ხელახლა შეკვეთა-დასრულება. თუ საჭიროა ცხრილის რამდენიმე მონაკვეთის გასწორება, მაშინ თითოეული ასეთი განყოფილებისთვის იქმნება განყოფილება.

მე დავაკოპირე ფაილების ახალი ვერსიები iso14651_t1_common и ru_RU საცავიდან glibc ჩემს მთავარ დირექტორიაში ~/.local/share/i18n/locales/ და ოდნავ შეცვალე განყოფილება LC_COLLATE в ru_RU. ფაილების ახალი ვერსიები სრულად თავსებადია ჩემს ვერსიასთან glibc. თუ გსურთ გამოიყენოთ ფაილების ძველი ვერსიები, მოგიწევთ ცხრილში სიმბოლური სახელების და ჩანაცვლების დაწყების ადგილის შეცვლა.

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_IDENTIFICATION ისე, რომ ისინი მიუთითებენ ლოკალზე ru_MY, მაგრამ ჩემს მაგალითში ეს არ იყო საჭირო, რადგან მე გამოვრიცხე არქივი ლოკალების ძიებიდან ლოკალი-არქივი.

რომ ლოკალდეფი მუშაობდა ჩემს საქაღალდეში არსებულ ფაილებთან ცვლადის საშუალებით I18NPATH თქვენ შეგიძლიათ დაამატოთ დამატებითი დირექტორია შეყვანის ფაილების მოსაძებნად, ხოლო ორობითი ფაილების შესანახი დირექტორია შეიძლება იყოს მითითებული, როგორც გზა დახრილებით:

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

POSIX ვარაუდობს, რომ ში ᲔᲜᲐ თქვენ შეგიძლიათ დაწეროთ აბსოლუტური ბილიკები დირექტორიაში ლოკალური ფაილებით, დაწყებული წინ დახრილობით, მაგრამ glibc в Linux ყველა ბილიკი დათვლილია საბაზისო დირექტორიადან, რომლის გადაფარვა შესაძლებელია ცვლადის მეშვეობით ლოკპათი. ინსტალაციის შემდეგ LOCPATH=~/.local/lib/locale/ ლოკალიზაციასთან დაკავშირებული ყველა ფაილი მოიძებნება მხოლოდ ჩემს საქაღალდეში. ლოკალების არქივი ცვლადის ნაკრებით ლოკპათი უგულებელყო.

აქ არის გადამწყვეტი ტესტი:

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

ჰოო! Ჩვენ ეს შევძელით!

ზოგიერთი შეცდომები

მე უკვე ვუპასუხე დასაწყისში დასმულ კითხვებს სტრიქონების დახარისხებასთან დაკავშირებით, მაგრამ ჯერ კიდევ არის რამდენიმე კითხვა შეცდომებთან დაკავშირებით - ხილული და უხილავი.

დავუბრუნდეთ საწყის პრობლემას.

და პროგრამა სახის და პროგრამა შეუერთდება გამოიყენეთ იგივე სტრიქონების შედარების ფუნქციები glibc. როგორ მოხდა ეს შეუერთდება ბრძანებით დალაგებულ მწკრივებზე დალაგების შეცდომა მისცა სახის ლოკალში en_US.UTF-8? პასუხი მარტივია: სახის ადარებს მთელ სტრიქონს და შეუერთდება ადარებს მხოლოდ კლავიშს, რომელიც ნაგულისხმევად არის სტრიქონის დასაწყისი პირველ სივრცემდე სიმბოლომდე. ჩემს მაგალითში, ამან გამოიწვია შეცდომის შეტყობინება, რადგან სტრიქონებში პირველი სიტყვების დახარისხება არ ემთხვეოდა სრული ხაზების დახარისხებას.

ლოკალი "C" გარანტიას იძლევა, რომ დალაგებულ სტრიქონებში ასევე დალაგდება საწყისი ქვესტრიქონები პირველ სივრცემდე, მაგრამ ეს მხოლოდ ფარავს შეცდომას. შესაძლებელია ისეთი მონაცემების არჩევა (ადამიანები ერთი და იგივე გვარით, მაგრამ განსხვავებული სახელით), რომლებიც შეცდომის შეტყობინების გარეშე მისცემს არასწორი ფაილის შერწყმის შედეგს. თუ გვინდა შეუერთდება ფაილის ხაზების გაერთიანება სრული სახელით, მაშინ სწორი გზა იქნება ველის გამყოფის ცალსახად მითითება და დახარისხება გასაღების ველის მიხედვით და არა მთელი ხაზის მიხედვით. ამ შემთხვევაში, შერწყმა გაგრძელდება სწორად და არ იქნება შეცდომები არცერთ ლოკალში:

$> 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 პაკეტებს აკლია კომპილირებული ლოკალი ru_RU.CP1251. თუ შედგენილი ლოკალი ვერ მოიძებნა, მაშინ სახის ჩუმად იყენებს ბაიტი-ბაიტი შედარებას, რასაც ჩვენ დავაკვირდით.

სხვათა შორის, არის კიდევ ერთი პატარა ხარვეზი, რომელიც დაკავშირებულია შედგენილი ლოკალების მიუწვდომელობასთან. გუნდი LOCPATH=/tmp ლოკალი -ა მოგცემთ ყველა ლოკალის ჩამონათვალს ლოკალი-არქივი, მაგრამ ცვლადი ნაკრებით ლოკპათი ყველა პროგრამისთვის (მათ შორის ყველაზე მეტად ადგილობრივი) ეს ლოკალები არ იქნება ხელმისაწვდომი.

$> 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 გამოაქვს ფაილები დაწყებული წერტილით შერეული ასოებით დაწყებული ფაილებით და შუაღამის სარდალი, რომელიც იყენებს თავის შიდა ფუნქციებს სახელების დასალაგებლად, სიის დასაწყისში აყენებს წერტილებით დაწყებულ ფაილებს.

ლიტერატურა

მოხსენება No. 10 უნიკოდის შედარების ალგორითმი

სიმბოლოების წონა unicode.org-ზე

ICU — ბიბლიოთეკის დანერგვა Unicode-თან მუშაობისთვის IBM-დან.

დახარისხება ტესტის გამოყენებით ICU

სიმბოლოების წონა ISO 14651

ფაილის ფორმატის აღწერა მასშტაბებით ISO 14652

სიმებიანი შედარების განხილვა glibc

წყარო: www.habr.com