یونیکد: سنگ روزتای دنیای مدرن

نگاهی به تاریخچه یونیکد و داستان کدگذاری پیام‌ها

به قلم دانیال خراسانی‌زاده ورودی ۹۹ کارشناسی مهندسی کامپیوتر صنعتی اصفهان

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

همانطور که احتمالا می‌دانید کامپیوترها تمامی اطلاعات را به صورت باینری و با ۰ و ۱ ذخیره می‌کنند. متون هم از این قاعده مستثنی نیستند و برای اینکه در کامپیوتر ذخیره شوند باید کاراکترهای آن‌ها به صورت عددی نمایش داده شود. به این کار "کدگذاری کاراکتر" گفته می‌شود. برای کدگذاری صحیح کاراکترها، به یک قرارداد همگانی هم نیاز داریم در غیر این صورت اطلاعات به طور صحیح رد و بدل نخواهند شد. مثلا اگر من حروف الفبا را از شماره صفر شمرده و شما آن را از شماره یک بشمارید، پیام "سلام" من را به صورت "ژگبل" دریافت خواهید کرد.

در دهه ۶۰ میلادی با پیشرفت تکنولوژی و ارزان‌تر شدن ارتباطات، بسیاری از محدودیت‌هایی که در گذشته برای ارسال پیام به راه‌های دور وجود داشت از بین رفت و به همین خاطر استفاده از استانداردهایِ ارسال پیام پیچیده اما راحت‌تر تبدیل به عملی منطقی شد. یکی از این استانداردها، که با هدف جایگزین کردن استاندارد ۵ بیتی[1] قبلی، برای تله‌پرینترها ساخته شد استاندارد ASCII بود که در ابتدا ۷ بیتی بود و از ۱۲۸ کاراکتر پشتیبانی می‌کرد.

۳۲ کاراکتر اول این استاندارد برای نشانه‌های کنترلی مانند "خط جدید" استفاده می‌شود که بعضی از آن‌ها امروزه منسوخ شده‌اند.

۹۵ کاراکتر بعدی علائم قابل پرینت هستند که از حروف کوچک و بزرگ انگلیسی و علامت‌های نگارشی تشکیل شده‌اند. آخرین کاراکتر نیز DEL است که برای پاک کردن کاراکتر‌های اشتباه تایپ شده قبلی استفاده می‌شود.[3]

نکته جالب درباره استاندارد [2] ASCII این است که به کاراکتر A آدرس ۶۵ و به کاراکتر a آدرس ۹۷ داده است. ۶۵ در باینری به صورت 1000001 و ۹۷ به صورت 1100001 نوشته می‌شود. مزیت این آدرس‌ها این است که می‌توان با حذف دو بیت آخر آن‌ها جای حرف را در حروف الفبای انگلیسی به آسانی پیدا کرد.

در ۱۹۷۲ و با ساخته شدن اولین پردازنده ۸ بیتی دنیا یعنی Intel 8008 تعداد بیت‌های استاندارد ASCII به ۸ بیت افزایش یافت و حال می‌شد از ۲۵۶ کاراکتر پشتیبانی کرد. اما این کاراکترهای جدید استانداردسازی شده نبودند و هر شرکت کامپیوترسازی کاراکترهایی مخصوص به خود را به ASCII اضافه کرد.

از آن جا که استاندارد ASCII از کاراکترهایی بجز حروف انگلیسی پشتیبانی نمی‌کرد، ۱۵ استاندارد دیگر[4] نیز برای حروف سیریلیک، عربی، عبری و تایوانی ساخته شد. مشکل بزرگ این استانداردها این بود که اگر فایلی با یکی از این استانداردها دریافت می‌کردید باید می‌دانستید دقیقا کدام‌یک استفاده شده است. مشکل دیگری نیز وجود داشت و این بود که هیچ کدام از این استانداردها از کاراکترهای چینی، ژاپنی و کره‌ای پشتیبانی نمی‌کرد. اما با وجود این مشکل‌ها تا اواخر دهه ۸۰ میلادی و ظهور اینترنت مشکل ارتباط تا حد زیادی حل شده فرض می‌شد.

اما با همه‌گیر شدن اینترنت و اتصال کامپیوترها، کشورها متوجه شدند هرکدام از استانداردی مخصوص به خود استفاده می‌کنند و امکان ارتباط همگانی وجود ندارد و باید راه حلی جدید ارائه شود.

در ۱۹۸۷ جو بکر[5] از شرکت زیراکس، به همراه لی کالینز[6] و مارک دیویس[7] از اپل، استاندارد یونیکد را بر اساس استاندارد XCCS که در اوایل دهه ۸۰ میلادی برای پشتیبانی از زبان‌های مختلف در شرکت زیراکس[8] ساخته شده بود ایجاد کرد.[9] در ادامه این راه Unicode Consortium در 1991 با هدف "ساخت یک کدگذاری که به هر کس در جهان اجازه می‌داد از زبان خود در کامپیوتر استفاده کند." شروع به کار کرد.[10]

