ٻي سائيڪل: اسان يونيڪوڊ تارن کي 30-60٪ وڌيڪ ڪمپيڪٽ UTF-8 کان محفوظ ڪريون ٿا

جيڪڏهن توهان هڪ ڊولپر آهيو ۽ توهان کي انڪوڊنگ چونڊڻ جو ڪم آهي، ته پوءِ يونيڪوڊ لڳ ڀڳ هميشه صحيح حل هوندو. مخصوص نمائندگي جو طريقو حوالن تي منحصر آهي، پر اڪثر ڪري هتي هڪ آفاقي جواب پڻ آهي - UTF-8. ان جي باري ۾ سٺي شيء اها آهي ته اهو توهان کي بغير خرچ ڪرڻ جي سڀني يونيڪوڊ اکرن کي استعمال ڪرڻ جي اجازت ڏئي ٿو پڻ اڪثر ڪيسن ۾ ڪيترائي بائيٽ. سچ، انهن ٻولين لاءِ جيڪي صرف لاطيني الفابيٽ کان وڌيڪ استعمال ڪن ٿيون، ”تمام گهڻو نه“ گهٽ ۾ گهٽ آهي ٻه بائيٽ في ڪردار. ڇا اسان اڳڀرائي واري انڪوڊنگ ڏانھن موٽڻ کان سواءِ بھتر ڪري سگھون ٿا جيڪي اسان کي صرف 256 موجود اکرن تائين محدود ڪري سگھن ٿا؟

هيٺ آئون توهان کي هن سوال جو جواب ڏيڻ جي منهنجي ڪوشش سان واقف ڪرڻ جو مشورو ڏيان ٿو ۽ هڪ نسبتا آسان الگورٿم لاڳو ڪرڻ جي اجازت ڏئي ٿو جيڪا توهان کي اجازت ڏئي ٿي دنيا جي اڪثر ٻولين ۾ لائينون ذخيرو ڪرڻ جي بغير بغير شامل ڪرڻ جي جيڪا UTF-8 ۾ آهي.

رد ڪرڻ. مان فوري طور تي ڪجهه اهم رزرويشن ڪندس: بيان ڪيل حل UTF-8 لاءِ آفاقي متبادل طور پيش نه ڪيو ويو آهي، اهو صرف ڪيسن جي تنگ فهرست ۾ مناسب آهي (انهن تي وڌيڪ هيٺ ڏنل)، ۽ ڪنهن به صورت ۾ ان کي ٽئين پارٽي APIs سان رابطو ڪرڻ لاءِ استعمال نه ڪيو وڃي (جيڪي ان بابت به نٿا ڄاڻن). گهڻو ڪري، عام-مقصد کمپريشن الگورتھم (مثال طور، ڊيفليٽ) ٽيڪسٽ ڊيٽا جي وڏي مقدار جي جامع اسٽوريج لاء مناسب آهن. ان کان علاوه، اڳ ۾ ئي منهنجي حل ٺاهڻ جي عمل ۾، مون کي يونيڪوڊ ۾ هڪ موجوده معيار مليو، جيڪو ساڳيو مسئلو حل ڪري ٿو - اهو ڪجهه وڌيڪ پيچيده (۽ گهڻو ڪري بدترين) آهي، پر اڃا تائين اهو هڪ قبول ٿيل معيار آهي، ۽ نه رڳو رکي ٿو. گڏو گڏ گڏي تي. مان توهان کي هن جي باري ۾ پڻ ٻڌايان ٿو.

يونيڪوڊ ۽ UTF-8 بابت

شروع ڪرڻ لاء، ڪجھ لفظن بابت اھو ڇا آھي يونيسيڊ и UTF-8.

جئين توهان کي خبر آهي، 8-bit انڪوڊنگس مشهور ٿي ويندا هئا. انھن سان گڏ، سڀڪنھن شيء کي سادو هو: 256 اکرن کي 0 کان 255 تائين انگن سان گڏ ڪري سگهجي ٿو، ۽ 0 کان 255 تائين انگن کي واضح طور تي هڪ بائيٽ طور پيش ڪري سگهجي ٿو. جيڪڏهن اسان بلڪل شروعات ڏانهن واپس وڃون ٿا، ASCII انڪوڊنگ مڪمل طور تي 7 بٽ تائين محدود آهي، تنهنڪري ان جي بائيٽ جي نمائندگي ۾ سڀ کان اهم بٽ صفر آهي، ۽ اڪثر 8-بٽ انڪوڊنگ ان سان مطابقت رکن ٿيون (اهي صرف "مٿين" ۾ مختلف آهن. حصو، جتي سڀ کان اهم سا هڪ آهي).

يونيڪوڊ انهن انڪوڊنگن کان ڪيئن مختلف آهي ۽ ان سان لاڳاپيل ڪيتريون ئي مخصوص نمائندگي ڇو آهن - UTF-8، UTF-16 (BE ۽ LE)، UTF-32؟ اچو ته ان کي ترتيب سان ترتيب ڏيو.

بنيادي يونيڪوڊ معيار صرف ڪردارن جي وچ ۾ خط و ڪتابت کي بيان ڪري ٿو (۽ ڪن حالتن ۾، ڪردارن جي انفرادي اجزاء) ۽ انهن جي انگن اکرن جي وچ ۾. ۽ ھن معيار ۾ ڪيترائي ممڪن نمبر آھن - کان 0x00 ڪرڻ 0x10FFFF (1 ٽڪر). جيڪڏهن اسان چاهيون ٿا ته هڪ عدد کي اهڙي حد ۾ هڪ متغير ۾ وجهي، نه ته 114 ۽ نه 112 بائيٽ اسان لاءِ ڪافي هوندا. ۽ جيئن ته اسان جا پروسيسر ٽي بائيٽ نمبرن سان ڪم ڪرڻ لاءِ بلڪل ٺهيل نه آهن، ان ڪري اسان کي 1 بائيٽ في ڪردار استعمال ڪرڻ تي مجبور ڪيو ويندو! هي UTF-2 آهي، پر اهو خاص طور تي هن "فضول خرچي" جي ڪري آهي ته هي فارميٽ مشهور نه آهي.

