تعارف

اهو سڀ ڪجهه هڪ مختصر اسڪرپٽ سان شروع ٿيو جنهن کي ايڊريس جي معلومات کي گڏ ڪرڻ گهرجي اي ميل ميلنگ لسٽ استعمال ڪندڙن جي لسٽ مان حاصل ڪيل ملازم، HR کاتي جي ڊيٽابيس مان حاصل ڪيل ملازمن جي پوزيشن سان. ٻئي لسٽون يونيڪوڊ ٽيڪسٽ فائلن ڏانهن برآمد ڪيون ويون UTF-8 ۽ يونڪس لائن جي آخر سان محفوظ ڪيو ويو.

مواد mail.txt

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

مواد buhg.txt

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

ضم ڪرڻ لاءِ، فائلن کي يونڪس ڪمانڊ ذريعي ترتيب ڏنو ويو ترتيب ڏيو ۽ يونڪس پروگرام جي ان پٽ تي جمع ڪرايو شامل ٿيو، جيڪو غير متوقع طور تي هڪ غلطي سان ناڪام ٿيو:

$> 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
Абаканов Михаил;маляр
Ёлкина Элла;крановщица
Иванова Алла;маляр
Иванов Андрей;слесарь

يونيڪوڊ ۾ هڪ ترتيب جي خرابي وانگر يا ترتيب ڏيڻ واري الگورتھم ۾ فيمينزم جي مظهر وانگر. پهرين، يقينا، وڌيڪ ممڪن آهي.

اچو ته ان کي في الحال بند ڪريون شامل ٿيو ۽ ڌيان ڏيڻ ترتيب ڏيو. اچو ته ان مسئلي کي سائنسي طريقي سان حل ڪرڻ جي ڪوشش ڪريون. پهرين، اچو ته مقامي کان تبديل ڪريون 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

ٻيهر ڪجھ به نه بدليو آهي.

هتي ڪجھ به ناهي جيڪو توهان ڪري سگهو ٿا، توهان کي انٽرنيٽ تي حل ڳولڻو پوندو. روسي نالن جي باري ۾ سڌو سنئون ڪجھ به نه آهي، پر ٻين ترتيبن جي باري ۾ سوال آهن. مثال طور، هتي هڪ مسئلو آهي: يونڪس ترتيب '-' (ڊيش) اکرن کي پوشيده طور تي علاج ڪري ٿو. مختصر ۾، "a-b"، "aa"، "ac" کي "aa"، "a-b"، "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

اهو بغير ڪنهن غلطي جي ڪم ڪيو، جيئن انٽرنيٽ انجام ڏنو. ۽ اها پهرين قطار ۾ يوڪينا جي باوجود.

مسئلو حل ٿيڻ لڳي ٿو، پر صرف صورت ۾، اچو ته ڪوشش ڪريون ٻي روسي انڪوڊنگ - ونڊوز سيڪسڪسينٽ:

$> 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 = سي
ڇو ڪيو ترتيب ڏيو и شامل ٿيو ترتيب ڏنل تارن جي ترتيب بابت مختلف خيالات
منهنجي سڀني مثالن ۾ غلطيون ڇو آهن؟
آخرڪار توهان جي پسند جي تارن کي ڪيئن ترتيب ڏيو

يونيڪوڊ ۾ ترتيب ڏيڻ

پهريون اسٽاپ ٽيڪنيڪل رپورٽ نمبر 10 جو حقدار هوندو يونيڪوڊ ڪوليشن الگورتھم آن لائن unicode.org. رپورٽ ۾ تمام گهڻو فني تفصيل شامل آهي، تنهنڪري مون کي بنيادي خيالن جو مختصر خلاصو ڏيان ٿو.

ڪوليشن - "مقابلي" اسٽرنگ ڪنهن به ترتيب ڏيڻ واري الگورتھم جو بنياد آهي. الگورٿم پاڻ ۾ مختلف ٿي سگهن ٿا ("بلبل"، "ضم"، "تيز")، پر اهي سڀئي تارن جي هڪ جوڙي جي مقابلي کي استعمال ڪندا ته جيئن اهي ظاهر ٿين.

