یونیکد (Unicode) چیست؟ – به زبان ساده

اگر در مورد یونیکد اطلاعات چندانی ندارید و علاقه‌مند هستید در مورد آن بیشتر بدانید، بهترین مقاله را برای مطالعه انتخاب کرده‌اید. درک مفهوم یونیکد دشوار نیست؛ اما شامل برخی مفاهیم سطح پایین علم رایانه مانند byte order است. مطالعه در مورد مفهوم یونیکد درس‌های بسیار مفیدی در مورد ایجاد تعادل بین مزایا و معایب و همچنین «تطبیق‌پذیری رو به عقب» (backwards compatibility) به ما می‌دهد.

مفاهیم کلیدی

در ابتدا برخی ایده‌های مهم را بیان می‌کنیم.

ایده‌ها متفاوت از داده‌ها هستند: مفهوم «A» چیزی متفاوت از نشانه‌های روی کاغذ، صدای «آ» یا عدد 65 ذخیره شده درون یک رایانه است.

یک ایده، انکودینگ (کدگذاری) های مختلفی می‌تواند داشته باشد: منظور از انکودینگ روشی است که برای تبدیل یک ایده (مانند حرف A) به داده‌های خام (بیت‌ها و بایت‌ها) استفاده می‌شود. ایده «A» می‌تواند به روش‌های مختلفی کدگذاری شود و کارایی و تطبیق‌پذیری کدگذاری‌ها نیز متفاوت است.

باید کدگذاری را بدانیم: زمانی که داده‌ها را می‌خوانیم باید کدگذاری مورد استفاده آن‌ها را بدانیم تا بتوانیم آن‌ها را به درستی تفسیر کنیم. گرچه این مفهوم ساده‌ای است؛ اما مهم محسوب می‌شود. اگر عدد 6 را به صورت دودویی ببینید، معنی آن چه خواهد بود؟ آیا مفهوم A در سیستم ASCII یا سن یا ضریب هوشی را نشان می‌دهد؟ در صورتی که هیچ زمینه دیگری در دست نباشد، به سختی می‌توان مفهوم آن را درک کرد. تصور کنید کسی سر راه شما پیدا شود و بگوید «65». بدیهی است که شما هیچ ایده‌ای نخواهید داشت که وی در مورد چه چیزی صحبت می‌کند. اینک تصور کنید این فرد مجدداً در پیش روی شما ظاهر شده و بیان کند که «عددی که بیان می‌کنم یک کاراکتر در سیستم ASCII است: 65». اینک کاملاً روشن شد که منظور وی چه بوده است.

همواره این را به خاطر داشته باشید که مفهوم و داده‌هایی که آن مفهوم را ذخیره می‌کنند، دو چیز کاملاً متفاوت هستند و این دو در ذهن ما با هم تطبیق پیدا می‌کنند.

ASCII و صفحه‌های کد

احتمالاً تاکنون نام مجموعه کاراکترهای ASCII/ANSI را شنیده‌اید. این مجموعه کاراکترها شامل مقادیر عددی 0 تا 127 و کاراکترهای مختلف الفبای غربی و کدهای کنترل (newline، tab و غیره) است. دقت کنید که مقادیر 0 تا 127 در 7 بیت ابتدایی در یک بایت 7 بیتی قرار می‌گیرند. ASCII به روشنی تعریف نکرده است که مقادیر 128 تا 255 به چه چیزی نگاشت شده است.

انکودینگ ASCII برای متون انگلیسی (با استفاده از کاراکترهای الفبای غربی) عملکرد مناسبی دارد؛ اما دنیا جای بزرگی است. در مورد زبان‌های عربی، چینی و فارسی چه می‌توان گفت؟

برای حل این مشکل سازندگان رایانه‌ها، مفهوم «صفحه‌های کد» (Code Pages) را ابداع کردند که از فضای تعریف شده 128 تا 255 در ASCII استفاده کرده و آن را به کاراکترهای مختلف مورد نیاز برای نمایش زبان‌های دیگر نگاشت می‌کند. متأسفانه این 128 کاراکتر اضافی برای کل دنیا کافی نیستند؛ صفحه‌های کد برحسب کشورها متفاوت هستند و برای مثال صفحه کد روسی، صفحه کد فارسی و غیره پدید آمده‌اند.

