ການນໍາສະເຫນີ

ມັນທັງຫມົດເລີ່ມຕົ້ນດ້ວຍ script ສັ້ນທີ່ຄາດວ່າຈະລວມຂໍ້ມູນທີ່ຢູ່ ອີເມລ໌ ພະນັກງານທີ່ໄດ້ຮັບຈາກບັນຊີລາຍຊື່ຂອງຜູ້ນໍາໃຊ້ບັນຊີລາຍຊື່ທາງໄປສະນີ, ມີຕໍາແຫນ່ງພະນັກງານທີ່ໄດ້ຮັບຈາກຖານຂໍ້ມູນຂອງພະແນກ 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 ຫຼືຄືກັບການສະແດງອອກຂອງຄວາມເປັນຜູ້ຍິງໃນລະບົບການຈັດຮຽງ. ທໍາອິດແມ່ນ, ແນ່ນອນ, ເປັນໄປໄດ້ຫຼາຍ.

ປ່ອຍໃຫ້ມັນໄປໃນຕອນນີ້ ເຂົ້າຮ່ວມ ແລະສຸມໃສ່ ການຈັດລຽງ. ໃຫ້ພະຍາຍາມແກ້ໄຂບັນຫາໂດຍໃຊ້ poking ວິທະຍາສາດ. ກ່ອນອື່ນ ໝົດ, ໃຫ້ປ່ຽນສະຖານທີ່ຈາກ ໃນສະຫະລັດ ສຸດ ru_RU. ເພື່ອຈັດຮຽງ, ມັນຈະພຽງພໍທີ່ຈະກໍານົດຕົວແປສະພາບແວດລ້ອມ LC_COLLATE, ແຕ່ພວກເຮົາຈະບໍ່ເສຍເວລາກັບ trifles:

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

ບໍ່ມີຫຍັງປ່ຽນແປງ.

ໃຫ້ພະຍາຍາມ recode ໄຟລ໌ເຂົ້າໄປໃນການເຂົ້າລະຫັດດຽວ byte:

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

ອີກເທື່ອຫນຶ່ງບໍ່ມີຫຍັງປ່ຽນແປງ.

ບໍ່ມີຫຍັງທີ່ທ່ານສາມາດເຮັດໄດ້, ທ່ານຈະຕ້ອງຊອກຫາວິທີແກ້ໄຂໃນອິນເຕີເນັດ. ບໍ່ມີຫຍັງໂດຍກົງກ່ຽວກັບນາມສະກຸນພາສາລັດເຊຍ, ແຕ່ມີຄໍາຖາມກ່ຽວກັບຄວາມແປກປະຫລາດການຈັດລຽງອື່ນໆ. ຕົວຢ່າງ, ນີ້ແມ່ນບັນຫາ: unix sort ປະຕິບັດຕໍ່ '-' (dash) ຕົວອັກສອນທີ່ເບິ່ງບໍ່ເຫັນ. ໃນສັ້ນ, ສາຍ "ab", "aa", "ac" ຖືກຈັດຮຽງເປັນ "aa", "ab", "ac".

ຄໍາຕອບແມ່ນມາດຕະຖານຢູ່ທົ່ວທຸກແຫ່ງ: ໃຊ້ທ້ອງຖິ່ນຂອງໂປແກມ "C" ແລະເຈົ້າຈະມີຄວາມສຸກ. ມາລອງເບິ່ງ:

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

ບາງສິ່ງບາງຢ່າງມີການປ່ຽນແປງ. Ivanovs ຈັດແຖວຢູ່ໃນລໍາດັບທີ່ຖືກຕ້ອງ, ເຖິງແມ່ນວ່າ Yolkina ເລື່ອນໄປບ່ອນໃດບ່ອນຫນຶ່ງ. ໃຫ້ກັບຄືນໄປຫາບັນຫາຕົ້ນສະບັບ:

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

ມັນເຮັດວຽກໂດຍບໍ່ມີຂໍ້ຜິດພາດ, ດັ່ງທີ່ອິນເຕີເນັດໄດ້ສັນຍາໄວ້. ແລະນີ້ເຖິງວ່າຈະມີ Yolkina ໃນແຖວທໍາອິດ.

ບັນຫາເບິ່ງຄືວ່າໄດ້ຮັບການແກ້ໄຂ, ແຕ່ໃນກໍລະນີ, ໃຫ້ລອງເຂົ້າລະຫັດພາສາລັດເຊຍອື່ນ - Windows CP1251:

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

ຜົນໄດ້ຮັບການຈັດລຽງ, oddly ພຽງພໍ, ຈະ coincide ກັບທ້ອງຖິ່ນ "C", ແລະຕົວຢ່າງທັງຫມົດ, ຕາມຄວາມເຫມາະສົມ, ດໍາເນີນການໂດຍບໍ່ມີຄວາມຜິດພາດ. ບາງປະເພດຂອງ mysticism.

ຂ້ອຍບໍ່ມັກ mysticism ໃນການຂຽນໂປລແກລມເພາະວ່າມັນມັກຈະປິດບັງຄວາມຜິດພາດ. ພວກເຮົາຈະຕ້ອງໄດ້ເບິ່ງຢ່າງຈິງຈັງວ່າມັນເຮັດວຽກແນວໃດ. ການຈັດລຽງ ແລະມັນມີຜົນກະທົບແນວໃດ? LC_COLLATE .

ໃນຕອນທ້າຍຂ້ອຍຈະພະຍາຍາມຕອບຄໍາຖາມ:

• ເປັນຫຍັງນາມສະກຸນຜູ້ຍິງຈຶ່ງຖືກຈັດຮຽງຜິດ?
• ເປັນຫຍັງ LANG=ru_RU.CP1251 ຫັນອອກໃຫ້ທຽບເທົ່າ LANG=C
• ເປັນຫຍັງ? ການຈັດລຽງ и ເຂົ້າຮ່ວມ ແນວຄວາມຄິດທີ່ແຕກຕ່າງກັນກ່ຽວກັບລໍາດັບຂອງສາຍຄັດ
• ເປັນຫຍັງມີຂໍ້ຜິດພາດໃນທຸກຕົວຢ່າງຂອງຂ້ອຍ?
• ສຸດ​ທ້າຍ​ວິ​ທີ​ການ​ຈັດ​ລຽງ​ສາຍ​ຕາມ​ຄວາມ​ມັກ​ຂອງ​ທ່ານ​

ການຈັດຮຽງໃນ Unicode

ການຢຸດເຊົາຄັ້ງທໍາອິດຈະເປັນບົດລາຍງານດ້ານວິຊາການ No 10 ສິດ ສູດການຄິດໄລ່ຂອງ Unicode ອອນໄລນ໌ unicode.org. ບົດລາຍງານປະກອບມີລາຍລະອຽດດ້ານວິຊາການຫຼາຍ, ດັ່ງນັ້ນຂ້າພະເຈົ້າຂໍສະຫຼຸບສັ້ນໆກ່ຽວກັບແນວຄວາມຄິດຕົ້ນຕໍ.

ການລຽງລໍາດັບ — “ການ​ສົມ​ທຽບ” ຊ່ອຍ​ແນ່​ແມ່ນ​ພື້ນ​ຖານ​ຂອງ​ວິ​ທີ​ການ​ຈັດ​ລຽງ​ລໍາ​ດັບ​ໃດ​ຫນຶ່ງ​. ສູດການຄິດໄລ່ຕົວມັນເອງອາດຈະແຕກຕ່າງກັນ ("ຟອງ", "ລວມ", "ໄວ"), ແຕ່ພວກເຂົາທັງຫມົດຈະໃຊ້ການປຽບທຽບຄູ່ຂອງສາຍສະຕິງເພື່ອກໍານົດລໍາດັບທີ່ປາກົດ.