قدرتي ٻولي ۾ تارن کي ترتيب ڏيڻ هڪ تمام پيچيده مسئلو آهي. ايستائين جو آسان ترين سنگل بائيٽ انڪوڊنگ ۾، الفابيٽ ۾ اکرن جي ترتيب، جيتوڻيڪ انگريزي لاطيني الفابيٽ کان ڪجھ مختلف طريقي سان، ھاڻي عددي قدرن جي ترتيب سان ٺھيل نه ٿيندي، جن سان اھي اکر انڪوڊ ٿيل آھن. تنهنڪري جرمن الفابيٽ ۾ خط Ö وچ ۾ بيٺو آهي О и P، ۽ انڪوڊنگ ۾ سيڪسڪسينٽ هوءَ وچ ۾ اچي ٿي ÿ и Ü.

توھان ڪوشش ڪري سگھوٿا ھڪڙي مخصوص انڪوڊنگ کان خلاصو ۽ غور ڪريو ”مثالي“ اکر جيڪي ڪنھن ترتيب سان ترتيب ڏنل آھن، جيئن يونيڪوڊ ۾ ڪيو ويو آھي. انڪوڊنگ UTF8, UTF16 يا هڪ بائيٽ KOI8-R (جيڪڏهن يونيڪوڊ جو هڪ محدود ذيلي سيٽ گهربل هجي) مختلف انگن اکرن جي نمائندگي ڏيندو، پر بنيادي جدول جي ساڳين عناصر ڏانهن اشارو ڪيو.

اهو ظاهر ٿئي ٿو ته جيتوڻيڪ اسان شروع کان هڪ علامتي جدول ٺاهي سگهون ٿا، اسان ان کي هڪ آفاقي علامت ترتيب ڏيڻ جي قابل نه هوندا. مختلف قومي الفابيٽ ۾ جيڪي ساڳيا اکر استعمال ڪن ٿا، انهن اکرن جي ترتيب مختلف ٿي سگهي ٿي. مثال طور، فرانسيسي ۾ Æ هڪ ligature سمجهيو ويندو ۽ هڪ تار طور ترتيب ڏنو ويندو AE. نارويجي ۾ Æ هڪ الڳ خط هوندو، جيڪو بعد ۾ واقع آهي Z. رستي جي ذريعي، جهڙوڪ ligatures کان علاوه Æ ڪيترن ئي نشانين سان لکيل اکر آهن. تنهنڪري چيڪ الفابيٽ ۾ هڪ اکر آهي Ch، جيڪو وچ ۾ بيٺو آهي H и I.

الفابيٽ ۾ اختلافن کان علاوه، ٻيون به قومي روايتون آهن جيڪي ترتيب ڏيڻ تي اثر انداز ٿين ٿيون. خاص طور تي، سوال پيدا ٿئي ٿو ته: ڊڪشنري ۾ وڏن ۽ ننڍن اکرن تي مشتمل لفظن کي ڪهڙي ترتيب ۾ ظاهر ٿيڻ گهرجي؟ ترتيب ڏيڻ پڻ متاثر ٿي سگھي ٿو اوقاف جي نشانين جي استعمال سان. اسپينش ۾، هڪ سواليه نشان استعمال ڪيو ويندو آهي سوال جي جملي جي شروعات ۾ (ڇا توھان کي موسيقي پسند آھي؟). ان صورت ۾، اهو ظاهر آهي ته سوالي جملن کي الفابيٽ کان ٻاهر هڪ الڳ ڪلستر ۾ گروپ نه ڪيو وڃي، پر ٻين اوقاف جي نشانين سان لائينون ڪيئن ترتيب ڏيو؟

مان يورپي ٻولين کان بلڪل مختلف ٻولين ۾ تارن کي ترتيب ڏيڻ تي ڌيان نه ڏيندس. ياد رهي ته ٻولين ۾ ساڄي کان کاٻي يا مٿي کان هيٺ لکڻ جي هدايتن ۾، لڪير ۾ اکر گهڻو ڪري پڙهڻ جي ترتيب ۾ محفوظ ڪيا ويندا آهن، ۽ جيتوڻيڪ غير الفابيٽ واري لکت واري نظام کي ترتيب ڏيڻ جا پنهنجا طريقا آهن. . مثال طور، hieroglyphs انداز سان ترتيب ڏئي سگهجي ٿو (چيني اکرن جي ڪنجيون) يا تلفظ سان. ايماندار ٿيڻ لاءِ ، مون کي ڪا خبر ناهي ته ايموجيز کي ڪيئن ترتيب ڏنو وڃي ، پر توهان انهن لاءِ پڻ ڪجهه وٺي سگهو ٿا.

