آج ہم اس بارے میں بات کریں گے کہ ویب سائٹ اور پروگراموں میں کراکوزیابر کہاں سے آتے ہیں، کون سے ٹیکسٹ انکوڈنگز موجود ہیں اور کن کو استعمال کیا جانا چاہیے۔ آئیے بنیادی ASCII کے ساتھ شروع ہونے والے، نیز اس کے توسیعی ورژن CP866، KOI8-R، Windows 1251 اور جدید یونیکوڈ کنسورشیم انکوڈنگز UTF 16 اور 8 کے ساتھ ختم ہونے والے، ان کی ترقی کی تاریخ پر گہری نظر ڈالتے ہیں۔ مندرجات کا جدول:
کچھ لوگوں کے نزدیک یہ معلومات غیر ضروری معلوم ہو سکتی ہیں، لیکن کیا آپ جانتے ہیں کہ مجھے رینگنے والے کراکوزیابرس (حروف کا ناقابلِ مطالعہ مجموعہ) کے بارے میں خاص طور پر کتنے سوالات موصول ہوتے ہیں۔ اب مجھے موقع ملے گا کہ میں ہر کسی کو اس مضمون کے متن کا حوالہ دوں اور اپنی غلطیاں تلاش کروں۔ ٹھیک ہے، معلومات کو جذب کرنے کے لیے تیار ہو جائیں اور کہانی کے بہاؤ کی پیروی کرنے کی کوشش کریں۔
ASCII - لاطینی حروف تہجی کے لیے بنیادی ٹیکسٹ انکوڈنگ
ٹیکسٹ انکوڈنگز کی ترقی آئی ٹی انڈسٹری کے قیام کے ساتھ ہی ہوئی، اور اس وقت کے دوران وہ کافی تبدیلیوں سے گزرنے میں کامیاب ہوئے۔ تاریخی طور پر، یہ سب ای بی سی ڈی آئی سی سے شروع ہوا، جو روسی تلفظ میں غیر متناسب تھا، جس کی وجہ سے لاطینی حروف تہجی کے حروف، عربی ہندسوں اور اوقاف کے نشانات کو کنٹرول حروف کے ساتھ انکوڈ کرنا ممکن ہوا۔ لیکن پھر بھی، جدید ٹیکسٹ انکوڈنگز کی ترقی کے لیے نقطہ آغاز کو مشہور ASCII (امریکن اسٹینڈرڈ کوڈ فار انفارمیشن انٹرچینج، جسے روسی زبان میں عام طور پر "پوچھنا" کہا جاتا ہے) سمجھا جانا چاہیے۔ یہ پہلے 128 حروف کی وضاحت کرتا ہے جو عام طور پر انگریزی بولنے والے صارفین کے ذریعہ استعمال ہوتے ہیں - لاطینی حروف، عربی ہندسوں اور اوقاف کے نشانات۔ ASCII میں بیان کردہ ان 128 حروف میں کچھ سروس کریکٹرز بھی شامل ہیں جیسے بریکٹ، ہیش مارکس، ستارے وغیرہ۔ درحقیقت، آپ انہیں خود دیکھ سکتے ہیں: یہ ASCII کے اصل ورژن کے یہ 128 حروف ہیں جو معیاری بن گئے، اور کسی بھی دوسرے انکوڈنگ میں آپ کو وہ ضرور ملیں گے اور وہ اس ترتیب میں ظاہر ہوں گے۔ لیکن حقیقت یہ ہے کہ معلومات کے ایک بائٹ کی مدد سے آپ 128 نہیں بلکہ زیادہ سے زیادہ 256 مختلف اقدار (دو سے آٹھ کی طاقت 256 کے برابر) کو انکوڈ کر سکتے ہیں، اس لیے آسوکا کے بنیادی ورژن کے بعد، ایک مکمل توسیع شدہ ASCII انکوڈنگز کا سلسلہ نمودار ہوا ، جس میں یہ ممکن تھا، 128 بنیادی حروف کے علاوہ قومی انکوڈنگ حروف (مثال کے طور پر، روسی) کا استعمال کرتے ہوئے انکوڈ کیا جا سکتا ہے۔ یہاں، تفصیل میں استعمال ہونے والے نمبر سسٹمز کے بارے میں کچھ اور کہنا شاید قابل قدر ہے۔ سب سے پہلے، جیسا کہ آپ سب جانتے ہیں، کمپیوٹر صرف بائنری سسٹم میں نمبروں کے ساتھ کام کرتا ہے، یعنی صفر اور ایک کے ساتھ ("بولین الجبرا"، اگر کسی نے اسے کسی ادارے یا اسکول میں لیا ہو)۔ ایک بائٹ آٹھ بٹس پر مشتمل ہوتا ہے، جن میں سے ہر ایک دو سے دو کی طاقت کی نمائندگی کرتا ہے، صفر سے شروع ہوتا ہے، اور دو سے ساتویں تک: یہ سمجھنا مشکل نہیں ہے کہ اس طرح کی تعمیر میں زیرو اور ایک کے تمام ممکنہ امتزاج ہو سکتے ہیں۔ صرف 256 ہو۔ بائنری سسٹم سے کسی نمبر کو ڈیسیمل میں تبدیل کرنا بہت آسان ہے۔ آپ کو صرف دو کی تمام طاقتوں کو ان کے اوپر والے کے ساتھ شامل کرنے کی ضرورت ہے۔ ہماری مثال میں، یہ 1 (2 صفر کی طاقت) جمع 8 (3 کی طاقت سے دو)، جمع 32 (دو سے پانچویں طاقت)، جمع 64 (چھٹے کی طاقت)، جمع 128 نکلتا ہے۔ (ساتویں طاقت تک)۔ اعشاریہ اشارے میں کل 233 ہے۔ جیسا کہ آپ دیکھ سکتے ہیں، سب کچھ بہت آسان ہے. لیکن اگر آپ ASCII حروف کے ساتھ ٹیبل کو قریب سے دیکھیں تو آپ دیکھیں گے کہ ان کی نمائندگی ہیکساڈیسیمل انکوڈنگ میں کی گئی ہے۔ مثال کے طور پر، "نجمہ" آسکی میں ہیکساڈیسیمل نمبر 2A سے مطابقت رکھتا ہے۔ آپ شاید جانتے ہوں گے کہ ہیکساڈیسیمل نمبر سسٹم میں عربی ہندسوں کے علاوہ A (یعنی دس) سے F (یعنی پندرہ) تک کے لاطینی حروف بھی استعمال ہوتے ہیں۔ ٹھیک ہے، بائنری نمبر کو ہیکسا ڈیسیمل میں تبدیل کرنے کے لیےدرج ذیل آسان طریقہ کا سہارا لیں۔ معلومات کے ہر بائٹ کو چار بٹس کے دو حصوں میں تقسیم کیا گیا ہے۔ وہ. ہر نصف بائٹ میں، صرف سولہ اقدار (دو سے چوتھی طاقت) کو بائنری میں انکوڈ کیا جا سکتا ہے، جسے آسانی سے ہیکسا ڈیسیمل نمبر کے طور پر پیش کیا جا سکتا ہے۔ مزید برآں، بائٹ کے بائیں آدھے حصے میں، ڈگریوں کو دوبارہ صفر سے شروع کرتے ہوئے شمار کرنے کی ضرورت ہوگی، اور جیسا کہ اسکرین شاٹ میں دکھایا گیا ہے۔ نتیجے کے طور پر، ہمیں معلوم ہوا کہ نمبر E9 اسکرین شاٹ میں انکوڈ ہے۔ مجھے امید ہے کہ میرے استدلال کا طریقہ اور اس پہیلی کا حل آپ پر واضح ہو گیا تھا۔ ٹھیک ہے، اب آئیے جاری رکھیں، حقیقت میں، ٹیکسٹ انکوڈنگز کے بارے میں بات کرتے ہیں۔
آسوکا کے توسیعی ورژن - CP866 اور KOI8-R انکوڈنگز سیڈوگرافکس کے ساتھ
لہذا، ہم نے ASCII کے بارے میں بات کرنا شروع کی، جو کہ جیسا تھا، تمام جدید انکوڈنگز (ونڈوز 1251، یونیکوڈ، UTF 8) کی ترقی کا نقطہ آغاز تھا۔ ابتدائی طور پر، اس میں لاطینی حروف تہجی کے صرف 128 حروف، عربی ہندسوں اور کچھ اور تھے، لیکن توسیع شدہ ورژن میں تمام 256 اقدار کو استعمال کرنا ممکن ہو گیا جنہیں معلومات کے ایک بائٹ میں انکوڈ کیا جا سکتا ہے۔ وہ. آسکی میں اپنی زبان کے حروف کی علامتیں شامل کرنا ممکن ہو گیا۔ یہاں ہمیں ایک بار پھر اس بات کی وضاحت کرنے کی ضرورت ہوگی کہ ٹیکسٹ انکوڈنگ کی بالکل ضرورت کیوں ہے اور یہ اتنا اہم کیوں ہے۔ آپ کے کمپیوٹر اسکرین پر حروف دو چیزوں کی بنیاد پر بنتے ہیں - مختلف حروف کی ویکٹر کی شکلوں کے سیٹ (وہ آپ کے کمپیوٹر پر نصب فونٹس والی فائلوں میں ہوتے ہیں) اور کوڈ جو آپ کو بالکل وہی نکالنے کی اجازت دیتا ہے۔ ویکٹر کی شکلوں کے اس سیٹ سے (فونٹ فائل)۔ علامت جو صحیح جگہ پر ڈالنے کی ضرورت ہوگی۔ یہ واضح ہے کہ فونٹس خود ویکٹر کی شکلوں کے ذمہ دار ہیں، لیکن آپریٹنگ سسٹم اور اس میں استعمال ہونے والے پروگرام انکوڈنگ کے ذمہ دار ہیں۔ وہ. آپ کے کمپیوٹر پر کوئی بھی متن بائٹس کا ایک سیٹ ہوگا، جن میں سے ہر ایک اس متن کے ایک ایک حرف کو انکوڈ کرتا ہے۔ وہ پروگرام جو اس ٹیکسٹ کو اسکرین پر دکھاتا ہے (ٹیکسٹ ایڈیٹر، براؤزر وغیرہ)، کوڈ کو پارس کرتے وقت، اگلے کریکٹر کی انکوڈنگ پڑھتا ہے اور مطلوبہ فونٹ فائل میں متعلقہ ویکٹر فارم کو تلاش کرتا ہے، جو اس کو ظاہر کرنے کے لیے منسلک ہوتا ہے۔ متن دستاویز. سب کچھ سادہ اور سادہ ہے۔ اس کا مطلب یہ ہے کہ کسی بھی حرف کو انکوڈ کرنے کے لیے جس کی ہمیں ضرورت ہے (مثال کے طور پر، قومی حروف تہجی سے)، دو شرائط کو پورا کرنا ضروری ہے: اس کریکٹر کی ویکٹر فارم استعمال کیے گئے فونٹ میں ہونی چاہیے، اور اس کریکٹر کو توسیعی ASCII انکوڈنگز میں انکوڈ کیا جا سکتا ہے۔ ایک بائٹ میں لہذا، اس طرح کے اختیارات کا ایک مکمل گروپ موجود ہیں. صرف روسی زبان کے حروف کو انکوڈنگ کرنے کے لیے، توسیع شدہ آسکا کی کئی اقسام ہیں۔ مثال کے طور پر، CP866 اصل میں ظاہر ہوا ، جس میں روسی حروف تہجی کے حروف کو استعمال کرنے کی صلاحیت تھی، اور یہ ASCII کا ایک توسیعی ورژن تھا۔ یعنی اسکا اوپری حصہ مکمل طور پر آسکا کے بنیادی ورژن (128 لاطینی حروف، نمبرز اور دیگر گھٹیا) کے ساتھ مطابقت رکھتا ہے، جو بالکل اوپر اسکرین شاٹ میں پیش کیا گیا ہے، لیکن CP866 انکوڈنگ کے ساتھ ٹیبل کے نچلے حصے کی ظاہری شکل میں اشارہ کیا گیا تھا۔ اسکرین شاٹ بالکل نیچے اور مزید 128 حروف کو انکوڈ کرنے کی اجازت دی گئی (روسی حروف اور ہر طرح کے سیوڈو گرافکس): آپ دیکھتے ہیں، دائیں کالم میں نمبر 8 سے شروع ہوتے ہیں، کیونکہ 0 سے 7 تک کے نمبر ASCII کے بنیادی حصے کا حوالہ دیتے ہیں (پہلا اسکرین شاٹ دیکھیں)۔ اس طرح، CP866 میں سیریلک خط "M" کا کوڈ 9C ہوگا (یہ 9 کے ساتھ متعلقہ لائن کے چوراہے پر واقع ہے اور ہیکساڈیسیمل نمبر سسٹم میں نمبر C کے ساتھ کالم ہے)، جسے معلومات کے ایک بائٹ میں لکھا جا سکتا ہے۔ ، اور اگر روسی حروف کے ساتھ کوئی مناسب فونٹ ہے تو یہ خط بغیر کسی پریشانی کے متن میں ظاہر ہوگا۔ یہ رقم کہاں سے آئی؟CP866 میں سیڈوگرافکس ؟ پورا نکتہ یہ ہے کہ روسی متن کے لیے یہ انکوڈنگ ان شگفتہ سالوں میں تیار کی گئی تھی جب گرافیکل آپریٹنگ سسٹم اب کی طرح وسیع نہیں تھے۔ اور ڈوسا اور اسی طرح کے ٹیکسٹ آپریٹنگ سسٹمز میں، سیوڈوگرافکس نے متن کے ڈیزائن کو کم از کم کسی نہ کسی طرح متنوع بنانا ممکن بنایا، اور اس وجہ سے CP866 اور آسوکا کے توسیعی ورژن کے زمرے سے اس کے دیگر تمام ساتھی اس میں موجود ہیں۔ CP866 IBM کے ذریعہ تقسیم کیا گیا تھا، لیکن اس کے علاوہ، روسی زبان کے حروف کے لیے متعدد انکوڈنگز تیار کی گئیں، مثال کے طور پر، KOI8-R کو ایک ہی قسم (توسیع شدہ ASCII) سے منسوب کیا جا سکتا ہے : اس کے آپریشن کا اصول وہی رہتا ہے۔ CP866 کا جو تھوڑا پہلے بیان کیا گیا ہے - متن کے ہر کردار کو ایک سنگل بائٹ کے طور پر انکوڈ کیا گیا ہے۔ اسکرین شاٹ KOI8-R ٹیبل کا دوسرا نصف دکھاتا ہے، کیونکہ پہلا نصف بنیادی آسوکا کے ساتھ مکمل طور پر مطابقت رکھتا ہے، جو اس مضمون کے پہلے اسکرین شاٹ میں دکھایا گیا ہے۔ KOI8-R انکوڈنگ کی خصوصیات میں سے، یہ نوٹ کیا جا سکتا ہے کہ اس کے ٹیبل میں سیریلک حروف حروف تہجی کی ترتیب میں نہیں ہیں، جیسا کہ CP866 میں کیا گیا تھا۔ اگر آپ سب سے پہلے اسکرین شاٹ (بنیادی حصے کا، جو تمام توسیع شدہ انکوڈنگز میں شامل ہے) کو دیکھیں گے، تو آپ دیکھیں گے کہ KOI8-R میں روسی حروف ٹیبل کے ان ہی خلیات میں موجود ہیں جو کہ لاطینی حروف تہجی کے متعلقہ حروف ہیں۔ میز کے پہلے حصے سے۔ یہ صرف ایک بٹ (دو سے ساتویں طاقت یا 128) کو ترک کر کے روسی سے لاطینی حروف میں تبدیل کرنے کی سہولت کے لیے کیا گیا تھا۔
ونڈوز 1251 - ASCII کا جدید ورژن اور دراڑیں کیوں آتی ہیں۔
ٹیکسٹ انکوڈنگز کی مزید ترقی اس حقیقت کی وجہ سے ہوئی کہ گرافیکل آپریٹنگ سسٹم مقبولیت حاصل کر رہے تھے اور وقت کے ساتھ ساتھ ان میں سیڈوگرافکس استعمال کرنے کی ضرورت ختم ہو گئی۔ نتیجے کے طور پر، ایک پورا گروہ پیدا ہوا جو کہ اصل میں، آسوکا کے اب بھی توسیع شدہ ورژن تھے (متن کا ایک حرف صرف ایک بائٹ معلومات کے ساتھ انکوڈ کیا گیا ہے)، لیکن سیوڈوگرافک علامتوں کے استعمال کے بغیر۔ ان کا تعلق نام نہاد ANSI انکوڈنگز سے تھا، جنہیں امریکن اسٹینڈرڈز انسٹی ٹیوٹ نے تیار کیا تھا۔ عام زبان میں، نام سیریلک روسی زبان کی حمایت کے ساتھ ورژن کے لیے بھی استعمال کیا گیا تھا۔ اس کی ایک مثال Windows 1251 ہو گی ۔ یہ پہلے استعمال ہونے والے CP866 اور KOI8-R سے سازگار طور پر مختلف تھا کہ اس میں سیوڈوگرافک علامتوں کی جگہ روسی نوع ٹائپ کی گمشدہ علامتوں (سوائے تلفظ کے نشان کے) کے ساتھ ساتھ سلووک زبانوں میں استعمال ہونے والی علامتوں نے لی تھی۔ روسی (یوکرینی، بیلاروسی، وغیرہ) ): روسی زبان کے انکوڈنگز کی اتنی کثرت کی وجہ سے، فونٹ مینوفیکچررز اور سافٹ ویئر مینوفیکچررز کو مسلسل سر درد رہتا تھا، اور آپ اور میں، پیارے قارئین، اکثر انہی بدنام زمانہ کیڑوں سے پریشانی میں پڑ جاتے تھے۔ جب متن میں استعمال شدہ ورژن کے ساتھ الجھن تھی۔ اکثر وہ ای میل کے ذریعے پیغامات بھیجنے اور وصول کرتے وقت سامنے آتے ہیں، جس میں بہت ہی پیچیدہ تبادلوں کے جدولوں کی تخلیق شامل تھی، جو درحقیقت اس مسئلے کو بنیادی طور پر حل نہیں کر سکتی تھی، اور اکثر صارفین خط و کتابت کے لیے لاطینی حروف کی نقل حرفی کا استعمال کرتے تھے۔ CP866، KOI8-R یا Windows 1251 جیسی روسی انکوڈنگز کا استعمال کرتے وقت بدنام زمانہ بدگمانی سے پرہیز کریں۔ درحقیقت روسی متن کے بجائے ظاہر ہونے والی دراڑیں کسی دی گئی زبان کی انکوڈنگ کے غلط استعمال کا نتیجہ تھیں، جو کہ اس میں سے مطابقت نہیں رکھتی تھیں۔ جس کا ٹیکسٹ میسج اصل میں انکوڈ کیا گیا تھا۔ ہم کہتے ہیں کہ اگر آپ ونڈوز 1251 کوڈ ٹیبل کا استعمال کرتے ہوئے CP866 کے ذریعے انکوڈ شدہ حروف کو ظاہر کرنے کی کوشش کرتے ہیں، تو یہ وہی گبڑ (حروف کا ایک بے معنی سیٹ) سامنے آجائیں گے، جو پیغام کے متن کو مکمل طور پر بدل دیں گے۔ اسی طرح کی صورتحال اکثر ویب سائٹس، فورمز یا بلاگز بنانے اور ترتیب دینے کے وقت پیدا ہوتی ہے، جب روسی حروف کے ساتھ ٹیکسٹ غلطی سے غلط انکوڈنگ میں محفوظ ہو جاتا ہے جو سائٹ پر بطور ڈیفالٹ استعمال ہوتا ہے، یا غلط ٹیکسٹ ایڈیٹر میں، جو ایک غیر مرئی گیگ کا اضافہ کرتا ہے۔ ننگی آنکھ کے ساتھ کوڈ پر. آخر میں، بہت سے لوگ اس صورت حال سے بہت زیادہ انکوڈنگز اور مسلسل گھٹیا پن سے تھک گئے، اور ایک نئے آفاقی تغیر کی تخلیق کے لیے لازمی شرائط ظاہر ہوئیں جو تمام موجودہ کو بدل دے گی اور ناقابل پڑھے ہوئے متن کے ظاہر ہونے سے مسئلہ حل کر دے گی۔ . اس کے علاوہ چینی جیسی زبانوں کا بھی مسئلہ تھا جہاں 256 سے کہیں زیادہ زبان کے حروف موجود تھے۔
یونیکوڈ - یونیورسل انکوڈنگز UTF 8، 16 اور 32
جنوب مشرقی ایشیائی زبان کے گروپ کے ان ہزاروں حروف کو ممکنہ طور پر معلومات کے ایک بائٹ میں بیان نہیں کیا جا سکتا جو ASCII کے توسیعی ورژن میں حروف کو انکوڈنگ کے لیے مختص کیا گیا تھا۔ نتیجے کے طور پر، یونی کوڈ (Unicode Consortium) کے نام سے ایک کنسورشیم آئی ٹی انڈسٹری کے بہت سے لیڈروں (وہ لوگ جو سافٹ ویئر تیار کرتے ہیں، جو ہارڈ ویئر کو انکوڈ کرتے ہیں، جو فونٹس بناتے ہیں) کے تعاون سے تشکیل دیا گیا تھا جو کہ ایک عالمگیر ٹیکسٹ انکوڈنگ کے ظہور میں دلچسپی رکھتے تھے۔ یونیکوڈ کنسورشیم کے زیراہتمام جاری ہونے والی پہلی تبدیلی UTF 32 تھی ۔ انکوڈنگ نام میں نمبر کا مطلب بٹس کی تعداد ہے جو ایک حرف کو انکوڈ کرنے کے لیے استعمال ہوتے ہیں۔ 32 بٹس معلومات کے 4 بائٹس کے برابر ہیں جو نئے یونیورسل UTF انکوڈنگ میں ایک واحد کردار کو انکوڈ کرنے کے لیے درکار ہوں گے۔ نتیجتاً، ASCII کے توسیعی ورژن اور UTF-32 میں متن کے ساتھ وہی فائل، جو بعد کی صورت میں، سائز (وزن) چار گنا زیادہ ہوگی۔ یہ بری بات ہے، لیکن اب ہمارے پاس UTF کا استعمال کرتے ہوئے دو سے بتیس سیکنڈ کی طاقت کے برابر حروف کی ایک بڑی تعداد کو انکوڈ کرنے کا موقع ہے ( اربوں حروف جو کسی بھی ضروری قدر کو بڑے مارجن کے ساتھ پورا کریں گے)۔ لیکن یورپی گروپ کی زبانوں والے بہت سے ممالک کو انکوڈنگ میں اتنی بڑی تعداد میں حروف کو استعمال کرنے کی ضرورت نہیں تھی، تاہم، UTF-32 کا استعمال کرتے وقت، انہیں بغیر کسی وجہ کے ٹیکسٹ دستاویزات کے وزن میں چار گنا اضافہ ہوا، اور اس کے نتیجے میں، انٹرنیٹ ٹریفک کے حجم اور ذخیرہ شدہ ڈیٹا کے حجم میں اضافہ۔ یہ بہت زیادہ ہے، اور کوئی بھی اس طرح کے فضلہ کا متحمل نہیں ہوسکتا ہے۔ یونیکوڈ کی ترقی کے نتیجے میں، UTF-16 نمودار ہوا ، جو اس قدر کامیاب ثابت ہوا کہ اسے بطور ڈیفالٹ تمام حروف کے لیے بنیادی جگہ کے طور پر اپنایا گیا جو ہم استعمال کرتے ہیں۔ یہ ایک کریکٹر کو انکوڈ کرنے کے لیے دو بائٹس استعمال کرتا ہے۔ آئیے دیکھتے ہیں کہ یہ چیز کیسی لگتی ہے۔ ونڈوز آپریٹنگ سسٹم میں، آپ "اسٹارٹ" - "پروگرامز" - "اسسریز" - "سسٹم ٹولز" - "کریکٹر ٹیبل" کے راستے پر چل سکتے ہیں۔ نتیجے کے طور پر، آپ کے سسٹم پر نصب تمام فونٹس کی ویکٹر کی شکلوں کے ساتھ ایک ٹیبل کھل جائے گا۔ اگر آپ "ایڈوانسڈ آپشنز" میں یونیکوڈ کریکٹر سیٹ کو منتخب کرتے ہیں، تو آپ ہر فونٹ کے لیے اس میں شامل کریکٹرز کی پوری رینج کو الگ الگ دیکھ سکیں گے۔ ویسے، ان میں سے کسی پر بھی کلک کرکے، آپ اس کا دو بائٹ کوڈ UTF-16 فارمیٹ میں دیکھ سکتے ہیں ، جو چار ہیکسا ڈیسیمل ہندسوں پر مشتمل ہے: 16 بٹس کا استعمال کرتے ہوئے UTF-16 میں کتنے حروف کو انکوڈ کیا جا سکتا ہے؟ 65,536 (دو سے سولہ کی طاقت)، اور یہ وہ نمبر ہے جسے یونیکوڈ میں بنیادی جگہ کے طور پر اپنایا گیا تھا۔ اس کے علاوہ، اسے استعمال کرتے ہوئے تقریباً 20 لاکھ حروف کو انکوڈ کرنے کے طریقے موجود ہیں، لیکن وہ متن کے دس لاکھ حروف کی توسیعی جگہ تک محدود تھے۔ لیکن یونیکوڈ انکوڈنگ کے اس کامیاب ورژن سے بھی ان لوگوں کو زیادہ اطمینان نہیں ہوا جنہوں نے صرف انگریزی میں پروگرام لکھے، کہتے ہیں، کیونکہ ASCII کے توسیعی ورژن سے UTF-16 میں منتقلی کے بعد، دستاویزات کا وزن دوگنا ہو گیا (ایک بائٹ فی آسکی میں کریکٹر اور YUTF-16 میں ایک ہی کردار کے لیے دو بائٹس)۔ یہ قطعی طور پر یونیکوڈ کنسورشیم میں ہر ایک اور ہر چیز کو مطمئن کرنے کے لیے تھا کہ متغیر لمبائی کی انکوڈنگ کے ساتھ آنے کا فیصلہ کیا گیا ۔ اسے UTF-8 کہا جاتا تھا۔ نام میں آٹھ ہونے کے باوجود، اس کی اصل میں ایک متغیر لمبائی ہے، یعنی متن کے ہر حرف کو لمبائی میں ایک سے چھ بائٹس کی ترتیب میں انکوڈ کیا جا سکتا ہے۔ عملی طور پر، UTF-8 صرف ایک سے چار بائٹس تک کی حد استعمال کرتا ہے، کیونکہ کوڈ کے چار بائٹس سے آگے کسی چیز کا تصور کرنا بھی نظریاتی طور پر ممکن نہیں ہے۔ اس میں تمام لاطینی حروف کو ایک بائٹ میں انکوڈ کیا گیا ہے، بالکل اسی طرح جیسے اچھے پرانے ASCII میں۔ قابل ذکر بات یہ ہے کہ صرف لاطینی حروف تہجی کو انکوڈنگ کرنے کی صورت میں، یہاں تک کہ وہ پروگرام جو یونیکوڈ کو نہیں سمجھتے ہیں وہ بھی YTF-8 میں انکوڈ شدہ چیزوں کو پڑھیں گے۔ یعنی، اسوکا کا بنیادی حصہ یونیکوڈ کنسورشیم کے اس دماغ کی تخلیق کو آسانی سے منتقل کر دیا گیا تھا۔ UTF-8 میں سیریلک حروف کو دو بائٹس میں انکوڈ کیا گیا ہے، اور مثال کے طور پر، جارجیائی حروف کو تین بائٹس میں انکوڈ کیا گیا ہے۔ یونیکوڈ کنسورشیم نے، UTF 16 اور 8 بنانے کے بعد، بنیادی مسئلہ حل کر دیا - اب ہمارے پاس اپنے فونٹس میں ایک کوڈ کی جگہ ہے ۔ اور اب ان کے مینوفیکچررز اپنی طاقت اور صلاحیتوں کی بنیاد پر اسے صرف ٹیکسٹ کریکٹرز کے ویکٹر فارمز سے بھر سکتے ہیں۔ اوپر "کریکٹر ٹیبل" میں آپ دیکھ سکتے ہیں کہ مختلف فونٹس مختلف نمبروں کی حروف کو سپورٹ کرتے ہیں۔ کچھ یونیکوڈ سے بھرپور فونٹس کافی بھاری ہو سکتے ہیں۔ لیکن اب ان میں فرق اس حقیقت میں نہیں ہے کہ وہ مختلف انکوڈنگز کے لیے بنائے گئے تھے، بلکہ اس حقیقت میں کہ فونٹ بنانے والے نے مخصوص ویکٹر فارمز کے ساتھ واحد کوڈ کی جگہ کو پُر کیا ہے یا نہیں کیا ہے۔
روسی حروف کے بجائے پاگل الفاظ - اسے کیسے ٹھیک کریں۔
آئیے اب دیکھتے ہیں کہ متن کے بجائے کراکوزیابرس کیسے ظاہر ہوتے ہیں یا دوسرے لفظوں میں روسی متن کے لیے صحیح انکوڈنگ کا انتخاب کیسے کیا جاتا ہے۔ دراصل، یہ اس پروگرام میں سیٹ کیا گیا ہے جس میں آپ متن کے ٹکڑوں کا استعمال کرتے ہوئے یہ متن، یا کوڈ بناتے یا اس میں ترمیم کرتے ہیں۔ ٹیکسٹ فائلوں میں ترمیم اور تخلیق کرنے کے لیے، میں ذاتی طور پر ایک بہت اچھا استعمال کرتا ہوں، میری رائے میں، Html اور PHP ایڈیٹر Notepad++ ۔ تاہم، یہ سینکڑوں دیگر پروگرامنگ اور مارک اپ لینگویجز کے نحو کو نمایاں کر سکتا ہے، اور پلگ ان کا استعمال کرتے ہوئے اس میں توسیع کی صلاحیت بھی ہے۔ دیے گئے لنک پر اس شاندار پروگرام کا تفصیلی جائزہ پڑھیں۔ Notepad++ کے سب سے اوپر والے مینو میں ایک آئٹم "Encodings" ہے، جہاں آپ کو ایک موجودہ آپشن میں تبدیل کرنے کا موقع ملے گا جو آپ کی سائٹ پر بطور ڈیفالٹ استعمال ہوتا ہے: جملہ 1.5 اور اس سے اوپر کی سائٹ کی صورت میں، جیسا کہ اسی طرح ورڈپریس پر بلاگ کے معاملے میں، آپ کو کراکوزیابروف کی ظاہری شکل سے بچنا چاہیے BOM کے بغیر UTF 8 آپشن کا انتخاب کریں ۔ BOM سابقہ کیا ہے؟ حقیقت یہ ہے کہ جب وہ YUTF-16 انکوڈنگ تیار کر رہے تھے، کسی وجہ سے انہوں نے اس کے ساتھ ایسی چیز منسلک کرنے کا فیصلہ کیا جیسے کریکٹر کوڈ کو براہ راست ترتیب (مثال کے طور پر 0A15) اور ریورس (150A) دونوں میں لکھنے کی صلاحیت۔ . اور پروگراموں کو یہ سمجھنے کے لیے کہ کوڈز کو کس ترتیب میں پڑھنا ہے، BOM (بائٹ آرڈر مارک یا دوسرے لفظوں میں، دستخط) ایجاد کیا گیا، جس کا اظہار دستاویزات کے آغاز میں تین اضافی بائٹس شامل کرنے میں کیا گیا تھا۔ UTF-8 انکوڈنگ میں، یونیکوڈ کنسورشیم میں کوئی BOM فراہم نہیں کیا گیا تھا، اور اس لیے دستخط (دستاویز کے شروع میں وہ بدنام زمانہ اضافی تین بائٹس) شامل کرنا کچھ پروگراموں کو کوڈ پڑھنے سے روکتا ہے۔ لہذا، UTF میں فائلوں کو محفوظ کرتے وقت، ہمیں ہمیشہ BOM کے بغیر (بغیر دستخط کے) آپشن کا انتخاب کرنا چاہیے۔ اس طرح، آپ krakozyabrs کے رینگنے سے پہلے ہی اپنے آپ کو بچائیں گے ۔ قابل ذکر بات یہ ہے کہ ونڈوز میں کچھ پروگرام ایسا نہیں کر سکتے ہیں (وہ بغیر BOM کے UTF-8 میں ٹیکسٹ محفوظ نہیں کر سکتے ہیں)، مثال کے طور پر وہی بدنام ونڈوز نوٹ پیڈ۔ یہ دستاویز کو UTF-8 میں محفوظ کرتا ہے، لیکن پھر بھی اس کے آغاز میں دستخط (تین اضافی بائٹس) شامل کرتا ہے۔ مزید یہ کہ یہ بائٹس ہمیشہ ایک جیسے ہوں گے - کوڈ کو براہ راست ترتیب میں پڑھیں۔ لیکن سرورز پر، اس چھوٹی سی چیز کی وجہ سے، ایک مسئلہ پیدا ہوسکتا ہے - بدمعاش نکلیں گے. لہذا، کسی بھی حالت میں باقاعدہ ونڈوز نوٹ پیڈ استعمال نہ کریں ۔اگر آپ نہیں چاہتے ہیں کہ کوئی دراڑیں نظر آئیں تو اپنی سائٹ پر دستاویزات میں ترمیم کریں۔ میں پہلے سے ذکر کردہ نوٹ پیڈ++ ایڈیٹر کو بہترین اور آسان آپشن سمجھتا ہوں، جس میں عملی طور پر کوئی کمی نہیں ہے اور یہ صرف فوائد پر مشتمل ہے۔ Notepad++ میں، جب آپ ایک انکوڈنگ کا انتخاب کرتے ہیں، تو آپ کے پاس متن کو UCS-2 انکوڈنگ میں تبدیل کرنے کا اختیار ہوگا، جو کہ فطرت میں یونیکوڈ معیار کے بہت قریب ہے۔ نوٹ پیڈ میں بھی ANSI میں متن کو انکوڈ کرنا ممکن ہو گا، یعنی روسی زبان کے سلسلے میں، یہ ونڈوز 1251 ہو گا، جسے ہم پہلے ہی اوپر بیان کر چکے ہیں۔ یہ معلومات کہاں سے آتی ہیں؟ یہ آپ کے ونڈوز آپریٹنگ سسٹم کی رجسٹری میں رجسٹرڈ ہے - جس کو اے این ایس آئی کے معاملے میں منتخب کرنا ہے، جو OEM کے معاملے میں منتخب کرنا ہے (روسی زبان کے لیے یہ CP866 ہوگا)۔ اگر آپ اپنے کمپیوٹر پر کوئی اور ڈیفالٹ لینگوئج سیٹ کرتے ہیں، تو ان انکوڈنگز کو اسی زبان کے لیے ANSI یا OEM زمرہ سے ملتی جلتی زبانوں سے بدل دیا جائے گا۔ دستاویز کو نوٹ پیڈ++ میں محفوظ کرنے کے بعد آپ کو مطلوبہ انکوڈنگ میں یا سائٹ سے دستاویز کو ایڈیٹنگ کے لیے کھولنے کے بعد، آپ ایڈیٹر کے نیچے دائیں کونے میں اس کا نام دیکھ سکیں گے: کنفیوژن سے بچنے کے لیے ، اوپر بیان کیے گئے اقدامات کے علاوہ , اس کے ہیڈر میں سورس کوڈ لکھنا مفید ہو گا سائٹ کے تمام صفحات پر اس انتہائی انکوڈنگ کے بارے میں معلومات، تاکہ سرور یا مقامی میزبان پر کوئی الجھن نہ ہو۔ عام طور پر، ایچ ٹی ایم ایل کے علاوہ تمام ہائپر ٹیکسٹ مارک اپ لینگویجز ایک خصوصی ایکس ایم ایل ڈیکلریشن استعمال کرتی ہیں، جو ٹیکسٹ انکوڈنگ کی وضاحت کرتی ہے۔
<?xml version="1.0" encoding="windows-1251"?>
کوڈ کو پارس کرنے سے پہلے، براؤزر جانتا ہے کہ کون سا ورژن استعمال کیا جا رہا ہے اور اسے اس زبان کے کریکٹر کوڈز کی ترجمانی کرنے کی ضرورت ہے۔ لیکن قابل غور بات یہ ہے کہ اگر آپ دستاویز کو پہلے سے طے شدہ یونیکوڈ میں محفوظ کرتے ہیں، تو اس xml ڈیکلریشن کو خارج کیا جا سکتا ہے (انکوڈنگ کو UTF-8 سمجھا جائے گا اگر BOM نہیں ہے یا UTF-16 اگر BOM ہے)۔ ایچ ٹی ایم ایل دستاویز کی صورت میں، میٹا عنصر کو انکوڈنگ کی نشاندہی کرنے کے لیے استعمال کیا جاتا ہے ، جو افتتاحی اور اختتامی ہیڈ ٹیگز کے درمیان رکھا جاتا ہے:
<head>...<meta charset="utf-8">...</head>
یہ اندراج ایچ ٹی ایم ایل 4.01 کے معیار سے بالکل مختلف ہے، لیکن ایچ ٹی ایم ایل 5 کے معیار کی مکمل تعمیل کرتا ہے، اور اس وقت استعمال ہونے والے کسی بھی براؤزر کے ذریعے اسے صحیح طور پر سمجھا جائے گا۔ نظریہ میں، ایچ ٹی ایم ایل دستاویز کی انکوڈنگ کی نشاندہی کرنے والے میٹا عنصر کو دستاویز کے ہیڈر میں زیادہ سے زیادہ بہتر طور پر رکھا جائے گا ، تاکہ جب تک متن کا سامنا پہلے حرف سے ہوتا ہے وہ بنیادی ANSI سے نہیں ہوتا ہے (جسے ہمیشہ صحیح طریقے سے پڑھا جاتا ہے۔ کسی بھی قسم کی تبدیلی)، براؤزر کے پاس پہلے سے ہی اس بارے میں معلومات ہونی چاہیے کہ ان حروف کے کوڈز کی تشریح کیسے کی جاتی ہے۔ اصل ماخذ سے لنک: ASCII ٹیکسٹ انکوڈنگ (Windows 1251, CP866, KOI8-R) اور یونیکوڈ (UTF 8, 16, 32) - پٹاخوں کے ساتھ مسئلہ کو کیسے حل کیا جائے
یہ ASCII کے اصل ورژن کے یہ 128 حروف ہیں جو معیاری بن گئے، اور کسی بھی دوسرے انکوڈنگ میں آپ کو وہ ضرور ملیں گے اور وہ اس ترتیب میں ظاہر ہوں گے۔ لیکن حقیقت یہ ہے کہ معلومات کے ایک بائٹ کی مدد سے آپ 128 نہیں بلکہ زیادہ سے زیادہ 256 مختلف اقدار (دو سے آٹھ کی طاقت 256 کے برابر) کو انکوڈ کر سکتے ہیں، اس لیے آسوکا کے بنیادی ورژن کے بعد، ایک مکمل توسیع شدہ ASCII انکوڈنگز کا سلسلہ نمودار ہوا ، جس میں یہ ممکن تھا، 128 بنیادی حروف کے علاوہ قومی انکوڈنگ حروف (مثال کے طور پر، روسی) کا استعمال کرتے ہوئے انکوڈ کیا جا سکتا ہے۔ یہاں، تفصیل میں استعمال ہونے والے نمبر سسٹمز کے بارے میں کچھ اور کہنا شاید قابل قدر ہے۔ سب سے پہلے، جیسا کہ آپ سب جانتے ہیں، کمپیوٹر صرف بائنری سسٹم میں نمبروں کے ساتھ کام کرتا ہے، یعنی صفر اور ایک کے ساتھ ("بولین الجبرا"، اگر کسی نے اسے کسی ادارے یا اسکول میں لیا ہو)۔ ایک بائٹ آٹھ بٹس پر مشتمل ہوتا ہے، جن میں سے ہر ایک دو سے دو کی طاقت کی نمائندگی کرتا ہے، صفر سے شروع ہوتا ہے، اور دو سے ساتویں تک: 
یہ سمجھنا مشکل نہیں ہے کہ اس طرح کی تعمیر میں زیرو اور ایک کے تمام ممکنہ امتزاج ہو سکتے ہیں۔ صرف 256 ہو۔ بائنری سسٹم سے کسی نمبر کو ڈیسیمل میں تبدیل کرنا بہت آسان ہے۔ آپ کو صرف دو کی تمام طاقتوں کو ان کے اوپر والے کے ساتھ شامل کرنے کی ضرورت ہے۔ ہماری مثال میں، یہ 1 (2 صفر کی طاقت) جمع 8 (3 کی طاقت سے دو)، جمع 32 (دو سے پانچویں طاقت)، جمع 64 (چھٹے کی طاقت)، جمع 128 نکلتا ہے۔ (ساتویں طاقت تک)۔ اعشاریہ اشارے میں کل 233 ہے۔ جیسا کہ آپ دیکھ سکتے ہیں، سب کچھ بہت آسان ہے. لیکن اگر آپ ASCII حروف کے ساتھ ٹیبل کو قریب سے دیکھیں تو آپ دیکھیں گے کہ ان کی نمائندگی ہیکساڈیسیمل انکوڈنگ میں کی گئی ہے۔ مثال کے طور پر، "نجمہ" آسکی میں ہیکساڈیسیمل نمبر 2A سے مطابقت رکھتا ہے۔ آپ شاید جانتے ہوں گے کہ ہیکساڈیسیمل نمبر سسٹم میں عربی ہندسوں کے علاوہ A (یعنی دس) سے F (یعنی پندرہ) تک کے لاطینی حروف بھی استعمال ہوتے ہیں۔ ٹھیک ہے، بائنری نمبر کو ہیکسا ڈیسیمل میں تبدیل کرنے کے لیےدرج ذیل آسان طریقہ کا سہارا لیں۔ معلومات کے ہر بائٹ کو چار بٹس کے دو حصوں میں تقسیم کیا گیا ہے۔ وہ. ہر نصف بائٹ میں، صرف سولہ اقدار (دو سے چوتھی طاقت) کو بائنری میں انکوڈ کیا جا سکتا ہے، جسے آسانی سے ہیکسا ڈیسیمل نمبر کے طور پر پیش کیا جا سکتا ہے۔ مزید برآں، بائٹ کے بائیں آدھے حصے میں، ڈگریوں کو دوبارہ صفر سے شروع کرتے ہوئے شمار کرنے کی ضرورت ہوگی، اور جیسا کہ اسکرین شاٹ میں دکھایا گیا ہے۔ نتیجے کے طور پر، ہمیں معلوم ہوا کہ نمبر E9 اسکرین شاٹ میں انکوڈ ہے۔ مجھے امید ہے کہ میرے استدلال کا طریقہ اور اس پہیلی کا حل آپ پر واضح ہو گیا تھا۔ ٹھیک ہے، اب آئیے جاری رکھیں، حقیقت میں، ٹیکسٹ انکوڈنگز کے بارے میں بات کرتے ہیں۔
آپ دیکھتے ہیں، دائیں کالم میں نمبر 8 سے شروع ہوتے ہیں، کیونکہ 0 سے 7 تک کے نمبر ASCII کے بنیادی حصے کا حوالہ دیتے ہیں (پہلا اسکرین شاٹ دیکھیں)۔ اس طرح، CP866 میں سیریلک خط "M" کا کوڈ 9C ہوگا (یہ 9 کے ساتھ متعلقہ لائن کے چوراہے پر واقع ہے اور ہیکساڈیسیمل نمبر سسٹم میں نمبر C کے ساتھ کالم ہے)، جسے معلومات کے ایک بائٹ میں لکھا جا سکتا ہے۔ ، اور اگر روسی حروف کے ساتھ کوئی مناسب فونٹ ہے تو یہ خط بغیر کسی پریشانی کے متن میں ظاہر ہوگا۔ یہ رقم کہاں سے آئی؟CP866 میں سیڈوگرافکس ؟ پورا نکتہ یہ ہے کہ روسی متن کے لیے یہ انکوڈنگ ان شگفتہ سالوں میں تیار کی گئی تھی جب گرافیکل آپریٹنگ سسٹم اب کی طرح وسیع نہیں تھے۔ اور ڈوسا اور اسی طرح کے ٹیکسٹ آپریٹنگ سسٹمز میں، سیوڈوگرافکس نے متن کے ڈیزائن کو کم از کم کسی نہ کسی طرح متنوع بنانا ممکن بنایا، اور اس وجہ سے CP866 اور آسوکا کے توسیعی ورژن کے زمرے سے اس کے دیگر تمام ساتھی اس میں موجود ہیں۔ CP866 IBM کے ذریعہ تقسیم کیا گیا تھا، لیکن اس کے علاوہ، روسی زبان کے حروف کے لیے متعدد انکوڈنگز تیار کی گئیں، مثال کے طور پر، KOI8-R کو ایک ہی قسم (توسیع شدہ ASCII) سے منسوب کیا جا سکتا ہے : 
اس کے آپریشن کا اصول وہی رہتا ہے۔ CP866 کا جو تھوڑا پہلے بیان کیا گیا ہے - متن کے ہر کردار کو ایک سنگل بائٹ کے طور پر انکوڈ کیا گیا ہے۔ اسکرین شاٹ KOI8-R ٹیبل کا دوسرا نصف دکھاتا ہے، کیونکہ پہلا نصف بنیادی آسوکا کے ساتھ مکمل طور پر مطابقت رکھتا ہے، جو اس مضمون کے پہلے اسکرین شاٹ میں دکھایا گیا ہے۔ KOI8-R انکوڈنگ کی خصوصیات میں سے، یہ نوٹ کیا جا سکتا ہے کہ اس کے ٹیبل میں سیریلک حروف حروف تہجی کی ترتیب میں نہیں ہیں، جیسا کہ CP866 میں کیا گیا تھا۔ اگر آپ سب سے پہلے اسکرین شاٹ (بنیادی حصے کا، جو تمام توسیع شدہ انکوڈنگز میں شامل ہے) کو دیکھیں گے، تو آپ دیکھیں گے کہ KOI8-R میں روسی حروف ٹیبل کے ان ہی خلیات میں موجود ہیں جو کہ لاطینی حروف تہجی کے متعلقہ حروف ہیں۔ میز کے پہلے حصے سے۔ یہ صرف ایک بٹ (دو سے ساتویں طاقت یا 128) کو ترک کر کے روسی سے لاطینی حروف میں تبدیل کرنے کی سہولت کے لیے کیا گیا تھا۔
سے پریشانی میں پڑ جاتے تھے۔ جب متن میں استعمال شدہ ورژن کے ساتھ الجھن تھی۔ اکثر وہ ای میل کے ذریعے پیغامات بھیجنے اور وصول کرتے وقت سامنے آتے ہیں، جس میں بہت ہی پیچیدہ تبادلوں کے جدولوں کی تخلیق شامل تھی، جو درحقیقت اس مسئلے کو بنیادی طور پر حل نہیں کر سکتی تھی، اور اکثر صارفین خط و کتابت کے لیے لاطینی حروف کی نقل حرفی کا استعمال کرتے تھے۔ CP866، KOI8-R یا Windows 1251 جیسی روسی انکوڈنگز کا استعمال کرتے وقت بدنام زمانہ بدگمانی سے پرہیز کریں۔ درحقیقت روسی متن کے بجائے ظاہر ہونے والی دراڑیں کسی دی گئی زبان کی انکوڈنگ کے غلط استعمال کا نتیجہ تھیں، جو کہ اس میں سے مطابقت نہیں رکھتی تھیں۔ جس کا ٹیکسٹ میسج اصل میں انکوڈ کیا گیا تھا۔ ہم کہتے ہیں کہ اگر آپ ونڈوز 1251 کوڈ ٹیبل کا استعمال کرتے ہوئے CP866 کے ذریعے انکوڈ شدہ حروف کو ظاہر کرنے کی کوشش کرتے ہیں، تو یہ وہی گبڑ (حروف کا ایک بے معنی سیٹ) سامنے آجائیں گے، جو پیغام کے متن کو مکمل طور پر بدل دیں گے۔ اسی طرح کی صورتحال اکثر ویب سائٹس، فورمز یا بلاگز بنانے اور ترتیب دینے کے وقت پیدا ہوتی ہے، جب روسی حروف کے ساتھ ٹیکسٹ غلطی سے غلط انکوڈنگ میں محفوظ ہو جاتا ہے جو سائٹ پر بطور ڈیفالٹ استعمال ہوتا ہے، یا غلط ٹیکسٹ ایڈیٹر میں، جو ایک غیر مرئی گیگ کا اضافہ کرتا ہے۔ ننگی آنکھ کے ساتھ کوڈ پر. آخر میں، بہت سے لوگ اس صورت حال سے بہت زیادہ انکوڈنگز اور مسلسل گھٹیا پن سے تھک گئے، اور ایک نئے آفاقی تغیر کی تخلیق کے لیے لازمی شرائط ظاہر ہوئیں جو تمام موجودہ کو بدل دے گی اور ناقابل پڑھے ہوئے متن کے ظاہر ہونے سے مسئلہ حل کر دے گی۔ . اس کے علاوہ چینی جیسی زبانوں کا بھی مسئلہ تھا جہاں 256 سے کہیں زیادہ زبان کے حروف موجود تھے۔ 
16 بٹس کا استعمال کرتے ہوئے UTF-16 میں کتنے حروف کو انکوڈ کیا جا سکتا ہے؟ 65,536 (دو سے سولہ کی طاقت)، اور یہ وہ نمبر ہے جسے یونیکوڈ میں بنیادی جگہ کے طور پر اپنایا گیا تھا۔ اس کے علاوہ، اسے استعمال کرتے ہوئے تقریباً 20 لاکھ حروف کو انکوڈ کرنے کے طریقے موجود ہیں، لیکن وہ متن کے دس لاکھ حروف کی توسیعی جگہ تک محدود تھے۔ لیکن یونیکوڈ انکوڈنگ کے اس کامیاب ورژن سے بھی ان لوگوں کو زیادہ اطمینان نہیں ہوا جنہوں نے صرف انگریزی میں پروگرام لکھے، کہتے ہیں، کیونکہ ASCII کے توسیعی ورژن سے UTF-16 میں منتقلی کے بعد، دستاویزات کا وزن دوگنا ہو گیا (ایک بائٹ فی آسکی میں کریکٹر اور YUTF-16 میں ایک ہی کردار کے لیے دو بائٹس)۔ یہ قطعی طور پر یونیکوڈ کنسورشیم میں ہر ایک اور ہر چیز کو مطمئن کرنے کے لیے تھا کہ متغیر لمبائی کی انکوڈنگ کے ساتھ آنے کا فیصلہ کیا گیا ۔ اسے UTF-8 کہا جاتا تھا۔ نام میں آٹھ ہونے کے باوجود، اس کی اصل میں ایک متغیر لمبائی ہے، یعنی متن کے ہر حرف کو لمبائی میں ایک سے چھ بائٹس کی ترتیب میں انکوڈ کیا جا سکتا ہے۔ عملی طور پر، UTF-8 صرف ایک سے چار بائٹس تک کی حد استعمال کرتا ہے، کیونکہ کوڈ کے چار بائٹس سے آگے کسی چیز کا تصور کرنا بھی نظریاتی طور پر ممکن نہیں ہے۔ اس میں تمام لاطینی حروف کو ایک بائٹ میں انکوڈ کیا گیا ہے، بالکل اسی طرح جیسے اچھے پرانے ASCII میں۔ قابل ذکر بات یہ ہے کہ صرف لاطینی حروف تہجی کو انکوڈنگ کرنے کی صورت میں، یہاں تک کہ وہ پروگرام جو یونیکوڈ کو نہیں سمجھتے ہیں وہ بھی YTF-8 میں انکوڈ شدہ چیزوں کو پڑھیں گے۔ یعنی، اسوکا کا بنیادی حصہ یونیکوڈ کنسورشیم کے اس دماغ کی تخلیق کو آسانی سے منتقل کر دیا گیا تھا۔ UTF-8 میں سیریلک حروف کو دو بائٹس میں انکوڈ کیا گیا ہے، اور مثال کے طور پر، جارجیائی حروف کو تین بائٹس میں انکوڈ کیا گیا ہے۔ یونیکوڈ کنسورشیم نے، UTF 16 اور 8 بنانے کے بعد، بنیادی مسئلہ حل کر دیا - اب ہمارے پاس اپنے فونٹس میں ایک کوڈ کی جگہ ہے ۔ اور اب ان کے مینوفیکچررز اپنی طاقت اور صلاحیتوں کی بنیاد پر اسے صرف ٹیکسٹ کریکٹرز کے ویکٹر فارمز سے بھر سکتے ہیں۔ اوپر "کریکٹر ٹیبل" میں آپ دیکھ سکتے ہیں کہ مختلف فونٹس مختلف نمبروں کی حروف کو سپورٹ کرتے ہیں۔ کچھ یونیکوڈ سے بھرپور فونٹس کافی بھاری ہو سکتے ہیں۔ لیکن اب ان میں فرق اس حقیقت میں نہیں ہے کہ وہ مختلف انکوڈنگز کے لیے بنائے گئے تھے، بلکہ اس حقیقت میں کہ فونٹ بنانے والے نے مخصوص ویکٹر فارمز کے ساتھ واحد کوڈ کی جگہ کو پُر کیا ہے یا نہیں کیا ہے۔
جملہ 1.5 اور اس سے اوپر کی سائٹ کی صورت میں، جیسا کہ اسی طرح ورڈپریس پر بلاگ کے معاملے میں، آپ کو کراکوزیابروف کی ظاہری شکل سے بچنا چاہیے BOM کے بغیر UTF 8 آپشن کا انتخاب کریں ۔ BOM سابقہ کیا ہے؟ حقیقت یہ ہے کہ جب وہ YUTF-16 انکوڈنگ تیار کر رہے تھے، کسی وجہ سے انہوں نے اس کے ساتھ ایسی چیز منسلک کرنے کا فیصلہ کیا جیسے کریکٹر کوڈ کو براہ راست ترتیب (مثال کے طور پر 0A15) اور ریورس (150A) دونوں میں لکھنے کی صلاحیت۔ . اور پروگراموں کو یہ سمجھنے کے لیے کہ کوڈز کو کس ترتیب میں پڑھنا ہے، BOM (بائٹ آرڈر مارک یا دوسرے لفظوں میں، دستخط) ایجاد کیا گیا، جس کا اظہار دستاویزات کے آغاز میں تین اضافی بائٹس شامل کرنے میں کیا گیا تھا۔ UTF-8 انکوڈنگ میں، یونیکوڈ کنسورشیم میں کوئی BOM فراہم نہیں کیا گیا تھا، اور اس لیے دستخط (دستاویز کے شروع میں وہ بدنام زمانہ اضافی تین بائٹس) شامل کرنا کچھ پروگراموں کو کوڈ پڑھنے سے روکتا ہے۔ لہذا، UTF میں فائلوں کو محفوظ کرتے وقت، ہمیں ہمیشہ BOM کے بغیر (بغیر دستخط کے) آپشن کا انتخاب کرنا چاہیے۔ اس طرح، آپ krakozyabrs کے رینگنے سے پہلے ہی اپنے آپ کو بچائیں گے ۔ قابل ذکر بات یہ ہے کہ ونڈوز میں کچھ پروگرام ایسا نہیں کر سکتے ہیں (وہ بغیر BOM کے UTF-8 میں ٹیکسٹ محفوظ نہیں کر سکتے ہیں)، مثال کے طور پر وہی بدنام ونڈوز نوٹ پیڈ۔ یہ دستاویز کو UTF-8 میں محفوظ کرتا ہے، لیکن پھر بھی اس کے آغاز میں دستخط (تین اضافی بائٹس) شامل کرتا ہے۔ مزید یہ کہ یہ بائٹس ہمیشہ ایک جیسے ہوں گے - کوڈ کو براہ راست ترتیب میں پڑھیں۔ لیکن سرورز پر، اس چھوٹی سی چیز کی وجہ سے، ایک مسئلہ پیدا ہوسکتا ہے - بدمعاش نکلیں گے. لہذا، کسی بھی حالت میں باقاعدہ ونڈوز نوٹ پیڈ استعمال نہ کریں ۔اگر آپ نہیں چاہتے ہیں کہ کوئی دراڑیں نظر آئیں تو اپنی سائٹ پر دستاویزات میں ترمیم کریں۔ میں پہلے سے ذکر کردہ نوٹ پیڈ++ ایڈیٹر کو بہترین اور آسان آپشن سمجھتا ہوں، جس میں عملی طور پر کوئی کمی نہیں ہے اور یہ صرف فوائد پر مشتمل ہے۔ Notepad++ میں، جب آپ ایک انکوڈنگ کا انتخاب کرتے ہیں، تو آپ کے پاس متن کو UCS-2 انکوڈنگ میں تبدیل کرنے کا اختیار ہوگا، جو کہ فطرت میں یونیکوڈ معیار کے بہت قریب ہے۔ نوٹ پیڈ میں بھی ANSI میں متن کو انکوڈ کرنا ممکن ہو گا، یعنی روسی زبان کے سلسلے میں، یہ ونڈوز 1251 ہو گا، جسے ہم پہلے ہی اوپر بیان کر چکے ہیں۔ یہ معلومات کہاں سے آتی ہیں؟ یہ آپ کے ونڈوز آپریٹنگ سسٹم کی رجسٹری میں رجسٹرڈ ہے - جس کو اے این ایس آئی کے معاملے میں منتخب کرنا ہے، جو OEM کے معاملے میں منتخب کرنا ہے (روسی زبان کے لیے یہ CP866 ہوگا)۔ اگر آپ اپنے کمپیوٹر پر کوئی اور ڈیفالٹ لینگوئج سیٹ کرتے ہیں، تو ان انکوڈنگز کو اسی زبان کے لیے ANSI یا OEM زمرہ سے ملتی جلتی زبانوں سے بدل دیا جائے گا۔ دستاویز کو نوٹ پیڈ++ میں محفوظ کرنے کے بعد آپ کو مطلوبہ انکوڈنگ میں یا سائٹ سے دستاویز کو ایڈیٹنگ کے لیے کھولنے کے بعد، آپ ایڈیٹر کے نیچے دائیں کونے میں اس کا نام دیکھ سکیں گے: 
کنفیوژن سے بچنے کے لیے ، اوپر بیان کیے گئے اقدامات کے علاوہ , اس کے ہیڈر میں سورس کوڈ لکھنا مفید ہو گا سائٹ کے تمام صفحات پر اس انتہائی انکوڈنگ کے بارے میں معلومات، تاکہ سرور یا مقامی میزبان پر کوئی الجھن نہ ہو۔ عام طور پر، ایچ ٹی ایم ایل کے علاوہ تمام ہائپر ٹیکسٹ مارک اپ لینگویجز ایک خصوصی ایکس ایم ایل ڈیکلریشن استعمال کرتی ہیں، جو ٹیکسٹ انکوڈنگ کی وضاحت کرتی ہے۔
GO TO FULL VERSION