ການຈັດຮຽງສາຍໃນພາສາທໍາມະຊາດແມ່ນເປັນບັນຫາທີ່ສັບສົນພໍສົມຄວນ. ເຖິງແມ່ນວ່າຢູ່ໃນການເຂົ້າລະຫັດດຽວໄບຕ໌ທີ່ງ່າຍດາຍທີ່ສຸດ, ລໍາດັບຂອງຕົວອັກສອນໃນຕົວອັກສອນ, ເຖິງແມ່ນວ່າໃນບາງທາງທີ່ແຕກຕ່າງຈາກຕົວອັກສອນລາຕິນພາສາອັງກິດ, ຈະບໍ່ກົງກັນກັບລໍາດັບຂອງຄ່າຕົວເລກທີ່ຕົວອັກສອນເຫຼົ່ານີ້ຖືກເຂົ້າລະຫັດ. ດັ່ງນັ້ນໃນຫນັງສືເຍຍລະມັນຕົວອັກສອນ Ö ຢືນຢູ່ລະຫວ່າງ О и P, ແລະ​ໃນ​ການ​ເຂົ້າ​ລະ​ຫັດ​ CP850 ນາງໄດ້ຮັບລະຫວ່າງ ÿ и Ü.

ທ່ານສາມາດພະຍາຍາມບໍ່ມີຕົວຕົນຈາກການເຂົ້າລະຫັດສະເພາະແລະພິຈາລະນາຕົວອັກສອນ "ທີ່ເຫມາະສົມ" ທີ່ຈັດລຽງຕາມລໍາດັບ, ດັ່ງທີ່ເຮັດໃນ Unicode. ການເຂົ້າລະຫັດ UTF8, UTF16 ຫຼື one-byte KOI8-R (ຖ້າ​ຫາກ​ວ່າ​ຈໍາ​ນວນ​ຈໍາ​ກັດ subset ຂອງ Unicode ແມ່ນ​ຈໍາ​ເປັນ​) ຈະ​ໃຫ້​ຕົວ​ແທນ​ຈໍາ​ນວນ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​ຂອງ​ຕົວ​ອັກ​ສອນ​, ແຕ່​ໃຫ້​ເບິ່ງ​ອົງ​ປະ​ກອບ​ດຽວ​ກັນ​ຂອງ​ຕາ​ຕະ​ລາງ​ຖານ​.

ມັນ turns ໃຫ້ ເຫັນ ວ່າ ຖ້າ ຫາກ ວ່າ ພວກ ເຮົາ ສ້າງ ຕາ ຕະ ລາງ ສັນ ຍາ ລັກ ຈາກ scratch , ພວກ ເຮົາ ຈະ ບໍ່ ສາ ມາດ ທີ່ ຈະ ມອບ ຫມາຍ ຄໍາ ສັ່ງ ສັນ ຍາ ລັກ ທົ່ວ ໄປ ກັບ ມັນ . ໃນຕົວອັກສອນແຫ່ງຊາດທີ່ແຕກຕ່າງກັນທີ່ໃຊ້ຕົວອັກສອນດຽວກັນ, ລໍາດັບຂອງຕົວອັກສອນເຫຼົ່ານີ້ອາດຈະແຕກຕ່າງກັນ. ສໍາລັບຕົວຢ່າງ, ໃນພາສາຝຣັ່ງ Æ ຈະຖືກພິຈາລະນາເປັນສາຍພັນ ແລະຈັດຮຽງເປັນສາຍ AE. ໃນນໍເວ Æ ຈະເປັນຕົວອັກສອນແຍກຕ່າງຫາກ, ເຊິ່ງຕັ້ງຢູ່ຫຼັງຈາກນັ້ນ Z. ໂດຍວິທີທາງການ, ນອກເຫນືອໄປຈາກ ligatures ຄື Æ ມີຕົວອັກສອນທີ່ຂຽນດ້ວຍສັນຍາລັກຫຼາຍຢ່າງ. ສະນັ້ນໃນພາສາເຊັກໂກມີຕົວອັກສອນ Ch, ເຊິ່ງຢືນຢູ່ລະຫວ່າງ H и I.

ນອກ ເໜືອ ໄປຈາກຄວາມແຕກຕ່າງຂອງຕົວ ໜັງ ສື, ຍັງມີປະເພນີແຫ່ງຊາດອື່ນໆທີ່ມີອິດທິພົນຕໍ່ການຈັດຮຽງ. ໂດຍສະເພາະ, ຄໍາຖາມທີ່ເກີດຂື້ນ: ຄໍາທີ່ປະກອບດ້ວຍຕົວພິມໃຫຍ່ແລະຕົວພິມນ້ອຍຄວນປາກົດຢູ່ໃນວັດຈະນານຸກົມແນວໃດ? ການຈັດຮຽງອາດຈະໄດ້ຮັບຜົນກະທົບຈາກການໃຊ້ເຄື່ອງໝາຍວັກຕອນ. ໃນແອສປາໂຍນ, ເຄື່ອງໝາຍຄໍາຖາມທີ່ປີ້ນກັບແມ່ນໃຊ້ໃນຕອນຕົ້ນຂອງປະໂຫຍກຕອບຄໍາຖາມ (ເຈົ້າມັກດົນຕີບໍ?). ໃນກໍລະນີນີ້, ມັນເປັນທີ່ຊັດເຈນວ່າປະໂຫຍກສໍາພາດບໍ່ຄວນຖືກຈັດເປັນກຸ່ມແຍກຕ່າງຫາກຢູ່ນອກຕົວຫນັງສື, ແຕ່ວິທີການຈັດລຽງແຖວດ້ວຍເຄື່ອງຫມາຍວັກຕອນອື່ນໆ?

ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ບໍ່​ຢູ່​ໃນ​ການ​ຈັດ​ລຽງ​ສາຍ​ໃນ​ພາ​ສາ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​ຫຼາຍ​ຈາກ​ປະ​ເທດ​ເອີ​ຣົບ​. ໃຫ້ສັງເກດວ່າໃນພາສາທີ່ມີທິດທາງການຂຽນຈາກຂວາຫາຊ້າຍຫຼືເທິງຫາລຸ່ມ, ຕົວອັກສອນໃນແຖວມັກຈະຖືກເກັບໄວ້ໃນລໍາດັບການອ່ານ, ແລະແມ້ກະທັ້ງລະບົບການຂຽນທີ່ບໍ່ແມ່ນຕົວຫນັງສືກໍ່ມີວິທີການຈັດລໍາດັບຕົວອັກສອນຕາມຕົວອັກສອນ. . ສໍາລັບຕົວຢ່າງ, hieroglyphs ສາມາດຖືກຈັດລໍາດັບຕາມແບບ (ກະແຈຕົວອັກສອນຈີນ) ຫຼືໂດຍການອອກສຽງ. ດ້ວຍຄວາມຊື່ສັດ, ຂ້ອຍບໍ່ຮູ້ວ່າ emojis ຄວນຖືກຈັດລຽງແນວໃດ, ແຕ່ເຈົ້າສາມາດມາກັບບາງສິ່ງບາງຢ່າງສໍາລັບພວກເຂົາເຊັ່ນກັນ.

ໂດຍອີງໃສ່ລັກສະນະທີ່ລະບຸໄວ້ຂ້າງເທິງ, ຄວາມຕ້ອງການພື້ນຖານສໍາລັບການປຽບທຽບສະຕຣິງໂດຍອີງໃສ່ຕາຕະລາງ Unicode ໄດ້ຖືກສ້າງຂື້ນ:

• ການປຽບທຽບສະຕຣິງບໍ່ຂຶ້ນກັບຕຳແໜ່ງຂອງຕົວອັກສອນໃນຕາຕະລາງລະຫັດ;
• ລໍາດັບຂອງຕົວອັກສອນທີ່ປະກອບເປັນລັກສະນະດຽວໄດ້ຖືກຫຼຸດລົງເປັນຮູບແບບ canonical (A + ວົງ​ມົນ​ເທິງ​ແມ່ນ​ດຽວ​ກັນ​ກັບ​ Å);
• ເມື່ອປຽບທຽບສະຕຣິງ, ຕົວລະຄອນຖືກພິຈາລະນາໃນບໍລິບົດຂອງສະຕຣິງແລະ, ຖ້າຈໍາເປັນ, ສົມທົບກັບເພື່ອນບ້ານຂອງມັນເຂົ້າໄປໃນຫນຶ່ງຫນ່ວຍຂອງການປຽບທຽບ (Ch ໃນພາສາເຊັກໂກ) ຫຼືແບ່ງອອກເປັນຫຼາຍ (Æ ໃນ​ພາ​ສາ​ຝຣັ່ງ);
• ລັກສະນະແຫ່ງຊາດທັງໝົດ (ຕົວອັກສອນ, ຕົວພິມໃຫຍ່/ຕົວພິມນ້ອຍ, ເຄື່ອງໝາຍວັກຕອນ, ລຳດັບຂອງປະເພດການຂຽນ) ຕ້ອງໄດ້ຮັບການກຳນົດຄ່າຕາມການກຳນົດຄູ່ມືຂອງຄຳສັ່ງ (ອີໂມຈິ);
• ການປຽບທຽບແມ່ນມີຄວາມສໍາຄັນບໍ່ພຽງແຕ່ສໍາລັບການຈັດຮຽງ, ແຕ່ຍັງຢູ່ໃນຫຼາຍບ່ອນ, ຕົວຢ່າງເຊັ່ນການກໍານົດຂອບເຂດແຖວ (ການທົດແທນ {A... z} ໃນ bash);
• ການປຽບທຽບຄວນເຮັດຢ່າງໄວວາ.

ນອກຈາກນັ້ນ, ຜູ້ຂຽນຂອງບົດລາຍງານໄດ້ສ້າງຄຸນສົມບັດການປຽບທຽບທີ່ນັກພັດທະນາ algorithm ບໍ່ຄວນອີງໃສ່:

• ຂັ້ນຕອນການປຽບທຽບບໍ່ຄວນຮຽກຮ້ອງໃຫ້ມີຊຸດຕົວອັກສອນແຍກຕ່າງຫາກສໍາລັບແຕ່ລະພາສາ (ພາສາລັດເຊຍແລະອູແກຣນມີຕົວອັກສອນ Cyrillic ສ່ວນໃຫຍ່);
• ການປຽບທຽບບໍ່ຄວນອີງໃສ່ຄໍາສັ່ງຂອງຕົວອັກສອນໃນຕາຕະລາງ Unicode;
• ນໍ້າໜັກຂອງສາຍບໍ່ຄວນເປັນຄຸນລັກສະນະຂອງສາຍເຊືອກ, ເພາະວ່າສາຍເຊືອກດຽວກັນຢູ່ໃນສະພາບວັດທະນະທໍາທີ່ແຕກຕ່າງກັນສາມາດມີນໍ້າໜັກແຕກຕ່າງກັນ;
• ນ້ ຳ ໜັກ ແຖວສາມາດປ່ຽນແປງໄດ້ເມື່ອລວມຫຼືແຍກ (ຈາກ x < y ມັນບໍ່ປະຕິບັດຕາມນັ້ນ xz < yz);
• ສະຕຣິງທີ່ແຕກຕ່າງກັນທີ່ມີນ້ໍາຫນັກດຽວກັນແມ່ນຖືວ່າເທົ່າທຽມກັນຈາກທັດສະນະຂອງສູດການຮຽງລໍາດັບ. ການແນະນໍາການສັ່ງເພີ່ມເຕີມຂອງສາຍດັ່ງກ່າວເປັນໄປໄດ້, ແຕ່ມັນອາດຈະເຮັດໃຫ້ປະສິດທິພາບຫຼຸດລົງ;
• ໃນລະຫວ່າງການຈັດຮຽງຊ້ຳໆ, ແຖວທີ່ມີນ້ຳໜັກດຽວກັນອາດຈະຖືກປ່ຽນ. ຄວາມແຂງແກ່ນແມ່ນຊັບສິນຂອງສູດການຮຽງລຳດັບສະເພາະ, ແລະບໍ່ແມ່ນຊັບສິນຂອງລະບົບການປຽບທຽບສະຕຣິງ (ເບິ່ງວັກກ່ອນໜ້າ);
• ກົດລະບຽບການຈັດຮຽງອາດຈະປ່ຽນແປງຕາມເວລາ ເນື່ອງຈາກປະເພນີວັດທະນະທໍາປັບປຸງ/ປ່ຽນແປງ.

ມັນຍັງຖືກກໍານົດວ່າ algorithm ການປຽບທຽບບໍ່ຮູ້ຫຍັງກ່ຽວກັບ semantics ຂອງ strings ກໍາລັງດໍາເນີນການ. ດັ່ງນັ້ນ, ສະຕຣິງທີ່ປະກອບດ້ວຍຕົວເລກເທົ່ານັ້ນບໍ່ຄວນຖືກປຽບທຽບເປັນຕົວເລກ, ແລະໃນບັນຊີລາຍຊື່ຂອງຊື່ພາສາອັງກິດບົດຄວາມ (Beatles, The).

ເພື່ອຕອບສະຫນອງຄວາມຕ້ອງການທີ່ກໍານົດໄວ້ທັງຫມົດ, ຂັ້ນຕອນການຈັດລຽງຕາຕະລາງຫຼາຍລະດັບ (ຕົວຈິງແລ້ວສີ່ລະດັບ) ໄດ້ຖືກສະເຫນີ.

ກ່ອນຫນ້ານີ້, ຕົວອັກສອນໃນສະຕຣິງຖືກຫຼຸດລົງເປັນຮູບແບບ canonical ແລະຈັດກຸ່ມເປັນຫົວຫນ່ວຍຂອງການປຽບທຽບ. ແຕ່ລະຫນ່ວຍຂອງການປຽບທຽບໄດ້ຖືກມອບຫມາຍນ້ໍາຫນັກຫຼາຍທີ່ສອດຄ້ອງກັນກັບຫຼາຍລະດັບຂອງການປຽບທຽບ. ນ້ຳໜັກຂອງຫົວໜ່ວຍປຽບທຽບແມ່ນອົງປະກອບຂອງຊຸດຕາມລຳດັບ (ໃນກໍລະນີນີ້, ຈຳນວນເຕັມ) ທີ່ສາມາດປຽບທຽບໄດ້ຫຼາຍ ຫຼື ໜ້ອຍ. ຄວາມຫມາຍພິເສດ ບໍ່ສົນໃຈ (0x0) ຫມາຍຄວາມວ່າໃນລະດັບການປຽບທຽບທີ່ສອດຄ້ອງກັນ ຫນ່ວຍງານນີ້ບໍ່ມີສ່ວນກ່ຽວຂ້ອງກັບການປຽບທຽບ. ການປຽບທຽບສາຍສາມາດຖືກຊ້ໍາຫຼາຍຄັ້ງ, ໂດຍໃຊ້ນ້ໍາຫນັກຂອງລະດັບທີ່ສອດຄ້ອງກັນ. ໃນ​ແຕ່​ລະ​ຂັ້ນ​, ນ​້​ໍາ​ຫນັກ​ຂອງ​ຫົວ​ຫນ່ວຍ​ການ​ປຽບ​ທຽບ​ຂອງ​ສອງ​ແຖວ​ເກັດ​ທີ່​ຈະ​ຖືກ​ສົມ​ທຽບ​ຕາມ​ລໍາ​ດັບ​ຕໍ່​ກັນ​.