مٿي ڏنل خصوصيتن جي بنياد تي، يونيڪوڊ جدولن جي بنياد تي تارن جي مقابلي لاءِ بنيادي ضرورتون ٺھيل ھيون:

تارن جو مقابلو ڪوڊ ٽيبل ۾ ڪردارن جي پوزيشن تي منحصر نه آهي؛
ھڪڙي اکرن کي ٺاھيندڙ اکرن جي تسلسل کي معياري شڪل ۾ گھٽايو ويو آھي (A + مٿي جو دائرو ساڳيو آهي Å);
تارن جو مقابلو ڪرڻ وقت، هڪ ڪردار کي اسٽرنگ جي حوالي سان سمجهيو ويندو آهي ۽، جيڪڏهن ضروري هجي ته، ان جي پاڙيسرين سان گڏ هڪ يونٽ جي مقابلي ۾ (Ch چيڪ ۾) يا ڪيترن ۾ ورهايل آهي (Æ فرانسيسي ۾)؛
سڀئي قومي خاصيتون (الف بيٽ، اپر اڪيس/لوئر اڪيز، اوقاف، لکڻ جي قسمن جو ترتيب) لازمي طور تي ترتيب ڏنل حڪم جي مينوئل اسائنمينٽ تائين (ايموجي)؛
مقابلو نه صرف ترتيب ڏيڻ لاءِ، پر ٻين ڪيترن ئي هنڌن تي پڻ، مثال طور قطار جي حدن کي بيان ڪرڻ لاءِ ({A... z} کي متبادل ڪرڻ ڪشادو);
مقابلو تيزيءَ سان ٿيڻ گهرجي.

ان کان علاوه، رپورٽ جي ليکڪن جي مقابلي جي ملڪيت ٺاهيا آهن جيڪي الگورتھم ڊولپرز تي ڀروسو نه ڪرڻ گهرجي:

مقابلي واري الگورٿم کي هر ٻوليءَ لاءِ اکرن جي الڳ سيٽ جي ضرورت نه هئڻ گهرجي (روسي ۽ يوڪريني ٻوليون اڪثر سيريلڪ اکر شيئر ڪن ٿيون)؛
مقابلي کي يونيڪوڊ جدولن ۾ ڪردارن جي ترتيب تي ڀروسو نه ڪرڻ گهرجي؛
اسٽرنگ جو وزن اسٽرنگ جي خاصيت نه هجڻ گهرجي، ڇاڪاڻ ته مختلف ثقافتي حوالن ۾ هڪ ئي تار جا مختلف وزن ٿي سگهن ٿا.
قطار جو وزن تبديل ٿي سگھي ٿو جڏهن ضم ٿيڻ يا ورهائڻ (کان x < y اهو ان جي پيروي نٿو ڪري xz < yz);
هڪجهڙا وزن رکندڙ مختلف تارن کي ترتيب ڏيڻ واري الگورتھم جي نقطي نظر کان برابر سمجهيو وڃي ٿو. اهڙين تارن جي اضافي ترتيب کي متعارف ڪرائڻ ممڪن آهي، پر اهو ڪارڪردگي کي خراب ڪري سگهي ٿو؛
بار بار ترتيب ڏيڻ دوران، ساڳئي وزن سان قطار کي تبديل ڪري سگھجي ٿو. مضبوطي هڪ خاص ترتيب ڏيڻ واري الگورٿم جي ملڪيت آهي، ۽ هڪ اسٽرنگ مقابلي واري الگورتھم جي ملڪيت نه آهي (ڏسو پوئين پيراگراف)؛
ترتيب ڏيڻ جا ضابطا وقت سان گڏ تبديل ٿي سگهن ٿا جيئن ثقافتي روايتون سڌارڻ/تبديل ٿين ٿيون.

اهو پڻ طئي ڪيو ويو آهي ته مقابلي واري الگورتھم کي پروسيس ٿيڻ واري تارن جي سيمينٽڪس بابت ڪجھ به نه ڄاڻندو آهي. اهڙيء طرح، صرف انگن تي مشتمل اسٽرنگ کي انگن سان مقابلو نه ڪيو وڃي، ۽ انگريزي نالن جي فهرستن ۾ آرٽيڪل (بيٽلس، دي).

سڀني مخصوص گهرجن کي پورو ڪرڻ لاء، هڪ گھڻ-سطح (اصل ۾ چار-سطح) ٽيبل ترتيب ڏيڻ وارو الگورتھم تجويز ڪيو ويو آهي.