خوشقسمتيءَ سان، يونيڪوڊ ۾ ڪردارن جو ترتيب بي ترتيب نه آهي. انهن جو سڄو سيٽ 17 ۾ ورهايل آهي.جهاز"، جن مان هر هڪ تي مشتمل آهي 65536 (0x10000)ڪوڊ پوائنٽس" هتي "ڪوڊ پوائنٽ" جو تصور آسان آهي ڪردار نمبر، يونيڪوڊ طرفان ان کي مقرر ڪيو ويو آهي. پر، جيئن مٿي ذڪر ڪيو ويو آهي، يونيڪوڊ ۾ نه رڳو انفرادي اکرن کي شمار ڪيو ويو آهي، پر انهن جا حصا ۽ خدمت جا نشان پڻ (۽ ڪڏهن ڪڏهن ڪجھ به نمبر سان ملندو آهي - شايد هن وقت تائين، پر اسان لاء اهو ضروري ناهي)، تنهنڪري. اهو وڌيڪ صحيح آهي ته هميشه خاص طور تي پنهنجي انگن جي تعداد بابت ڳالهايو، ۽ علامتن جي نه. بهرحال، هيٺ ڏنل ۾، اختصار جي خاطر، مان اڪثر لفظ ”علامت“ استعمال ڪندس، جنهن جي معنيٰ ”ڪوڊ پوائنٽ“ آهي.

يونيڪوڊ جهاز. جئين توهان ڏسي سگهو ٿا، ان مان گهڻا (جهاز 4 کان 13) اڃا تائين غير استعمال ٿيل آهن.

سڀ کان وڌيڪ قابل ذڪر اهو آهي ته سڀ مکيه "پلپ" صفر جهاز ۾ آهي، ان کي سڏيو ويندو آهي "بنيادي گهڻ لساني جهاز"جيڪڏهن هڪ لڪير جديد ٻولين مان ڪنهن هڪ ۾ متن تي مشتمل آهي (بشمول چيني)، توهان هن جهاز کان اڳتي نه ويندا. پر توهان باقي يونيڪوڊ کي به ڪٽي نٿا سگهو - مثال طور، ايموجي بنيادي طور تي آخر ۾ واقع آهن. ايندڙ جهاز،ضمني ملٽي لساني جهاز"(اهو پکڙيل آهي 0x10000 ڪرڻ 0x1FFFF). تنهن ڪري UTF-16 اهو ڪري ٿو: سڀئي ڪردار اندر اچي رهيا آهن بنيادي گهڻ لساني جهاز، انڪوڊ ٿيل آهن "جيئن آهي" هڪ لاڳاپيل ٻه بائيٽ نمبر سان. تنهن هوندي به، هن حد ۾ ڪجهه انگن اکرن کي خاص طور تي ظاهر نه ڪندا آهن، پر ظاهر ڪن ٿا ته بائيٽ جي هن جوڙي کان پوء اسان کي هڪ ٻئي تي غور ڪرڻ جي ضرورت آهي - انهن چئن بائيٽن جي قيمتن کي گڏ ڪرڻ سان، اسان کي هڪ نمبر ملي ٿو جيڪو احاطه ڪري ٿو. پوري صحيح يونيڪوڊ رينج. هن خيال کي سڏيو ويندو آهي "سروگيٽ جوڙو" - توهان شايد انهن بابت ٻڌو هوندو.

تنهن ڪري UTF-16 جي ضرورت آهي ٻه يا (تمام نادر ڪيسن ۾) چار بائيٽ في ”ڪوڊ پوائنٽ“. هي هر وقت چار بائيٽ استعمال ڪرڻ کان بهتر آهي، پر لاطيني (۽ ٻيا ASCII اکر) جڏهن هن طريقي سان انڪوڊ ڪيو ويو ته صفر تي اڌ جاءِ ضايع ڪري ٿي. UTF-8 هن کي درست ڪرڻ لاءِ ٺاهيو ويو آهي: ASCII ان ۾ قبضو ڪري ٿو، جيئن اڳ ۾، صرف هڪ بائيٽ؛ کان ڪوڊس 0x80 ڪرڻ 0x7FF - ٻه بائيٽ؛ کان 0x800 ڪرڻ 0xFFFF - ٽي، ۽ مان 0x10000 ڪرڻ 0x10FFFF - چار. هڪ پاسي، لاطيني الفابيٽ سٺو ٿي چڪو آهي: ASCII سان مطابقت واپس آئي آهي، ۽ تقسيم وڌيڪ هڪجهڙائي سان "پکڙيل" آهي 1 کان 4 بائيٽ تائين. پر لاطيني کان سواءِ ٻيا الفابيٽ، افسوس، UTF-16 جي مقابلي ۾ ڪنهن به طرح سان فائدو نه ٿا ڏين، ۽ ڪيترن کي هاڻي ٻن جي بدران ٽن بائيٽ جي ضرورت آهي - هڪ ٻه بائيٽ رڪارڊ سان ڍڪيل حد 32 ڀيرا تنگ ٿي وئي آهي، 0xFFFF ڪرڻ 0x7FF، ۽ نه ته چيني ۽ نه، مثال طور، جارجيا ان ۾ شامل آهن. سيريلڪ ۽ پنج ٻيا الفابيٽ - hurray - خوش قسمت، 2 بائيٽ في ڪردار.

ائين ڇو ٿو ٿئي؟ اچو ته ڏسون ته ڪيئن UTF-8 ڪردارن جي ڪوڊ جي نمائندگي ڪري ٿو:

سڌو سنئون انگن اکرن جي نمائندگي ڪرڻ لاء، نشان سان نشان لڳل بٽ هتي استعمال ڪيا ويا آهن x. اهو ڏسي سگهجي ٿو ته ٻه بائيٽ رڪارڊ ۾ صرف 11 اهڙا بٽ آهن (16 مان). هتي جي اڳوڻن بٽس وٽ صرف هڪ معاون ڪم آهي. چار بائيٽ رڪارڊ جي صورت ۾، ڪوڊ پوائنٽ نمبر لاءِ 21 مان 32 بِٽ مختص ڪيا ويا آهن- لڳي ٿو ته ٽي بائيٽ (جيڪي ڪل 24 بِٽ ڏين ٿا) ڪافي هوندا، پر سروس مارڪر تمام گهڻو کائي ويندا آهن.