ໃນການປະຕິບັດທີ່ແຕກຕ່າງກັນຂອງ algorithm ສໍາລັບປະເພນີແຫ່ງຊາດທີ່ແຕກຕ່າງກັນ, ຄຸນຄ່າຂອງຕົວຄູນອາດຈະແຕກຕ່າງກັນ, ແຕ່ມາດຕະຖານ Unicode ປະກອບມີຕາຕະລາງພື້ນຖານຂອງນ້ໍາຫນັກ - "ຕາຕະລາງອົງປະກອບການລວບລວມ Unicode ເລີ່ມຕົ້ນ" (DUCET). ຂ້າພະເຈົ້າຢາກສັງເກດວ່າການຕັ້ງຄ່າຕົວແປ LC_COLLATE ຕົວ​ຈິງ​ແລ້ວ​ແມ່ນ​ຕົວ​ຊີ້​ບອກ​ຂອງ​ການ​ຄັດ​ເລືອກ​ຂອງ​ຕາ​ຕະ​ລາງ​ນ​້​ໍ​າ​ໃນ​ການ​ທໍາ​ງານ​ຂອງ​ການ​ປຽບ​ທຽບ​ສາຍ​ຕັ້ງ​.

ຄ່າສໍາປະສິດການນ້ໍາຫນັກ DUCET ຈັດ​ລຽງ​ດັ່ງ​ນີ້​:

• ໃນລະດັບທໍາອິດ, ຕົວອັກສອນທັງຫມົດຖືກຫຼຸດລົງເປັນກໍລະນີດຽວກັນ, diacritics ຖືກຍົກເລີກ, ເຄື່ອງຫມາຍວັກຕອນ (ບໍ່ແມ່ນທັງຫມົດ) ແມ່ນຖືກລະເລີຍ;
• ໃນລະດັບທີສອງ, ພຽງແຕ່ diacritics ໄດ້ຖືກພິຈາລະນາ;
• ໃນລະດັບທີສາມ, ກໍລະນີພຽງແຕ່ຖືກພິຈາລະນາ;
• ໃນລະດັບທີສີ່, ພຽງແຕ່ເຄື່ອງໝາຍວັກຕອນຖືກພິຈາລະນາ.

ການປຽບທຽບເກີດຂຶ້ນໃນຫຼາຍ passes: ທໍາອິດ, ຕົວຄູນຂອງລະດັບທໍາອິດແມ່ນປຽບທຽບ; ຖ້ານ້ຳໜັກກົງກັນ, ການປຽບທຽບຊ້ຳໆກັບນ້ຳໜັກລະດັບທີສອງແມ່ນດຳເນີນ; ຫຼັງຈາກນັ້ນ, ບາງທີສາມແລະສີ່.

ການປຽບທຽບຈະສິ້ນສຸດເມື່ອແຖວມີຫົວໜ່ວຍທີ່ກົງກັນຂອງການປຽບທຽບກັບນ້ຳໜັກທີ່ແຕກຕ່າງກັນ. ແຖວ​ທີ່​ມີ​ນ​້​ໍາ​ຫນັກ​ເທົ່າ​ທຽມ​ກັນ​ໃນ​ທັງ​ສີ່​ລະ​ດັບ​ແມ່ນ​ພິ​ຈາ​ລະ​ນາ​ເທົ່າ​ທຽມ​ກັນ​.

ສູດການຄິດໄລ່ນີ້ (ມີຊໍ່ຂອງລາຍລະອຽດດ້ານວິຊາການເພີ່ມເຕີມ) ໄດ້ໃຫ້ຊື່ເພື່ອລາຍງານສະບັບເລກທີ 10 - "Unicode Collation Algorithm" (ACU).

ນີ້ແມ່ນບ່ອນທີ່ພຶດຕິກໍາການຈັດລຽງຈາກຕົວຢ່າງຂອງພວກເຮົາກາຍເປັນທີ່ຊັດເຈນເລັກນ້ອຍ. ມັນຈະເປັນການດີທີ່ຈະປຽບທຽບມັນກັບມາດຕະຖານ Unicode.

ເພື່ອທົດສອບການປະຕິບັດ ACU ມີຄວາມພິເສດ ການທົດສອບ, ການນໍາໃຊ້ ໄຟລ​໌​ນ​້​ໍາ​ຫນັກ​, ການ​ປະ​ຕິ​ບັດ​ DUCET. ທ່ານ​ສາ​ມາດ​ຊອກ​ຫາ​ຄັດ​ທັງ​ຫມົດ​ຂອງ​ເລື່ອງ​ຕະ​ຫລົກ​ໃນ​ໄຟລ​໌​ເກັດ​ໄດ້​. ສໍາລັບຕົວຢ່າງ, ມີຄໍາສັ່ງຂອງລີມແລະ dominoes ເອີຣົບ, ເຊັ່ນດຽວກັນກັບຄໍາສັ່ງຂອງເຫມາະສົມໃນ deck ຂອງບັດ (ສັນຍາລັກ. 1F000 ແລະຕື່ມອີກ). ຊຸດບັດແມ່ນຖືກຈັດໃສ່ຕາມກົດລະບຽບຂອງຂົວ - PCBT, ແລະບັດໃນຊຸດແມ່ນຢູ່ໃນລໍາດັບ T, 2,3, XNUMX ... K.

ການກວດສອບດ້ວຍຕົນເອງວ່າແຖວຖືກຈັດຮຽງຢ່າງຖືກຕ້ອງຕາມ DUCET ອາດຈະຂ້ອນຂ້າງເມື່ອຍ, ແຕ່, ໂຊກດີສໍາລັບພວກເຮົາ, ມີການປະຕິບັດຕົວຢ່າງຂອງຫ້ອງສະຫມຸດສໍາລັບການເຮັດວຽກກັບ Unicode - "ອົງປະກອບສາກົນສໍາລັບ Unicode"(ICU).

ຢູ່ໃນເວັບໄຊທ໌ຂອງຫ້ອງສະຫມຸດນີ້, ພັດທະນາໃນ IBM, ມີຫນ້າຕົວຢ່າງ, ລວມທັງ ຫນ້າ algorithm ການປຽບທຽບ string. ພວກເຮົາເຂົ້າໄປໃນສາຍການທົດສອບຂອງພວກເຮົາກັບການຕັ້ງຄ່າເລີ່ມຕົ້ນແລະ, ເບິ່ງແລະເບິ່ງ, ພວກເຮົາໄດ້ຮັບການຈັດຮຽງພາສາລັດເຊຍທີ່ສົມບູນແບບ.

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

ໂດຍວິທີທາງການ, ເວັບໄຊທ໌ ICU ທ່ານສາມາດຊອກຫາຄວາມກະຈ່າງແຈ້ງຂອງລະບົບການປຽບທຽບເມື່ອປະມວນຜົນເຄື່ອງໝາຍວັກຕອນ. ໃນຕົວຢ່າງ ຄຳຖາມທີ່ຖາມເລື້ອຍໆກ່ຽວກັບຄໍລຳ apostrophe ແລະ hyphen ຖືກລະເລີຍ.

Unicode ຊ່ວຍພວກເຮົາ, ແຕ່ຊອກຫາເຫດຜົນສໍາລັບພຶດຕິກໍາທີ່ແປກປະຫຼາດ ການຈັດລຽງ в Linux ຈະຕ້ອງໄປບ່ອນອື່ນ.

ການຈັດຮຽງໃນ glibc