اڳي، اسٽرنگ ۾ ڪردارن کي معياري شڪل ۾ گھٽايو ويو آھي ۽ مقابلي جي يونٽن ۾ گروپ ڪيو ويو آھي. مقابلي جي هر يونٽ کي ڪيترن ئي وزنن جي مقابلي جي ڪيترن ئي سطحن سان لاڳاپيل آهي. مقابلي جي يونٽن جا وزن آرڊر ٿيل سيٽن جا عنصر آھن (ھن صورت ۾، انٽيجرز) جن کي وڌيڪ يا گھٽ لاءِ مقابلو ڪري سگھجي ٿو. خاص معنيٰ نظر انداز ڪيو ويو (0x0) مطلب ته ساڳئي مقابلي واري سطح تي هي يونٽ مقابلي ۾ شامل ناهي. تارن جي مقابلي کي ڪيترائي ڀيرا ورجائي سگھجي ٿو، لاڳاپيل سطحن جي وزن کي استعمال ڪندي. هر سطح تي، ٻن قطارن جي مقابلي واري يونٽن جي وزن کي ترتيب سان هڪ ٻئي سان مقابلو ڪيو ويندو آهي.

مختلف قومي روايتن لاءِ الگورٿم جي مختلف عملن ۾، ڪوئفيڪٽن جا قدر مختلف ٿي سگهن ٿا، پر يونيڪوڊ معيار ۾ وزن جي بنيادي جدول شامل آهي. "ڊفالٽ يونيڪوڊ ڪوليشن عنصر ٽيبل" (DUCET). مان نوٽ ڪرڻ چاهيان ٿو ته متغير کي ترتيب ڏيو LC_COLLATE اصل ۾ اسٽرنگ جي مقابلي واري فنڪشن ۾ وزن جي ٽيبل جي چونڊ جو اشارو آهي.

وزن جي کوٽائي DUCET هيٺ ڏنل ترتيب ڏنل:

پهرين سطح تي، سڀئي اکر ساڳي صورت ۾ گهٽجي ويا آهن، ڊائريڪٽڪس رد ڪيا ويا آهن، اوقاف جا نشان (سڀ نه) نظر انداز ڪيا ويا آهن؛
ٻئي سطح تي، صرف diacritics حساب ۾ ورتو وڃي ٿو؛
ٽئين سطح تي، صرف ڪيس ۾ ورتو وڃي ٿو؛
چوٿين سطح تي، صرف اوقاف جي نشانين کي حساب ۾ ورتو وڃي ٿو.

مقابلو ڪيترن ئي پاسن ۾ ٿئي ٿو: پهريون، پهرين سطح جي کوٽائي جو مقابلو ڪيو ويو آهي؛ جيڪڏهن وزن هڪجهڙائي سان ٺهڪي اچي ٿي، ته پوء ٻي سطح جي وزن سان بار بار مقابلو ڪيو ويندو آهي؛ پوءِ شايد ٽيون ۽ چوٿون.

مقابلو ختم ٿئي ٿو جڏهن قطار ۾ مختلف وزنن جي مقابلي ۾ ملندڙ يونٽ شامل آهن. اهي قطارون جن جو وزن چئن سطحن تي برابر هجي، انهن کي هڪ ٻئي جي برابر سمجهيو وڃي ٿو.

هي الگورٿم (اضافي ٽيڪنيڪل تفصيلن جي هڪ گروپ سان) رپورٽ نمبر 10 جو نالو ڏنو - "يونيڪوڊ ڪوليشن الگورٿم" (يو سي).

هي آهي جتي اسان جي مثال کان ترتيب ڏيڻ وارو رويو ٿورو واضح ٿي وڃي ٿو. اهو سٺو لڳندو ته ان کي يونيڪوڊ معيار سان ڀيٽيو.

عمل جي جانچ ڪرڻ لاء يو سي اتي هڪ خاص آهي امتحان، استعمال ڪندي وزن فائل، لاڳو ڪرڻ DUCET. توهان اسڪيل فائل ۾ سڀني قسمن جون عجيب شيون ڳولي سگهو ٿا. مثال طور، مهجونگ ۽ يورپي ڊومينو جو حڪم آهي، انهي سان گڏ ڪارڊ جي ڊيڪ ۾ سوٽ جو حڪم (علامت 1F000 ۽ اڳتي). ڪارڊ سوٽ پل - PCBT جي ضابطن جي مطابق رکيا ويا آهن، ۽ سوٽ ۾ ڪارڊ ترتيب ڏنل آهن T، 2,3، XNUMX... K.