ڇا هي خراب آهي؟ سچي نه. هڪ پاسي، جيڪڏهن اسان خلا جي باري ۾ تمام گهڻو خيال رکون ٿا، اسان وٽ کمپريشن الگورتھم آهن جيڪي آساني سان تمام اضافي اينٽراپي ۽ بيڪار کي ختم ڪري سگهن ٿيون. ٻئي طرف، يونيڪوڊ جو مقصد سڀ کان وڌيڪ عالمگير ڪوڊنگ مهيا ڪرڻ هو. مثال طور، اسان UTF-8 ۾ انڪوڊ ٿيل لائن کي ڪوڊ ڪرڻ جي حوالي ڪري سگھون ٿا جيڪو اڳ ۾ صرف ASCII سان ڪم ڪندو هو، ۽ ڊپ نه ٿيو ته اهو ASCII رينج مان هڪ ڪردار ڏسندو جيڪو اصل ۾ موجود ناهي (آخرڪار، UTF-8 ۾ سڀ بائيٽ صفر بٽ کان شروع ٿئي ٿو - اھو اھو آھي جيڪو ASCII آھي). ۽ جيڪڏهن اوچتو اسان چاهيون ٿا ته اوچتو ڪنهن وڏي تار مان هڪ ننڍڙي دم کي شروع کان ڊيڪوڊ ڪرڻ کان سواءِ ان کي ڪٽڻ (يا نقصان ٿيل حصي کان پوءِ معلومات جو حصو بحال ڪريو)، اسان لاءِ اهو آسان آهي ته اهو آفسٽ ڳولڻ آسان آهي جتي ڪردار شروع ٿئي ٿو (اهو ڪافي آهي. بائٽس کي ڇڏڻ لاءِ جنهن ۾ ٿورو اڳيئي هجي 10).

پوءِ ڇو ڪا نئين شيءِ ايجاد ڪئي؟

ساڳئي وقت، ڪڏهن ڪڏهن حالتون آهن جڏهن ڪمپريشن الگورتھم جهڙوڪ ڊيفليٽ خراب طور تي لاڳو ٿين ٿا، پر توهان حاصل ڪرڻ چاهيو ٿا اسٽرنگ جي جامع اسٽوريج کي. ذاتي طور تي، مون کي هن مسئلي جو سامنا ڪيو جڏهن تعمير بابت سوچيو compressed prefix وڻ هڪ وڏي ڊڪشنري لاءِ جنهن ۾ لفظن جا لفظ به شامل آهن. هڪ طرف، هر لفظ تمام ننڍو آهي، تنهنڪري ان کي دٻائڻ غير موثر ٿيندو. ٻئي طرف، وڻ تي عمل درآمد جنهن تي مون غور ڪيو ان کي ڊزائين ڪيو ويو ته جيئن ذخيرو ٿيل اسٽرنگ جي هر بائيٽ هڪ الڳ وڻ جي ويڪر ٺاهي، تنهنڪري انهن جي تعداد کي گھٽائڻ تمام مفيد هو. منهنجي لائبريري ۾ اي جي ايس (جيئن ۾ pymorphy2، جنهن تي ٻڌل آهي) هڪ ساڳيو مسئلو آساني سان حل ڪري سگهجي ٿو - تارن ۾ ڀريل DAWG- ڊڪشنري، اتي ذخيرو ٿيل سٺو پراڻو CP1251. پر، جيئن سمجھڻ ۾ آسان آھي، اھو ڪم صرف محدود الفابيٽ لاءِ آھي - چيني ٻوليءَ ۾ ھڪ ليڪ اھڙي ڊڪشنري ۾ شامل نه ٿي ڪري سگھجي.

الڳ الڳ، مان هڪ وڌيڪ ناپسنديده nuance نوٽ ڪرڻ چاهيان ٿو جيڪو پيدا ٿئي ٿو جڏهن UTF-8 استعمال ڪندي اهڙي ڊيٽا جي جوڙجڪ ۾. مٿي ڏنل تصوير ڏيکاري ٿي ته جڏهن هڪ ڪردار کي ٻه بائيٽ لکيو وڃي ٿو ته ان جي نمبر سان لاڳاپيل بٽ هڪ قطار ۾ نه ٿا اچن، پر بٽس جي هڪ جوڙي سان الڳ ٿي وڃن ٿا. 10 وچ ۾: 110xxxxx 10xxxxxx. انهي جي ڪري، جڏهن سيڪنڊ بائيٽ جا هيٺيان 6 بٽ ڪردار ڪوڊ ۾ اوور فلو (يعني، هڪ منتقلي ٿئي ٿي. 10111111 → 10000000)، پوء پهريون بائيٽ پڻ تبديل ڪري ٿو. اهو ظاهر ٿئي ٿو ته خط "p" بائيٽ طرفان ظاهر ڪيو ويو آهي 0xD0 0xBF، ۽ ايندڙ "r" اڳ ۾ ئي آهي 0xD1 0x80. هڪ اڳياڙيءَ واري وڻ ۾، هي پيرن نوڊ کي ٻن حصن ۾ ورهائڻ جو سبب بڻجي ٿو - هڪ اڳياڙي لاءِ 0xD0، ۽ ٻيو لاء 0xD1 (جيتوڻيڪ پوري سيريلڪ الفابيٽ کي صرف سيڪنڊ بائيٽ ذريعي انڪوڊ ڪري سگهجي ٿو).

مون کي ڇا مليو

هن مسئلي سان منهن ڏيڻ، مون بٽس سان رانديون کيڏڻ جي مشق ڪرڻ جو فيصلو ڪيو، ۽ ساڳئي وقت يونيڪوڊ جي مجموعي ساخت سان ٿورو بهتر واقف ٿي. نتيجو هو UTF-C انڪوڊنگ فارميٽ ("سي" لاءِ (توريت))، جيڪو خرچ نٿو ڪري 3 بائيٽ في ڪوڊ پوائنٽ کان وڌيڪ، ۽ گهڻو ڪري توهان کي صرف خرچ ڪرڻ جي اجازت ڏئي ٿو هڪ اضافي بائيٽ پوري انڪوڊ ٿيل لائن لاءِ. اهو حقيقت ڏانهن وٺي وڃي ٿو ته ڪيترن ئي غير ASCII الفابيٽ تي اهڙي انڪوڊنگ ٿي چڪي آهي UTF-30 کان 60-8٪ وڌيڪ ڪمپيڪٽ.

مون فارم ۾ انڪوڊنگ ۽ ڊيڪوڊنگ الگورتھم جي عمل درآمد جا مثال پيش ڪيا آھن JavaScript ۽ Go لائبريريون، توھان انھن کي آزاديءَ سان پنھنجي ڪوڊ ۾ استعمال ڪري سگھو ٿا. پر مان اڃا تائين زور ڏيندس ته هڪ لحاظ کان هي فارميٽ هڪ "سائيڪل" رهي ٿو، ۽ مان ان کي استعمال ڪرڻ جي سفارش نٿو ڪريان. بغير سمجهڻ جي توهان کي ان جي ضرورت ڇو آهي. اهو اڃا به وڌيڪ تجربو آهي هڪ سنجيده "UTF-8 جي بهتري" کان. پر ان جي باوجود، اتي ڪوڊ صاف طور تي لکيو ويو آهي، مختصر طور تي، وڏي تعداد ۾ تبصرن ۽ ٽيسٽ ڪوريج سان.