ເບິ່ງດ່ວນຂອງລະຫັດແຫຼ່ງຜົນປະໂຫຍດ ການຈັດລຽງ ຈາກນັ້ນ GNU Core Utils ສະແດງໃຫ້ເຫັນວ່າໃນຜົນປະໂຫຍດຂອງມັນເອງ, ທ້ອງຖິ່ນລົງມາກັບການພິມມູນຄ່າປັດຈຸບັນຂອງຕົວແປ LC_COLLATE ເມື່ອແລ່ນຢູ່ໃນໂໝດດີບັກ:

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

ການປຽບທຽບສະຕຣິງຖືກປະຕິບັດໂດຍໃຊ້ຟັງຊັນມາດຕະຖານ ເລື່ອນ, ຊຶ່ງຫມາຍຄວາມວ່າທຸກສິ່ງທຸກຢ່າງທີ່ຫນ້າສົນໃຈແມ່ນຢູ່ໃນຫ້ອງສະຫມຸດ glibc.

ກ່ຽວກັບ ວິ​ກີ ໂຄງການ glibc ອຸທິດຕົນເພື່ອການປຽບທຽບສະຕຣິງ ວັກຫນຶ່ງ. ຈາກວັກນີ້ມັນສາມາດເຂົ້າໃຈໄດ້ວ່າໃນ glibc ການຈັດລຽງແມ່ນອີງໃສ່ສູດການຄິດໄລ່ທີ່ພວກເຮົາຮູ້ແລ້ວ ACU (ສູດການຄິດໄລ່ຂອງ Unicode collation) ແລະ/ຫຼື ມາດຕະຖານໃກ້ຄຽງກັບມັນ ISO 14651 (ການຈັດລໍາດັບສະຕຣິງສາກົນແລະການປຽບທຽບ). ກ່ຽວກັບມາດຕະຖານຫລ້າສຸດ, ຄວນສັງເກດວ່າຢູ່ໃນເວັບໄຊທ໌ standard.iso.org ISO 14651 ໄດ້ປະກາດຢ່າງເປັນທາງການຢ່າງເປັນທາງການ, ແຕ່ການເຊື່ອມຕໍ່ທີ່ສອດຄ້ອງກັນນໍາໄປສູ່ຫນ້າທີ່ບໍ່ມີຢູ່. Google ກັບຄືນຫລາຍຫນ້າທີ່ມີການເຊື່ອມຕໍ່ກັບເວັບໄຊທ໌ທາງການທີ່ສະເຫນີໃຫ້ຊື້ສໍາເນົາເອເລັກໂຕຣນິກຂອງມາດຕະຖານສໍາລັບຮ້ອຍເອີໂຣ, ແຕ່ໃນຫນ້າທີສາມຫຼືສີ່ຂອງຜົນການຄົ້ນຫາຍັງມີການເຊື່ອມຕໍ່ໂດຍກົງກັບ. PDF. ໂດຍທົ່ວໄປ, ມາດຕະຖານແມ່ນປະຕິບັດບໍ່ແຕກຕ່າງຈາກ ACU, ແຕ່ເປັນການອ່ານທີ່ຫນ້າເບື່ອຫຼາຍເພາະວ່າມັນບໍ່ມີຕົວຢ່າງທີ່ຊັດເຈນຂອງລັກສະນະແຫ່ງຊາດຂອງການຈັດລຽງສະຕຣິງ.

ຂໍ້ມູນທີ່ຫນ້າສົນໃຈຫຼາຍທີ່ສຸດກ່ຽວກັບ ວິ​ກີ ມີການເຊື່ອມຕໍ່ກັບ ບົບຕິດຕາມລຸດ bug ກັບການສົນທະນາຂອງການປະຕິບັດການປຽບທຽບສະຕຣິງໃນ glibc. ຈາກການສົນທະນາມັນສາມາດຮຽນຮູ້ໄດ້ glibc ໃຊ້ເພື່ອປຽບທຽບສະຕຣິງ ISOຕາ​ຕະ​ລາງ​ສ່ວນ​ບຸກ​ຄົນ​ ຕາຕະລາງແມ່ແບບທົ່ວໄປ (CTT), ທີ່ຢູ່ຂອງທີ່ສາມາດໄດ້ຮັບການພົບເຫັນຢູ່ໃນຄໍາຮ້ອງສະຫມັກ A ມາດຕະຖານ ISO 14651. ລະຫວ່າງ 2000 ແລະ 2015 ຕາຕະລາງນີ້ໃນ glibc ບໍ່ມີຜູ້ຮັກສາແລະແມ່ນຂ້ອນຂ້າງແຕກຕ່າງກັນ (ຢ່າງຫນ້ອຍພາຍນອກ) ຈາກສະບັບປະຈຸບັນຂອງມາດຕະຖານ. ຈາກ 2015 ຫາ 2018, ການປັບຕົວເຂົ້າກັບຕາຕະລາງໃຫມ່ໄດ້ເກີດຂຶ້ນ, ແລະໃນປັດຈຸບັນທ່ານມີໂອກາດທີ່ຈະພົບກັນໃນຊີວິດຈິງຂອງຕາຕະລາງສະບັບໃຫມ່ (CentOS 8), ແລະເກົ່າ (CentOS 7).

ໃນປັດຈຸບັນທີ່ພວກເຮົາມີຂໍ້ມູນທັງຫມົດກ່ຽວກັບ algorithm ແລະຕາຕະລາງ auxiliary, ພວກເຮົາສາມາດກັບຄືນໄປຫາບັນຫາຕົ້ນສະບັບແລະເຂົ້າໃຈວິທີການຈັດຮຽງສາຍພາສາລັດເຊຍຢ່າງຖືກຕ້ອງ.

ISO 14651/14652

ລະຫັດແຫຼ່ງຂອງຕາຕະລາງທີ່ພວກເຮົາສົນໃຈ CTT ກ່ຽວກັບການແຈກຢາຍສ່ວນໃຫຍ່ Linux ຢູ່ໃນລາຍການ /usr/share/i18n/locales/. ຕາຕະລາງຕົວມັນເອງແມ່ນຢູ່ໃນໄຟລ໌ iso14651_t1_common. ຫຼັງຈາກນັ້ນ, ນີ້ແມ່ນຄໍາສັ່ງໄຟລ໌ ສຳເນົາ iso14651_t1_common ລວມຢູ່ໃນໄຟລ໌ iso14651_t1, ເຊິ່ງ, ໃນທາງກັບກັນ, ແມ່ນລວມຢູ່ໃນເອກະສານແຫ່ງຊາດ, ລວມທັງ ໃນສະຫະລັດ и ru_RU. ກ່ຽວກັບການແຈກຢາຍສ່ວນໃຫຍ່ Linux ໄຟລ໌ແຫຼ່ງທັງຫມົດແມ່ນລວມຢູ່ໃນການຕິດຕັ້ງພື້ນຖານ, ແຕ່ຖ້າພວກມັນບໍ່ຢູ່, ທ່ານຈະຕ້ອງຕິດຕັ້ງຊຸດເພີ່ມເຕີມຈາກການແຈກຢາຍ.

ໂຄງສ້າງໄຟລ໌ iso14651_t1 ອາດຈະເບິ່ງຄືວ່າ verbose ຂີ້ຮ້າຍ, ມີກົດລະບຽບທີ່ບໍ່ຊັດເຈນສໍາລັບການກໍ່ສ້າງຊື່, ແຕ່ຖ້າທ່ານເບິ່ງມັນ, ທຸກສິ່ງທຸກຢ່າງແມ່ນຂ້ອນຂ້າງງ່າຍດາຍ. ໂຄງສ້າງໄດ້ຖືກອະທິບາຍໄວ້ໃນມາດຕະຖານ ISO 14652, ສໍາເນົາທີ່ສາມາດດາວໂຫລດໄດ້ຈາກເວັບໄຊທ໌ open-std.org. ລາຍລະອຽດຂອງຮູບແບບໄຟລ໌ອື່ນສາມາດອ່ານໄດ້ໃນ ຂໍ້ມູນສະເພາະ POSIX ຈາກ OpenGroup. ເປັນທາງເລືອກໃນການອ່ານມາດຕະຖານ, ທ່ານສາມາດສຶກສາລະຫັດແຫຼ່ງຂອງຟັງຊັນ collate_read в glibc/locale/programs/ld-collate.c.