دستي طور تي چيڪ ڪريو ته قطارون صحيح ترتيب سان ترتيب ڏنل آهن DUCET ڪافي ڏکوئيندڙ هوندو، پر، خوشقسمتيءَ سان اسان لاءِ، يونيڪوڊ سان ڪم ڪرڻ لاءِ لائبريريءَ جو مثالي نفاذ موجود آهي - "يونيڪوڊ لاءِ بين الاقوامي اجزاء"(اي سي يو).

هن لائبريري جي ويب سائيٽ تي، ۾ ترقي ڪئي IBM، ڊيمو صفحا آهن، بشمول string comparison algorithm صفحو. اسان پنھنجي ٽيسٽ لائينن کي ڊفالٽ سيٽنگن سان داخل ڪريون ٿا، ۽ ڏسو، اسان کي مڪمل روسي ترتيب ملي ٿي.

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

رستي ۾، ويب سائيٽ اي سي يو توهان ڳولهي سگهو ٿا هڪ وضاحت جي مقابلي واري الگورتھم جي جڏهن پروسيسنگ اوقاف جي نشانين کي. مثالن ۾ ڪوليشن FAQ apostrophe ۽ hyphen کي نظرانداز ڪيو ويو آهي.

يونيڪوڊ اسان جي مدد ڪئي، پر عجيب رويي جا سبب ڳوليو ترتيب ڏيو в لينڪس ڪنهن ٻئي هنڌ وڃڻو پوندو.

glibc ۾ ترتيب ڏيڻ

يوٽيلٽي سورس ڪوڊز جو تڪڙو ڏيک ترتيب ڏيو کان GNU بنيادي استعمال ڏيکاريو ويو آهي ته يوٽيلٽيءَ ۾ ئي، لوڪلائيزيشن هيٺ اچي ٿي ته متغير جي موجوده قيمت کي ڇپائي LC_COLLATE جڏهن ڊيبگ موڊ ۾ هلندي:

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

اسٽرنگ جي مقابلي کي معياري فنڪشن استعمال ڪندي ڪيو ويندو آهي strcoll، جنهن جو مطلب آهي هر شيءِ دلچسپ لائبريري ۾ آهي چمڪندڙ.

تي رڪن منصوبو چمڪندڙ تارن جي مقابلي لاءِ وقف هڪ پيراگراف. هن پيراگراف مان سمجهي سگهجي ٿو ته ان ۾ چمڪندڙ ترتيب ڏيڻ هڪ الگورٿم تي ٻڌل آهي جيڪو اسان کي اڳ ۾ ئي معلوم آهي يو سي (يونيڪوڊ ڪوليشن الگورٿم) ۽/يا ان جي ويجهو معيار تي مذهبي پابنديون لاڳو 14651 (بين الاقوامي اسٽرنگ آرڊرنگ ۽ مقابلو). جديد معيار جي حوالي سان، اهو ياد رکڻ گهرجي ته سائيٽ تي standards.iso.org مذهبي پابنديون لاڳو 14651 سرڪاري طور تي عوامي طور تي دستياب قرار ڏنو ويو آهي، پر لاڳاپيل لنڪ هڪ غير موجود صفحي ڏانهن وڃي ٿي. گوگل ڪيترن ئي صفحن کي واپس ڪري ٿو سرڪاري سائيٽن جي لنڪ سان جيڪي هڪ سئو يورو جي معيار جي اليڪٽرانڪ ڪاپي خريد ڪرڻ جي آڇ ڪن ٿا، پر ڳولا جي نتيجن جي ٽئين يا چوٿين صفحي تي پڻ سڌو لنڪ آهن. ڪر PDF. عام طور تي، معيار عملي طور تي مختلف ناهي يو سي، پر پڙهڻ لاءِ وڌيڪ بورنگ آهي ڇو ته ان ۾ تارن جي ترتيب جي قومي خاصيتن جا واضح مثال شامل نه آهن.

