ایک اور موٹر سائیکل: ہم یونیکوڈ سٹرنگز کو UTF-30 سے 60-8% زیادہ کمپیکٹ اسٹور کرتے ہیں

اگر آپ ایک ڈویلپر ہیں اور آپ کو انکوڈنگ کا انتخاب کرنے کا کام درپیش ہے، تو یونیکوڈ تقریباً ہمیشہ ہی صحیح حل ہوگا۔ مخصوص نمائندگی کا طریقہ سیاق و سباق پر منحصر ہے، لیکن اکثر یہاں بھی ایک عالمگیر جواب ہوتا ہے - UTF-8۔ اس کے بارے میں اچھی بات یہ ہے کہ یہ آپ کو بغیر خرچ کیے تمام یونیکوڈ حروف استعمال کرنے کی اجازت دیتا ہے۔ بھی زیادہ تر معاملات میں بہت زیادہ بائٹس۔ سچ ہے، ایسی زبانوں کے لیے جو صرف لاطینی حروف تہجی سے زیادہ استعمال کرتی ہیں، "زیادہ نہیں" کم از کم دو بائٹس فی کریکٹر. کیا ہم پراگیتہاسک انکوڈنگز پر واپس آئے بغیر بہتر کر سکتے ہیں جو ہمیں صرف 256 دستیاب حروف تک محدود رکھتے ہیں؟

ذیل میں میں اس سوال کا جواب دینے کی اپنی کوشش سے اپنے آپ کو واقف کرنے اور نسبتاً آسان الگورتھم کو لاگو کرنے کی تجویز پیش کرتا ہوں جو آپ کو UTF-8 میں موجود فالتو پن کو شامل کیے بغیر دنیا کی زیادہ تر زبانوں میں لائنوں کو ذخیرہ کرنے کی اجازت دیتا ہے۔

ڈس کلیمر میں فوری طور پر چند اہم تحفظات کروں گا: بیان کردہ حل UTF-8 کے عالمی متبادل کے طور پر پیش نہیں کیا جاتا ہے۔، یہ صرف معاملات کی ایک تنگ فہرست میں موزوں ہے (ذیل میں ان پر مزید)، اور کسی بھی صورت میں اسے فریق ثالث APIs کے ساتھ تعامل کے لیے استعمال نہیں کیا جانا چاہیے (جو اس کے بارے میں بھی نہیں جانتے ہیں)۔ اکثر، عام مقصد کے کمپریشن الگورتھم (مثال کے طور پر، ڈیفلیٹ) ٹیکسٹ ڈیٹا کی بڑی مقدار کے کمپیکٹ اسٹوریج کے لیے موزوں ہوتے ہیں۔ اس کے علاوہ، پہلے سے ہی اپنا حل بنانے کے عمل میں، مجھے خود یونیکوڈ میں ایک موجودہ معیار ملا، جو اسی مسئلے کو حل کرتا ہے - یہ کچھ زیادہ پیچیدہ (اور اکثر بدتر) ہے، لیکن پھر بھی یہ ایک قبول شدہ معیار ہے، اور نہ صرف ایک ساتھ گھٹنے پر. میں آپ کو اس کے بارے میں بھی بتاؤں گا۔

یونیکوڈ اور UTF-8 کے بارے میں

شروع کرنے کے لئے، یہ کیا ہے کے بارے میں چند الفاظ یونیکوڈ۔ и UTF-8.

جیسا کہ آپ جانتے ہیں، 8 بٹ انکوڈنگز مقبول ہوا کرتی تھیں۔ ان کے ساتھ، سب کچھ آسان تھا: 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).

پھر کچھ نیا کیوں ایجاد کیا؟