ໂຄງ​ປະ​ກອບ​ການ​ໄຟລ​໌​ເບິ່ງ​ຄື​ນີ້​:

ໂດຍຄ່າເລີ່ມຕົ້ນ, ຕົວອັກສອນຖືກໃຊ້ເປັນຕົວລະຄອນຫລົບຫນີ, ແລະທ້າຍແຖວຫຼັງຈາກຕົວອັກສອນ # ແມ່ນຄໍາຄິດຄໍາເຫັນ. ສັນຍາລັກທັງສອງສາມາດຖືກກໍານົດຄືນໃຫມ່, ເຊິ່ງເປັນສິ່ງທີ່ເຮັດຢູ່ໃນຕາຕະລາງສະບັບໃຫມ່:

escape_char /
comment_char %

ໄຟລ໌ຈະມີ tokens ໃນຮູບແບບ ຫຼື (ບ່ອນໃດ x - ເລກຖານສິບຫົກ). ນີ້ແມ່ນຕົວແທນເລກຖານສິບຫົກຂອງຈຸດລະຫັດ Unicode ໃນການເຂົ້າລະຫັດ UCS-4 (UTF-32). ອົງປະກອບອື່ນໆທັງໝົດໃນວົງເລັບມຸມ (ລວມທັງ , <2> ແລະຄ້າຍຄືກັນ) ຖືກພິຈາລະນາເປັນສະຕຣິງຄົງທີ່ທີ່ງ່າຍດາຍທີ່ມີຄວາມຫມາຍພຽງເລັກນ້ອຍຢູ່ນອກສະພາບການ.

ສາຍ LC_COLLATE ບອກພວກເຮົາວ່າຕໍ່ໄປຈະເລີ່ມຕົ້ນຂໍ້ມູນທີ່ອະທິບາຍການປຽບທຽບຂອງສະຕຣິງ.

ຫນ້າທໍາອິດ, ຊື່ແມ່ນຖືກກໍານົດສໍາລັບນ້ໍາຫນັກໃນຕາຕະລາງການປຽບທຽບແລະຊື່ສໍາລັບການປະສົມສັນຍາລັກ. ໂດຍທົ່ວໄປແລ້ວ, ທັງສອງປະເພດຂອງຊື່ແມ່ນຂຶ້ນກັບສອງຫນ່ວຍງານທີ່ແຕກຕ່າງກັນ, ແຕ່ໃນເອກະສານຕົວຈິງແມ່ນປະສົມກັນ. ຊື່ຂອງນ້ໍາຫນັກຖືກລະບຸໄວ້ໂດຍຄໍາສໍາຄັນ collating-ສັນ​ຍາ​ລັກ​ (comparison character) ເພາະວ່າເມື່ອປຽບທຽບ, ຕົວອັກສອນ Unicode ທີ່ມີນ້ຳໜັກເທົ່າກັນຈະຖືວ່າເປັນຕົວອັກສອນທີ່ທຽບເທົ່າ.

ຄວາມຍາວທັງຫມົດຂອງພາກສ່ວນໃນການແກ້ໄຂໄຟລ໌ໃນປະຈຸບັນແມ່ນປະມານ 900 ເສັ້ນ. ຂ້າພະເຈົ້າໄດ້ດຶງຕົວຢ່າງຈາກຫຼາຍໆບ່ອນເພື່ອສະແດງໃຫ້ເຫັນເຖິງຄວາມບໍ່ພໍໃຈຂອງຊື່ແລະຫຼາຍປະເພດຂອງ syntax.

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

• collating-ສັນ​ຍາ​ລັກ​ ບັນທຶກສະຕຣິງ OSMANYA ໃນຕາຕະລາງຂອງຊື່ຂອງເກັດ
• collating-ສັນ​ຍາ​ລັກ​ .. ລົງທະບຽນລໍາດັບຂອງຊື່ທີ່ປະກອບດ້ວຍຄໍານໍາຫນ້າ S ແລະຄຳຕໍ່ທ້າຍຕົວເລກເລກຖານສິບຫົກຈາກ 1D000 ການ 1D35F.
• FFFF в collating-ສັນ​ຍາ​ລັກ​ ເບິ່ງຄືວ່າເປັນຈຳນວນເຕັມທີ່ບໍ່ໄດ້ເຊັນໃນລະບົບເລກຖານສິບຫົກ, ແຕ່ ມັນເປັນພຽງແຕ່ຊື່ທີ່ອາດຈະຄ້າຍຄື
• имя ຫມາຍເຖິງຈຸດລະຫັດໃນການເຂົ້າລະຫັດ UCS-4
• collating-ອົງປະກອບ ຈາກ " " ລົງທະບຽນຊື່ໃໝ່ສຳລັບຄູ່ຂອງຈຸດ Unicode.

ເມື່ອຊື່ຂອງນ້ຳໜັກຖືກກຳນົດ, ນ້ຳໜັກຕົວຈິງແມ່ນກຳນົດ. ເນື່ອງຈາກພຽງແຕ່ການພົວພັນທີ່ໃຫຍ່ກວ່າຫນ້ອຍແມ່ນມີຄວາມສໍາຄັນໃນການປຽບທຽບ, ນ້ໍາຫນັກຖືກກໍານົດໂດຍລໍາດັບງ່າຍໆຂອງລາຍຊື່. ນ້ ຳ ໜັກ "ອ່ອນກວ່າ" ຖືກລະບຸໄວ້ກ່ອນ, ຫຼັງຈາກນັ້ນແມ່ນ "ໜັກກວ່າ". ຂ້າພະເຈົ້າຂໍເຕືອນທ່ານວ່າຕົວອັກສອນ 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

ສຸດທ້າຍ, ຕາຕະລາງນ້ໍາຫນັກຕົວຈິງ.

ພາກສ່ວນນ້ໍາຫນັກຖືກຫຸ້ມຢູ່ໃນເສັ້ນຄໍາສໍາຄັນ order_start и order_end. ທາງເລືອກພິເສດ order_start ກໍານົດວ່າແຖວທິດທາງໃດຖືກສະແກນໃນແຕ່ລະລະດັບຂອງການປຽບທຽບ. ການຕັ້ງຄ່າເລີ່ມຕົ້ນແມ່ນ ໄປຂ້າງຫນ້າ. ຮ່າງກາຍຂອງພາກສ່ວນປະກອບດ້ວຍເສັ້ນທີ່ມີລະຫັດສັນຍາລັກແລະສີ່ນ້ໍາຫນັກຂອງມັນ. ລະຫັດຕົວອັກສອນສາມາດຖືກສະແດງໂດຍຕົວອັກສອນຕົວມັນເອງ, ຈຸດລະຫັດ, ຫຼືຊື່ສັນຍາລັກທີ່ກໍານົດໄວ້ກ່ອນຫນ້ານີ້. ນ້ໍາຫນັກຍັງສາມາດຖືກມອບໃຫ້ກັບຊື່ສັນຍາລັກ, ຈຸດລະຫັດ, ຫຼືສັນຍາລັກຂອງຕົນເອງ. ຖ້າຈຸດລະຫັດຫຼືຕົວອັກສອນຖືກນໍາໃຊ້, ນ້ໍາຫນັກຂອງພວກມັນແມ່ນເທົ່າກັບຄ່າຕົວເລກຂອງຈຸດລະຫັດ (ຕໍາແຫນ່ງໃນຕາຕະລາງ Unicode). ຕົວອັກສອນທີ່ບໍ່ໄດ້ລະບຸຢ່າງຊັດເຈນ (ຕາມທີ່ຂ້ອຍເຂົ້າໃຈ) ໄດ້ຖືກພິຈາລະນາໃຫ້ຢູ່ໃນຕາຕະລາງທີ່ມີນ້ໍາຫນັກຕົ້ນຕໍທີ່ກົງກັບຕໍາແຫນ່ງໃນຕາຕະລາງ Unicode. ມູນຄ່ານ້ໍາຫນັກພິເສດ ບໍ່ສົນໃຈ ຫມາຍຄວາມວ່າສັນຍາລັກຖືກລະເວັ້ນໃນລະດັບທີ່ເຫມາະສົມຂອງການປຽບທຽບ.