امتحان جا نتيجا ۽ UTF-8 سان مقابلو

مون پڻ ڪيو ڊيمو صفحوجتي توهان الگورتھم جي ڪارڪردگي جو اندازو لڳائي سگهو ٿا، ۽ پوء آئون توهان کي ان جي اصولن ۽ ترقي جي عمل بابت وڌيڪ ٻڌائيندس.

بيڪار بٽس کي ختم ڪرڻ

مون UTF-8 کي بنياد طور ورتو، يقينا. پهرين ۽ سڀ کان وڌيڪ واضح شيء جيڪا ان ۾ تبديل ٿي سگهي ٿي هر بائيٽ ۾ سروس بٽس جو تعداد گهٽائڻ آهي. مثال طور، UTF-8 ۾ پهريون بائيٽ هميشه ڪنهن سان شروع ٿئي ٿو 0، يا سان گڏ 11 - هڪ اڳوڻو 10 صرف هيٺ ڏنل بائيٽس وٽ آهن. اچو ته اڳيئي کي تبديل ڪريو 11 تي 1، ۽ ايندڙ بائيٽس لاءِ اسان اڳياڙين کي مڪمل طور تي ختم ڪنداسين. ڇا ٿيندو؟

0xxxxxxx - 1 بائيٽ
10xxxxxx xxxxxxxx - 2 بائيٽ
110xxxxx xxxxxxxx xxxxxxxx - 3 بائيٽ

انتظار ڪريو، چار بائيٽ رڪارڊ ڪٿي آهي؟ پر هاڻي ان جي ضرورت نه رهي آهي - جڏهن ٽن بائيٽ ۾ لکندا آهيون، اسان وٽ هاڻي 21 بٽ موجود آهن ۽ اهو سڀني نمبرن لاءِ ڪافي آهي. 0x10FFFF.

اسان هتي ڇا قربان ڪيو آهي؟ سڀ کان اهم شيء بفر ۾ هڪ خودمختيار مقام کان ڪردار جي حدن جي ڳولا آهي. اسان هڪ صوابديدي بائيٽ ڏانهن اشارو نٿا ڪري سگهون ۽ ان مان ايندڙ ڪردار جي شروعات ڳولي سگهون ٿا. هي اسان جي فارميٽ جي هڪ حد آهي، پر عملي طور تي اهو گهٽ ۾ گهٽ ضروري آهي. اسان عام طور تي شروع کان ئي بفر ذريعي هلڻ جي قابل آهيون (خاص طور تي جڏهن اهو اچي ٿو مختصر لائينون).

2 بائيٽ سان ٻولين کي ڍڪڻ جي صورتحال پڻ بهتر ٿي چڪي آهي: هاڻي ٻه بائيٽ فارميٽ 14 بٽ جي حد ڏئي ٿو، ۽ اهي ڪوڊ آهن 0x3FFF. چيني بدقسمت آهن (انهن جا ڪردار گهڻو ڪري حد تائين 0x4E00 ڪرڻ 0x9FFF)، پر جارجيا ۽ ٻين ڪيترن ئي ماڻهن کي وڌيڪ مزو آهي - انهن جون ٻوليون پڻ 2 بائيٽ في ڪردار ۾ مناسب آهن.

انڪوڊر اسٽيٽ داخل ڪريو

اچو ته هاڻي پاڻ کي لائنن جي خاصيتن بابت سوچيو. ڊڪشنريءَ ۾ اڪثر لفظ ساڳيا الفابيٽ جي اکرن ۾ لکيل هوندا آهن، ۽ اها ڳالهه ٻين ڪيترن ئي لکتن لاءِ به صحيح آهي. اھو بھتر ٿيندو ته ھن الفابيٽ کي ھڪ ڀيرو ڏيکاريو، ۽ پوءِ ان ۾ صرف اکر جو تعداد ڏيکاريو. اچو ته ڏسون ته يونيڪوڊ ٽيبل ۾ ڪردارن جي ترتيب اسان جي مدد ڪندي.

جيئن مٿي ڄاڻايل آهي، يونيڪوڊ ۾ ورهايل آهي جهاز 65536 ڪوڊ هر هڪ. پر هي هڪ تمام مفيد ڊويزن نه آهي (جيئن اڳ ۾ چيو ويو آهي، اڪثر ڪري اسان صفر جهاز ۾ آهيون). وڌيڪ دلچسپ تقسيم آهي بلاڪ. انهن حدن جي هاڻي ڪا مقرر ڊگھائي نه آهي، ۽ وڌيڪ معنيٰ وارا آهن - ضابطي جي طور تي، هر هڪ کي ساڳي الفابيٽ مان اکرن کي گڏ ڪري ٿو.

بنگالي الفابيٽ جي اکرن تي مشتمل هڪ بلاڪ. بدقسمتيءَ سان، تاريخي سببن لاءِ، هي هڪ مثال آهي نه تمام گهاٽي پيڪنگنگ جو - 96 اکرن ۾ 128 بلاڪ ڪوڊ پوائنٽس تي پکڙيل آهن.

بلاڪ جي شروعات ۽ انهن جي سائيز هميشه 16 جي ضربن ۾ آهن - اهو صرف سهولت لاء ڪيو ويو آهي. ان کان علاوه، ڪيترائي بلاڪ شروع ۽ ختم ٿين ٿا قدرن تي جيڪي 128 يا 256 کان به ملن ٿا - مثال طور، بنيادي سيريلڪ الفابيٽ 256 بائيٽ وٺي ٿو 0x0400 ڪرڻ 0x04FF. اهو ڪافي آسان آهي: جيڪڏهن اسان هڪ ڀيرو اڳفڪس کي بچايو 0x04، پوءِ ڪنهن به سيريلڪ ڪردار کي هڪ بائيٽ ۾ لکي سگهجي ٿو. سچ، هن طريقي سان اسان ASCII ڏانهن موٽڻ جو موقعو وڃائي ڇڏينداسين (۽ عام طور تي ڪنهن ٻئي اکرن ڏانهن). تنهن ڪري اسان هي ڪريون ٿا:

1. ٻه بائيٽ 10yyyyyy yxxxxxxx نه رڳو هڪ نمبر سان علامت ظاهر ڪريو yyyyyy yxxxxxxx، پر پڻ تبديلي موجوده الفابيٽ تي yyyyyy y0000000 (يعني اسان سڀني بٽن کي ياد رکون ٿا سواءِ گهٽ ۾ گهٽ اهم 7 بٽ);
2. هڪ بائيٽ 0xxxxxxx هي موجوده الفابيٽ جو ڪردار آهي. ان کي صرف آفسيٽ ۾ شامل ڪرڻ جي ضرورت آھي جيڪا اسان کي قدم 1 ۾ ياد آھي. جڏھن ته اسان الفابيٽ کي تبديل نه ڪيو آھي، آفسيٽ صفر آھي، تنھنڪري اسان ASCII سان مطابقت برقرار رکي.

