امروز ما در مورد اینکه کراکوزیابرها از کجا در یک وب سایت و در برنامه ها آمده اند، کدگذاری متنی وجود دارد و کدام یک باید استفاده شود صحبت خواهیم کرد. بیایید نگاهی دقیق‌تر به تاریخچه توسعه آنها بیندازیم، از ASCII پایه، و همچنین نسخه‌های توسعه‌یافته آن CP866، KOI8-R، Windows 1251 و با رمزگذاری‌های کنسرسیوم یونیکد مدرن UTF 16 و 8 پایان می‌دهیم. فهرست مطالب:
برای برخی، این اطلاعات ممکن است غیر ضروری به نظر برسد، اما آیا می دانید که من به طور خاص در مورد کراکوزیابرهای خزنده (مجموعه شخصیت های ناخوانا) چقدر سؤال دریافت می کنم. اکنون این فرصت را خواهم داشت که همه را به متن این مقاله ارجاع دهم و اشتباهات خود را بیابم. خوب، برای جذب اطلاعات آماده شوید و سعی کنید جریان داستان را دنبال کنید.
ASCII - کدگذاری متن اصلی برای الفبای لاتین
توسعه رمزگذاری های متنی همزمان با شکل گیری صنعت IT اتفاق افتاد و در این مدت آنها توانستند دستخوش تغییرات بسیار زیادی شوند. از نظر تاریخی، همه چیز با EBCDIC شروع شد، که در تلفظ روسی نسبتاً ناسازگار بود، که امکان رمزگذاری حروف الفبای لاتین، اعداد عربی و علائم نگارشی را با کاراکترهای کنترلی امکان پذیر می کرد. اما با این حال، نقطه شروع برای توسعه رمزگذاری های متنی مدرن باید ASCII معروف (کد استاندارد آمریکایی برای تبادل اطلاعات، که در روسی معمولا به عنوان "پرسیدن" تلفظ می شود) در نظر گرفته شود. این 128 نویسه اول را توصیف می کند که بیشتر توسط کاربران انگلیسی زبان استفاده می شود - حروف لاتین، اعداد عربی و علائم نگارشی. این 128 کاراکتر توصیف شده در ASCII همچنین شامل برخی از کاراکترهای خدماتی مانند براکت ها، علامت های هش، ستاره و غیره است. در واقع، شما خودتان می توانید آنها را ببینید: این 128 کاراکتر از نسخه اصلی ASCII هستند که به استاندارد تبدیل شدند و در هر کدگذاری دیگری قطعا آنها را پیدا خواهید کرد و به این ترتیب ظاهر می شوند. اما واقعیت این است که با کمک یک بایت اطلاعات می توانید نه 128، بلکه 256 مقدار مختلف (دو به توان هشت برابر با 256) رمزگذاری کنید، بنابراین، پس از نسخه اصلی Asuka، یک کل مجموعه ای از رمزگذاری های ASCII توسعه یافته ظاهر شد ، که در آن امکان پذیر بود، علاوه بر 128 کاراکتر اصلی، همچنین می توان با استفاده از شخصیت های رمزگذاری ملی (به عنوان مثال، روسی) کدگذاری کرد. در اینجا، احتمالاً ارزش آن را دارد که کمی بیشتر در مورد سیستم های اعدادی که در توضیحات استفاده می شود، صحبت کنیم. اولا، همانطور که همه می دانید، یک کامپیوتر فقط با اعداد در سیستم دودویی کار می کند، یعنی با صفر و یک ("جبر بولی"، اگر کسی آن را در یک موسسه یا مدرسه گرفته باشد). یک بایت از هشت بیت تشکیل شده است که هر کدام نشان دهنده یک دو به توان دو است که از صفر شروع می شود و تا دو تا هفتم را نشان می دهد: درک این نکته دشوار نیست که همه ترکیب های ممکن از صفر و یک در چنین ساختاری می توانند فقط 256 باشد. تبدیل یک عدد از سیستم باینری به اعشاری بسیار ساده است. شما فقط باید تمام قدرت های دو را با یک های بالاتر از آنها جمع کنید. در مثال ما، 1 (2 به توان صفر) به اضافه 8 (دو به توان 3)، به اضافه 32 (دو به توان پنجم)، به اضافه 64 (به توان ششم)، به اضافه 128 می شود. (به قوه هفتم). مجموع در نماد اعشاری 233 است. همانطور که می بینید، همه چیز بسیار ساده است. اما اگر به جدول با کاراکترهای ASCII دقت کنید، خواهید دید که آنها در کدگذاری هگزا دسیمال نشان داده شده اند. به عنوان مثال، "ستاره" مطابق با عدد هگزادسیمال 2A در Aski است. حتما می دانید که در سیستم اعداد هگزا دسیمال، علاوه بر اعداد عربی، از حروف لاتین A (به معنی ده) تا F (به معنی پانزده) نیز استفاده می شود. خوب، برای تبدیل یک عدد باینری به هگزادسیمالبه روش ساده زیر متوسل شوید. هر بایت اطلاعات به دو قسمت چهار بیتی تقسیم می شود. آن ها در هر نیم بایت، تنها شانزده مقدار (دو تا توان چهارم) را می توان به صورت باینری رمزگذاری کرد که به راحتی می توان آن را به عنوان یک عدد هگزادسیمال نشان داد. علاوه بر این، در نیمه سمت چپ بایت، درجه ها باید دوباره از صفر شروع شود و نه همانطور که در تصویر نشان داده شده است. در نتیجه، دریافتیم که عدد E9 در اسکرین شات کدگذاری شده است. امیدوارم مسیر استدلال من و راه حل این معما برای شما روشن بوده باشد. خوب، اکنون اجازه دهید در واقع در مورد رمزگذاری متن صحبت کنیم.
نسخه های توسعه یافته Asuka - رمزگذاری CP866 و KOI8-R با شبه نگاری
بنابراین، ما شروع به صحبت در مورد ASCII کردیم، که، همانطور که بود، نقطه شروع توسعه همه رمزگذاری های مدرن (ویندوز 1251، یونیکد، UTF 8) بود. در ابتدا فقط شامل 128 کاراکتر از الفبای لاتین، اعداد عربی و چیزهای دیگر بود، اما در نسخه توسعه یافته امکان استفاده از تمام 256 مقداری که می توانند در یک بایت اطلاعات رمزگذاری شوند، وجود داشت. آن ها اضافه کردن نمادهای حروف زبان خود به Aski امکان پذیر شد. در اینجا لازم است یک بار دیگر به انحراف بپردازیم تا توضیح دهیم که چرا رمزگذاری متن اصلاً مورد نیاز است و چرا اینقدر مهم است. کاراکترهای روی صفحه نمایش رایانه شما بر اساس دو چیز تشکیل می شوند - مجموعه ای از اشکال برداری (نمایش) از کاراکترهای مختلف (آنها در فایل هایی با فونت هایی هستند که روی رایانه شما نصب شده اند) و کدی که به شما امکان می دهد دقیقاً آن یکی را بیرون بکشید. از این مجموعه اشکال برداری (فایل فونت) نمادی که باید در جای مناسب درج شود. واضح است که خود فونت ها مسئول اشکال برداری هستند، اما سیستم عامل و برنامه های استفاده شده در آن مسئولیت کدگذاری را بر عهده دارند. آن ها هر متنی در رایانه شما مجموعه ای از بایت ها خواهد بود که هر کدام یک کاراکتر از همین متن را رمزگذاری می کند. برنامه ای که این متن را روی صفحه نمایش می دهد (ویرایشگر متن، مرورگر و غیره)، هنگام تجزیه کد، رمزگذاری کاراکتر بعدی را می خواند و به دنبال فرم برداری مربوطه در فایل فونت مورد نیاز است که برای نمایش این وصل است. سند متنی همه چیز ساده و پیش پا افتاده است. این بدان معنی است که برای رمزگذاری هر کاراکتری که نیاز داریم (مثلاً از الفبای ملی)، دو شرط باید رعایت شود: شکل برداری این کاراکتر باید با فونت استفاده شده باشد و این کاراکتر می تواند در رمزگذاری های ASCII توسعه یافته رمزگذاری شود. در یک بایت بنابراین، یک دسته کامل از این گزینه ها وجود دارد. فقط برای رمزگذاری کاراکترهای زبان روسی، انواع مختلفی از Aska توسعه یافته وجود دارد. به عنوان مثال، CP866 در ابتدا ظاهر شد که توانایی استفاده از کاراکترهای الفبای روسی را داشت و نسخه توسعه یافته ASCII بود. یعنی قسمت بالایی آن کاملاً با نسخه اصلی Aska (128 کاراکتر لاتین، اعداد و سایر موارد مزخرف) مطابقت دارد که در تصویر بالا ارائه شده است، اما قسمت پایین جدول با رمزگذاری CP866 ظاهری داشت که در تصویر نشان داده شده است. اسکرین شات درست در زیر و رمزگذاری مجاز 128 کاراکتر دیگر (حروف روسی و انواع شبه گرافیک): ببینید، در ستون سمت راست اعداد با 8 شروع می شوند، زیرا اعداد از 0 تا 7 به بخش اصلی ASCII اشاره دارند (نگاه کنید به تصویر اول). بنابراین، حرف سیریلیک "M" در CP866 دارای کد 9C خواهد بود (در تقاطع خط مربوطه با 9 و ستون با عدد C در سیستم اعداد هگزادسیمال قرار دارد)، که می تواند در یک بایت اطلاعات نوشته شود. و در صورت وجود فونت مناسب با حروف روسی این حرف بدون مشکل در متن ظاهر می شود. این مبلغ از کجا آمده است؟شبه نگاری در CP866 نکته اصلی این است که این رمزگذاری برای متن روسی در آن سال‌های پشمالو توسعه داده شد، زمانی که سیستم‌عامل‌های گرافیکی مانند اکنون گسترده نبودند. و در Dosa و سیستم‌عامل‌های متنی مشابه، شبه‌نگاری این امکان را فراهم می‌آورد که حداقل به نحوی طراحی متون را متنوع کند و بنابراین CP866 و سایر همتایان آن از دسته نسخه‌های توسعه‌یافته Asuka در آن فراوان است. CP866 توسط IBM توزیع شد، اما علاوه بر این، تعدادی رمزگذاری برای کاراکترهای زبان روسی توسعه داده شد، به عنوان مثال، KOI8-R را می توان به همان نوع نسبت داد (ASCII توسعه یافته) : اصل عملکرد آن مانند CP866 که کمی پیشتر توضیح داده شد - هر کاراکتر متن به صورت یک بایت کدگذاری می شود. اسکرین شات نیمه دوم جدول KOI8-R را نشان می دهد، زیرا نیمه اول کاملاً با Asuka اصلی مطابقت دارد که در اولین تصویر در این مقاله نشان داده شده است. از جمله ویژگی های رمزگذاری KOI8-R می توان به این نکته اشاره کرد که حروف سیریلیک در جدول آن به ترتیب حروف الفبا نیستند، همانطور که در CP866 انجام شد. اگر به اولین اسکرین شات (بخش اصلی، که در تمام رمزگذاری های توسعه یافته گنجانده شده است) نگاه کنید، متوجه خواهید شد که در KOI8-R حروف روسی در همان سلول های جدول قرار دارند که حروف مربوط به الفبای لاتین هستند. از قسمت اول جدول این کار برای راحتی جابجایی از حروف روسی به لاتین با حذف فقط یک بیت (دو به توان هفتم یا 128) انجام شد.
ویندوز 1251 - نسخه مدرن ASCII و دلیل بیرون آمدن کرک ها
توسعه بیشتر رمزگذاری متن به این دلیل بود که سیستم عامل های گرافیکی در حال محبوبیت بودند و نیاز به استفاده از شبه نگاری در آنها به مرور زمان از بین رفت. در نتیجه، یک گروه کامل به وجود آمد که در اصل، هنوز نسخه های توسعه یافته Asuka بودند (یک کاراکتر از متن فقط با یک بایت اطلاعات رمزگذاری می شود)، اما بدون استفاده از نمادهای شبه. آنها متعلق به رمزگذاری های به اصطلاح ANSI بودند که توسط مؤسسه استانداردهای آمریکایی توسعه یافته بودند. در اصطلاح رایج، نام سیریلیک نیز برای نسخه با پشتیبانی از زبان روسی استفاده شده است. یک مثال از این ویندوز 1251 است . تفاوت مطلوبی با CP866 و KOI8-R که قبلاً استفاده شده بود به این دلیل بود که مکان نمادهای شبه نگاری در آن توسط نمادهای گمشده تایپوگرافی روسی (به جز علامت لهجه) و همچنین نمادهای مورد استفاده در زبان های اسلاوی نزدیک به روسی (اوکراینی، بلاروسی، و غیره) : به دلیل انبوهی از رمزگذاری های زبان روسی، تولیدکنندگان فونت و تولیدکنندگان نرم افزار دائماً دچار سردرد می شدند و من و شما، خوانندگان عزیز، اغلب با همان اشکالات بدنام دچار مشکل می شدیم. زمانی که با نسخه استفاده شده در متن سردرگمی وجود داشت. اغلب آنها هنگام ارسال و دریافت پیام از طریق ایمیل بیرون می آمدند که مستلزم ایجاد جداول تبدیل بسیار پیچیده بود که در واقع نمی توانست این مشکل را به طور اساسی حل کند و اغلب کاربران از نویسه گردانی حروف لاتین برای مکاتبات استفاده می کردند. هنگام استفاده از رمزگذاری‌های روسی مانند CP866، KOI8-R یا Windows 1251 از حرف‌های نامفهوم پرهیز کنید. در واقع، شکاف‌هایی که به جای متن روسی ظاهر می‌شوند، نتیجه استفاده نادرست از رمزگذاری یک زبان خاص است که با زبان موجود مطابقت نداشت. که پیامک در ابتدا کدگذاری شده بود. فرض کنید که اگر بخواهید با استفاده از جدول کد ویندوز 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 بیت کدگذاری کرد؟ 65536 (دو به توان شانزده) و این عددی است که به عنوان فضای پایه در یونیکد پذیرفته شد. علاوه بر این، راه هایی برای رمزگذاری حدود دو میلیون کاراکتر با استفاده از آن وجود دارد، اما آنها به فضای گسترده ای از یک میلیون کاراکتر متن محدود می شدند. اما حتی این نسخه موفق رمزگذاری یونیکد رضایت زیادی را برای کسانی که مثلاً برنامه ها را فقط به زبان انگلیسی می نوشتند، به همراه نداشت، زیرا پس از انتقال از نسخه توسعه یافته ASCII به UTF-16، وزن اسناد دو برابر شد (یک بایت در هر بایت). کاراکتر در Aski و دو بایت برای یک کاراکتر در YUTF-16). دقیقاً برای جلب رضایت همه و همه چیز در کنسرسیوم یونیکد بود که تصمیم گرفته شد یک رمزگذاری با طول متغیر ارائه شود . UTF-8 نام داشت. با وجود هشت در نام، در واقع دارای طول متغیر است، یعنی. هر کاراکتر متن را می توان در یک دنباله به طول یک تا شش بایت کدگذاری کرد. در عمل، UTF-8 فقط از محدوده یک تا چهار بایت استفاده می کند، زیرا فراتر از چهار بایت کد، دیگر حتی از نظر تئوری دیگر نمی توان چیزی را تصور کرد. تمام حروف لاتین موجود در آن در یک بایت رمزگذاری شده اند، درست مانند ASCII خوب قدیمی. نکته قابل توجه این است که در صورت رمزگذاری فقط الفبای لاتین، حتی برنامه هایی که یونیکد را درک نمی کنند، همچنان آنچه را که در YTF-8 رمزگذاری شده است، می خوانند. یعنی بخش اصلی Asuka به سادگی به این زاده فکر کنسرسیوم یونیکد منتقل شد. کاراکترهای سیریلیک در UTF-8 در دو بایت و به عنوان مثال کاراکترهای گرجی در سه بایت کدگذاری می شوند. کنسرسیوم یونیکد، پس از ایجاد UTF 16 و 8، مشکل اصلی را حل کرد - اکنون ما یک فضای کد واحد در فونت های خود داریم . و اکنون سازندگان آنها فقط می توانند آن را با فرم های برداری از کاراکترهای متنی بر اساس نقاط قوت و قابلیت های خود پر کنند. در "جدول کاراکترها" بالا می توانید ببینید که فونت های مختلف از تعداد کاراکترهای متفاوتی پشتیبانی می کنند. برخی از فونت های غنی از یونیکد می توانند بسیار سنگین باشند. اما اکنون تفاوت آنها نه در این واقعیت است که آنها برای رمزگذاری های مختلف ایجاد شده اند، بلکه در این واقعیت است که سازنده فونت فضای کد واحد را با فرم های برداری خاصی پر کرده یا به طور کامل پر نکرده است.
کلمات دیوانه به جای حروف روسی - چگونه آن را تعمیر کنیم
حال ببینیم چگونه krakozyabrs به جای متن ظاهر می شود یا به عبارت دیگر چگونه رمزگذاری صحیح برای متن روسی انتخاب می شود. در واقع، در برنامه ای تنظیم شده است که در آن شما همین متن یا کد را با استفاده از قطعات متن ایجاد یا ویرایش می کنید. برای ویرایش و ایجاد فایل های متنی، من شخصا از یک ویرایشگر Html و PHP بسیار خوب Notepad++ استفاده می کنم . با این حال، می تواند سینتکس صدها زبان برنامه نویسی و نشانه گذاری دیگر را برجسته کند و همچنین قابلیت گسترش با استفاده از افزونه ها را دارد. بررسی دقیق این برنامه فوق العاده را در لینک ارائه شده بخوانید. در منوی بالای Notepad++ یک مورد "Encodings" وجود دارد که در آن شما فرصت خواهید داشت یک گزینه موجود را به گزینه ای که به طور پیش فرض در سایت شما استفاده می شود تبدیل کنید: در مورد سایتی در جوملا 1.5 و بالاتر، به عنوان همچنین در مورد یک وبلاگ در وردپرس، باید از ظاهر شدن کراکوزیابروف گزینه UTF 8 را بدون BOM اجتناب کنید . پیشوند BOM چیست؟ واقعیت این است که هنگامی که آنها در حال توسعه رمزگذاری YUTF-16 بودند، به دلایلی تصمیم گرفتند چیزی مانند توانایی نوشتن کد کاراکتر را به ترتیب مستقیم (مثلاً 0A15) و معکوس (150A) به آن وصل کنند. . و برای اینکه برنامه ها بفهمند در چه ترتیبی باید کدها را بخوانند ، BOM (Byte Order Mark یا به عبارت دیگر امضا) اختراع شد که با افزودن سه بایت اضافی به همان ابتدای اسناد بیان شد. در رمزگذاری UTF-8، هیچ BOM در کنسرسیوم یونیکد پیش بینی نشده بود، و بنابراین اضافه کردن یک امضا (آن سه بایت بدنام اضافی در ابتدای سند) به سادگی از خواندن کد برخی از برنامه ها جلوگیری می کند. بنابراین هنگام ذخیره فایل ها در UTF، همیشه باید گزینه بدون BOM (بدون امضا) را انتخاب کنیم. بنابراین، از قبل از خزیدن کراکوزیابرها از خود محافظت خواهید کرد . نکته قابل توجه این است که برخی از برنامه های ویندوز نمی توانند این کار را انجام دهند (بدون BOM نمی توانند متن را در UTF-8 ذخیره کنند) مثلاً همان Notepad بدنام ویندوز. سند را در UTF-8 ذخیره می کند، اما همچنان امضا (سه بایت اضافی) را به ابتدای آن اضافه می کند. علاوه بر این، این بایت ها همیشه یکسان خواهند بود - کد را به ترتیب مستقیم بخوانید. اما در سرورها، به دلیل این چیز کوچک، ممکن است مشکلی ایجاد شود - کلاهبرداران بیرون می آیند. بنابراین به هیچ عنوان از نوت پد معمولی ویندوز استفاده نکنید .برای ویرایش اسناد در سایت خود اگر نمی خواهید هیچ کرکی ظاهر شود. من ویرایشگر Notepad++ را که قبلا ذکر شد بهترین و ساده ترین گزینه می دانم که عملاً هیچ ایرادی ندارد و فقط از مزایا تشکیل شده است. در Notepad++، زمانی که کدگذاری را انتخاب می‌کنید، این گزینه را خواهید داشت که متن را به کدگذاری UCS-2 تبدیل کنید، که ماهیت آن بسیار نزدیک به استاندارد یونیکد است. همچنین در Notepad امکان رمزگذاری متن در ANSI وجود خواهد داشت. در رابطه با زبان روسی، این ویندوز 1251 خواهد بود که قبلاً در بالا توضیح دادیم. این اطلاعات از کجا آمده است؟ در رجیستری سیستم عامل ویندوز شما ثبت شده است - در مورد ANSI کدام کد را انتخاب کنید، در مورد OEM کدام را انتخاب کنید (برای زبان روسی CP866 خواهد بود). اگر زبان پیش‌فرض دیگری را روی رایانه خود تنظیم کنید، این کدگذاری‌ها با زبان‌های مشابه از دسته ANSI یا OEM برای همان زبان جایگزین می‌شوند. پس از اینکه سند را در Notepad++ در کدگذاری مورد نیاز خود ذخیره کردید یا سند را از سایت برای ویرایش باز کردید، می‌توانید نام آن را در گوشه سمت راست پایین ویرایشگر مشاهده کنید: برای جلوگیری از سردرگمی ، علاوه بر مراحل توضیح داده شده در بالا. ، نوشتن کد منبع در هدر آن همه صفحات اطلاعات سایت در مورد همین رمزگذاری مفید خواهد بود تا در سرور یا میزبان محلی سردرگمی ایجاد نشود. به طور کلی، همه زبان‌های نشانه‌گذاری فرامتن به جز Html از یک اعلان خاص xml استفاده می‌کنند که کدگذاری متن را مشخص می‌کند.
<?xml version="1.0" encoding="windows-1251"?>
قبل از تجزیه کد، مرورگر می داند که از کدام نسخه استفاده می شود و دقیقاً چگونه باید کدهای کاراکتر آن زبان را تفسیر کند. اما آنچه قابل توجه است این است که اگر سند را در یونیکد پیش فرض ذخیره کنید، این اعلان xml می تواند حذف شود (اگر BOM وجود نداشته باشد رمزگذاری UTF-8 یا در صورت وجود BOM UTF-16 در نظر گرفته می شود). در مورد یک سند HTML، عنصر Meta برای نشان دادن رمزگذاری استفاده می‌شود که بین تگ‌های Head باز و بسته می‌شود:
<head>...<meta charset="utf-8">...</head>
این ورودی کاملاً با استاندارد Html 4.01 متفاوت است، اما کاملاً با استاندارد Html 5 مطابقت دارد و توسط هر مرورگر مورد استفاده فعلی به درستی درک خواهد شد. در تئوری، عنصر Meta که رمزگذاری سند Html را نشان می‌دهد بهتر است تا حد امکان در هدر سند قرار گیرد ، به طوری که زمانی که متن با اولین کاراکتر نه از ANSI اصلی (که همیشه به درستی و در خوانده می‌شود) مواجه شود. هر گونه تغییر)، مرورگر از قبل باید اطلاعاتی در مورد نحوه تفسیر کدهای این کاراکترها داشته باشد. پیوند به منبع اصلی: رمزگذاری متن ASCII (ویندوز 1251، CP866، KOI8-R) و یونیکد (UTF 8، 16، 32) - نحوه رفع مشکل با کرکرها
این 128 کاراکتر از نسخه اصلی ASCII هستند که به استاندارد تبدیل شدند و در هر کدگذاری دیگری قطعا آنها را پیدا خواهید کرد و به این ترتیب ظاهر می شوند. اما واقعیت این است که با کمک یک بایت اطلاعات می توانید نه 128، بلکه 256 مقدار مختلف (دو به توان هشت برابر با 256) رمزگذاری کنید، بنابراین، پس از نسخه اصلی Asuka، یک کل مجموعه ای از رمزگذاری های ASCII توسعه یافته ظاهر شد ، که در آن امکان پذیر بود، علاوه بر 128 کاراکتر اصلی، همچنین می توان با استفاده از شخصیت های رمزگذاری ملی (به عنوان مثال، روسی) کدگذاری کرد. در اینجا، احتمالاً ارزش آن را دارد که کمی بیشتر در مورد سیستم های اعدادی که در توضیحات استفاده می شود، صحبت کنیم. اولا، همانطور که همه می دانید، یک کامپیوتر فقط با اعداد در سیستم دودویی کار می کند، یعنی با صفر و یک ("جبر بولی"، اگر کسی آن را در یک موسسه یا مدرسه گرفته باشد). یک بایت از هشت بیت تشکیل شده است که هر کدام نشان دهنده یک دو به توان دو است که از صفر شروع می شود و تا دو تا هفتم را نشان می دهد: 
درک این نکته دشوار نیست که همه ترکیب های ممکن از صفر و یک در چنین ساختاری می توانند فقط 256 باشد. تبدیل یک عدد از سیستم باینری به اعشاری بسیار ساده است. شما فقط باید تمام قدرت های دو را با یک های بالاتر از آنها جمع کنید. در مثال ما، 1 (2 به توان صفر) به اضافه 8 (دو به توان 3)، به اضافه 32 (دو به توان پنجم)، به اضافه 64 (به توان ششم)، به اضافه 128 می شود. (به قوه هفتم). مجموع در نماد اعشاری 233 است. همانطور که می بینید، همه چیز بسیار ساده است. اما اگر به جدول با کاراکترهای ASCII دقت کنید، خواهید دید که آنها در کدگذاری هگزا دسیمال نشان داده شده اند. به عنوان مثال، "ستاره" مطابق با عدد هگزادسیمال 2A در Aski است. حتما می دانید که در سیستم اعداد هگزا دسیمال، علاوه بر اعداد عربی، از حروف لاتین A (به معنی ده) تا F (به معنی پانزده) نیز استفاده می شود. خوب، برای تبدیل یک عدد باینری به هگزادسیمالبه روش ساده زیر متوسل شوید. هر بایت اطلاعات به دو قسمت چهار بیتی تقسیم می شود. آن ها در هر نیم بایت، تنها شانزده مقدار (دو تا توان چهارم) را می توان به صورت باینری رمزگذاری کرد که به راحتی می توان آن را به عنوان یک عدد هگزادسیمال نشان داد. علاوه بر این، در نیمه سمت چپ بایت، درجه ها باید دوباره از صفر شروع شود و نه همانطور که در تصویر نشان داده شده است. در نتیجه، دریافتیم که عدد E9 در اسکرین شات کدگذاری شده است. امیدوارم مسیر استدلال من و راه حل این معما برای شما روشن بوده باشد. خوب، اکنون اجازه دهید در واقع در مورد رمزگذاری متن صحبت کنیم.
ببینید، در ستون سمت راست اعداد با 8 شروع می شوند، زیرا اعداد از 0 تا 7 به بخش اصلی ASCII اشاره دارند (نگاه کنید به تصویر اول). بنابراین، حرف سیریلیک "M" در CP866 دارای کد 9C خواهد بود (در تقاطع خط مربوطه با 9 و ستون با عدد C در سیستم اعداد هگزادسیمال قرار دارد)، که می تواند در یک بایت اطلاعات نوشته شود. و در صورت وجود فونت مناسب با حروف روسی این حرف بدون مشکل در متن ظاهر می شود. این مبلغ از کجا آمده است؟شبه نگاری در CP866 نکته اصلی این است که این رمزگذاری برای متن روسی در آن سال‌های پشمالو توسعه داده شد، زمانی که سیستم‌عامل‌های گرافیکی مانند اکنون گسترده نبودند. و در Dosa و سیستم‌عامل‌های متنی مشابه، شبه‌نگاری این امکان را فراهم می‌آورد که حداقل به نحوی طراحی متون را متنوع کند و بنابراین CP866 و سایر همتایان آن از دسته نسخه‌های توسعه‌یافته Asuka در آن فراوان است. CP866 توسط IBM توزیع شد، اما علاوه بر این، تعدادی رمزگذاری برای کاراکترهای زبان روسی توسعه داده شد، به عنوان مثال، KOI8-R را می توان به همان نوع نسبت داد (ASCII توسعه یافته) : 
اصل عملکرد آن مانند CP866 که کمی پیشتر توضیح داده شد - هر کاراکتر متن به صورت یک بایت کدگذاری می شود. اسکرین شات نیمه دوم جدول KOI8-R را نشان می دهد، زیرا نیمه اول کاملاً با Asuka اصلی مطابقت دارد که در اولین تصویر در این مقاله نشان داده شده است. از جمله ویژگی های رمزگذاری KOI8-R می توان به این نکته اشاره کرد که حروف سیریلیک در جدول آن به ترتیب حروف الفبا نیستند، همانطور که در CP866 انجام شد. اگر به اولین اسکرین شات (بخش اصلی، که در تمام رمزگذاری های توسعه یافته گنجانده شده است) نگاه کنید، متوجه خواهید شد که در KOI8-R حروف روسی در همان سلول های جدول قرار دارند که حروف مربوط به الفبای لاتین هستند. از قسمت اول جدول این کار برای راحتی جابجایی از حروف روسی به لاتین با حذف فقط یک بیت (دو به توان هفتم یا 128) انجام شد.
به دلیل انبوهی از رمزگذاری های زبان روسی، تولیدکنندگان فونت و تولیدکنندگان نرم افزار دائماً دچار سردرد می شدند و من و شما، خوانندگان عزیز، اغلب با همان اشکالات بدنام دچار مشکل می شدیم. زمانی که با نسخه استفاده شده در متن سردرگمی وجود داشت. اغلب آنها هنگام ارسال و دریافت پیام از طریق ایمیل بیرون می آمدند که مستلزم ایجاد جداول تبدیل بسیار پیچیده بود که در واقع نمی توانست این مشکل را به طور اساسی حل کند و اغلب کاربران از نویسه گردانی حروف لاتین برای مکاتبات استفاده می کردند. هنگام استفاده از رمزگذاری‌های روسی مانند CP866، KOI8-R یا Windows 1251 از حرف‌های نامفهوم پرهیز کنید. در واقع، شکاف‌هایی که به جای متن روسی ظاهر می‌شوند، نتیجه استفاده نادرست از رمزگذاری یک زبان خاص است که با زبان موجود مطابقت نداشت. که پیامک در ابتدا کدگذاری شده بود. فرض کنید که اگر بخواهید با استفاده از جدول کد ویندوز 1251، کاراکترهایی را که با استفاده از CP866 کدگذاری شده اند، نمایش دهید، همان ابهامات (مجموعه ای بی معنی از کاراکترها) ظاهر می شود و کاملاً جایگزین متن پیام می شود. 
وضعیت مشابهی اغلب هنگام ایجاد و راه‌اندازی وب‌سایت‌ها، انجمن‌ها یا وبلاگ‌ها رخ می‌دهد، زمانی که متن با حروف روسی به اشتباه در رمزگذاری اشتباهی که به‌طور پیش‌فرض در سایت استفاده می‌شود، یا در ویرایشگر متن اشتباه ذخیره می‌شود، که یک گگ نامرئی اضافه می‌کند. به کد با چشم غیر مسلح. در نهایت، بسیاری از مردم از این وضعیت با رمزگذاری های زیاد و مدام مزخرفات خسته شدند و پیش نیازها برای ایجاد یک تنوع جهانی جدید ظاهر شد که جایگزین همه موارد موجود شود و مشکل را با ظاهر متون ناخوانا حل کند. . علاوه بر این، مشکل زبان هایی مانند چینی وجود داشت که تعداد کاراکترهای زبان بسیار بیشتر از 256 بود.
چند کاراکتر را می توان در UTF-16 با استفاده از 16 بیت کدگذاری کرد؟ 65536 (دو به توان شانزده) و این عددی است که به عنوان فضای پایه در یونیکد پذیرفته شد. علاوه بر این، راه هایی برای رمزگذاری حدود دو میلیون کاراکتر با استفاده از آن وجود دارد، اما آنها به فضای گسترده ای از یک میلیون کاراکتر متن محدود می شدند. اما حتی این نسخه موفق رمزگذاری یونیکد رضایت زیادی را برای کسانی که مثلاً برنامه ها را فقط به زبان انگلیسی می نوشتند، به همراه نداشت، زیرا پس از انتقال از نسخه توسعه یافته ASCII به UTF-16، وزن اسناد دو برابر شد (یک بایت در هر بایت). کاراکتر در Aski و دو بایت برای یک کاراکتر در YUTF-16). دقیقاً برای جلب رضایت همه و همه چیز در کنسرسیوم یونیکد بود که تصمیم گرفته شد یک رمزگذاری با طول متغیر ارائه شود . UTF-8 نام داشت. با وجود هشت در نام، در واقع دارای طول متغیر است، یعنی. هر کاراکتر متن را می توان در یک دنباله به طول یک تا شش بایت کدگذاری کرد. در عمل، UTF-8 فقط از محدوده یک تا چهار بایت استفاده می کند، زیرا فراتر از چهار بایت کد، دیگر حتی از نظر تئوری دیگر نمی توان چیزی را تصور کرد. تمام حروف لاتین موجود در آن در یک بایت رمزگذاری شده اند، درست مانند ASCII خوب قدیمی. نکته قابل توجه این است که در صورت رمزگذاری فقط الفبای لاتین، حتی برنامه هایی که یونیکد را درک نمی کنند، همچنان آنچه را که در YTF-8 رمزگذاری شده است، می خوانند. یعنی بخش اصلی Asuka به سادگی به این زاده فکر کنسرسیوم یونیکد منتقل شد. کاراکترهای سیریلیک در UTF-8 در دو بایت و به عنوان مثال کاراکترهای گرجی در سه بایت کدگذاری می شوند. کنسرسیوم یونیکد، پس از ایجاد UTF 16 و 8، مشکل اصلی را حل کرد - اکنون ما یک فضای کد واحد در فونت های خود داریم . و اکنون سازندگان آنها فقط می توانند آن را با فرم های برداری از کاراکترهای متنی بر اساس نقاط قوت و قابلیت های خود پر کنند. در "جدول کاراکترها" بالا می توانید ببینید که فونت های مختلف از تعداد کاراکترهای متفاوتی پشتیبانی می کنند. برخی از فونت های غنی از یونیکد می توانند بسیار سنگین باشند. اما اکنون تفاوت آنها نه در این واقعیت است که آنها برای رمزگذاری های مختلف ایجاد شده اند، بلکه در این واقعیت است که سازنده فونت فضای کد واحد را با فرم های برداری خاصی پر کرده یا به طور کامل پر نکرده است.
در مورد سایتی در جوملا 1.5 و بالاتر، به عنوان همچنین در مورد یک وبلاگ در وردپرس، باید از ظاهر شدن کراکوزیابروف گزینه UTF 8 را بدون BOM اجتناب کنید . پیشوند BOM چیست؟ واقعیت این است که هنگامی که آنها در حال توسعه رمزگذاری YUTF-16 بودند، به دلایلی تصمیم گرفتند چیزی مانند توانایی نوشتن کد کاراکتر را به ترتیب مستقیم (مثلاً 0A15) و معکوس (150A) به آن وصل کنند. . و برای اینکه برنامه ها بفهمند در چه ترتیبی باید کدها را بخوانند ، BOM (Byte Order Mark یا به عبارت دیگر امضا) اختراع شد که با افزودن سه بایت اضافی به همان ابتدای اسناد بیان شد. در رمزگذاری UTF-8، هیچ BOM در کنسرسیوم یونیکد پیش بینی نشده بود، و بنابراین اضافه کردن یک امضا (آن سه بایت بدنام اضافی در ابتدای سند) به سادگی از خواندن کد برخی از برنامه ها جلوگیری می کند. بنابراین هنگام ذخیره فایل ها در UTF، همیشه باید گزینه بدون BOM (بدون امضا) را انتخاب کنیم. بنابراین، از قبل از خزیدن کراکوزیابرها از خود محافظت خواهید کرد . نکته قابل توجه این است که برخی از برنامه های ویندوز نمی توانند این کار را انجام دهند (بدون BOM نمی توانند متن را در UTF-8 ذخیره کنند) مثلاً همان Notepad بدنام ویندوز. سند را در UTF-8 ذخیره می کند، اما همچنان امضا (سه بایت اضافی) را به ابتدای آن اضافه می کند. علاوه بر این، این بایت ها همیشه یکسان خواهند بود - کد را به ترتیب مستقیم بخوانید. اما در سرورها، به دلیل این چیز کوچک، ممکن است مشکلی ایجاد شود - کلاهبرداران بیرون می آیند. بنابراین به هیچ عنوان از نوت پد معمولی ویندوز استفاده نکنید .برای ویرایش اسناد در سایت خود اگر نمی خواهید هیچ کرکی ظاهر شود. من ویرایشگر Notepad++ را که قبلا ذکر شد بهترین و ساده ترین گزینه می دانم که عملاً هیچ ایرادی ندارد و فقط از مزایا تشکیل شده است. در Notepad++، زمانی که کدگذاری را انتخاب می‌کنید، این گزینه را خواهید داشت که متن را به کدگذاری UCS-2 تبدیل کنید، که ماهیت آن بسیار نزدیک به استاندارد یونیکد است. همچنین در Notepad امکان رمزگذاری متن در ANSI وجود خواهد داشت. در رابطه با زبان روسی، این ویندوز 1251 خواهد بود که قبلاً در بالا توضیح دادیم. این اطلاعات از کجا آمده است؟ در رجیستری سیستم عامل ویندوز شما ثبت شده است - در مورد ANSI کدام کد را انتخاب کنید، در مورد OEM کدام را انتخاب کنید (برای زبان روسی CP866 خواهد بود). اگر زبان پیش‌فرض دیگری را روی رایانه خود تنظیم کنید، این کدگذاری‌ها با زبان‌های مشابه از دسته ANSI یا OEM برای همان زبان جایگزین می‌شوند. پس از اینکه سند را در Notepad++ در کدگذاری مورد نیاز خود ذخیره کردید یا سند را از سایت برای ویرایش باز کردید، می‌توانید نام آن را در گوشه سمت راست پایین ویرایشگر مشاهده کنید: 
برای جلوگیری از سردرگمی ، علاوه بر مراحل توضیح داده شده در بالا. ، نوشتن کد منبع در هدر آن همه صفحات اطلاعات سایت در مورد همین رمزگذاری مفید خواهد بود تا در سرور یا میزبان محلی سردرگمی ایجاد نشود. به طور کلی، همه زبان‌های نشانه‌گذاری فرامتن به جز Html از یک اعلان خاص xml استفاده می‌کنند که کدگذاری متن را مشخص می‌کند.
GO TO FULL VERSION