ເພື່ອສະແດງໃຫ້ເຫັນໂຄງສ້າງຂອງເກັດ, ຂ້າພະເຈົ້າໄດ້ເລືອກສາມຊິ້ນທີ່ເຫັນໄດ້ຊັດເຈນ:

• ຕົວອັກສອນທີ່ຖືກລະເລີຍຢ່າງສົມບູນ
• ສັນຍາລັກທຽບເທົ່າກັບຕົວເລກສາມໃນສອງລະດັບທໍາອິດ
• ການເລີ່ມຕົ້ນຂອງຕົວອັກສອນ Cyrillic, ເຊິ່ງບໍ່ມີ diacritics, ແລະດັ່ງນັ້ນຈຶ່ງຖືກຈັດຮຽງສ່ວນໃຫຍ່ໂດຍລະດັບທໍາອິດແລະທີສາມ.

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 ຕາຕະລາງພິເສດຖືກໂຫລດທີ່ລະບຸການປຽບທຽບ byte-by-byte

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 ຂ້ອນຂ້າງເປັນຂັ້ນຕອນຄ່າໃຊ້ຈ່າຍ. ເພື່ອເພີ່ມປະສິດທິພາບການເຂົ້າເຖິງຕາຕະລາງ, ມັນຖືກລວບລວມເຂົ້າໄປໃນຮູບແບບຖານສອງດ້ວຍຄໍາສັ່ງ ທ້ອງຖິ່ນ.

ທີມງານ ທ້ອງຖິ່ນ ຍອມຮັບເປັນພາລາມິເຕີໄຟລ໌ທີ່ມີຕາຕະລາງລັກສະນະແຫ່ງຊາດ (ທາງເລືອກ -i), ເຊິ່ງຕົວອັກສອນທັງໝົດແມ່ນສະແດງໂດຍຈຸດ Unicode, ແລະເອກະສານການຕິດຕໍ່ລະຫວ່າງຈຸດ Unicode ແລະຕົວອັກສອນຂອງການເຂົ້າລະຫັດສະເພາະ (ທາງເລືອກ -f). ເປັນຜົນມາຈາກການເຮັດວຽກ, ໄຟລ໌ຖານສອງແມ່ນຖືກສ້າງຂຶ້ນສໍາລັບທ້ອງຖິ່ນທີ່ມີຊື່ທີ່ລະບຸໄວ້ໃນພາລາມິເຕີສຸດທ້າຍ.

glibc ສະຫນັບສະຫນູນສອງຮູບແບບເອກະສານຄູ່: "ດັ້ງເດີມ" ແລະ "ທັນສະໄຫມ".

ຮູບແບບພື້ນເມືອງຫມາຍຄວາມວ່າຊື່ຂອງທ້ອງຖິ່ນແມ່ນຊື່ຂອງ subdirectory ໃນ /usr/lib/locale/. ໄດເລກະທໍລີຍ່ອຍນີ້ເກັບຮັກສາໄຟລ໌ໄບນາຣີ LC_COLLATE, LC_CTYPE, LC_TIME ແລະອື່ນໆ. ໄຟລ໌ LC_IDENTIFICATION ມີຊື່ຢ່າງເປັນທາງການຂອງທ້ອງຖິ່ນ (ເຊິ່ງອາດຈະແຕກຕ່າງຈາກຊື່ໄດເລກະທໍລີ) ແລະຄໍາເຫັນ.

ຮູບແບບທີ່ທັນສະໄຫມກ່ຽວຂ້ອງກັບການເກັບຮັກສາທ້ອງຖິ່ນທັງຫມົດໃນຮວບຮວມດຽວ /usr/lib/locale/locale-archive, ເຊິ່ງຖືກແຜນທີ່ກັບຫນ່ວຍຄວາມຈໍາ virtual ຂອງຂະບວນການທັງຫມົດໂດຍໃຊ້ glibc. ຊື່ທ້ອງຖິ່ນໃນຮູບແບບທີ່ທັນສະໄຫມແມ່ນຂຶ້ນກັບບາງ canonization - ພຽງແຕ່ຕົວເລກແລະຕົວອັກສອນທີ່ຫຼຸດລົງເປັນຕົວພິມນ້ອຍຍັງຄົງຢູ່ໃນຊື່ເຂົ້າລະຫັດ. ດັ່ງນັ້ນ 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.maccyrillic

ຖ້າທ່ານກໍານົດຕົວແປ LANG = en_USUTF-8 ຫຼັງຈາກນັ້ນ, glibc ຈະຊອກຫາ binaries ທ້ອງຖິ່ນໃນລໍາດັບຕໍ່ໄປນີ້ຂອງໄຟລ໌ແລະໄດເລກະທໍລີ:

/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 ພາກສ່ວນສໍາລັບການປັບນ້ໍາຫນັກຂອງຕາຕະລາງທີ່ມີຢູ່ແລ້ວແມ່ນສະຫນອງໃຫ້. ພາກສ່ວນເລີ່ມຕົ້ນດ້ວຍຄໍາສໍາຄັນ reorder-ຫຼັງຈາກ ແລະຊີ້ບອກຕໍາແຫນ່ງຫຼັງຈາກນັ້ນການທົດແທນໄດ້ຖືກປະຕິບັດ. ພາກສ່ວນສິ້ນສຸດລົງດ້ວຍເສັ້ນ reorder-end. ຖ້າມັນຈໍາເປັນຕ້ອງແກ້ໄຂຫຼາຍໆພາກຂອງຕາຕະລາງ, ຫຼັງຈາກນັ້ນ, ພາກສ່ວນຫນຶ່ງແມ່ນຖືກສ້າງຂຶ້ນສໍາລັບແຕ່ລະພາກດັ່ງກ່າວ.

ຂ້ອຍໄດ້ສຳເນົາໄຟລ໌ສະບັບໃໝ່ iso14651_t1_common и ru_RU ຈາກ repository ໄດ້ 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, ແຕ່ໃນຕົວຢ່າງຂອງຂ້ອຍນີ້ບໍ່ຈໍາເປັນ, ເພາະວ່າຂ້ອຍໄດ້ຍົກເວັ້ນການເກັບຂໍ້ມູນຈາກການຄົ້ນຫາທ້ອງຖິ່ນ locale-archive.

ທີ່ ທ້ອງຖິ່ນ ເຮັດວຽກກັບໄຟລ໌ໃນໂຟນເດີຂອງຂ້ອຍຜ່ານຕົວແປ I18NPATH ທ່ານສາມາດເພີ່ມໄດເລກະທໍລີເພີ່ມເຕີມເພື່ອຊອກຫາໄຟລ໌ປ້ອນຂໍ້ມູນ, ແລະໄດເລກະທໍລີເພື່ອບັນທຶກໄຟລ໌ໄບນາຣີສາມາດຖືກກໍານົດເປັນເສັ້ນທາງທີ່ມີ slashes:

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