تي سڀ کان وڌيڪ دلچسپ معلومات رڪن جي لنڪ هئي بگ ٽريڪر ۾ string comparison جي عمل درآمد جي بحث سان چمڪندڙ. بحث مان اهو معلوم ڪري سگهجي ٿو ته چمڪندڙ تارن جي ڀيٽ ڪرڻ لاءِ استعمال ڪيو ويو اوذاتي ٽيبل عام ٽيمپليٽ ٽيبل (سي ٽي ٽي)، جنهن جو پتو ايپليڪيشن ۾ ملي سگهي ٿو A معياري مذهبي پابنديون لاڳو 14651. 2000 ۽ 2015 جي وچ ۾ هن جدول ۾ چمڪندڙ وٽن سنڀاليندڙ نه هو ۽ معيار جي موجوده ورزن کان بلڪل مختلف (گهٽ ۾ گهٽ ٻاهرئين) هو. 2015 کان 2018 تائين، جدول جي نئين نسخي جي موافقت ڪئي وئي، ۽ ھاڻي توھان وٽ ھڪڙو موقعو آھي حقيقي زندگي ۾ ملڻ جو ھڪڙو نئون نسخو ٽيبل (CentOS 8)، ۽ پراڻي (CentOS 7).

ھاڻي ته اسان وٽ الورورٿم ۽ معاون جدولن جي باري ۾ سڀ معلومات آھي، اسان اصل مسئلي ڏانھن موٽي سگھون ٿا ۽ سمجھي سگھون ٿا ته ڪيئن صحيح طريقي سان روسي لوڪل ۾ تارن کي ترتيب ڏيو.

ISO 14651 / 14652

جدول جو ماخذ ڪوڊ جنهن ۾ اسان دلچسپي رکون ٿا سي ٽي ٽي اڪثر تقسيم تي لينڪس فهرست ۾ آهي /usr/share/i18n/locales/. ٽيبل پاڻ فائل ۾ آهي iso14651_t1_common. پوء هي فائل هدايت آهي ڪاپي iso14651_t1_common فائل ۾ شامل iso14651_t1، جيڪو، موڙ ۾، قومي فائلن ۾ شامل ڪيو ويو آهي، بشمول en_US и ru_RU. اڪثر تقسيم تي لينڪس سڀ ماخذ فائلون بنيادي تنصيب ۾ شامل آهن، پر جيڪڏهن اهي موجود نه آهن، توهان کي تقسيم کان هڪ اضافي پيڪيج انسٽال ڪرڻو پوندو.

فائل جي جوڙجڪ iso14651_t1 نالن جي تعمير لاءِ غير واضع قاعدن سان گڏ، خوفناڪ لفظي لڳي سگھي ٿو، پر جيڪڏھن توھان ان کي ڏسو، سڀ ڪجھ بلڪل سادو آھي. جوڙجڪ معيار ۾ بيان ڪيو ويو آهي مذهبي پابنديون لاڳو 14652، جنهن جي هڪ ڪاپي ويب سائيٽ تان ڊائون لوڊ ڪري سگهجي ٿي open-std.org. فائل فارميٽ جي ٻي وضاحت پڙهي سگهجي ٿي وضاحتون POSIX от اوپن گروپ. معياري پڙهڻ جي متبادل جي طور تي، توهان پڙهي سگهو ٿا فنڪشن جو سورس ڪوڊ collate_read в glibc/locale/programs/ld-collate.c.

فائل جي جوڙجڪ هن طرح ڏسڻ ۾ اچي ٿي:

ڊفالٽ طور، ڪردار هڪ فرار ڪردار طور استعمال ڪيو ويندو آهي، ۽ # ڪردار کان پوء لڪير جي آخر ۾ هڪ تبصرو آهي. ٻنهي نشانين کي ٻيهر بيان ڪري سگهجي ٿو، جيڪو ڇا ڪيو ويو آهي ٽيبل جي نئين نسخي ۾:

escape_char /
comment_char %

فائل فارميٽ ۾ ٽوڪن تي مشتمل هوندي يا (ڪٿي x - hexadecimal digit). هي انڪوڊنگ ۾ يونيڪوڊ ڪوڊ پوائنٽس جي هيڪساڊيڪل نمائندگي آهي UCS-4 (UTF-32). ٻيا سڀئي عنصر زاويه بریکٹ ۾ (بشمول , <2> ۽ جھڙوڪ) سمجھيا ويندا آھن سادو اسٽرنگ مستقل آھن جن جي معنيٰ کان ٻاھر آھي.