ساڳئي طرح 3 بائيٽ جي ضرورتن لاءِ ڪوڊس:

1. ٽي بائيٽ 110yyyyy yxxxxxxx xxxxxxxx هڪ عدد سان علامت ظاهر ڪريو yyyyyy yxxxxxxx xxxxxxxx، تبديلي موجوده الفابيٽ تي yyyyyy y0000000 00000000 (سڀ ڪجهه ياد آهي سواءِ ننڍن جي 15 بٽ)، ۽ دٻي کي چيڪ ڪريو جنهن ۾ اسان هاڻي آهيون ڊگهو موڊ (جڏهن الفابيٽ کي واپس ڊبل بائيٽ ۾ تبديل ڪيو وڃي، اسان هن پرچم کي ري سيٽ ڪنداسين)؛
2. ٻه بائيٽ 0xxxxxxx xxxxxxxx ڊگهي موڊ ۾ اهو موجوده الفابيٽ جو ڪردار آهي. اهڙي طرح، اسان ان کي قدم 1 کان آفسيٽ سان شامل ڪندا آهيون. فرق صرف اهو آهي ته هاڻي اسان ٻه بائيٽ پڙهون ٿا (ڇاڪاڻ ته اسان هن موڊ تي سوئچ ڪيو آهي).

آواز سٺو: ھاڻي جڏھن اسان کي اکرن کي انڪوڊ ڪرڻ جي ضرورت آھي ساڳي 7-bit يونيڪوڊ رينج مان، اسان خرچ ڪريون ٿا 1 اضافي بائيٽ شروع ۾ ۽ ڪل ھڪ بائيٽ في اکر.

اڳوڻي نسخن مان هڪ کان ڪم. اهو اڳ ۾ ئي اڪثر ڪري ٿو UTF-8، پر اڃا به بهتري لاء ڪمرو آهي.

ڇا خراب آهي؟ پهرين، اسان وٽ هڪ شرط آهي، يعني موجوده الفابيٽ آفسيٽ ۽ چيڪ باڪس ڊگهو موڊ. هي اسان کي وڌيڪ حد تائين محدود ڪري ٿو: هاڻي ساڳيا اکرن کي مختلف صورتن ۾ انڪوڊ ڪري سگهجي ٿو. ذيلي اسٽرنگ جي ڳولا، مثال طور، هن کي حساب ۾ رکڻو پوندو، ۽ نه صرف بائيٽ جي مقابلي سان. ٻيو، جيئن ئي اسان الفابيٽ کي تبديل ڪيو، اهو ASCII اکرن جي انڪوڊنگ سان خراب ٿي ويو (۽ اهو نه رڳو لاطيني الفابيٽ آهي، پر بنيادي رموز پڻ شامل آهن، جن ۾ اسپيس شامل آهن) - انهن کي الفابيٽ کي ٻيهر 0 ۾ تبديل ڪرڻ جي ضرورت آهي، يعني، ٻيهر هڪ اضافي بائيٽ (۽ پوءِ هڪ ٻيو اسان جي مکيه نقطي ڏانهن واپس وڃڻ لاءِ).

هڪ الفابيٽ سٺو آهي، ٻه بهتر آهي

اچو ته ڪوشش ڪريون ته اسان جي بٽ اڳياڙين کي ٿورو تبديل ڪريون، مٿي بيان ڪيل ٽن کي وڌيڪ هڪ ۾ نچوڙي:

0xxxxxxx - 1 بائيٽ عام موڊ ۾، 2 ڊگھي موڊ ۾
11xxxxxx - 1 بائيٽ
100xxxxx xxxxxxxx - 2 بائيٽ
101xxxxx xxxxxxxx xxxxxxxx - 3 بائيٽ

ھاڻي ھڪڙي ٻن بائيٽ رڪارڊ ۾ ھڪڙو گھٽ دستياب بٽ آھي - ڪوڊ پوائنٽس تائين 0x1FFF۽ نه 0x3FFF. بهرحال، اهو اڃا تائين نمايان طور تي وڏو آهي ڊبل بائيٽ UTF-8 ڪوڊس ۾، اڪثر عام ٻوليون اڃا به مناسب آهن، سڀ کان وڌيڪ قابل ذڪر نقصان ختم ٿي چڪو آهي. هيراگانا и ڪٽڪانا، جاپاني اداس آهن.

هي نئون ڪوڊ ڇا آهي؟ 11xxxxxx؟ هي 64 اکرن جي سائيز جو هڪ ننڍڙو "اسٽيش" آهي، اهو اسان جي مکيه الفابيٽ کي پورو ڪري ٿو، تنهنڪري مون ان کي معاون سڏيو (معاون) الفابيٽ. جڏهن اسان موجوده الفابيٽ کي تبديل ڪندا آهيون، پراڻي الفابيٽ جو هڪ ٽڪرو مددگار بڻجي ويندو آهي. مثال طور، اسان ASCII کان Cyrillic ڏانهن تبديل ڪيو - اسٽش هاڻي 64 اکرن تي مشتمل آهي لاطيني الفابيٽ، انگ، اسپيس ۽ ڪاما (غير ASCII نصوص ۾ اڪثر داخل ٿيڻ). واپس وڃو ASCII - ۽ سريلڪ الفابيٽ جو مکيه حصو مددگار الفابيٽ بڻجي ويندو.

ٻن الفابيٽ تائين رسائي ڪرڻ جي مهرباني، اسان الفابيٽ کي مٽائڻ لاءِ گهٽ ۾ گهٽ خرچن سان وڏي تعداد ۾ متن کي سنڀالي سگهون ٿا (اوقاف اڪثر ڪري ASCII ڏانهن واپسي جو سبب بڻجندو، پر ان کان پوءِ اسان کي اضافي الفابيٽ مان ڪيترائي غير ASCII اکر ملندا، بغير ٻيهر تبديل ڪرڻ).

بونس: ذيلي الفابيٽ جي اڳڀرائي 11xxxxxx ۽ ان جي شروعاتي آفسيٽ کي چونڊڻ لاء 0xC0اسان CP1252 سان جزوي مطابقت حاصل ڪندا آهيون. ٻين لفظن ۾، CP1252 ۾ انڪوڊ ٿيل ڪيترائي (پر سڀ نه) مغربي يورپي متن UTF-C ۾ ساڳيا نظر ايندا.