بدین ترتیب، اگر افراد با صفحه کد یکسان داده‌هایی را با هم مبادله کنند، همه چیز به خوبی پیش خواهد رفت. در این حالت، کاراکتر شماره 200 روی یک رایانه همان کاراکتر شماره 200 روی رایانه دیگر خواهد بود. اما اگر صفحه‌های کد یکسان نباشند، یعنی برای مثال فرستنده یک متن از صفحه کد روسی و گیرنده آن از صفحه کد فارسی استفاده کند، همه چیز به هم می‌ریزد.

کاراکتر نگاشت شده به شماره 200 در صفحه کدهای روسی و فارسی متفاوت است و می‌توانید تصور کنید که چه سردرگمی بزرگی در چیزهایی مانند ایمیل و تبریک تولید پدید می‌آید. همیشه این نگرانی وجود دارد که آیا گیرنده پیام شما، آن را با همان صفحه کدی که نوشته‌اید می‌خواند یا نه. برای مثال اگر از یک وب‌سایت بین‌المللی بازدید کنید و صفحه کد آن تعیین نشده باشد، مرورگرتان تلاش خواهد کرد که صفحه کد آن را حدس بزند. مثلاً بررسی می‌کند و می‌بیند که در این متن به میزان زیادی از کاراکترهای شماره 213 و 218 استفاده شده است و احتمالاً صفحه کد آن فارسی است. اما بدیهی است که این روش مستعد خطا است و صفحه کد باید نجات یابد.

راه نجات، یونیکد است

زمانی که بحث اصلاح سیستم ASCII ضروری تلقی شد، در دنیا یک عدم توافق جدی پیش آمد. کشورهای مختلف در مورد این که کدام اعداد باید به کدام حروف در سیستم ASCII نگاشت شوند توافق نداشتند. بنابراین گروه یونیکد دوباره به سر خانه اول یعنی به حروف و مفاهیم مجرد بازگشتند. یونیکد به هر کاراکتر مجرد یک «نقطه کد» (code point). تخصیص داد. برای نمونه A به نقطه کد U+0041 نگاشت شد. این نقطه کد به صورت هگزادسیمال بیان شده و همان 65 در سیستم ده‌دهی است.

فیلم کد اسکی چیست؟ عملکرد و نحوه استفاده (فیلم آموزش رایگان) در فرادرس

کلیک کنید

بدین ترتیب گروه یونیکد کار دشوار نگاشت هر کاراکتر در همه زبان‌ها به یک نقطه کد را به انجام رسانید. زمانی که همه این نقطه کدها تخصیص یافتند، استاندارد یونیکد همچنان فضای کافی برای 1 میلیون نقطه کد دیگر نیز داشت که برای همه تمدن‌های شناخته شده و حتی کشف نشده آینده نیز فضای کافی ارائه می‌کند. شما می‌توانید نقطه کدها را در ویندوز با مراجعه به مسیر Start Menu > Run > Charmap یا به صورت آنلاین در وب‌سایت Unicode.org ملاحظه کنید.

بدین ترتیب به نخستین تصمیم در طراحی می‌رسیم که «تطبیق‌پذیری» (compatibility) نام دارد. این قواعد عبارت هستند از:

در زمان طراحی یونیکد جهت ایجاد تطبیق‌پذیری با سیستم ASCII، همه نقطه کدها از U+0000 تا U+007F یعنی از 0 تا 127 همان کدهای ASCII بودند. افراد باریک‌بین احتمالاً از این موضوع راضی نبوده‌اند، چون مجموعه کامل کاراکترهای لاتین در جای دیگری تعریف شده بود و اینک یک حرف 1 نقطه کد داشت. ضمناً این وضعیت باعث می‌شد که کاراکترهای غربی در اولویت قرار بگیرند در حالی که کاراکترهای چینی، عربی و زبان‌های غیراستاندارد در نقطه کدهای بعدی قرار بگیرند که نیازمند 2 بایت برای ذخیره‌سازی بود.

با این وجود، این طراحی ناگزیر بود، چون ASCII یک استاندارد بود و اگر یونیکد قرار بود از سوی دنیای غرب پذیرفته شود، بی‌شک باید با آن سازگاری می‌داشت. در این زمان اغلب زبان‌های رایج در 65535 نقطه کد اول جای می‌گیرند که می‌تواند در 2 بایت ذخیره شود.