ایک ہی وقت میں، کبھی کبھار ایسے حالات ہوتے ہیں جب کمپریشن الگورتھم جیسے ڈیفلیٹ کا اطلاق ناقص ہوتا ہے، لیکن آپ تاروں کا کمپیکٹ اسٹوریج حاصل کرنا چاہتے ہیں۔ ذاتی طور پر، عمارت کے بارے میں سوچتے وقت مجھے اس مسئلے کا سامنا کرنا پڑا کمپریسڈ سابقہ ​​درخت صوابدیدی زبانوں کے الفاظ سمیت ایک بڑی لغت کے لیے۔ ایک طرف، ہر لفظ بہت مختصر ہے، اس لیے اسے کمپریس کرنا بے اثر ہوگا۔ دوسری طرف، درختوں کے نفاذ کو جس پر میں نے غور کیا اس طرح ڈیزائن کیا گیا تھا کہ ذخیرہ شدہ سٹرنگ کے ہر بائٹ نے ایک علیحدہ درخت کی چوٹی پیدا کی، لہذا ان کی تعداد کو کم کرنا بہت مفید تھا۔ میری لائبریری میں Az.js (جیسا کہ میں pymorphy2، جس پر یہ مبنی ہے) اسی طرح کے مسئلے کو آسانی سے حل کیا جاسکتا ہے - اس میں بھرے ہوئے تار ڈی اے ڈبلیو جی- ڈکشنری، اس میں محفوظ ہے۔ اچھا پرانا CP1251. لیکن، جیسا کہ سمجھنا آسان ہے، یہ صرف ایک محدود حروف تہجی کے لیے اچھی طرح کام کرتا ہے - چینی زبان میں کوئی سطر ایسی لغت میں شامل نہیں کی جا سکتی۔

الگ سے، میں ایک اور ناخوشگوار نزاکت کو نوٹ کرنا چاہوں گا جو اس طرح کے ڈیٹا ڈھانچے میں UTF-8 استعمال کرتے وقت پیدا ہوتا ہے۔ اوپر دی گئی تصویر سے پتہ چلتا ہے کہ جب کسی حرف کو دو بائٹس کے طور پر لکھا جاتا ہے تو اس کے نمبر سے متعلق بٹس ایک قطار میں نہیں آتے بلکہ بٹس کے جوڑے سے الگ ہوتے ہیں۔ 10 درمیان میں: 110xxxxx 10xxxxxx. اس کی وجہ سے، جب کریکٹر کوڈ میں دوسرے بائٹ کے نچلے 6 بٹ اوور فلو ہوتے ہیں (یعنی، ایک منتقلی ہوتی ہے 10111111 → 10000000)، پھر پہلا بائٹ بھی بدل جاتا ہے۔ یہ پتہ چلتا ہے کہ حرف "p" بائٹس سے ظاہر ہوتا ہے۔ 0xD0 0xBF، اور اگلا "r" پہلے ہی ہے۔ 0xD1 0x80. ایک سابقہ ​​درخت میں، یہ پیرنٹ نوڈ کو دو حصوں میں تقسیم کرنے کا باعث بنتا ہے - ایک سابقہ ​​کے لیے 0xD0، اور دوسرے کے لیے 0xD1 (حالانکہ پورے سیریلک حروف تہجی کو صرف دوسرے بائٹ سے انکوڈ کیا جا سکتا ہے)۔

مجھے کیا ملا

اس مسئلے کا سامنا کرتے ہوئے، میں نے بٹس کے ساتھ گیمز کھیلنے کی مشق کرنے کا فیصلہ کیا، اور ساتھ ہی ساتھ مجموعی طور پر یونیکوڈ کی ساخت سے قدرے بہتر واقفیت حاصل کی۔ نتیجہ UTF-C انکوڈنگ فارمیٹ تھا ("C" for کمپیکٹ)، جو فی کوڈ پوائنٹ 3 بائٹس سے زیادہ خرچ نہیں کرتا ہے، اور اکثر آپ کو صرف خرچ کرنے کی اجازت دیتا ہے۔ پوری انکوڈ لائن کے لیے ایک اضافی بائٹ. یہ اس حقیقت کی طرف جاتا ہے کہ بہت سے غیر ASCII حروف تہجی پر اس طرح کی انکوڈنگ ہوتی ہے۔ UTF-30 سے 60-8% زیادہ کمپیکٹ.