هتي، تنهن هوندي، هڪ مشڪل پيدا ٿئي ٿي: مکيه الفابيٽ مان هڪ معاون هڪ ڪيئن حاصل ڪجي؟ توهان هڪ ئي آفسٽ ڇڏي سگهو ٿا، پر افسوس - هتي يونيڪوڊ ڍانچي اڳ ۾ ئي اسان جي خلاف راند ڪري رهيو آهي. گهڻو ڪري الفابيٽ جو مکيه حصو بلاڪ جي شروعات ۾ نه آهي (مثال طور، روسي راڄڌاني "اي" جو ڪوڊ آهي. 0x0410، جيتوڻيڪ سيريلڪ بلاڪ سان شروع ٿئي ٿو 0x0400). اهڙيءَ طرح، پهرين 64 اکرن کي اسٽش ۾ وٺي وڃڻ سان، اسان الفابيٽ جي دم واري حصي تائين رسائي وڃائي سگهون ٿا.

ھن مسئلي کي حل ڪرڻ لاءِ، مون دستي طور مختلف ٻولين سان ملندڙ ڪجھ بلاڪن مان گذريو، ۽ انھن لاءِ مکيه الفابيٽ جي اندر معاون الفابيٽ جو آفسٽ بيان ڪيو. لاطيني الفابيٽ، هڪ استثنا جي طور تي، عام طور تي بيس 64 وانگر ترتيب ڏني وئي هئي.

آخري لمس

اچو ته آخر ۾ سوچيون ته ٻيو ڪٿي اسان ڪجهه بهتر ڪري سگهون ٿا.

نوٽ ڪريو ته فارميٽ 101xxxxx xxxxxxxx xxxxxxxx توهان کي نمبرن تائين انڪوڊ ڪرڻ جي اجازت ڏئي ٿي 0x1FFFFF، ۽ يونيڪوڊ اڳ ۾ ختم ٿئي ٿو، تي 0x10FFFF. ٻين لفظن ۾، آخري ڪوڊ پوائنٽ جي نمائندگي ڪئي ويندي 10110000 11111111 11111111. تنهن ڪري، اسان اهو چئي سگهون ٿا ته جيڪڏهن پهريون بائيٽ فارم جو آهي 1011xxxx (ڪٿي xxxx 0 کان وڌيڪ)، پوء ان جو مطلب ڪجھ ٻيو آھي. مثال طور، توھان اتي ٻيا 15 اکر شامل ڪري سگھو ٿا جيڪي مسلسل ھڪڙي بائيٽ ۾ انڪوڊنگ لاءِ موجود آھن، پر مون ان کي مختلف طريقي سان ڪرڻ جو فيصلو ڪيو.

اچو ته انهن يونيڪوڊ بلاڪن تي نظر وجهون جن کي هاڻي ٽي بائيٽ جي ضرورت آهي. بنيادي طور تي، جيئن اڳ ۾ ئي ذڪر ڪيو ويو آهي، اهي چيني ڪردار آهن - پر انهن سان ڪجهه ڪرڻ ڏکيو آهي، انهن مان 21 هزار آهن. پر هيراگانا ۽ ڪٽڪانا به اُتي اُڏامڻ لڳا- ۽ اُتي اُنهن مان ڪي به نه آهن، ٻه سؤ کان به گهٽ. ۽، جتان اسان کي جاپاني ياد آيا، اتي ايمجيس پڻ آهن (حقيقت ۾، اهي يونيڪوڊ ۾ ڪيترن ئي هنڌن تي پکڙيل آهن، پر مکيه بلاڪ رينج ۾ آهن. 0x1F300 - 0x1FBFF). جيڪڏهن توهان هن حقيقت جي باري ۾ سوچيو ته هاڻي ايمجسي آهن جيڪي هڪ ئي وقت ۾ ڪيترن ئي ڪوڊ پوائنٽس کان گڏ ڪيا ويا آهن (مثال طور، ايموجي ‍‍‍ جيتري قدر 7 ڪوڊس تي مشتمل آهي!)، پوءِ هر هڪ تي ٽي بائيٽ خرچ ڪرڻ هڪ مڪمل شرم جي ڳالهه آهي (7 × 3 = 21 بائيٽ هڪ آئڪن جي خاطر، هڪ خواب ڏسڻ).

تنهن ڪري، اسان ڪجھ چونڊيل حدون چونڊون ٿا جيڪي ايموجي، هيراگانا ۽ ڪتاڪانا سان لاڳاپيل آهن، انهن کي هڪ لڳاتار لسٽ ۾ ٻيهر نمبر ڏيو ۽ انهن کي ٽن بدران ٻن بائيٽ طور انڪوڊ ڪيو:

1011xxxx xxxxxxxx

عظيم: مٿي بيان ڪيل ايموجي، 7 ڪوڊ پوائنٽس تي مشتمل آهي، UTF-8 ۾ 25 بائيٽ وٺي ٿو، ۽ اسان ان کي درست ڪريون ٿا 14 (هر ڪوڊ پوائنٽ لاءِ بلڪل ٻه بائيٽ). رستي ۾، حبر ان کي هضم ڪرڻ کان انڪار ڪيو (ٻئي پراڻن ۽ نئين ايڊيٽر ۾)، تنهنڪري مون کي ان کي تصوير سان شامل ڪرڻو پيو.

اچو ته هڪ ٻيو مسئلو حل ڪرڻ جي ڪوشش ڪريون. جيئن اسان کي ياد آهي، بنيادي الفابيٽ لازمي طور تي آهي اعلي 6 بٽ، جنهن کي اسان ذهن ۾ رکون ٿا ۽ هر ايندڙ ڊيڪوڊ ٿيل علامت جي ڪوڊ سان ڳنڍيندا آهيون. چيني اکرن جي صورت ۾ جيڪي بلاڪ ۾ آهن 0x4E00 - 0x9FFF, هي يا ته bit 0 يا 1 آهي. هي تمام آسان ناهي: اسان کي انهن ٻن قدرن جي وچ ۾ الفابيٽ کي مسلسل مٽائڻو پوندو (يعني ٽي بائيٽ خرچ ڪريو). پر نوٽ ڪريو ته ڊگھي موڊ ۾، ڪوڊ مان ئي اسان انھن اکرن جو تعداد گھٽائي سگھون ٿا جن کي اسان شارٽ موڊ استعمال ڪندي انڪوڊ ڪندا آھيون (مٿي بيان ڪيل سڀني ٽوڪن کان پوءِ، ھي آھي 10240) - پوءِ ھيروگليفس جي حد تبديل ٿي ويندي. 0x2600 - 0x77FF، ۽ ان صورت ۾، هن سڄي رينج ۾، سڀ کان اهم 6 بٽ (21 مان) 0 جي برابر هوندا. اهڙيءَ طرح، هائيروگليفس جا تسلسل ٻه بائيٽ استعمال ڪندا في هائيروگليف (جيڪا اهڙي وڏي رينج لاءِ بهتر آهي)، بغير الفابيٽ سوئچ جو سبب بڻجڻ.