بدین ترتیب دنیا به جای بهتری تبدیل شد و هر کس در مورد این که چه نقطه کدی به کدام کاراکتر اختصاص یافته است توافق داشت؛ اما یک سؤال همچنان بی‌پاسخ ماند: چگونه می‌توانیم یک نقطه کد را به عنوان داده ذخیره کنیم؟

انکودینگ راه نجات است

در بخش‌های قبل گفتیم که انکودینگ یا کدگذاری باعث می‌شود که ایده‌ها به داده‌های خام تبدیل شوند. در این مورد ایده یک نقطه کد است.

برای نمونه به طرح انکودینگ ASCII نگاه کنید. قواعد آن بسیار ساده است.

• نقطه کدها از U+0000 تا U+007F در یک بایت منفرد ذخیره می‌شوند.
• نقطه کدهای بالاتر از U+0080 خارج از دید هستند و هرگز مشاهده نخواهند شد.

همان طور که می‌بینید ASCII برای ذخیره‌سازی یونیکد مناسب نیست. در واقع اغلب نقطه کدهای یونیکد را کلاً نادیده می‌گیرد. اگر یک سند یونیکد داشته باشید و آن را به صورت ASCII ذخیره کنید، همه کاراکترهای خاص و یا مطالب غیر انگلیسی شما از دست می‌روند. در اغلب موارد می‌بینید که برخی ویرایشگرهای متن هنگامی که می‌خواهید داده‌های یونیکد را در یک فایل با قالب ASCII ذخیره کنید هشدار می‌دهند.

اما مثالی که بیان کردیم با منظور خاصی مطرح شده است. انکودینگ، سیستمی است که یک ایده را به داده تبدیل می‌کند. در این حالت، تبدیل می‌تواند به بیان ساده به صورت «با اتلاف» (lossy) باشد.

برای این که این تفاوت‌ها را در عمل مشاهده کنید، می‌تواند از دو برنامه Notepad ویندوز و Programmer’s Notepad استفاده کنید. به این منظور نت پد را باز کنید و عبارت hello را در آن ذخیره کنید. سپس این فایل را به صورت جداگانه با قالب‌های ANSI، Unicode، Unicode Big Endian و UTF-8 ذخیره کنید. در نهایت فایل‌ها را با نرم افزار Programmer’s Notepad باز کنید و از مسیر View > View Hex محتوای آن‌ها را مشاهده کنید.

همه چیز در مورد ASCII

اگر عبارت hello را در نت پد نوشته و آن را در قالب ANSI یا ASCII ذخیره کنید و سپس این فایل را با یک نرم افزار ویرایشگر hex مانند Programmer’s Notepad باز کنید، چیزی مانند زیر را شاهد خواهید بود:

Byte: 48 65 6C 6C 6F
Letter: H e l l o

ASCII مهم است، زیرا بسیاری از ابزارها و پروتکل‌های ارتباطی تنها کاراکترهای ASCII را می‌پذیرند. در واقع این کمینه استاندارد پذیرفته شده برای متن محسوب می‌شود. برخی انکودینگ های یونیکد، به دلیل پذیرش جهانی ASCII، نقطه کدهای خود را یک سری کاراکترهای ASCII تبدیل می‌کنند تا بدون هیچ مشکلی جا به جا شوند.

در مثال فوق می دانیم که داده‌ها متنی هستند زیرا آن را نوشته‌ایم. اگر ما تصادفاً با یک فایل مواجه شویم، می‌توانیم بر اساس محتوای آن تصور کنیم که یک متن ASCII است؛ اما ممکن است یک شماره حساب یا داده دیگری باشد که در ASCII شبیه hello به نظر می‌رسد.

به طور معمول، می‌توانیم این که داده‌های یک فایل از چه نوع است را بر اساس برخی هدرهای خاص یا «اعداد جادویی» به درستی حدس بزنیم. منظور از اعداد جادویی، توالی‌های خاصی از کاراکترها است که در مکان‌های مشخصی ظاهر می‌شوند. اما در این مورد هرگز نمی‌توان مطمئن بود و برخی اوقات نیز احتمال اشتباه وجود دارد.

UCS-2 / UTF-16