این سازمان غیرانتفاعی، هماهنگی توسعه یونیکد را بر عهده دارد و امروزه اعضای آن از شرکت‌های کامپیوتری مانند اپل، گوگل، فیس‌بوک، ادوبی، آی‌بی‌ام، مایکروسافت و... تشکیل شده و تا به حال ۱۴۳۸۵۹ کاراکتر مختلف را کدگذاری کرده است.

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

برای مقابله با این مشکل‌ها روش‌های مختلفی وجود دارد که امروزه پر استفاده‌ترین آن‌ها در دنیای اینترنت UTF-8 است.

۱۲۸ کاراکتر اول UTF-8 برای پس-سازگاری به همان شکل ASCII کدگذاری شده‌اند. پس از این وارد کاراکترهایی جلوتر از ۱۲۸ می‌شویم. در این قسمت UTF-8 بایت اول را به صورت 110xxxxx و بایت دوم را به صورت 10xxxxxx کدگذاری می‌کند. "110" آغاز بایت اول به معنی شروع یک کاراکتر ۲ بایتی، و "10" آغاز بایت دوم به معنای ادامه بایت قبلی است. این شکل از فرستادن کاراکترها به همین شکل ادامه پیدا می‌کند و طبق قرارداد از کاراکترهایی با حداکثر ۲۱ بیت اطلاعات که در ۴ بایت جا می‌گیرند و بایت آغاز آ‌ن‌ها به شکل 11110xxx پشتیبانی می‌کند.[11] برای مثال کاراکتر به کاراکتر ∑ در یونیکد شماره 8721 دسیمال داده شده است در باینری به صورت 0010001000010001 نوشته می‌شود که طبق قوانین UTF-8 برای کدگذاری شدن به سه بایت نیاز دارد.(دو بیت صفر آخر به این دلیل اضافه شده‌اند که بر اساس قرارداد اعدادی که برای کدگذاری به 3 بایت نیاز دارند حتما باید با 16 بیت اطلاعات نمایش داده شوند.) چون این عدد 3 بایتی است بایت اول آن به سه تا یک و یک صفر شروع می‌شود، چهار بیت با ارزش‌تر عدد در کنار این اعداد قرار گرفته و بایت اول آن را به شکل 11100010 تشکیل می‌دهند. بایت دوم با نشانه ادامه 10 شروع شده و در ادامه 6 بیت دیگر از عدد را به شکل 10001000 در خود ذخیره می‌کنند. بایت آخر نیز مانند بایت دوم شروع شده و به صورت 10010001 نوشته می‌شود. پس در کل کاراکتر ∑ در سیستم کدگذاری UTF-8 به صورت 111000101000100010010001 کدگذاری می‌شود.

با وجود چنین استانداردی هنوز هم ممکن است به خاطر مشکل‌ها در ارسال یا دریافت پیام و یا پشتیبانی نکردن کامپیوتر گیرنده از بعضی کاراکترها با کاراکترهایی ناشناخته که با علامت سوال نمایش داده می‌شوند مواجه شوید، جالب است بدانید در زبان ژاپنی به چنین مشکلی "موجیباکه"[12] می‌گویند.

پانویس ها:

[1] Murray code
[2] American Standard Code for Information Interchange
[3] درگذشته که استفاده از تله‌تایپ‌ها مرسوم بود در صورت تایپ کاراکتر اشتباه نویسنده ابتدا با فشردن دکمه بک‌اسپیس نوار اطلاعات را به عقب باز می‌گرداند و سپس با فشردن دکمه این کاراکتر تمام ردیف را پانچ می‌کرد.تا آن قسمت کاملا نادیده گرفته شود. در حال حاضر در کامپیوترها فشردن دکمه بک‌اسپیس جایگزین این کاراکتر شده البته هنوز هم کامپیوترهایی وجود دارند که برای پاک کردن کاراکتر قبلی از این کاراکتر پشتیبانی کنند.
[4] استانداردهای ISO 8859-1 تا ISO 8859-16 (استاندارد ISO 8859-12 هیچ‌وقت رسمی نشد.)
[5] Joe Becker
[6] Lee Collins
[7] Mark Davis
[8] Xerox
[9] https://unicode.org/history/unicode88.pdf
[10] این سازمان هنوز هم به طور کامل به این هدف دست پیدا نکرده و نوشتارهایی وجود دارند که بوسیله یونیکد کدگذاری نشده‌اند. البته لازم به ذکر است که اکثر این نوشتارها باستانی بوده و امروزه استفاده نمی‌شوند.
[11] https://tools.ietf.org/html/rfc3629
[12] Mojibake: برگرفته از کلمه 文字化け در زبان ژاپنی