متبادل حل: SCSU، BOCU-1

يونيڪوڊ جا ماهر، مضمون جو عنوان پڙهڻ کان پوءِ، گهڻو ڪري جلدي جلدي توهان کي ياد ڏياريندا ته يونيڪوڊ معيارن ۾ سڌو سنئون موجود آهي. يونيڪوڊ لاءِ معياري ڪمپريشن اسڪيم (SCSU)، جيڪو مضمون ۾ بيان ڪيل انڪوڊنگ جو طريقو بلڪل ساڳيو بيان ڪري ٿو.

مان ايمانداري سان اعتراف ڪريان ٿو: مون کي ان جي وجود جي باري ۾ تڏهن ئي معلوم ٿيو، جڏهن مان پنهنجي فيصلي کي لکڻ ۾ ڏاڍي غرق ٿي ويس. جيڪڏهن مون کي ان جي باري ۾ شروعات کان ئي خبر هجي ها ته شايد مان ڪوشش ڪريان ها ته ان تي عمل ڪرڻ بجاءِ پنهنجي طريقي سان عمل ڪرڻ بدران.

دلچسپ ڳالهه اها آهي ته SCSU انهن خيالن سان بلڪل ملندڙ جلندڙ خيالن کي استعمال ڪري ٿو جيڪي مون پاڻ سان گڏ ڪيا آهن (جنهن ”الف بيٽس“ جي تصور جي بدران اهي ”ونڊوز“ استعمال ڪن ٿا، ۽ انهن مان وڌيڪ مون وٽ موجود آهن). ساڳئي وقت، هن فارميٽ ۾ پڻ نقصانات آهن: اهو انڪوڊنگ وارن جي ڀيٽ ۾ کمپريشن الگورتھم جي ٿورو ويجهو آهي. خاص طور تي، معيار ڪيترن ئي نمائندگي جي طريقن کي ڏئي ٿو، پر اهو نه ٿو چوي ته ڪيئن چونڊيو هڪ بهترين چونڊيو - ان لاء، انڪوڊر کي ڪجهه قسم جي هوريسٽ استعمال ڪرڻ گهرجي. اهڙيء طرح، هڪ SCSU انڪوڊر جيڪو سٺو پيڪنگنگ پيدا ڪري ٿو منهنجي الگورتھم کان وڌيڪ پيچيده ۽ وڌيڪ پيچيده هوندو.

مقابلي لاءِ، مون SCSU جو هڪ نسبتاً سادو عمل JavaScript ڏانهن منتقل ڪيو- ڪوڊ جي مقدار جي لحاظ کان اهو منهنجي UTF-C جي مقابلي ۾ نڪتو، پر ڪجهه حالتن ۾ نتيجو ڏهه سيڪڙو خراب هو (ڪڏهن ڪڏهن اهو ان کان به وڌي سگهي ٿو، پر گهڻو نه). مثال طور، عبراني ۽ يوناني ۾ نصوص UTF-C پاران انڪوڊ ڪيا ويا 60٪ SCSU کان بهتر (شايد انهن جي ٺهڪندڙ الفابيٽ جي ڪري).

الڳ الڳ، مان شامل ڪندس ته SCSU کان علاوه يونيڪوڊ جي نمائندگي ڪرڻ جو هڪ ٻيو طريقو پڻ آهي. BOCU-1، پر اهو مقصد MIME مطابقت (جنهن جي مون کي ضرورت نه هئي) لاءِ آهي ۽ انڪوڊنگ لاءِ ٿورو مختلف طريقو اختيار ڪري ٿو. مون ان جي اثرائتي جو اندازو نه ڪيو آهي، پر اهو مون کي لڳي ٿو ته اهو ممڪن ناهي ته اهو SCSU کان وڌيڪ هجي.

ممڪن بهتري

جيڪو الگورتھم مون پيش ڪيو آھي اھو ڊزائن جي لحاظ کان آفاقي نه آھي (شايد اھو اھو آھي جتي منھنجا مقصد يونيڪوڊ ڪنسورشيم جي مقصدن کان گھڻا ڌار ٿين ٿا). مون اڳ ۾ ئي ذڪر ڪيو آهي ته اهو بنيادي طور تي هڪ ڪم لاءِ ٺاهيو ويو هو (هڪ اڳياڙيءَ جي وڻ ۾ هڪ گهڻ لساني لغت کي محفوظ ڪرڻ) ۽ ان جون ڪجهه خاصيتون ٻين ڪمن لاءِ مناسب نه هونديون. پر حقيقت اها آهي ته اهو معيار نه آهي هڪ پلس ٿي سگهي ٿو - توھان آساني سان تبديل ڪري سگھوٿا توھان جي ضرورتن مطابق.

مثال طور، واضح طريقي سان توهان رياست جي موجودگي کان نجات حاصل ڪري سگهو ٿا، بنا رياستي ڪوڊنگ - صرف متغيرن کي اپڊيٽ نه ڪريو offs, auxOffs и is21Bit انڪوڊر ۽ ڊيڪوڊر ۾. انهي صورت ۾، اهو ممڪن نه ٿيندو ته ساڳئي الفابيٽ جي اکرن جي ترتيبن کي مؤثر انداز سان پيڪ ڪرڻ، پر اتي هڪ گارنٽي هوندي ته هڪ ئي ڪردار هميشه ساڳئي بائيٽ سان انڪوڊ ڪيو ويندو آهي، ڪنهن به حوالي سان.

ان کان علاوه، توهان ڊفالٽ اسٽيٽ کي تبديل ڪندي انڪوڊر کي مخصوص ٻولي ۾ ترتيب ڏئي سگهو ٿا - مثال طور، روسي متن تي ڌيان ڏيڻ، شروع ۾ انڪوڊر ۽ ڊيڪوڊر سيٽ ڪريو offs = 0x0400 и auxOffs = 0. اهو خاص طور تي بي رياستي موڊ جي صورت ۾ احساس ڪري ٿو. عام طور تي، اهو ساڳيو هوندو جيڪو پراڻي اٺ-بٽ انڪوڊنگ کي استعمال ڪندي، پر ضرورت جي مطابق سڀني يونيڪوڊ مان ڪردارن کي داخل ڪرڻ جي صلاحيت کي هٽائڻ کان سواء.