وقتی می‌شنویم که یونیکد همه کاراکترها را در 2 بایت ذخیره می‌کند، اولین انکودینگی که به ذهنمان می‌رسد این است. این انکودینگ در سطح پایه خود می‌تواند نقطه کدهای 0x0000 تا 0xFFFF یا 0 تا 65535 را ذخیره کند. البته 65535 عدد بزرگی است و تقریباً کاراکترهای مورد نیاز برای همه افراد را تأمین می‌کند. ذخیره‌سازی داده‌ها در چندین بایت باعث بروز مشکلی به نام byte order می‌شود. برخی رایانه‌ها بایت کوچک‌تر را ابتدا ذخیره می‌کنند و برخی دیگر بایت بزرگ را اول ذخیره‌سازی می‌کنند. برای حل این مشکل می‌توانیم کارهای زیر را انجام دهیم:

گزینه 1: انتخاب یک قرارداد

ما یک قرارداد می‌گذاریم که همه داده‌های متنی باید به صورت big یا little-endian باشند. البته این قرارداد پاسخگو نیست، زیرا رایانه‌ها در جریان تصمیم‌گیری ما نیستند و هر بار که فایلی را باز می‌کنند نمی‌توانند تشخیص دهند که از چه ترتیب بایتی باید برای تبدیل آن استفاده کنند.

گزینه 2: همه افراد بر سر یک علامت ترتیب بایت (BOM) توافق می‌کنند

بدین ترتیب یک هدر به ابتدای هر فایل اضافه می‌شود. اگر فایلی را باز کنید و BOM آن رو به عقب باشد، بدین معنی است که در ترتیب بایت متفاوتی ذخیره شده است و باید تبدیل شود.

راه‌حلی که انتخاب شده است هدر BOM است. انکودینگ های UCS-2 می‌توانند نقطه کد U+FEFF را به عنوان هدر فایل بنویسند. اگر یک رشته UCS-2 را باز کنید و با عبارت FEFF مواجه شوید، داده‌هایی که در ترتیب صحیح بایت قرار دارند می‌توانند به صورت مستقیم استفاده شوند. اگر با FFFE مواجه شود به این معنی است که داده‌ها از رایانه‌ای با نوع متفاوت می‌آیند و باید به معماری مورد نظر شما تبدیل شوند. بدین ترتیب باید همه بایت‌های موجود در فایل معکوس شوند.

اما متأسفانه همه مسائل به این سادگی نیستند. BOM در واقع یک کاراکتر معتبر یونیکد است. اگر فردی فایلی بدون یک هدر ارسال کند و آن کاراکتر در واقع بخشی از فایل باشد چه رخ می‌دهد؟

این وضعیت همچنان یک مشکل حل نشده در یونیکد محسوب می‌شود. پیشنهاد شده است که از کاراکتر U+FEFF به جز در هدر فایل اجتناب و از کاراکترهای جایگزین به جای آن استفاده شود. این وضعیت مشاهده شماره 2 طراحی یونیکد را مشخص می‌سازد: داده‌های چند بایتی مشکل ترتیب بایت را دارند!

در استاندارد ASCII هرگز در مورد ترتیب بایت دغدغه‌ای وجود ندارد. در این سیستم هر کاراکتر یک بایت منفرد است و نمی‌تواند به صورت نادرستی تفسیر شود. اما در عمل وقتی بایت‌های 0xFEFF یا 0xFFEE را در ابتدای فایل می‌بینید این احتمال وجود دارد که یک BOM در یک فایل متنی یونیکد است. این کاراکترها به احتمال زیاد یک نشانگر برای ترتیب بایت هستند.

USC-2 داده‌ها را در بسته‌های 16 بیتی ذخیره می‌کند. UTF-16 امکان افراز 20 بیت بین دو کاراکتر 16 بیتی را فراهم ساخته است که به نام «جفت جانشین» (surrogate pair) شناخته می‌شود. هر کاراکتر در جفت جانشین یک کاراکتر نامعتبر یونیکد است؛ اما وقتی در کنار هم قرار می‌گیرند می‌توانند یک کاراکتر معتبر را تشکیل دهند.

مثال USC-2

عبارت Hello را در نت پد وارد کرده و آن را به صورت Unicode ذخیره کنید. قالب بومی ویندوز به صورت little-endian USC-2 است.

Hello-little-endian:

F FE 4800 6500 6C00 6c00 6F00
header H e l l o

