اڄ اسان ان بابت ڳالهائينداسين ته krakozyabrs ڪٿان اچن ٿا ويب سائيٽ ۽ پروگرامن ۾، ڪهڙيون ٽيڪسٽ انڪوڊنگ موجود آهن ۽ ڪهڙن کي استعمال ڪرڻ گهرجي. اچو ته انهن جي ترقيءَ جي تاريخ تي هڪ ويجھو نظر وجهون، بنيادي ASCII سان شروع ٿي، ان سان گڏ ان جي وڌايل ورجن CP866، KOI8-R، Windows 1251 ۽ جديد يونيڪوڊ ڪنسورشيم انڪوڊنگس UTF 16 ۽ 8 سان ختم ٿي. مواد جو جدول:
ڪجهه ماڻهن لاءِ، اها معلومات غير ضروري لڳي سگهي ٿي، پر ڇا توهان کي خبر آهي ته مون کي ڪيترا سوال مليا آهن خاص طور تي ڪرالنگ ڪراڪوزابرس (ڪردارن جي اڻ پڙهيل سيٽ) جي حوالي سان. هاڻي مون کي اهو موقعو هوندو ته هر ڪنهن کي هن مضمون جي متن ڏانهن رجوع ڪريان ۽ پنهنجون غلطيون ڳوليان. خير، معلومات جذب ڪرڻ لاءِ تيار ٿي وڃو ۽ ڪوشش ڪريو ڪهاڻي جي وهڪري جي پيروي ڪرڻ جي.
ASCII - لاطيني الفابيٽ لاءِ بنيادي متن انڪوڊنگ
ٽيڪسٽ انڪوڊنگ جي ترقي هڪ ئي وقت آئي ٽي انڊسٽري جي ٺهڻ سان گڏ ٿي، ۽ هن عرصي دوران اهي ڪافي تبديلين مان گذري ويا. تاريخي طور تي، اهو سڀ ڪجهه EBCDIC سان شروع ٿيو، جيڪو روسي تلفظ ۾ بلڪه اختلافي هو، جنهن اهو ممڪن ڪيو ته لاطيني الفابيٽ جي اکرن، عربي انگن ۽ اوقاف جي نشانين کي ڪنٽرول اکرن سان. پر تڏهن به، جديد ٽيڪسٽ انڪوڊنگ جي ترقيءَ لاءِ شروعاتي نقطي کي مشهور ASCII (آمريڪي معياري ڪوڊ فار انفارميشن انٽرچينج، جنهن کي روسي ۾ عام طور تي ”پڇڻ“ چيو ويندو آهي. اهو بيان ڪري ٿو پهريون 128 اکر جيڪي عام طور تي انگريزي ڳالهائيندڙ استعمال ڪندڙن پاران استعمال ڪيا ويا آهن - لاطيني اکر، عربي انگن ۽ اوقاف جا نشان. ASCII ۾ بيان ڪيل انهن 128 اکرن ۾ پڻ ڪجهه سروس اکر شامل آهن جهڙوڪ بريڪٽس، هيش مارڪ، اسٽرڪس، وغيره. حقيقت ۾، توهان انهن کي پنهنجو پاڻ ڏسي سگهو ٿا: اهي ASCII جي اصل نسخي مان 128 اکر آهن جيڪي معيار بڻجي ويا، ۽ ڪنهن ٻئي انڪوڊنگ ۾ توهان ضرور انهن کي ڳوليندا ۽ اهي هن ترتيب ۾ ظاهر ٿيندا. پر حقيقت اها آهي ته معلومات جي هڪ بائيٽ جي مدد سان توهان 128 نه، پر 256 مختلف قدرن کي انڪوڊ ڪري سگهو ٿا (ٻه کان اٺ جي طاقت 256 برابر آهي)، تنهن ڪري، اسوڪا جي بنيادي نسخي کان پوء، مڪمل. وڌايل ASCII انڪوڊنگز جو سلسلو ظاهر ٿيو ، جنهن ۾ اهو ممڪن هو، ان کان علاوه 128 بنيادي اکرن کي پڻ انڪوڊ ڪري سگهجي ٿو قومي انڪوڊنگ ڪردارن (مثال طور روسي). هتي، اهو شايد ڪجهه چوڻ جي قابل آهي تعداد سسٽم بابت ٿورو وڌيڪ جيڪو تفصيل ۾ استعمال ڪيو ويو آهي. پهرين، جيئن توهان سڀني کي خبر آهي، ڪمپيوٽر صرف بائنري سسٽم ۾ نمبرن سان ڪم ڪري ٿو، يعني زيرو ۽ هڪ سان (“بولين الجبرا”، جيڪڏهن ڪو ان کي ڪنهن اداري يا اسڪول ۾ وٺي). هڪ بائيٽ اٺن بِٽن تي مشتمل هوندو آهي، جن مان هر هڪ ٻن کان ٻن جي طاقت جي نمائندگي ڪري ٿو، صفر کان شروع ٿئي ٿو، ۽ ٻن کان ستين تائين: اهو سمجهڻ ڏکيو ناهي ته اهڙي اڏاوت ۾ صفر ۽ هڪ جا سڀ ممڪن مجموعا ٿي سگهن ٿا. صرف 256 هجي. بائنري سسٽم مان هڪ عدد کي ڊيسيمل ۾ تبديل ڪرڻ بلڪل سادو آهي. توھان کي صرف ٻنھي جي مڙني طاقتن کي انھن جي مٿان شامل ڪرڻ جي ضرورت آھي. اسان جي مثال ۾، اهو نڪرندو آهي 1 (2 کان صفر جي طاقت) پلس 8 (ٻه کان 3 جي طاقت)، پلس 32 (ٻه کان پنجين طاقت)، پلس 64 (ڇهين طاقت تائين)، پلس 128 (ستون طاقت ڏانهن). ڪل 233 ڊيسيمل نوٽيشن ۾ آهي. جئين توهان ڏسي سگهو ٿا، هر شيء بلڪل سادو آهي. پر جيڪڏهن توهان ASCII اکرن سان ٽيبل تي ويجهڙائي سان ڏسندا، توهان ڏسندا ته اهي هيڪساڊيڪل انڪوڊنگ ۾ نمائندگي ڪيا ويا آهن. مثال طور، "Asterisk" اسڪي ۾ هيڪساڊيڪل نمبر 2A سان ملندو آهي. توهان کي شايد خبر آهي ته هيڪساڊسيمل نمبر سسٽم ۾ عربي انگن کان علاوه لاطيني اکر A (يعني ڏهه) کان F (يعني پندرهن) تائين به استعمال ٿيندا آهن. خير، هڪ بائنري نمبر کي هيڪساڊيڪل ۾ تبديل ڪرڻ لاءهيٺ ڏنل سادي طريقي سان استعمال ڪريو. معلومات جي هر بائيٽ کي چار بِٽ جي ٻن حصن ۾ ورهايو ويو آهي. اهي. هر اڌ بائيٽ ۾، صرف ڇهن قدرن (ٻن کان چوٿين طاقت) کي بائنري ۾ انڪوڊ ڪري سگهجي ٿو، جنهن کي آسانيءَ سان هيڪساڊيڪل نمبر طور پيش ڪري سگهجي ٿو. ان کان علاوه، بائيٽ جي کاٻي اڌ ۾، درجا ٻيهر ڳڻڻ جي ضرورت پوندي صفر کان شروع ٿيندي، ۽ نه جيئن اسڪرين شاٽ ۾ ڏيکاريل آهي. نتيجي طور، اسان حاصل ڪيو ته نمبر E9 اسڪرين شاٽ ۾ انڪوڊ ٿيل آهي. مون کي اميد آهي ته منهنجي استدلال جو طريقو ۽ هن پزل جو حل توهان لاء واضح هو. خير، هاڻي اچو ته جاري رکون، حقيقت ۾، ٽيڪسٽ انڪوڊنگ بابت ڳالهائڻ.
Asuka - CP866 ۽ KOI8-R انڪوڊنگس جا توسيع ٿيل نسخا pseudographics سان
تنهن ڪري، اسان ASCII بابت ڳالهائڻ شروع ڪيو، جيڪو هو، جيئن هو، سڀني جديد انڪوڊنگز (ونڊوز 1251، يونيڪوڊ، UTF 8) جي ترقي لاء شروعاتي نقطو. شروعات ۾، ان ۾ لاطيني الفابيٽ جا صرف 128 اکر، عربي انگن ۽ ٻيو ڪجهه شامل هئا، پر وڌايل نسخي ۾ اهو ممڪن ٿيو ته سڀني 256 قدرن کي استعمال ڪيو وڃي جيڪي معلومات جي هڪ بائيٽ ۾ انڪوڊ ٿي سگهن ٿيون. اهي. اهو ممڪن ٿيو ته توهان جي ٻولي جي اکرن جي نشانين کي شامل ڪرڻ لاء اسڪي. هتي اسان کي هڪ ڀيرو ٻيهر بحث ڪرڻ جي ضرورت پوندي ته متن جي انڪوڊنگ جي ضرورت ڇو آهي ۽ اهو تمام ضروري آهي. توهان جي ڪمپيوٽر جي اسڪرين تي ڪردار ٻن شين جي بنياد تي ٺاهيا ويندا آهن - مختلف ڪردارن جي ویکٹر جي شڪلن (نمائندن) جو سيٽ (اهي توهان جي ڪمپيوٽر تي نصب ڪيل فونٽ سان فائلن ۾ آهن) ۽ ڪوڊ جيڪو توهان کي بلڪل ان کي ڪڍڻ جي اجازت ڏئي ٿو. ویکٹر جي شڪل (فونٽ فائل) جي هن سيٽ مان. علامت جنهن کي صحيح جڳهه تي داخل ڪرڻ جي ضرورت پوندي. واضح رهي ته فونٽ پاڻ ویکٹر جي شڪل جا ذميوار هوندا آهن، پر آپريٽنگ سسٽم ۽ ان ۾ استعمال ٿيندڙ پروگرامز انڪوڊنگ جا ذميوار هوندا آهن. اهي. توهان جي ڪمپيوٽر تي ڪو به متن بائٽس جو هڪ سيٽ هوندو، جنهن مان هر هڪ هن متن جي هڪ هڪ اکرن کي انڪوڊ ڪري ٿو. اهو پروگرام جيڪو هن متن کي اسڪرين تي ڏيکاري ٿو (ٽيڪسٽ ايڊيٽر، برائوزر، وغيره)، جڏهن ڪوڊ پارس ڪري ٿو، ايندڙ ڪردار جي انڪوڊنگ کي پڙهي ٿو ۽ گهربل فونٽ فائل ۾ لاڳاپيل ویکٹر فارم ڳولي ٿو، جيڪو هن کي ڊسپلي ڪرڻ لاء ڳنڍيل آهي. ٽيڪسٽ سند. سڀڪنھن شيء کي سادي ۽ banal آهي. هن جو مطلب اهو آهي ته ڪنهن به ڪردار کي انڪوڊ ڪرڻ لاءِ جنهن جي اسان کي ضرورت آهي (مثال طور، قومي الفابيٽ مان)، ٻه شرط پورا ٿيڻ گهرجن: هن ڪردار جو ویکٹر فارم استعمال ٿيل فونٽ ۾ هجڻ گهرجي، ۽ هي ڪردار انڪوڊ ٿي سگهي ٿو وڌايل ASCII انڪوڊنگز ۾. هڪ بائيٽ ۾. تنهن ڪري، اهڙين اختيارن جو هڪ مڪمل گروپ آهي. صرف روسي ٻوليءَ جي اکرن کي انڪوڊنگ ڪرڻ لاءِ، وڌايل اسڪا جا ڪيترائي قسم آھن. مثال طور، CP866 اصل ۾ ظاهر ٿيو ، جنهن ۾ روسي الفابيٽ مان اکر استعمال ڪرڻ جي صلاحيت هئي، ۽ اهو ASCII جو وڌايل نسخو هو. اهو آهي ته، ان جو مٿو حصو مڪمل طور تي اسڪا جي بنيادي نسخي سان ٺهڪي اچي ٿو (128 لاطيني اکر، انگ ۽ ٻيا ڪيپ)، جيڪو صرف مٿي اسڪرين شاٽ ۾ پيش ڪيو ويو آهي، پر CP866 انڪوڊنگ سان ٽيبل جي هيٺئين حصي ۾ ظاهر ڪيل ظاهري طور تي ظاهر ڪيو ويو آهي. صرف ھيٺ ڏنل اسڪرين شاٽ ۽ انڪوڊ ڪرڻ جي اجازت ڏني 128 اکر (روسي اکر ۽ سڀني قسمن جا pseudo-graphics): توھان ڏسندا، ساڄي ڪالم ۾ نمبر 8 سان شروع ٿين ٿا، ڇاڪاڻ ته نمبر 0 کان 7 تائين ASCII جي بنيادي حصي جو حوالو ڏيو (ڏسو پهريون اسڪرين شاٽ). اهڙيءَ طرح، CP866 ۾ سيريلڪ اکر “M” ۾ ڪوڊ 9C هوندو (اهو 9 سان لاڳاپيل لڪير جي چوڪ تي واقع آهي ۽ هيڪساڊيڪل نمبر سسٽم ۾ نمبر C سان ڪالم)، جنهن کي معلومات جي هڪ بائيٽ ۾ لکي سگهجي ٿو. ، ۽ جيڪڏهن روسي اکرن سان هڪ مناسب فونٽ آهي ته هي خط بغير ڪنهن پريشاني جي متن ۾ ظاهر ٿيندو. اها رقم ڪٿان آئي؟CP866 ۾ pseudographics ؟ سڄو نقطو اهو آهي ته روسي متن لاءِ هي انڪوڊنگ واپس ترقي يافته سالن ۾ ترقي ڪئي وئي هئي جڏهن گرافڪ آپريٽنگ سسٽم وسيع نه هئا جيئن اهي هاڻي آهن. ۽ ڊوسا ۽ ساڳئي ٽيڪسٽ آپريٽنگ سسٽم ۾، pseudographics اهو ممڪن ڪيو ته گهٽ ۾ گهٽ متن جي ڊيزائن کي متنوع ڪرڻ، ۽ تنهن ڪري CP866 ۽ ان جي ٻين سڀني ساٿين جي درجي کان اسڪوا جي وڌايل ورزن جي درجي ۾ شامل آهن. CP866 IBM پاران ورهايو ويو، پر ان کان علاوه، روسي ٻوليء جي اکرن لاء ڪيترن ئي انڪوڊنگز کي ترقي ڪئي وئي، مثال طور، KOI8-R ساڳئي قسم سان منسوب ڪري سگهجي ٿو (وڌايو ويو ASCII) : ان جي عمل جو اصول ساڳيو رهي ٿو. CP866 جو ٿورو اڳ بيان ڪيو ويو آهي - متن جي هر ڪردار کي هڪ واحد بائيٽ طور انڪوڊ ڪيو ويو آهي. اسڪرين شاٽ KOI8-R ٽيبل جو ٻيو اڌ ڏيکاري ٿو، ڇاڪاڻ ته پهريون اڌ مڪمل طور تي بنيادي اسوڪا سان مطابقت رکي ٿو، جيڪو هن آرٽيڪل ۾ پهرين اسڪرين شاٽ ۾ ڏيکاريل آهي. KOI8-R انڪوڊنگ جي خاصيتن مان، اهو نوٽ ڪري سگهجي ٿو ته ان جي ٽيبل ۾ سيريلڪ اکر الفابيٽ جي ترتيب ۾ نه آهن، جيئن CP866 ۾ ڪيو ويو آهي. جيڪڏهن توهان پهرين اسڪرين شاٽ تي نظر وجهو (بنيادي حصو جو، جيڪو سڀني وڌايل انڪوڊنگن ۾ شامل آهي)، توهان ڏسندا ته KOI8-R ۾ روسي اکر ٽيبل جي ساڳئي خاني ۾ واقع آهن جيئن لاطيني الفابيٽ جا لاڳاپيل اکر. ٽيبل جي پهرين حصي کان. اهو صرف هڪ ساٽ (ٻه کان ستين پاور يا 128) کي رد ڪندي روسي کان لاطيني اکرن کي مٽائڻ جي سهولت لاءِ ڪيو ويو.
ونڊوز 1251 - ASCII جو جديد نسخو ۽ ڇو ڪڪڙ نڪرندا آهن
ٽيڪسٽ انڪوڊنگ جي وڌيڪ ترقي حقيقت اها هئي ته گرافڪ آپريٽنگ سسٽم مقبوليت حاصل ڪري رهيا هئا ۽ انهن ۾ pseudographics استعمال ڪرڻ جي ضرورت وقت سان غائب ٿي وئي. نتيجي طور، ھڪڙو سڄو گروھ اڀري آيو، جو اصل ۾، اڃا تائين اسوڪا (ٽيڪسٽ جو ھڪڙو ڪردار صرف معلومات جي ھڪڙي بائيٽ سان انڪوڊ ٿيل آھي) جا وڌايل نسخا آھن، پر pseudographic علامتن جي استعمال کان سواء. اهي نام نهاد ANSI انڪوڊنگز سان تعلق رکن ٿا، جيڪي آمريڪي معيار انسٽيٽيوٽ پاران ٺاهيا ويا آهن. عام اصطلاحن ۾، نالو سائريلڪ پڻ استعمال ڪيو ويو نسخي لاء روسي ٻوليء جي مدد سان. ان جو هڪ مثال هوندو Windows 1251 . اهو اڳ ۾ استعمال ٿيل CP866 ۽ KOI8-R کان مناسب طور تي مختلف آهي ته ان ۾ pseudographic علامتن جي جڳهه روسي ٽائپوگرافي جي گم ٿيل علامتن (سواءِ تلفظ جي نشان جي)، ۽ گڏوگڏ سلوڪ ٻولين ۾ استعمال ٿيندڙ علامتن جي ويجهو آهي. روسي (يوڪريني، بيلاروسي، وغيره) ): روسي ٻوليءَ جي انڪوڊنگز جي اهڙي وڏي تعداد جي ڪري، فونٽ ٺاهيندڙن ۽ سافٽ ويئر ٺاهيندڙن کي مسلسل سر درد هوندو هو، ۽ توهان ۽ مان، پيارا پڙهندڙ، اڪثر ڪري انهن ساڳين بدمعاشي مسئلن ۾ مبتلا ٿي ويندا هئاسين. جڏهن متن ۾ استعمال ٿيل نسخي سان مونجهارو هو. گهڻو ڪري اهي ٻاهر نڪرندا هئا جڏهن اي ميل ذريعي پيغام موڪلڻ ۽ وصول ڪندا هئا، جنهن ۾ تمام پيچيده تبادلي جي جدولن جي تخليق شامل هئي، جيڪا حقيقت ۾، هن مسئلي کي بنيادي طور تي حل نه ڪري سگهيا، ۽ اڪثر ڪري صارفين لاطيني خطن جي ترجمي کي خط و ڪتابت لاء استعمال ڪندا هئا. CP866، KOI8-R يا ونڊوز 1251 وانگر روسي انڪوڊنگز استعمال ڪرڻ وقت بدنام گبباري کان پاسو ڪريو. حقيقت ۾، روسي متن جي بدران ظاهر ٿيندڙ شگاف هڪ ڏنل ٻوليءَ جي انڪوڊنگ جي غلط استعمال جو نتيجو هو، جيڪو هڪ ٻوليءَ سان مطابقت نه رکندو هو. جيڪو ٽيڪسٽ پيغام اصل ۾ انڪوڊ ٿيل هو. اچو ته چئو ته جيڪڏهن توهان Windows 1251 ڪوڊ ٽيبل کي استعمال ڪندي CP866 استعمال ڪندي انڪوڊ ٿيل اکرن کي ڏيکارڻ جي ڪوشش ڪندا ته پوءِ اهي ساڳيا گببارش (ڪردارن جو هڪ بي معنيٰ سيٽ) نڪرندا، مڪمل طور تي پيغام جي متن کي بدلائي. ساڳي صورتحال اڪثر پيدا ٿيندي آهي جڏهن ويب سائيٽون، فورمز يا بلاگ ٺاهڻ ۽ ترتيب ڏيڻ، جڏهن روسي اکرن سان ٽيڪسٽ غلطي سان غلط انڪوڊنگ ۾ محفوظ ڪيو ويندو آهي جيڪو سائيٽ تي ڊفالٽ طور استعمال ڪيو ويندو آهي، يا غلط ٽيڪسٽ ايڊيٽر ۾، جيڪو هڪ پوشيده گيگ شامل ڪري ٿو. ننگي اک سان ڪوڊ ڏانهن. آخر ۾، ڪيترائي ماڻھو ھن صورتحال مان تنگ ٿي ويا آھن گھڻن انڪوڊنگن ۽ مسلسل گندگي کي ختم ڪرڻ سان، ۽ ھڪڙي نئين آفاقي تبديليءَ جي ٺاھڻ لاءِ اڳڀرائيون نمودار ٿي ويون، جيڪي سڀني موجودن کي مٽائي ڇڏينديون ۽ اڻ پڙھيل نصوص جي ظاھر ٿيڻ سان مسئلو حل ڪندا. . ان کان علاوه، چيني ٻولين جو مسئلو هو، جتي 256 کان وڌيڪ ٻولي جا اکر هئا.
يونيڪوڊ - آفاقي انڪوڊنگس UTF 8، 16 ۽ 32
ڏکڻ اوڀر ايشيائي ٻوليءَ جي گروپ جا اهي هزارين ڪردار ممڪن طور تي معلومات جي هڪ بائيٽ ۾ بيان نٿا ڪري سگهجن جيڪي ASCII جي وڌايل ورزن ۾ اکرن کي انڪوڊنگ ڪرڻ لاءِ مختص ڪيا ويا هئا. نتيجي طور، يونيڪوڊ (يونيڪوڊ ڪنسورشيم) نالي هڪ ڪنسورشيم آئي ٽي صنعت جي ڪيترن ئي اڳواڻن (جيڪي سافٽ ويئر ٺاهيندا آهن، جيڪي هارڊويئر کي انڪوڊ ڪندا آهن، جيڪي فونٽ ٺاهيندا آهن) جي تعاون سان ٺاهيا ويا، جيڪي هڪ عالمگير ٽيڪسٽ انڪوڊنگ جي شروعات ۾ دلچسپي رکندا هئا. يونيڪوڊ ڪنسورشيم جي سرپرستي هيٺ جاري ڪيل پهرين تبديلي UTF 32 هئي . انڪوڊنگ نالي ۾ نمبر جو مطلب آھي بٽ جو تعداد جيڪو ھڪڙي اکرن کي انڪوڊ ڪرڻ لاءِ استعمال ڪيو ويندو آھي. 32 بٽ برابر 4 بائيٽ معلومات جي جيڪا نئين يونيورسل UTF انڪوڊنگ ۾ هڪ واحد ڪردار کي انڪوڊ ڪرڻ جي ضرورت پوندي. نتيجي طور، ساڳئي فائل متن سان گڏ ASCII جي وڌايل ورزن ۾ انڪوڊ ٿيل ۽ UTF-32 ۾، پوئين صورت ۾، هڪ سائيز (وزن) چار ڀيرا وڏو هوندو. اهو خراب آهي، پر هاڻي اسان وٽ UTF استعمال ڪندي انڪوڊ ڪرڻ جو موقعو آهي ڪيترن ئي ڪردارن جي برابر ٻه کان ٽيٽيهه سيڪنڊ پاور ( بلين ڪردار جيڪي ڪنهن به واقعي ضروري قيمت کي وڏي مارجن سان ڍڪيندا). پر يورپي گروپ جي ٻولين سان ڪيترن ئي ملڪن کي انڪوڊنگ ۾ ايتري وڏي انگ اکرن کي استعمال ڪرڻ جي ضرورت نه هئي، جڏهن ته، UTF-32 استعمال ڪندي، انهن کي بغير ڪنهن سبب جي ٽيڪسٽ دستاويزن جي وزن ۾ چار ڀيرا اضافو نه مليو، ۽ نتيجي طور، انٽرنيٽ ٽرئفڪ جي مقدار ۽ ذخيرو ٿيل ڊيٽا جي مقدار ۾ اضافو. اهو تمام گهڻو آهي، ۽ ڪو به اهڙو فضول برداشت نه ڪري سگهيو. يونيڪوڊ جي ترقيءَ جي نتيجي ۾، UTF-16 ظاهر ٿيو ، جيڪو ايترو ته ڪامياب ٿيو جو ان کي ڊفالٽ طور قبول ڪيو ويو بنيادي جاءِ جي طور تي سڀني ڪردارن لاءِ جيڪي اسان استعمال ڪريون ٿا. اهو هڪ ڪردار انڪوڊ ڪرڻ لاءِ ٻه بائيٽ استعمال ڪندو آهي. اچو ته ڏسو ته هي شيء ڪيئن نظر اچي ٿو. ونڊوز آپريٽنگ سسٽم ۾، توهان رستي تي عمل ڪري سگهو ٿا "شروع" - "پروگرام" - "لوازمات" - "سسٽم اوزار" - "ڪردار ٽيبل". نتيجي طور، توهان جي سسٽم تي نصب ڪيل سڀني فانٽ جي ویکٹر جي شڪلن سان هڪ ٽيبل کوليو ويندو. جيڪڏھن توھان يونيڪوڊ اکر سيٽ کي منتخب ڪريو ”اعلي اختيارن“ ۾، توھان ھر فونٽ لاءِ الڳ الڳ ان ۾ شامل ڪيل اکرن جي پوري حد کي ڏسي سگھندا. رستي ۾، انهن مان ڪنهن تي ڪلڪ ڪندي، توهان ڏسي سگهو ٿا ان جو ٻه-بائيٽ ڪوڊ UTF-16 فارميٽ ۾ ، جنهن ۾ چار هيڪساڊيڪل انگ شامل آهن: UTF-16 ۾ 16 بٽس استعمال ڪندي ڪيترا ڪردار انڪوڊ ڪري سگھجن ٿا؟ 65,536 (ٻه کان ڇهن جي طاقت)، ۽ هي اهو انگ آهي جنهن کي يونيڪوڊ ۾ بنيادي اسپيس طور قبول ڪيو ويو آهي. ان کان علاوه، ان کي استعمال ڪندي اٽڪل 2 ملين اکرن کي انڪوڊ ڪرڻ جا طريقا آهن، پر اهي متن جي هڪ لک اکرن جي وڌايل جاءِ تائين محدود هئا. پر يونيڪوڊ انڪوڊنگ جو هي ڪامياب ورزن به انهن لاءِ گهڻو اطمينان نه آڻي سگهيو، جيڪي صرف انگريزيءَ ۾ پروگرام لکيا، چون ٿا، ڇاڪاڻ ته ASCII جي وڌايل ورزن کان UTF-16 ۾ منتقلي کان پوءِ، دستاويزن جو وزن ٻيڻو ٿي ويو (هڪ بائيٽ في. Aski ۾ ڪردار ۽ YUTF-16 ۾ ساڳئي ڪردار لاء ٻه بائيٽ). يونيڪوڊ ڪنسورشيم ۾ هر ڪنهن ۽ هر شيءِ کي مطمئن ڪرڻ لاءِ اهو فيصلو ڪيو ويو ته متغير ڊگھائي انڪوڊنگ سان گڏ اچي . ان کي UTF-8 سڏيو ويو. نالي ۾ اٺن جي باوجود، ان جي اصل ۾ هڪ متغير ڊيگهه آهي، يعني. متن جي هر ڪردار کي انڪوڊ ڪري سگهجي ٿو هڪ کان ڇهه بائيٽ جي ڊيگهه ۾. عملي طور تي، UTF-8 صرف هڪ کان چار بائٽس جي حد استعمال ڪري ٿو، ڇاڪاڻ ته ڪوڊ جي چار بائيٽ کان وڌيڪ اهو نظرياتي طور تي ممڪن ناهي ته ڪنهن به شيء کي تصور ڪرڻ لاء. ان ۾ سڀئي لاطيني اکرن کي هڪ بائيٽ ۾ انڪوڊ ڪيو ويو آهي، جيئن سٺي پراڻي ASCII ۾. قابل ذڪر ڳالهه اها آهي ته صرف لاطيني الفابيٽ کي انڪوڊنگ ڪرڻ جي صورت ۾، جيتوڻيڪ اهي پروگرام جيڪي يونيڪوڊ کي نٿا سمجهن، اهي اڃا به پڙهي سگهندا جيڪي YTF-8 ۾ انڪوڊ ٿيل آهن. اهو آهي، اسوڪا جو بنيادي حصو صرف يونيڪوڊ ڪنسورشيم جي هن دماغ جي تخليق ڏانهن منتقل ڪيو ويو. UTF-8 ۾ سيريلڪ اکر ٻن بائيٽن ۾ انڪوڊ ٿيل آھن، ۽ مثال طور، جارجيا اکر ٽن بائيٽن ۾ انڪوڊ ٿيل آھن. يونيڪوڊ ڪنسورشيم، UTF 16 ۽ 8 ٺاهڻ کان پوء، بنيادي مسئلو حل ڪيو - هاڻي اسان وٽ اسان جي فونٽ ۾ هڪ واحد ڪوڊ اسپيس آهي . ۽ ھاڻي انھن جا ٺاھيندڙ ان کي صرف پنھنجي طاقت ۽ صلاحيتن جي بنياد تي ٽيڪسٽ اکرن جي ویکٹر فارمن سان ڀري سگھن ٿا. مٿي ڏنل ”ڪرڪٽر ٽيبل“ ۾ توهان ڏسي سگهو ٿا ته مختلف فونٽس مختلف انگن اکرن کي سپورٽ ڪن ٿا. ڪجھ يونيڪوڊ سان مالا مال فونٽ ڪافي ڳري ٿي سگھن ٿا. پر هاڻي انهن ۾ فرق نه آهي ته اهي مختلف انڪوڊنگز لاءِ ٺاهيا ويا هئا، پر حقيقت ۾ ته فونٽ ٺاهيندڙ واحد ڪوڊ اسپيس کي ڪجهه ویکٹر فارمن سان ڀريو آهي يا مڪمل نه ڀريو آهي.
روسي اکرن جي بدران چريو لفظ - ان کي ڪيئن حل ڪرڻ
اچو ته ھاڻي ڏسون ته متن جي بدران krakozyabrs ڪيئن ظاهر ٿين ٿا، يا ٻين لفظن ۾، روسي متن لاءِ صحيح انڪوڊنگ ڪيئن چونڊيو وڃي ٿو. دراصل، اهو ان پروگرام ۾ مقرر ڪيو ويو آهي جنهن ۾ توهان هي متن ٺاهيو يا ايڊٽ ڪيو، يا ٽيڪسٽ ٽڪڙن کي استعمال ڪندي ڪوڊ. ٽيڪسٽ فائلن کي ايڊٽ ڪرڻ ۽ ٺاهڻ لاءِ، مان ذاتي طور تي هڪ تمام سٺو استعمال ڪريان ٿو، منهنجي خيال ۾، Html ۽ PHP ايڊيٽر Notepad++ . بهرحال، اهو ٻين سوين پروگرامنگ ۽ مارڪ اپ ٻولين جي نحو کي نمايان ڪري سگهي ٿو، ۽ پڻ پلگ ان استعمال ڪندي وڌائڻ جي صلاحيت رکي ٿو. ڏنل لنڪ تي هن شاندار پروگرام جو تفصيلي جائزو پڙهو. Notepad++ جي مٿين مينيو ۾ هڪ آئٽم آهي “Encodings”، جتي توهان وٽ هڪ موجوده آپشن کي تبديل ڪرڻ جو موقعو هوندو جيڪو توهان جي سائيٽ تي ڊفالٽ طور استعمال ڪيو ويندو آهي: سائيٽ جي صورت ۾ Joomla 1.5 ۽ ان کان وڌيڪ، جيئن انهي سان گڏ ورڈپریس تي هڪ بلاگ جي صورت ۾، توهان کي ظاهر ٿيڻ کان پاسو ڪرڻ گهرجي Krakozyabrov BOM کان سواءِ UTF 8 آپشن چونڊيو . BOM اڳوڻو ڇا آهي؟ حقيقت اها آهي ته جڏهن اهي YUTF-16 انڪوڊنگ کي ترقي ڪري رهيا هئا، ڪجهه سببن لاء انهن کي ان سان ڳنڍڻ جو فيصلو ڪيو ويو آهي جيئن ته ڪردار ڪوڊ لکڻ جي صلاحيت ٻنهي سڌي ترتيب ۾ (مثال طور، 0A15) ۽ ريورس (150A) ۾. . ۽ پروگرامن لاءِ سمجھڻ لاءِ ته ڪھڙي ترتيب ۾ ڪوڊ پڙھڻ لاءِ، BOM (بائيٽ آرڊر مارڪ يا ٻين لفظن ۾، دستخط) ٺاھيو ويو، جنھن جو اظهار ڪيو ويو ھو ٽن اضافي بائيٽن کي شامل ڪرڻ ۾ دستاويزن جي شروعات ۾. UTF-8 انڪوڊنگ ۾، يونيڪوڊ ڪنسورشيم ۾ ڪو به BOM مهيا نه ڪيو ويو هو، ۽ تنهن ڪري هڪ دستخط شامل ڪرڻ (اهي بدنام اضافي ٽي بائيٽ دستاويز جي شروعات ۾) صرف ڪجهه پروگرامن کي ڪوڊ پڙهڻ کان روڪي ٿو. تنهن ڪري، UTF ۾ فائلون محفوظ ڪرڻ وقت، اسان کي هميشه BOM کان سواءِ اختيار چونڊڻ گهرجي (بغير دستخط جي). اهڙيءَ طرح، توهان اڳ ۾ ئي پنهنجو پاڻ کي ڪرڪوزائبرس جي ٻاهر نڪرڻ کان بچائيندا . ڇا قابل ذڪر آهي ته ونڊوز ۾ ڪجهه پروگرام اهو نٿا ڪري سگهن (اهي UTF-8 ۾ متن محفوظ نٿا ڪري سگهن بغير BOM)، مثال طور، ساڳيو بدنام ونڊوز نوٽ پيڊ. اهو دستاويز کي UTF-8 ۾ محفوظ ڪري ٿو، پر تڏهن به ان جي شروعات ۾ دستخط (ٽي اضافي بائيٽ) شامل ڪري ٿو. ان کان علاوه، اهي بائيٽ هميشه ساڳيا هوندا - سڌو ترتيب ۾ ڪوڊ پڙهو. پر سرور تي، هن ننڍڙي شيء جي ڪري، هڪ مسئلو پيدا ٿي سگهي ٿو - بدمعاش نڪرندا. تنهن ڪري، ڪنهن به حالت ۾ باقاعده ونڊوز نوٽ پيڊ استعمال نه ڪريو .توھان جي سائيٽ تي دستاويزن کي تبديل ڪرڻ لاءِ جيڪڏھن توھان نٿا چاھيو ته ڪو ٽڪرا ظاھر ٿئي. مان سمجهان ٿو اڳ ۾ ئي ذڪر ڪيل Notepad ++ ايڊيٽر کي بهترين ۽ آسان آپشن، جنهن ۾ عملي طور تي ڪا به خرابي ناهي ۽ صرف فائدن تي مشتمل آهي. Notepad++ ۾، جڏهن توهان هڪ انڪوڊنگ چونڊيو ٿا، توهان وٽ اختيار هوندو ته متن کي UCS-2 انڪوڊنگ ۾ تبديل ڪريو، جيڪو فطرت ۾ يونيڪوڊ معيار جي تمام ويجهو آهي. نوٽ پيڊ ۾ پڻ ANSI ۾ ٽيڪسٽ انڪوڊ ڪرڻ ممڪن ٿيندو، يعني. روسي ٻوليءَ جي حوالي سان، هي Windows 1251 هوندو، جنهن کي اسان مٿي بيان ڪري چڪا آهيون، اها معلومات ڪٿان آئي؟ اهو توهان جي ونڊوز آپريٽنگ سسٽم جي رجسٽري ۾ رجسٽر ٿيل آهي - جيڪو ANSI جي صورت ۾ چونڊڻ لاءِ انڪوڊنگ، جيڪو OEM جي صورت ۾ چونڊڻ لاءِ (روسي ٻولي لاءِ اهو هوندو CP866). جيڪڏهن توهان پنهنجي ڪمپيوٽر تي ڪا ٻي ڊفالٽ ٻولي سيٽ ڪريو ٿا، ته پوءِ اهي انڪوڊنگ ساڳي ٻولي لاءِ ANSI يا OEM ڪيٽيگري مان ساڳين ٻولين سان تبديل ڪيا ويندا. توھان کان پوءِ توھان دستاويز کي Notepad++ ۾ محفوظ ڪريو انڪوڊنگ ۾ جنھن جي توھان کي ضرورت آھي يا دستاويز کي ايڊيٽنگ لاءِ سائيٽ تان کوليو، توھان ان جو نالو ڏسي سگھوٿا ايڊيٽر جي ھيٺئين ساڄي ڪنڊ ۾: مونجهاري کان بچڻ لاءِ ، مٿي بيان ڪيل قدمن کان علاوه. , اهو مفيد ٿيندو ته سورس ڪوڊ ان جي هيڊر ۾ لکڻ لاءِ سائيٽ جي سڀني صفحن تي هن تمام گهڻي انڪوڊنگ بابت معلومات هجي، ته جيئن سرور يا مقامي ميزبان تي ڪو مونجهارو نه ٿئي. عام طور تي، Html کان سواءِ سڀ هائپر ٽيڪسٽ مارڪ اپ ٻوليون خاص xml بيان استعمال ڪن ٿيون، جيڪو متن جي انڪوڊنگ کي بيان ڪري ٿو.
<?xml version="1.0" encoding="windows-1251"?>
ڪوڊ پارس ڪرڻ کان اڳ، برائوزر ڄاڻي ٿو ته ڪھڙو ورجن استعمال ڪيو پيو وڃي ۽ ان کي ان ٻوليءَ جي ڪردارن جي ڪوڊن جي تشريح ڪرڻ جي ضرورت ڪيئن آھي. پر قابل ذڪر ڳالهه اها آهي ته جيڪڏهن توهان دستاويز کي ڊفالٽ يونيڪوڊ ۾ محفوظ ڪريو ٿا، ته هي xml اعلان کي ختم ڪري سگهجي ٿو (انڪوڊنگ کي UTF-8 سمجهيو ويندو جيڪڏهن ڪو BOM يا UTF-16 نه هجي جيڪڏهن BOM آهي). HTML دستاويز جي صورت ۾، ميٽا عنصر انڪوڊنگ کي ظاهر ڪرڻ لاءِ استعمال ڪيو ويندو آهي ، جيڪو کولڻ ۽ بند ڪرڻ واري هيڊ ٽيگ جي وچ ۾ رکيل آهي:
<head>...<meta charset="utf-8">...</head>
هي داخلا Html 4.01 ۾ معيار کان بلڪل مختلف آهي، پر مڪمل طور تي Html 5 معيار سان مطابقت رکي ٿي، ۽ اهو صحيح طور تي ڪنهن به موجوده استعمال ٿيل برائوزرن کي سمجهي سگهندو. نظريي ۾، ميٽا عنصر جيڪو Html ڊاڪيومينٽ جي انڪوڊنگ کي ظاهر ڪري ٿو، اوترو بهتر طور تي ڊاڪيومينٽ جي هيڊر ۾ رکيو ويندو، ته جيئن ٽيڪسٽ پهريون اکر سامهون اچي، نه ته بنيادي 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 اکرن سان ٽيبل تي ويجهڙائي سان ڏسندا، توهان ڏسندا ته اهي هيڪساڊيڪل انڪوڊنگ ۾ نمائندگي ڪيا ويا آهن. مثال طور، "Asterisk" اسڪي ۾ هيڪساڊيڪل نمبر 2A سان ملندو آهي. توهان کي شايد خبر آهي ته هيڪساڊسيمل نمبر سسٽم ۾ عربي انگن کان علاوه لاطيني اکر A (يعني ڏهه) کان F (يعني پندرهن) تائين به استعمال ٿيندا آهن. خير، هڪ بائنري نمبر کي هيڪساڊيڪل ۾ تبديل ڪرڻ لاءهيٺ ڏنل سادي طريقي سان استعمال ڪريو. معلومات جي هر بائيٽ کي چار بِٽ جي ٻن حصن ۾ ورهايو ويو آهي. اهي. هر اڌ بائيٽ ۾، صرف ڇهن قدرن (ٻن کان چوٿين طاقت) کي بائنري ۾ انڪوڊ ڪري سگهجي ٿو، جنهن کي آسانيءَ سان هيڪساڊيڪل نمبر طور پيش ڪري سگهجي ٿو. ان کان علاوه، بائيٽ جي کاٻي اڌ ۾، درجا ٻيهر ڳڻڻ جي ضرورت پوندي صفر کان شروع ٿيندي، ۽ نه جيئن اسڪرين شاٽ ۾ ڏيکاريل آهي. نتيجي طور، اسان حاصل ڪيو ته نمبر E9 اسڪرين شاٽ ۾ انڪوڊ ٿيل آهي. مون کي اميد آهي ته منهنجي استدلال جو طريقو ۽ هن پزل جو حل توهان لاء واضح هو. خير، هاڻي اچو ته جاري رکون، حقيقت ۾، ٽيڪسٽ انڪوڊنگ بابت ڳالهائڻ.
توھان ڏسندا، ساڄي ڪالم ۾ نمبر 8 سان شروع ٿين ٿا، ڇاڪاڻ ته نمبر 0 کان 7 تائين ASCII جي بنيادي حصي جو حوالو ڏيو (ڏسو پهريون اسڪرين شاٽ). اهڙيءَ طرح، CP866 ۾ سيريلڪ اکر “M” ۾ ڪوڊ 9C هوندو (اهو 9 سان لاڳاپيل لڪير جي چوڪ تي واقع آهي ۽ هيڪساڊيڪل نمبر سسٽم ۾ نمبر C سان ڪالم)، جنهن کي معلومات جي هڪ بائيٽ ۾ لکي سگهجي ٿو. ، ۽ جيڪڏهن روسي اکرن سان هڪ مناسب فونٽ آهي ته هي خط بغير ڪنهن پريشاني جي متن ۾ ظاهر ٿيندو. اها رقم ڪٿان آئي؟CP866 ۾ pseudographics ؟ سڄو نقطو اهو آهي ته روسي متن لاءِ هي انڪوڊنگ واپس ترقي يافته سالن ۾ ترقي ڪئي وئي هئي جڏهن گرافڪ آپريٽنگ سسٽم وسيع نه هئا جيئن اهي هاڻي آهن. ۽ ڊوسا ۽ ساڳئي ٽيڪسٽ آپريٽنگ سسٽم ۾، pseudographics اهو ممڪن ڪيو ته گهٽ ۾ گهٽ متن جي ڊيزائن کي متنوع ڪرڻ، ۽ تنهن ڪري CP866 ۽ ان جي ٻين سڀني ساٿين جي درجي کان اسڪوا جي وڌايل ورزن جي درجي ۾ شامل آهن. CP866 IBM پاران ورهايو ويو، پر ان کان علاوه، روسي ٻوليء جي اکرن لاء ڪيترن ئي انڪوڊنگز کي ترقي ڪئي وئي، مثال طور، KOI8-R ساڳئي قسم سان منسوب ڪري سگهجي ٿو (وڌايو ويو ASCII) : 
ان جي عمل جو اصول ساڳيو رهي ٿو. CP866 جو ٿورو اڳ بيان ڪيو ويو آهي - متن جي هر ڪردار کي هڪ واحد بائيٽ طور انڪوڊ ڪيو ويو آهي. اسڪرين شاٽ KOI8-R ٽيبل جو ٻيو اڌ ڏيکاري ٿو، ڇاڪاڻ ته پهريون اڌ مڪمل طور تي بنيادي اسوڪا سان مطابقت رکي ٿو، جيڪو هن آرٽيڪل ۾ پهرين اسڪرين شاٽ ۾ ڏيکاريل آهي. KOI8-R انڪوڊنگ جي خاصيتن مان، اهو نوٽ ڪري سگهجي ٿو ته ان جي ٽيبل ۾ سيريلڪ اکر الفابيٽ جي ترتيب ۾ نه آهن، جيئن CP866 ۾ ڪيو ويو آهي. جيڪڏهن توهان پهرين اسڪرين شاٽ تي نظر وجهو (بنيادي حصو جو، جيڪو سڀني وڌايل انڪوڊنگن ۾ شامل آهي)، توهان ڏسندا ته KOI8-R ۾ روسي اکر ٽيبل جي ساڳئي خاني ۾ واقع آهن جيئن لاطيني الفابيٽ جا لاڳاپيل اکر. ٽيبل جي پهرين حصي کان. اهو صرف هڪ ساٽ (ٻه کان ستين پاور يا 128) کي رد ڪندي روسي کان لاطيني اکرن کي مٽائڻ جي سهولت لاءِ ڪيو ويو.
۾ مبتلا ٿي ويندا هئاسين. جڏهن متن ۾ استعمال ٿيل نسخي سان مونجهارو هو. گهڻو ڪري اهي ٻاهر نڪرندا هئا جڏهن اي ميل ذريعي پيغام موڪلڻ ۽ وصول ڪندا هئا، جنهن ۾ تمام پيچيده تبادلي جي جدولن جي تخليق شامل هئي، جيڪا حقيقت ۾، هن مسئلي کي بنيادي طور تي حل نه ڪري سگهيا، ۽ اڪثر ڪري صارفين لاطيني خطن جي ترجمي کي خط و ڪتابت لاء استعمال ڪندا هئا. CP866، KOI8-R يا ونڊوز 1251 وانگر روسي انڪوڊنگز استعمال ڪرڻ وقت بدنام گبباري کان پاسو ڪريو. حقيقت ۾، روسي متن جي بدران ظاهر ٿيندڙ شگاف هڪ ڏنل ٻوليءَ جي انڪوڊنگ جي غلط استعمال جو نتيجو هو، جيڪو هڪ ٻوليءَ سان مطابقت نه رکندو هو. جيڪو ٽيڪسٽ پيغام اصل ۾ انڪوڊ ٿيل هو. اچو ته چئو ته جيڪڏهن توهان Windows 1251 ڪوڊ ٽيبل کي استعمال ڪندي CP866 استعمال ڪندي انڪوڊ ٿيل اکرن کي ڏيکارڻ جي ڪوشش ڪندا ته پوءِ اهي ساڳيا گببارش (ڪردارن جو هڪ بي معنيٰ سيٽ) نڪرندا، مڪمل طور تي پيغام جي متن کي بدلائي. ساڳي صورتحال اڪثر پيدا ٿيندي آهي جڏهن ويب سائيٽون، فورمز يا بلاگ ٺاهڻ ۽ ترتيب ڏيڻ، جڏهن روسي اکرن سان ٽيڪسٽ غلطي سان غلط انڪوڊنگ ۾ محفوظ ڪيو ويندو آهي جيڪو سائيٽ تي ڊفالٽ طور استعمال ڪيو ويندو آهي، يا غلط ٽيڪسٽ ايڊيٽر ۾، جيڪو هڪ پوشيده گيگ شامل ڪري ٿو. ننگي اک سان ڪوڊ ڏانهن. آخر ۾، ڪيترائي ماڻھو ھن صورتحال مان تنگ ٿي ويا آھن گھڻن انڪوڊنگن ۽ مسلسل گندگي کي ختم ڪرڻ سان، ۽ ھڪڙي نئين آفاقي تبديليءَ جي ٺاھڻ لاءِ اڳڀرائيون نمودار ٿي ويون، جيڪي سڀني موجودن کي مٽائي ڇڏينديون ۽ اڻ پڙھيل نصوص جي ظاھر ٿيڻ سان مسئلو حل ڪندا. . ان کان علاوه، چيني ٻولين جو مسئلو هو، جتي 256 کان وڌيڪ ٻولي جا اکر هئا. 
UTF-16 ۾ 16 بٽس استعمال ڪندي ڪيترا ڪردار انڪوڊ ڪري سگھجن ٿا؟ 65,536 (ٻه کان ڇهن جي طاقت)، ۽ هي اهو انگ آهي جنهن کي يونيڪوڊ ۾ بنيادي اسپيس طور قبول ڪيو ويو آهي. ان کان علاوه، ان کي استعمال ڪندي اٽڪل 2 ملين اکرن کي انڪوڊ ڪرڻ جا طريقا آهن، پر اهي متن جي هڪ لک اکرن جي وڌايل جاءِ تائين محدود هئا. پر يونيڪوڊ انڪوڊنگ جو هي ڪامياب ورزن به انهن لاءِ گهڻو اطمينان نه آڻي سگهيو، جيڪي صرف انگريزيءَ ۾ پروگرام لکيا، چون ٿا، ڇاڪاڻ ته ASCII جي وڌايل ورزن کان UTF-16 ۾ منتقلي کان پوءِ، دستاويزن جو وزن ٻيڻو ٿي ويو (هڪ بائيٽ في. Aski ۾ ڪردار ۽ YUTF-16 ۾ ساڳئي ڪردار لاء ٻه بائيٽ). يونيڪوڊ ڪنسورشيم ۾ هر ڪنهن ۽ هر شيءِ کي مطمئن ڪرڻ لاءِ اهو فيصلو ڪيو ويو ته متغير ڊگھائي انڪوڊنگ سان گڏ اچي . ان کي UTF-8 سڏيو ويو. نالي ۾ اٺن جي باوجود، ان جي اصل ۾ هڪ متغير ڊيگهه آهي، يعني. متن جي هر ڪردار کي انڪوڊ ڪري سگهجي ٿو هڪ کان ڇهه بائيٽ جي ڊيگهه ۾. عملي طور تي، UTF-8 صرف هڪ کان چار بائٽس جي حد استعمال ڪري ٿو، ڇاڪاڻ ته ڪوڊ جي چار بائيٽ کان وڌيڪ اهو نظرياتي طور تي ممڪن ناهي ته ڪنهن به شيء کي تصور ڪرڻ لاء. ان ۾ سڀئي لاطيني اکرن کي هڪ بائيٽ ۾ انڪوڊ ڪيو ويو آهي، جيئن سٺي پراڻي ASCII ۾. قابل ذڪر ڳالهه اها آهي ته صرف لاطيني الفابيٽ کي انڪوڊنگ ڪرڻ جي صورت ۾، جيتوڻيڪ اهي پروگرام جيڪي يونيڪوڊ کي نٿا سمجهن، اهي اڃا به پڙهي سگهندا جيڪي YTF-8 ۾ انڪوڊ ٿيل آهن. اهو آهي، اسوڪا جو بنيادي حصو صرف يونيڪوڊ ڪنسورشيم جي هن دماغ جي تخليق ڏانهن منتقل ڪيو ويو. UTF-8 ۾ سيريلڪ اکر ٻن بائيٽن ۾ انڪوڊ ٿيل آھن، ۽ مثال طور، جارجيا اکر ٽن بائيٽن ۾ انڪوڊ ٿيل آھن. يونيڪوڊ ڪنسورشيم، UTF 16 ۽ 8 ٺاهڻ کان پوء، بنيادي مسئلو حل ڪيو - هاڻي اسان وٽ اسان جي فونٽ ۾ هڪ واحد ڪوڊ اسپيس آهي . ۽ ھاڻي انھن جا ٺاھيندڙ ان کي صرف پنھنجي طاقت ۽ صلاحيتن جي بنياد تي ٽيڪسٽ اکرن جي ویکٹر فارمن سان ڀري سگھن ٿا. مٿي ڏنل ”ڪرڪٽر ٽيبل“ ۾ توهان ڏسي سگهو ٿا ته مختلف فونٽس مختلف انگن اکرن کي سپورٽ ڪن ٿا. ڪجھ يونيڪوڊ سان مالا مال فونٽ ڪافي ڳري ٿي سگھن ٿا. پر هاڻي انهن ۾ فرق نه آهي ته اهي مختلف انڪوڊنگز لاءِ ٺاهيا ويا هئا، پر حقيقت ۾ ته فونٽ ٺاهيندڙ واحد ڪوڊ اسپيس کي ڪجهه ویکٹر فارمن سان ڀريو آهي يا مڪمل نه ڀريو آهي.
سائيٽ جي صورت ۾ Joomla 1.5 ۽ ان کان وڌيڪ، جيئن انهي سان گڏ ورڈپریس تي هڪ بلاگ جي صورت ۾، توهان کي ظاهر ٿيڻ کان پاسو ڪرڻ گهرجي Krakozyabrov BOM کان سواءِ UTF 8 آپشن چونڊيو . BOM اڳوڻو ڇا آهي؟ حقيقت اها آهي ته جڏهن اهي YUTF-16 انڪوڊنگ کي ترقي ڪري رهيا هئا، ڪجهه سببن لاء انهن کي ان سان ڳنڍڻ جو فيصلو ڪيو ويو آهي جيئن ته ڪردار ڪوڊ لکڻ جي صلاحيت ٻنهي سڌي ترتيب ۾ (مثال طور، 0A15) ۽ ريورس (150A) ۾. . ۽ پروگرامن لاءِ سمجھڻ لاءِ ته ڪھڙي ترتيب ۾ ڪوڊ پڙھڻ لاءِ، BOM (بائيٽ آرڊر مارڪ يا ٻين لفظن ۾، دستخط) ٺاھيو ويو، جنھن جو اظهار ڪيو ويو ھو ٽن اضافي بائيٽن کي شامل ڪرڻ ۾ دستاويزن جي شروعات ۾. UTF-8 انڪوڊنگ ۾، يونيڪوڊ ڪنسورشيم ۾ ڪو به BOM مهيا نه ڪيو ويو هو، ۽ تنهن ڪري هڪ دستخط شامل ڪرڻ (اهي بدنام اضافي ٽي بائيٽ دستاويز جي شروعات ۾) صرف ڪجهه پروگرامن کي ڪوڊ پڙهڻ کان روڪي ٿو. تنهن ڪري، UTF ۾ فائلون محفوظ ڪرڻ وقت، اسان کي هميشه BOM کان سواءِ اختيار چونڊڻ گهرجي (بغير دستخط جي). اهڙيءَ طرح، توهان اڳ ۾ ئي پنهنجو پاڻ کي ڪرڪوزائبرس جي ٻاهر نڪرڻ کان بچائيندا . ڇا قابل ذڪر آهي ته ونڊوز ۾ ڪجهه پروگرام اهو نٿا ڪري سگهن (اهي UTF-8 ۾ متن محفوظ نٿا ڪري سگهن بغير BOM)، مثال طور، ساڳيو بدنام ونڊوز نوٽ پيڊ. اهو دستاويز کي UTF-8 ۾ محفوظ ڪري ٿو، پر تڏهن به ان جي شروعات ۾ دستخط (ٽي اضافي بائيٽ) شامل ڪري ٿو. ان کان علاوه، اهي بائيٽ هميشه ساڳيا هوندا - سڌو ترتيب ۾ ڪوڊ پڙهو. پر سرور تي، هن ننڍڙي شيء جي ڪري، هڪ مسئلو پيدا ٿي سگهي ٿو - بدمعاش نڪرندا. تنهن ڪري، ڪنهن به حالت ۾ باقاعده ونڊوز نوٽ پيڊ استعمال نه ڪريو .توھان جي سائيٽ تي دستاويزن کي تبديل ڪرڻ لاءِ جيڪڏھن توھان نٿا چاھيو ته ڪو ٽڪرا ظاھر ٿئي. مان سمجهان ٿو اڳ ۾ ئي ذڪر ڪيل Notepad ++ ايڊيٽر کي بهترين ۽ آسان آپشن، جنهن ۾ عملي طور تي ڪا به خرابي ناهي ۽ صرف فائدن تي مشتمل آهي. Notepad++ ۾، جڏهن توهان هڪ انڪوڊنگ چونڊيو ٿا، توهان وٽ اختيار هوندو ته متن کي UCS-2 انڪوڊنگ ۾ تبديل ڪريو، جيڪو فطرت ۾ يونيڪوڊ معيار جي تمام ويجهو آهي. نوٽ پيڊ ۾ پڻ ANSI ۾ ٽيڪسٽ انڪوڊ ڪرڻ ممڪن ٿيندو، يعني. روسي ٻوليءَ جي حوالي سان، هي Windows 1251 هوندو، جنهن کي اسان مٿي بيان ڪري چڪا آهيون، اها معلومات ڪٿان آئي؟ اهو توهان جي ونڊوز آپريٽنگ سسٽم جي رجسٽري ۾ رجسٽر ٿيل آهي - جيڪو ANSI جي صورت ۾ چونڊڻ لاءِ انڪوڊنگ، جيڪو OEM جي صورت ۾ چونڊڻ لاءِ (روسي ٻولي لاءِ اهو هوندو CP866). جيڪڏهن توهان پنهنجي ڪمپيوٽر تي ڪا ٻي ڊفالٽ ٻولي سيٽ ڪريو ٿا، ته پوءِ اهي انڪوڊنگ ساڳي ٻولي لاءِ ANSI يا OEM ڪيٽيگري مان ساڳين ٻولين سان تبديل ڪيا ويندا. توھان کان پوءِ توھان دستاويز کي Notepad++ ۾ محفوظ ڪريو انڪوڊنگ ۾ جنھن جي توھان کي ضرورت آھي يا دستاويز کي ايڊيٽنگ لاءِ سائيٽ تان کوليو، توھان ان جو نالو ڏسي سگھوٿا ايڊيٽر جي ھيٺئين ساڄي ڪنڊ ۾: 
مونجهاري کان بچڻ لاءِ ، مٿي بيان ڪيل قدمن کان علاوه. , اهو مفيد ٿيندو ته سورس ڪوڊ ان جي هيڊر ۾ لکڻ لاءِ سائيٽ جي سڀني صفحن تي هن تمام گهڻي انڪوڊنگ بابت معلومات هجي، ته جيئن سرور يا مقامي ميزبان تي ڪو مونجهارو نه ٿئي. عام طور تي، Html کان سواءِ سڀ هائپر ٽيڪسٽ مارڪ اپ ٻوليون خاص xml بيان استعمال ڪن ٿيون، جيڪو متن جي انڪوڊنگ کي بيان ڪري ٿو.
GO TO FULL VERSION