لڪير LC_COLLATE اسان کي ٻڌائي ٿو ته اڳيون ڊيٽا شروع ٿئي ٿو جيڪو تارن جي مقابلي کي بيان ڪري ٿو.

پهريون، نالن جي مقابلي واري جدول ۾ وزنن لاءِ ۽ علامتن جي مجموعن جا نالا بيان ڪيا ويا آهن. عام طور تي، ٻن قسمن جا نالا ٻن مختلف ادارن سان تعلق رکن ٿا، پر اصل فائل ۾ اهي ملايا ويندا آهن. وزن جا نالا لفظ جي ذريعي بيان ڪيا ويا آهن گڏ ڪرڻ- علامت (مقابلي وارو ڪردار) ڇاڪاڻ ته جڏهن مقابلو ڪيو وڃي ٿو، يونيڪوڊ اکر جيڪي ساڳيا وزن آهن انهن کي برابر ڪردار سمجهيو ويندو.

موجوده فائل جي نظرثاني ۾ سيڪشن جي ڪل ڊيگهه اٽڪل 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>"

colling-symbol هڪ تار کي لاگ ان ڪري ٿو آسمانيا ترازو جي نالن جي جدول ۾
colling-symbol .. نالن جو هڪ سلسلو رجسٽر ڪري ٿو جنهن ۾ هڪ اڳياڙي شامل آهي S and hexadecimal numeric suffix from 1D000 ڪرڻ 1D35F.
اي ايف ايف ايف в colling-symbol هيڪساڊيڪل ۾ هڪ وڏي غير دستخط ٿيل انٽيجر وانگر ڏسڻ ۾ اچي ٿو، پر اهو صرف هڪ نالو آهي جيڪو نظر اچي سگهي ٿو
نالو انڪوڊنگ ۾ ڪوڊ پوائنٽ جو مطلب آهي 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 کان اڳ اچي ٿو، تارن جي ترتيب مطابق ترتيب ڏنل آهي.

متن ۽ بائنري جدول

ظاهر آهي، اسٽرنگ جو مقابلو هڪ انتهائي عام آپريشن آهي، ۽ ٽيبل پارسنگ سي ٽي ٽي ڪافي قيمتي عمل. ٽيبل تائين پهچ کي بهتر ڪرڻ لاءِ، اهو ڪمانڊ سان گڏ بائنري فارم ۾ مرتب ڪيو ويو آهي localdef.

ٽيم localdef قومي خاصيتن جي جدول سان گڏ هڪ فائل کي پيرا ميٽر طور قبول ڪري ٿو (اختيار -i)، جنهن ۾ سڀني اکرن کي يونيڪوڊ ڊٽس ذريعي ظاھر ڪيو ويندو آھي، ۽ يونيڪوڊ ڊٽس ۽ ھڪڙي مخصوص انڪوڊنگ جي اکرن جي وچ ۾ خط و ڪتابت جي ھڪڙي فائل (اختيار -f). ڪم جي نتيجي ۾، بائنري فائلون ٺاهي وينديون آهن مقامي لاءِ آخري پيٽرولر ۾ ڏنل نالو سان.

گليبڪ ٻن بائنري فائل فارميٽ کي سپورٽ ڪري ٿو: "روايتي" ۽ "جديد".

روايتي فارميٽ جو مطلب آهي ته لوڪل جو نالو ان ۾ سب ڊاريڪٽري جو نالو آهي /usr/lib/locale/. هي ذيلي ڊاريڪٽري بائنري فائلن کي ذخيرو ڪري ٿي LC_COLLATE, LC_CTYPE, LC_TIME ۽ ايئن. فائل LC_IDENTIFICATION لوڪل جو رسمي نالو شامل آھي (جيڪو ڊاريڪٽري جي نالي کان مختلف ٿي سگھي ٿو) ۽ تبصرا.

جديد فارميٽ ۾ سڀني هنڌن کي هڪ آرڪائيو ۾ محفوظ ڪرڻ شامل آهي /usr/lib/locale/locale-archive، جيڪو استعمال ڪندي سڀني عملن جي ورچوئل ميموري ڏانهن نقشو ڪيو ويو آهي چمڪندڙ. جديد فارميٽ ۾ مقامي نالو ڪجهه ڪننائيزيشن سان مشروط آهي - صرف انگ ۽ اکرن کي گھٽ ۾ گھٽ ڪيو ويو انڪوڊنگ نالن ۾. سو ru_RU.KOI8-Rجي طور تي محفوظ ڪيو ويندو ru_RU.koi8r.