آن را مجدداً به صورت Unicode Big Endian ذخیره کنید.

Hello-big-endian:

FE FF 0048 0065 006C 006C 006F
header H e l l o

می‌توان مشاهدات را به صورت زیر جمع‌بندی کرد:

• هدر (BOM (U+FEFF چنان که انتظار می‌رفت نمایش می‌یابد، یعنی FF FE برای little-endian، FEFF برای big-endian
• حروف صرف‌نظر از این که چه هستند همواره 2 بایت مصرف می‌کنند. H در ASCII به صورت 0x48 و در USC-2 به صورت 0x0048 است.
• انکودینگ ساده است. نقطه کد مورد نظر خود را در hex انتخاب کنید و آن را در 2 بایت بنویسید. به هیچ پردازش اضافی نیازی نیست.
• انکودینگ با بایت‌های تهی (0x00) آغاز می‌شود که می‌تواند یک مشکل باشد. برنامه‌های قدیمی ASCII ممکن است در مواردی که به بایت تهی می‌رسند، فکر کنند که رشته یونیکد پایان یافته است. در یک رایانه با سیستم little-endian، با خواندن یک بایت در هر بار به کاراکتر  H به صورت (H = 0x4800) می‌رسیم و سپس به بایت تهی رسیده و متوقف می‌شویم. در یک رایانه big endian ابتدا به بایت تهی (H = 0x0048) می‌رسیم و حتی H را در ASCII مشاهده نمی‌کنید که وضعیت خوبی نیست.

مشاهده طراحی شماره 3: تطبیق‌پذیری رو به عقب را در نظر بگیرید. یک برنامه قدیمی، داده‌های جدید را چگونه می‌خواند. نادیده گرفتن داده‌های جدید خوب است. از کار افتادن هنگام مواجهه با داده‌های جدید بد است.

UTF-8

UCS-2 / UTF-16 ساده و زیبا است؛ اما برخی بیت‌ها در آن به هدر می‌روند. این سیستم نه تنها دو برابر ASCII است؛ بلکه ASCII تبدیل یافته، ممکن است به دلیل وجود بایت‌های تهی حتی خوانا نباشد.

به همین دلیل UTF-8 طراحی شده است. هدف این سیستم آن است که در موارد ممکن کاراکترهای یونیکد را در یک بایت منفرد (ASCII) انکود کند و با استفاده از بایت‌های تهی، اپلیکیشن‌های ASCII را مختل نسازد. این انکودینگ پیش‌فرض XML است.

برای اطلاعات بیشتر می‌توانید به مشخصات UTF-8 مراجعه کنید؛ اما به طور کلی می‌توان به نکات زیر اشاره کرد:

• نقطه‌های کد 0 تا 007f به صورت معمولی یعنی ASCII تک بایت ذخیره می‌شوند.
• نقطه کدهای 0080 و بالاتر به صورت دودویی تبدیل می‌شوند و در یک سری بایت‌ها ذخیره (انکود) می‌شوند.
• بایت اول «count» نشان‌دهنده تعداد بایت‌های نقطه کد است که شامل خود بایت count نیز می‌شود. این بایت‌ها با 0...11 آغاز می‌شوند:
  110xxxxx ( آن 11 اول نشان‌دهنده وجود 2 بایت به صورت متوالی است که شامل بایت count نیز می‌شود.)
  1110xxxx ( 1110 یعنی  3 بایت در دنباله وجود دارد)
  11110xxx (11110 یعنی 4 بایت در دنباله وجود دارد)
• بایت‌هایی که با ...10 آغاز می‌شوند بایت‌های داده هستند و شامل اطلاعاتی در مورد نقطه کد هستند. یک مثال 2 بایتی به صورت زیر است:
  110xxxxx 10xxxxxx

این بدان معنی است که 2 بایت در دنباله وجود دارد. X ها نشان‌دهنده مقادیر دودویی نقطه کد هستند که باید در بیت‌های باقی‌مانده ارائه شوند.

ملاحظاتمان در مورد UTF-8 را می‌توانیم به صورت زیر جمع‌بندی بکنیم:

• هیچ بایت تهی وجود ندارد. همه کاراکترهای ASCII یعنی شماره‌های 0 تا 127 یکسان هستند. کاراکترهای غیر ASCII همگی با 1 به عنوان بزرگ‌ترین بیت آغاز می‌شوند.
• متن ASCII به صورت یکسان و کارآمدی ذخیره می‌شود.
• کاراکترهای یونیکد با 1 به عنوان بیت اول آغاز می‌شوند و می‌توانند از سوی برنامه‌های صرفاً ASCII نادیده گرفته شوند (هر چند می‌توانند در برخی مواد حذف شوند. برای اطلاعات بیشتر جزییات UTF-7 را ببینید).
• یک تعادل بین زمان-فضا وجود دارد. بدین ترتیب باید روی هر کاراکتر یونیکد قدری پردازش صورت بگیرد؛ اما این هزینه ارزش خود را دارد.

مفهوم شماره 4 طراحی:

• UTF-8 هشتاد درصد موارد (ASCII) را به خوبی ‌پاسخ‌دهی می‌کند و امکان بروز موارد دیگر (Unicode) را نیز فراهم می‌سازد. USC-2 همه موارد را به صورت یکسان پاسخ‌دهی می‌کند؛ اما در 80 درصد موارد ناکافی است زیرا می‌خواهد 99% موارد را حل کند. از طرفی USC-2 به توان پردازشی کمتری نسبت به UTF-8 نیاز دارد چون UTF-8 به دستکاری بیت روی همه کاراکترهای یونیکد نیازمند است.
• شاید بپرسید چرا XML داده‌ها را به جای USC-2 در قالب UTF-8 ذخیره می‌کند؟ آیا هنگام خواندن اسناد XML توان پردازشی مهم‌تر است یا فضای مورد نیاز؟
• چرا ویندوز XP رشته‌ها را به صورت بومی در قالب USC-2 ذخیره می‌کند. از نظر عملیات درونی سیستم عامل، توان پردازشی مهم‌تر است یا فضای مورد نیاز؟

در هر حال UTF-8 برای نمایش چگونگی کدگذاری متن همچنان به هدر نیاز دارد. در غیر این صورت ممکن است به صورت یک ASCII مستقیم با صفحه کد متفاوت جهت مدیریت مقادیر بالاتر از 127 تلقی شود. در این قالب نیز همچنان از نقطه کد U+FEFF به عنوان یک BOM استفاده می‌شود؛ اما BOM خودش در UTF-8 کدگذاری شده است.

مثال UTF-8

Hello-UTF-8:

EF BB BF 48 65 6C 6C 6F
header H e l l o

در این مورد نیز متن ASCII در UTF-8 تغییر نیافته است. شما می‌توانید از charmap برای کپی کردن برخی کاراکترهای یونیکد و مشاهده چگونگی ذخیره شدن آن‌ها در UTF-8 استفاده کنید. همچنین می‌توانید از این وب‌سایت (+) به صورت آنلاین کمک بگیرید.

UTF-7

با این که UTF-8 برای ASCII عالی است؛ اما همچنان داده‌های یونیکد به صورت کاراکترهای غیر ASCII و مجموعه بیت بالا ذخیره می‌شوند. برخی پروتکل‌های ایمیل امکان استفاده از مقادیر غیر ASCII را نمی‌دهند و از این رو داده‌های UTF-8 به درستی ارسال نمی‌شوند. سیستم‌هایی که می‌توانند داده‌ها را با مجموعه بیت بالا مدیریت کنند «8-bit clean» نامیده می‌شوند؛ در حالی که سیستم‌هایی که نیازمند داده‌هایی در بازه 0 تا 127 هستند (مانند SMTP) چنین خصوصیتی ندارند. بنابراین اینک سؤال این است که چگونه می‌توان داده‌ها را از طریق چنین سیستم‌هایی ارسال کرد؟

پاسخ در UTF-7 است هدف از طراحی این انکودینگ، کدگذاری داده‌های یونیکد با استفاده از 7 بیت (0 تا 127) بوده است که با ASCII سازگار است. طرز کار UTF-7 چنین است:

• نقطه کدهای موجود در بازه ASCII به صورت ASCII ذخیره می‌شوند به جز این که نمادهای خاص (+ و -) معنای خاصی دارند.
• نقطه کدهای بالاتر از ASCII به مقادیر دودویی تبدیل می‌شوند و در انکودینگ base64 ذخیره می‌شوند (اطلاعات باینری در ASCII ذخیره می‌شود).

اینک سؤال این است که از کجا می‌توان فهمید کدام حروف ASCII واقعاً ASCII هستند و کدام یک به صورت base64 کدگذاری شده‌اند. کاراکترهای ASCII بین نمادهای + و - به صورت base64 کدگذاری شده‌اند.

به این ترتیب - در واقع مانند یک کاراکتر پسوند عمل می‌کند. اگر پس از یک کاراکتر بیاید، آن آیتم به صورت لغوی تفسیر می‌شود. بنابراین «+-» به صورت + و بدون هیچ کدگذاری دیگری تفسیر می‌شود. در حقیقت ما یک علامت + را در Utf-7 به همین گونه ذخیره می‌کنیم.

مثال UTF-7

ویکی‌پدیا چند مثال برای UTF-7 ارائه کرده است، چون نت پد نمی‌تواند UTF-7 را ذخیره کند. بدین ترتیب Hello همانند کد ASCII خود خواهد بود چون ما از همه کاراکترهای ASCII استفاده می‌کنیم و به نماد دیگری نیاز نداریم:

Byte: 48 65 6C 6C 6F
Letter: H e l l o

در سوی دیگر عبارت «£1» یعنی 1 پوند بریتانیا به صورت زیر درمی‌آید:

+AKM-1

کاراکترهای +AKM- به این معنی است که AKM باید در base64 کدگذاری و به یک نقطه کد تبدیل شود که به مقدار 0x00A3 یا نماد پوند بریتانیا نگاشت می‌شود. 1 همان طور که هست باقی می‌ماند، چون یک کاراکتر ASCII است.

در واقع UTF-7 یک تبدیل یونیکد به ASCII است که همه کاراکترهایی که بالاترین بیت دارند را حذف می‌کند. اغلب کاراکترهای ASCII همان طور که هستند باقی می‌مانند به جز نمادهای (+ ، -) که باید escape شوند.

سخن پایانی

با این که در این مطلب صرفاً مقدماتی در مورد یونیکد ارائه کردیم، با این حال موارد زیادی را آموخته‌ایم. این موارد را می‌توانیم به صورت زیر جمع‌بندی بکنیم:

• یونیکد به معنی استفاده از 2 بایت نیست. یونیکد نقطه‌های کد را تعریف می‌کند که می‌توانند به روش‌های مختلف مانند USC-2، UTF-8، UTF-7 و غیره ذخیره شوند. انکودینگ ها برحسب سادگی و کارآمدی از هم متفاوت هستند.

فیلم مجموعه آموزش مهارت های کاربردی کامپیوتر ICDL – جامع و کاربردی در فرادرس

کلیک کنید

• یونیکد بیش از 65535 (16 بیت) کاراکتر دارد. انکودینگ ها می‌توانند کاراکترهای بیشتری را توصیف کنند؛ اما 65535 بیت نخست، اغلب زبان‌های موجود را پوشش می‌دهند.
• شما باید انکودینگ یک فایل را بدانید تا بتوانید آن را به درستی بخوانید. شما در اغلب موارد می‌توانید بر اساس علامت بایت (BOM) حدس بزنید که فایل بر مبنای یونیکد است؛ اما همچنین احتمال سردرگمی وجود دارد؛ مگر این که انکودینگ دقیق را بدانید. حتی متنی که شبیه به ASCII به نظر می‌رسد، ممکن است در عمل با UTF-7 کدگذاری شده باشد و شما ندانید.

یونیکد موضوع جذابی برای مطالعه است. با مطالعه تاریخچه و مفاهیم یونیکد با اصول مختلف طراحی آشنا می‌شویم و به اهمیت جدا نگه‌داشتن ایده از انکودینگ مورد استفاده برای ذخیره‌سازی آن پی می‌بریم.

اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

• مجموعه آموزش‌های مهارت‌های اساسی کامپیوتر
• مجموعه آموزش‌های نسخه‌های مختلف ویندوز
• مجموعه آموزش‌های برنامه‌نویسی
• چگونه یک وب سایت با مخاطبان جهانی داشته باشیم؟
• تبدیل فایل های PDF به فرمت های دیگر — راهنمای ابزارهای آنلاین و رایگان
• آشنایی با کدهای اسکی (ASCII) — مفاهیم کامپیوتر به زبان ساده

==