میں نے فارم میں انکوڈنگ اور ڈی کوڈنگ الگورتھم کے نفاذ کی مثالیں پیش کی ہیں۔ جاوا اسکرپٹ اور گو لائبریریاں، آپ انہیں اپنے کوڈ میں آزادانہ طور پر استعمال کرسکتے ہیں۔ لیکن میں پھر بھی اس بات پر زور دوں گا کہ ایک لحاظ سے یہ فارمیٹ ایک "سائیکل" ہی رہتا ہے، اور میں اسے استعمال کرنے کی سفارش نہیں کرتا یہ سمجھے بغیر کہ آپ کو اس کی ضرورت کیوں ہے۔. یہ اب بھی ایک سنجیدہ "UTF-8 کی بہتری" سے زیادہ ایک تجربہ ہے۔ اس کے باوجود، وہاں کا کوڈ صاف، اختصار کے ساتھ، بڑی تعداد میں تبصروں اور ٹیسٹ کوریج کے ساتھ لکھا گیا ہے۔

ٹیسٹ کے نتائج اور UTF-8 کے ساتھ موازنہ

میں نے بھی کیا۔ ڈیمو صفحہ، جہاں آپ الگورتھم کی کارکردگی کا جائزہ لے سکتے ہیں، اور پھر میں آپ کو اس کے اصولوں اور ترقی کے عمل کے بارے میں مزید بتاؤں گا۔

بے کار بٹس کو ختم کرنا

میں نے UTF-8 کو ایک بنیاد کے طور پر لیا، یقیناً۔ پہلی اور سب سے واضح چیز جو اس میں تبدیل کی جا سکتی ہے وہ ہے ہر بائٹ میں سروس بٹس کی تعداد کو کم کرنا۔ مثال کے طور پر، UTF-8 میں پہلا بائٹ ہمیشہ کسی ایک سے شروع ہوتا ہے۔ 0، یا کے ساتھ 11 --.ایک سابقہ ​​n 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 بٹ یونیکوڈ رینج سے حروف کو انکوڈ کرنے کی ضرورت ہے، ہم شروع میں 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 میں تبدیل کیا - stash میں اب 64 حروف شامل ہیں لاطینی حروف تہجی، اعداد، اسپیس اور کوما (غیر ASCII نصوص میں کثرت سے اندراجات)۔ ASCII پر واپس جائیں - اور سیریلک حروف تہجی کا بنیادی حصہ معاون حروف تہجی بن جائے گا۔

دو حروف تہجی تک رسائی کی بدولت، ہم حروف تہجی کو تبدیل کرنے کے لیے کم سے کم لاگت کے ساتھ متن کی ایک بڑی تعداد کو سنبھال سکتے ہیں (اوقاف اکثر ASCII پر واپسی کا باعث بنے گا، لیکن اس کے بعد ہمیں اضافی حروف تہجی سے بہت سے غیر ASCII حروف ملیں گے، بغیر۔ دوبارہ سوئچنگ)۔

بونس: ذیلی حروف تہجی کا سابقہ ​​لگانا 11xxxxxx اور اس کے ابتدائی آفسیٹ کو منتخب کرنا 0xC0، ہمیں CP1252 کے ساتھ جزوی مطابقت ملتی ہے۔ دوسرے الفاظ میں، CP1252 میں انکوڈ کردہ بہت سے (لیکن سبھی نہیں) مغربی یورپی متن UTF-C میں ایک جیسے نظر آئیں گے۔