ان پٽ فائلون ڳولها آھن موجوده ڊاريڪٽري ۾، ۽ گڏوگڏ ڊائريڪٽرن ۾ /usr/share/i18n/locales/ и /usr/share/i18n/charmaps/ فائلن لاء سي ٽي ٽي ۽ انڪوڊنگ فائلون، ترتيب سان.

مثال طور، حڪم

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

جيڪڏهن ڪو علائقو روايتي ۽ جديد ٻنهي شڪلين ۾ ٿئي ٿو، ته پوءِ اوليت جديد کي ڏني وڃي ٿي.

توھان ڪمانڊ سان گڏ ڪيل جڳھن جي لسٽ ڏسي سگھو ٿا مڪلي -ا.

توھان جي مقابلي واري جدول تيار ڪرڻ

هاڻي، علم سان هٿياربند، توهان ٺاهي سگهو ٿا پنهنجو مثالي اسٽرنگ مقابلي واري ٽيبل. ھن جدول کي صحيح طور تي روسي اکر جو مقابلو ڪرڻ گھرجي، جنھن ۾ اکر Ё شامل آھي، ۽ ساڳئي وقت ھن جدول جي حساب سان اوقاف جي نشانين کي پڻ شامل ڪرڻ گھرجي. ASCII.

توھان جي پنھنجي ترتيب واري جدول کي تيار ڪرڻ جو عمل ٻن مرحلن تي مشتمل آھي: وزن جي جدول کي ايڊٽ ڪرڻ ۽ ان کي ڪمانڊ سان بائنري شڪل ۾ مرتب ڪرڻ localdef.

مقابلي واري جدول کي ترتيب ڏيڻ لاءِ گھٽ ۾ گھٽ ايڊيٽنگ جي خرچن سان، فارميٽ ۾ مذهبي پابنديون لاڳو 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_IDENTIFICATION ته جيئن اهي جڳهه ڏانهن اشارو ڪن ru_MY, پر منهنجي مثال ۾ اهو گهربل نه هو، ڇاڪاڻ ته مون آرڪائيو کي مقامي هنڌن جي ڳولا مان خارج ڪيو آهي مقامي-آرڪائيو.

ته localdef هڪ متغير ذريعي منهنجي فولڊر ۾ فائلن سان ڪم ڪيو I18NPATH توھان ان پٽ فائلن کي ڳولھڻ لاءِ اضافي ڊاريڪٽري شامل ڪري سگھو ٿا، ۽ بائنري فائلن کي محفوظ ڪرڻ لاءِ ڊاريڪٽري کي سليش سان رستي جي طور تي بيان ڪري سگھجي ٿو:

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

POSIX فرض ڪري ٿو ته ۾ لانگ توھان لکي سگھوٿا مطلق رستا ڊاريڪٽريز ڏانھن لوڪل فائلن سان، شروع ڪندي فارورڊ سليش سان، پر چمڪندڙ в لينڪس سڀ رستا بنيادي ڊاريڪٽري مان ڳڻيا ويا آھن، جيڪي ھڪڙي ويريبل ذريعي ختم ڪري سگھجن ٿيون LOCPATH. انسٽاليشن کان پوء LOCPATH=~/.local/lib/locale/ لوڪلائيزيشن سان لاڳاپيل سڀئي فائلون صرف منهنجي فولڊر ۾ ڳولي وينديون. variable سيٽ سان مقامي جڳهن جو آرڪائيو 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

انڪوڊنگ ۾ ڪاميابيءَ سان عمل ڪيو ويو مثال سيڪسڪسينٽ ٻي غلطي تي مشتمل آهي. حقيقت اها آهي ته مون کي ڄاڻايل سڀني تقسيم ۾ لينڪس پيڪيجز گڏ ٿيل لوڪل غائب آهن ru_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 فائلن کي آئوٽ ڪري ٿو جيڪو هڪ ڊٽ سان شروع ٿيندڙ فائلن سان گڏ هڪ خط سان شروع ٿئي ٿو، ۽ آڌي رات جو ڪمانڊر، جيڪو نالن کي ترتيب ڏيڻ لاءِ ان جي اندروني افعال کي استعمال ڪري ٿو، لسٽ جي شروعات ۾ ڊٽ سان شروع ٿيندڙ فائلن کي رکي ٿو.