
یکی از مشکلاتی که معمولاً برنامهنویسها به آن برمیخورند این است که اطلاعات یک فایل به فارسی ذخیره شده ولی موقع استفاده به صورت علامت سوال یا دیگر نویسههای نامربوط در میآید. برای غلبه به این مشکل و دیگر مشکلات مرتبط دانستن بعضی نکات ضروری است. من هر بار که به این طور مشکلات برخورد کردهام سعی کردهام آنها را در جایی یادداشت کنم تا بعداً بتوانم از آنها استفاده کنم. فهرست زیر همان مجموعه یادداشتهای من راجع به مشکلات Encoding به خصوص در رابطه با برنامهنویسی و Visual Studio است.
۱- اگر در Visual Source Safe انکودینگ فایلی عوض شود دیگر قادر به انجام عملیات «مقایسه» نخواهید بود.
۲- کدپیج ۱۲۵۶ ویندوز که عربی است از حروف «ی» و «ک» فارسی پشتیبانی نمیکند. و اگر در Visual Studio بخواهید فایلی را که در آن از این حروف استفاده میکند ذخیره کنید موفق نمیشوید. بلکه مجبور هستید از کدپیجهای یونیکدی مثل ۶۵۰۰۱ و ۱۲۰۰ و ۱۲۰۱ استفاده کنید.
۳- فایلهای utf-8 را که notepad ذخیره میکند با امضای سه بایتی ذخیره میکند و حجم فایل را سه بایت افزایش میدهد. ولی در Visual Studio اجازه دارید utf-8 را هم با این امضا و هم بدون آن ذخیره کنید. اگر بدون امضا ذخیره کنید این سه بایت اضافه نمیشود.
۴- نمیدانم Visual Studio در حالتی که از utf-8 بدون امضا استفاده شده، از کجا میفهمد که فایل ما با چه انکودینگی ذخیره شده و چطور باید آن را نشان دهد.
۵- اگر فایلی را با notepad به صورت unicode ذخیره کنید دو بایت به حجم آن اضافه میشود. احتمالا این دو بایت به اول فایل به صورت امضا اضافه میشود. VS هم دقیقا به همین روش عمل میکند.
۶- Unicode و Big Endian Unicode مثل هم هستند به جز یک فرق: ترتیب ذخیره بایتها در آنها فرق دارد. در یکی بایت پر ارزشتر در بایت اول و در دیگری در بایت دوم ذخیره میشود.
۷- utf-8 یکی از کدپیجهای رایج است که هر کاراکتر را بسته به شرایط در ۱ الی ۶ بایت نگهداری میکند. کاراکترهای معمولی که همان حروف کوچک و بزرگ انگلیسی به علاوه بعضی نشانهها و علامات هستند (همان ASCII معروف) به خاطر سازگاری با برنامههای قدیمی و به خاطر کاهش حجم فایلهای فقط «اسکی» در یک بایت نگهداری میشوند. کاراکترهای زبانهای رایج و معمولی دنیا از جمله عربی و فارسی در ۲ بایت ذخیره میشود. کاراکترهای دیگر زبانها از جمله ژاپنی و چینی در ۳ بایت ذخیره میشوند و الی آخر. به این ترتیب اگر فایلی فقط حاوی حروف انگلیسی باشد به اندازه تعداد کاراکترهایش حجم دارد و اگر فقط شامل حروف عربی و فارسی باشد دو برابر تعداد کاراکترها حجم خواهد داشت. نام دیگر این استاندارد code-page 65001 است.
۸- نام دیگر یونیکد، کد پیج ۱۲۰۰ و نام دیگر یونیکد (Big-Endian)، کدپیج ۱۲۰۱ است.
۹- یونیکد آن طور که همه تصور میکنند که دو بایت است و حداکثر ۶۵۵۳۶ کاراکتر را نگهداری میکند نیست بلکه میتواند حدود یک میلیون و صد هزار (۱۱۱۴۱۱۲) کاراکتر را ذخیره کند و من قضیه آن را خوب نمیفهمم.
۱۰- برای کاربردهای ما همان utf-8 کفایت میکند و نیازی نیست به مسائل دیگر فکر کنیم جز این که از signature در ابتدای فایلها استفاده کنیم یا نه. توجه شود که در بیشر محیطهای لینوکسی از فایلها utf-8 بدون signature استفاده میشود و در محیطهای ویندوزی به طور برعکس عمل میشود.
۱۱- اسکی یا ASCII از ۷ بیت و درنتیجه ۱۲۸ کاراکتر تشکیل شده و در محیطهای متنی کاربرد دارد.
۱۲- امضای سه بایتی اختیاری در ابتدای فایلهای utf-8: این امضا یک کاراکتر یونیکد به نام Byte Order Mark یا همان BOM است که وقتی به utf-8 تبدیل میشود سه کاراکتر جا میگیرد. این سه کاراکتر عبارتند از 0xEF,0xBB,0xBF. این کاراکتر را عمدتا برنامههای ویندوزی برای تشخیص فایلهای utf-8 در ابتدای آنها میگذارند. شکل نمایشی این سه کاراکتر به شکل  است. نام اصلی آن: )U+FEFF (zero-width no-break space
۱۳- امضای دو بایتی اجباری در ابتدای فایلهای یونیکد: احتمالا همان امضای کاراکتر BOM است که در utf-8 به صورت ۳ کاراکتر و در یونیکد به صورت ۲ کاراکتر ذخیره میشود.
۱۴- نتیجه گیری کلی: چون ما از کاراکترهای غیر انگلیسی و گاها غیر عربی (مثل «ی» فارسی) استفاده میکنیم بهتر است از یکی از فرمهای یونیکد استفاده کنیم. استفاده از utf-8 به خاطر حجم کمتر و سازگاری خوب با کاراکترهای انگلیسی بهتر است. با این که مدل امضا دار با بعضی محیطها و برنامههای دیگر خصوصا انواع غیر ویندوزی ناسازگار است ولی اگر سر و کار ما فقط با ویندوز است، بهتر است از مدل امضا دار استفاده کنیم. در غیر این صورت اگر با لینوکس هم سر و کار داریم بهتر است از utf-8 بدون signature استفاده کنیم.
۱۵- یک منبع خوب برای فهمیدن کد یونیکد کاراکترها: fileformat.info
دیدگاهها
مرسی
برای من خیلی مفید بود و یک مشکل خیلی سخت من حل شد.