اڳ ۾ ذڪر ڪيل هڪ ٻي خرابي اها آهي ته UTF-C ۾ انڪوڊ ٿيل وڏي ٽيڪسٽ ۾ ڪو به تڪڙو رستو نه آهي ته ڪردار جي حد کي ڳولڻ جو هڪ صوابديدي بائيٽ جي ويجهو آهي. جيڪڏهن توهان آخري کي ڪٽي ڇڏيو، چئو، انڪوڊ ٿيل بفر مان 100 بائيٽ، توهان کي گندگي حاصل ڪرڻ جو خطرو آهي جنهن سان توهان ڪجهه به نٿا ڪري سگهو. انڪوڊنگ ملٽي گيگا بائيٽ لاگز کي محفوظ ڪرڻ لاءِ ٺهيل نه آهي، پر عام طور تي هن کي درست ڪري سگهجي ٿو. بائيٽ 0xBF پهرين بائيٽ وانگر ڪڏهن به ظاهر نه ٿيڻ گهرجي (پر ٿي سگهي ٿو ٻيو يا ٽيون). تنهن ڪري، جڏهن انڪوڊنگ، توهان ترتيب داخل ڪري سگهو ٿا 0xBF 0xBF 0xBF هر، چئو، 10 KB - پوء، جيڪڏهن توهان کي حد ڳولڻ جي ضرورت آهي، اهو ڪافي هوندو ته چونڊيل ٽڪرا اسڪين ڪرڻ لاء جيستائين هڪ جهڙو مارڪر نه ملي. پوئين پٺيان 0xBF هڪ ڪردار جي شروعات هجڻ جي ضمانت آهي. (جڏهن ڊيڪوڊنگ، ٽن بائيٽ جو هي سلسلو، يقينا، نظر انداز ڪرڻ جي ضرورت آهي.)

مختصر ڪرڻ لاء

جيڪڏهن توهان هن پري پڙهيو آهي، مبارڪون هجن! مون کي اميد آهي ته توهان، مون وانگر، يونيڪوڊ جي جوڙجڪ بابت ڪجهه نئون (يا توهان جي يادگيري کي تازو ڪيو) سکيو هوندو.

ڊيمو صفحو. عبراني جو مثال UTF-8 ۽ SCSU ٻنهي جي فائدن کي ڏيکاري ٿو.

مٿي بيان ڪيل تحقيق کي معيار تي قبضو نه سمجهيو وڃي. بهرحال، مان عام طور تي منهنجي ڪم جي نتيجن سان مطمئن آهيان، تنهنڪري مان انهن سان خوش آهيان حصيداري ڪريو: مثال طور، هڪ ننڍڙي JS لائبريري جو وزن صرف 1710 بائيٽ آهي (۽ يقينن ڪو به انحصار ناهي). جيئن مون مٿي ذڪر ڪيو آهي، هن جو ڪم هتي ڳولي سگهجي ٿو ڊيمو صفحو (اتي پڻ نصوص جو هڪ سيٽ آهي جنهن تي اهو UTF-8 ۽ SCSU سان مقابلو ڪري سگهجي ٿو).

آخرڪار، مان هڪ ڀيرو ٻيهر ڪيسن ڏانهن ڌيان ڏيندس جن ۾ UTF-C استعمال ڪيو ويو آهي ان جي قابل نه آهي:

• جيڪڏھن توھان جون لائينون ڪافي ڊگھيون آھن (100-200 اکرن کان). انهي حالت ۾، توهان کي استعمال ڪرڻ جي باري ۾ سوچڻ گهرجي کمپريشن الگورتھم جهڙوڪ ڊفليٽ.
• جيڪڏھن توھان کي ضرورت آھي ASCII شفافيت، اهو آهي، اهو توهان لاءِ ضروري آهي ته انڪوڊ ٿيل ترتيبن ۾ ASCII ڪوڊ شامل نه هجن جيڪي اصل اسٽرنگ ۾ نه هئا. ان جي ضرورت کان بچي سگهجي ٿو جيڪڏهن، جڏهن ٽئين پارٽي APIs سان لهه وچڙ ۾ هجي (مثال طور، هڪ ڊيٽابيس سان ڪم ڪندي)، توهان انڪوڊنگ نتيجو پاس ڪريو بائٽس جي هڪ خلاصي سيٽ جي طور تي، نه ڪي تارن جي طور تي. ٻي صورت ۾، توهان کي غير متوقع خطرات حاصل ڪرڻ جو خطرو آهي.
• جيڪڏھن توھان چاھيو ٿا ته جلدي ڪردار جي حدن کي ڳولڻ جي قابل ٿي ھڪڙي خودمختيار آفسيٽ تي (مثال طور، جڏھن ھڪڙي لڪير جو حصو خراب ٿئي). اهو ٿي سگهي ٿو، پر صرف شروع کان لائن کي اسڪين ڪرڻ سان (يا پوئين حصي ۾ بيان ڪيل ترميم کي لاڳو ڪرڻ).
• جيڪڏهن توهان کي ضرورت آهي ته تيزيءَ سان اسٽرنگ جي مواد تي عمل ڪريو (انهن کي ترتيب ڏيو، انهن ۾ سب اسٽرنگ جي ڳولا ڪريو، ڪنٽينيٽ ڪريو). ان لاءِ ضروري آهي ته تارن کي پهريان ڊيڪوڊ ڪيو وڃي، تنهن ڪري UTF-C انهن ڪيسن ۾ UTF-8 کان سست هوندو (پر ڪمپريشن الگورٿم کان تيز). جيئن ته هڪ ئي اسٽرنگ هميشه ساڳئي طريقي سان انڪوڊ ڪيو ويندو آهي، ڊيڪوڊنگ جي صحيح مقابلي جي ضرورت ناهي ۽ بائيٽ بائيٽ جي بنياد تي ڪري سگهجي ٿو.

تازه: استعمال ڪندڙ ٽاميچ هيٺ ڏنل تبصرن ۾ UTF-C جي قابل اطلاق حدن کي نمايان ڪندي گراف پوسٽ ڪيو. اهو ڏيکاري ٿو ته UTF-C عام-مقصد ڪمپريشن الگورٿم (LZW جي هڪ تبديلي) کان وڌيڪ ڪارائتو آهي جيستائين ڀريل اسٽرنگ ننڍو آهي. ~ 140 اکر (جڏهن ته، مون کي ياد آهي ته مقابلو هڪ متن تي ڪيو ويو آهي؛ ٻين ٻولين لاء نتيجو مختلف ٿي سگهي ٿو).


جو ذريعو: www.habr.com