POSIX ສົມມຸດວ່າໃນ ພາສາ ທ່ານສາມາດຂຽນເສັ້ນທາງຢ່າງແທ້ຈິງໄປຫາໄດເລກະທໍລີທີ່ມີໄຟລ໌ທ້ອງຖິ່ນ, ເລີ່ມຕົ້ນດ້ວຍ slash ໄປຂ້າງຫນ້າ, ແຕ່ glibc в Linux ເສັ້ນທາງທັງໝົດແມ່ນນັບຈາກໄດເລກະທໍລີພື້ນຖານ, ເຊິ່ງສາມາດຖືກຂ້າມຜ່ານຕົວແປໄດ້ ສະຖານທີ່. ຫຼັງຈາກການຕິດຕັ້ງ LOCPATH=~/.local/lib/locale/ ໄຟລ໌ທັງຫມົດທີ່ກ່ຽວຂ້ອງກັບການທ້ອງຖິ່ນຈະຖືກຄົ້ນຫາຢູ່ໃນໂຟນເດີຂອງຂ້ອຍເທົ່ານັ້ນ. ຮວບຮວມຂອງທ້ອງຖິ່ນດ້ວຍຊຸດຕົວແປ ສະຖານທີ່ ບໍ່ສົນໃຈ.

ນີ້ແມ່ນການທົດສອບທີ່ຕັດສິນ:

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

ໂຫ້ຍ! ພວກເຮົາໄດ້ເຮັດມັນ!

Bug work

ຂ້າພະເຈົ້າໄດ້ຕອບຄໍາຖາມກ່ຽວກັບການຈັດລຽງສະຕຣິງທີ່ວາງໄວ້ໃນຕອນຕົ້ນ, ແຕ່ຍັງມີສອງສາມຄໍາຖາມກ່ຽວກັບຄວາມຜິດພາດ - ເບິ່ງເຫັນແລະເບິ່ງບໍ່ເຫັນ.

ໃຫ້ກັບຄືນໄປຫາບັນຫາຕົ້ນສະບັບ.

ແລະໂຄງການ ການຈັດລຽງ ແລະໂຄງການ ເຂົ້າຮ່ວມ ໃຊ້ຟັງຊັນການປຽບທຽບສະຕຣິງດຽວກັນຈາກ glibc. ມັນເກີດຂຶ້ນໄດ້ແນວໃດ ເຂົ້າຮ່ວມ ໃຫ້ຄວາມຜິດພາດໃນການຈັດຮຽງແຖວທີ່ຈັດຮຽງຕາມຄໍາສັ່ງ ການຈັດລຽງ ຢູ່ໃນທ້ອງຖິ່ນ en_US.UTF-8? ຄໍາຕອບແມ່ນງ່າຍດາຍ: ການຈັດລຽງ ປຽບທຽບສາຍທັງໝົດ, ແລະ ເຂົ້າຮ່ວມ ປຽບທຽບພຽງແຕ່ກະແຈ, ເຊິ່ງຕາມຄ່າເລີ່ມຕົ້ນແມ່ນຈຸດເລີ່ມຕົ້ນຂອງສະຕຣິງເຖິງຕົວອັກສອນ whitespace ທຳອິດ. ໃນຕົວຢ່າງຂອງຂ້ອຍ, ນີ້ເຮັດໃຫ້ເກີດຄວາມຜິດພາດເພາະວ່າການຈັດລຽງຂອງຄໍາທໍາອິດໃນແຖວບໍ່ກົງກັບການຈັດລຽງຂອງແຖວທີ່ສົມບູນ.

ສະຖານທີ່ "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. ຖ້າສະຖານທີ່ທີ່ລວບລວມບໍ່ພົບ, ຫຼັງຈາກນັ້ນ ການຈັດລຽງ ໃຊ້ການປຽບທຽບ byte-by-byte ຢ່າງງຽບໆ, ເຊິ່ງເປັນສິ່ງທີ່ພວກເຮົາສັງເກດເຫັນ.

ໂດຍວິທີທາງການ, ມີ glitch ຂະຫນາດນ້ອຍອີກອັນຫນຶ່ງທີ່ກ່ຽວຂ້ອງກັບຄວາມບໍ່ສາມາດເຂົ້າເຖິງທ້ອງຖິ່ນທີ່ລວບລວມໄດ້. ທີມງານ LOCPATH=/tmp locale -a ຈະໃຫ້ບັນຊີລາຍຊື່ຂອງທ້ອງຖິ່ນທັງຫມົດໃນ locale-archive, ແຕ່ມີຊຸດຕົວແປ ສະຖານທີ່ ສໍາລັບໂຄງການທັງຫມົດ (ລວມທັງຫຼາຍທີ່ສຸດ ທ້ອງຖິ່ນ) ທ້ອງຖິ່ນເຫຼົ່ານີ້ຈະບໍ່ສາມາດໃຊ້ໄດ້.

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

ສະຫລຸບ

ຖ້າທ່ານເປັນນັກຂຽນໂປລແກລມຜູ້ທີ່ເຄີຍຄິດວ່າ strings ເປັນຊຸດຂອງ bytes, ຫຼັງຈາກນັ້ນທາງເລືອກຂອງເຈົ້າ LC_COLLATE=C.

ຖ້າທ່ານເປັນນັກພາສາສາດຫຼືນັກລວບລວມວັດຈະນານຸກົມ, ຫຼັງຈາກນັ້ນທ່ານລວບລວມຢູ່ໃນທ້ອງຖິ່ນຂອງທ່ານດີກວ່າ.

ຖ້າທ່ານເປັນຜູ້ໃຊ້ງ່າຍດາຍ, ຫຼັງຈາກນັ້ນທ່ານພຽງແຕ່ຕ້ອງການທີ່ຈະໄດ້ຮັບການນໍາໃຊ້ກັບຄວາມຈິງທີ່ວ່າຄໍາສັ່ງ ls -a outputs ໄຟລ໌ເລີ່ມຕົ້ນດ້ວຍຈຸດປະສົມກັບໄຟລ໌ທີ່ເລີ່ມຕົ້ນດ້ວຍຕົວອັກສອນ, ແລະ ຜູ້ບັນຊາການເວລາທ່ຽງຄືນ, ເຊິ່ງໃຊ້ຫນ້າທີ່ພາຍໃນຂອງຕົນເພື່ອຈັດຮຽງຊື່, ເອົາໄຟລ໌ເລີ່ມຕົ້ນດ້ວຍຈຸດໃນຕອນຕົ້ນຂອງບັນຊີລາຍຊື່.

ເອກະສານ

ລາຍງານສະບັບເລກທີ 10 ສູດການຄິດໄລ່ຂອງ Unicode

ນ້ຳໜັກຕົວລະຄອນຢູ່ unicode.org

ICU — ການຈັດຕັ້ງປະຕິບັດຫ້ອງສະໝຸດເພື່ອເຮັດວຽກກັບ Unicode ຈາກ IBM.

ການ​ທົດ​ສອບ​ການ​ຄັດ​ເລືອກ​ໂດຍ​ການ​ນໍາ​ໃຊ້​ ICU

ນ້ຳໜັກຕົວລະຄອນຢູ່ໃນ ISO 14651

ລາຍລະອຽດຂອງຮູບແບບໄຟລ໌ທີ່ມີເກັດ ISO 14652

ການສົນທະນາຂອງການປຽບທຽບສະຕຣິງໃນ glibc

ແຫຼ່ງຂໍ້ມູນ: www.habr.com