یہاں، تاہم، ایک مشکل پیدا ہوتی ہے: مرکزی حروف تہجی سے معاون کو کیسے حاصل کیا جائے؟ آپ اسی آفسیٹ کو چھوڑ سکتے ہیں، لیکن - افسوس - یہاں یونیکوڈ ڈھانچہ پہلے ہی ہمارے خلاف کھیل رہا ہے۔ اکثر حروف تہجی کا بنیادی حصہ بلاک کے شروع میں نہیں ہوتا ہے (مثال کے طور پر، روسی دارالحکومت "A" کا کوڈ ہوتا ہے 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، یہ یا تو بٹ 0 یا 1 ہے۔ یہ بہت آسان نہیں ہے: ہمیں ان دو اقدار کے درمیان حروف تہجی کو مسلسل تبدیل کرنے کی ضرورت ہوگی (یعنی تین بائٹس خرچ کریں)۔ لیکن نوٹ کریں کہ لمبے موڈ میں، کوڈ سے ہی ہم ان حروف کی تعداد کو گھٹا سکتے ہیں جنہیں ہم شارٹ موڈ کا استعمال کرتے ہوئے انکوڈ کرتے ہیں (اوپر بیان کی گئی تمام چالوں کے بعد، یہ 10240 ہے) - پھر ہائروگلیفس کی رینج اس طرف منتقل ہو جائے گی۔ 0x2600 - 0x77FF، اور اس صورت میں، اس پوری رینج میں، سب سے اہم 6 بٹس (21 میں سے) 0 کے برابر ہوں گے۔ اس طرح، ہائروگلیف کے سلسلے دو بائٹس فی ہائروگلیف (جو اتنی بڑی رینج کے لیے بہترین ہے) استعمال کریں گے، بغیر حروف تہجی کے سوئچ کا سبب بنتا ہے۔

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

یونیکوڈ ماہرین، مضمون کا عنوان پڑھ کر، غالباً آپ کو یہ یاد دلانے میں جلدی کریں گے کہ یونیکوڈ معیارات میں براہ راست موجود ہے۔ یونیکوڈ کے لیے معیاری کمپریشن اسکیم (SCSU)، جو مضمون میں بیان کردہ انکوڈنگ کے طریقہ سے بالکل مماثل بیان کرتا ہے۔

میں ایمانداری سے تسلیم کرتا ہوں: مجھے اس کے وجود کے بارے میں تب ہی معلوم ہوا جب میں اپنا فیصلہ لکھنے میں گہرائی سے ڈوبا ہوا تھا۔ اگر مجھے اس کے بارے میں شروع ہی سے معلوم ہوتا تو میں شاید اپنے نقطہ نظر کے ساتھ آنے کے بجائے عمل درآمد لکھنے کی کوشش کرتا۔

دلچسپ بات یہ ہے کہ SCSU ان خیالات سے بہت ملتے جلتے خیالات کا استعمال کرتا ہے جو میں نے خود پیش کیا تھا ("حروف تہجی" کے تصور کی بجائے وہ "ونڈوز" استعمال کرتے ہیں، اور ان میں سے میرے پاس سے زیادہ دستیاب ہیں)۔ ایک ہی وقت میں، اس فارمیٹ کے بھی نقصانات ہیں: یہ انکوڈنگ والے کے مقابلے کمپریشن الگورتھم کے تھوڑا قریب ہے۔ خاص طور پر، معیار بہت سے نمائندگی کے طریقے فراہم کرتا ہے، لیکن یہ نہیں بتاتا ہے کہ کس طرح بہترین کا انتخاب کیا جائے - اس کے لیے، انکوڈر کو کسی نہ کسی قسم کے ہیورسٹکس کا استعمال کرنا چاہیے۔ اس طرح، ایک SCSU انکوڈر جو اچھی پیکیجنگ تیار کرتا ہے میرے الگورتھم سے زیادہ پیچیدہ اور زیادہ بوجھل ہوگا۔

مقابلے کے لیے، میں نے SCSU کے نسبتاً آسان نفاذ کو JavaScript میں منتقل کیا - کوڈ کے حجم کے لحاظ سے یہ میرے UTF-C سے موازنہ کرنے والا نکلا، لیکن بعض صورتوں میں نتیجہ دسیوں فیصد بدتر تھا (بعض اوقات یہ اس سے تجاوز کر سکتا ہے، لیکن زیادہ نہیں)۔ مثال کے طور پر، عبرانی اور یونانی میں متن کو UTF-C کے ذریعے انکوڈ کیا گیا تھا۔ SCSU سے 60% بہتر (شاید ان کے کمپیکٹ حروف تہجی کی وجہ سے)۔

علیحدہ طور پر، میں یہ شامل کروں گا کہ 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 حروف سے)۔ اس صورت میں، آپ کو کمپریشن الگورتھم جیسے deflate کے استعمال کے بارے میں سوچنا چاہیے۔
• اگر آپ کو ضرورت ہے ASCII شفافیت، یعنی، یہ آپ کے لیے اہم ہے کہ انکوڈ شدہ ترتیبوں میں ASCII کوڈز شامل نہ ہوں جو اصل سٹرنگ میں نہیں تھے۔ اس کی ضرورت سے بچا جا سکتا ہے اگر، تیسرے فریق APIs کے ساتھ بات چیت کرتے وقت (مثال کے طور پر، ڈیٹا بیس کے ساتھ کام کرتے ہوئے)، آپ انکوڈنگ کے نتیجے کو بائٹس کے خلاصہ سیٹ کے طور پر پاس کرتے ہیں، نہ کہ تار کے طور پر۔ بصورت دیگر، آپ کو غیر متوقع خطرات کا سامنا کرنا پڑتا ہے۔
• اگر آپ کسی صوابدیدی آفسیٹ (مثال کے طور پر، جب کسی لائن کا کچھ حصہ خراب ہو جاتا ہے) پر فوری طور پر کردار کی حدود تلاش کرنے کے قابل ہونا چاہتے ہیں۔ ایسا کیا جا سکتا ہے، لیکن صرف شروع سے لائن کو اسکین کرکے (یا پچھلے حصے میں بیان کردہ ترمیم کو لاگو کرکے)۔
• اگر آپ کو سٹرنگز کے مواد پر تیزی سے آپریشن کرنے کی ضرورت ہے (ان کو ترتیب دیں، ان میں سب اسٹرنگز تلاش کریں، کنکٹیٹ کریں)۔ اس کے لیے سٹرنگز کو پہلے ڈی کوڈ کرنے کی ضرورت ہے، اس لیے UTF-C ان صورتوں میں UTF-8 سے سست ہوگا (لیکن کمپریشن الگورتھم سے تیز)۔ چونکہ ایک ہی سٹرنگ کو ہمیشہ اسی طرح انکوڈ کیا جاتا ہے، اس لیے ڈی کوڈنگ کے عین مطابق موازنہ کی ضرورت نہیں ہے اور بائٹ بائی بائٹ کی بنیاد پر کیا جا سکتا ہے۔

: اپ ڈیٹ کریں صارف ٹائیومِچ ذیل میں تبصرے میں UTF-C کی قابل اطلاق حدود کو نمایاں کرنے والا ایک گراف پوسٹ کیا گیا ہے۔ یہ ظاہر کرتا ہے کہ UTF-C عام مقصد کے کمپریشن الگورتھم (LZW کی تبدیلی) سے زیادہ موثر ہے جب تک کہ پیکڈ سٹرنگ چھوٹا ہو۔ ~140 حروف (تاہم، میں نوٹ کرتا ہوں کہ موازنہ ایک متن پر کیا گیا تھا؛ دوسری زبانوں کے لیے نتیجہ مختلف ہو سکتا ہے)۔


ماخذ: www.habr.com