مبدل کدگذاری متن
بایتهای خوشساخت UTF-۸، UTF-۱۶LE یا UTF-۱۶BE را به متن یونیکد رمزگشایی میکند، بهصورت اختیاری پایان خطوط را یکسانسازی میکند، سپس همان نویسهها را در یکی از این سه کدگذاری با انتخاب صریح نشانهٔ ترتیب بایت مینویسد.
یک فایل متنی ساده تا ۲۵ مگابایت. قالبهای باینری مانند اسناد Word کدگذاری متنی نیستند و رد میشوند.
نتیجهها بدون تضمین درستی ارائه میشوند. روش و منابع در پایین صفحه منتشر شدهاند تا بتوانید محاسبه را بررسی کنید.
چگونگی کار
این ابزار چه چیزی را محاسبه میکند
یک فایل متنی یعنی بایتها بهعلاوهٔ توافقی دربارهٔ معنای آن بایتها. UTF-۸، UTF-۱۶ با ترتیب بایت کوچک و UTF-۱۶ با ترتیب بایت بزرگ میتوانند همان نویسههای یونیکد را نمایش دهند، اما از توالی بایتهای متفاوتی استفاده میکنند. باز کردن UTF-۱۶ بهعنوان UTF-۸ فونت متفاوتی نشان نمیدهد؛ عددهای نادرستی را رمزگشایی میکند.
این مبدل هر دو توافق را آشکار میکند: منبع چگونه خوانده شود و نتیجه چگونه نوشته شود. تشخیص خودکار عمداً محدود است: نشانهٔ ترتیب بایت یونیکد را تشخیص میدهد و در غیر این صورت از UTF-۸ — پیشفرض امن وب — استفاده میکند، بهجای اینکه دربارهٔ یک صفحهکد قدیمی بدون نشانه اطمینانی ساختگی بسازد.
روش
تشخیص BOM در استاندارد کدگذاری WHATWG یک جدول سهردیفی است:
| بایتهای آغازین | کدگذاری |
|---|---|
EF BB BF | UTF-۸ |
FF FE | UTF-۱۶ با ترتیب بایت کوچک |
FE FF | UTF-۱۶ با ترتیب بایت بزرگ |
نشانه پیش از نمایش متن برداشته میشود. وقتی کدگذاری منبع دستی انتخاب شده و نشانهٔ فایل چیز دیگری میگوید، فایل رد میشود. نشانهٔ UTF-۱۶LE در برابر انتخاب UTF-۱۶BE شاهدی قویتر از نام فایل یا حدس است.
رمزگشایی سختگیر است: هر بایت ورودی باید به یک توالی خوشساخت تعلق داشته باشد. کنسرسیوم یونیکد اقدامات بازیابی مانند نویسهٔ جایگزین برای ورودی نامجاز را مجاز میداند، اما جایگزین همان متن اصلی نیست. مبدلی که وعدهاش بدون اتلاف بودن است باید متوقف شود و بگذارد مالک فایل ابزار بازیابی را خودش انتخاب کند.
پیش از ادامهٔ مطلب
یک فایل بدون BOM بایت ۸۰ را دارد. آیا کدگذاری قدیمی آن را میتوان تنها از روی همین بایت تشخیص داد؟
خیر. یک جریان بایت قدیمی بدون نشانه اطلاعات کافی برای تمایز همهٔ صفحهکدها را ندارد. بنابراین تشخیص خودکار BOMهای صریح یونیکد را میشناسد و در غیر این صورت UTF-۸ خوشساخت را الزامی میکند.
یک نمونهٔ کارشده
song.txt با کدگذاری UTF-۱۶LE و نشانهٔ دوبایتی FF FE است و این محتوا را دارد:
café
🎵
محتوای قابلمشاهده ۹ نقطهٔ کد یونیکد دارد: چهار حرف، دو جفت CRLF و یک نویسهٔ نت موسیقی. UTF-۱۶ این نت را بهصورت یک جفت جانشین — دو واحد کد ۱۶ بیتی — ذخیره میکند، اما همچنان یک نقطهٔ کد است.
منبع ۲۲ بایت است: ۲ بایت نشانه بهعلاوهٔ ۱۰ واحد کد UTF-۱۶. وقتی بهصورت UTF-۸ بدون نشانه و با حفظ پایان خطوط نوشته شود، نتیجه ۱۳ بایت است. متن دقیق همان café\r\n🎵\r\n میماند و نام فایل دانلودشده song-utf8.txt است. آزمون فرمول هر ۲۲ بایت ورودی، ۱۳ بایت خروجی، شمار نویسهها، هر دو برچسب کدگذاری و نام فایل را تأیید میکند.
ترتیب بایت و نشانههای ترتیب بایت
UTF-۸ روی واحدهای کد هشتبیتی کار میکند و روی هر پردازندهای همان توالی بایت را دارد. نشانهٔ آن یک امضاست، نه سوئیچ ترتیب بایت. نویسههای ASCII همان بایتهای ASCII خود میمانند؛ نقاط کد دیگر دو تا چهار بایت میگیرند.
UTF-۱۶ با واحدهای کد ۱۶ بیتی کار میکند. UTF-۱۶LE ابتدا بایت کمارزش هر واحد را مینویسد؛ UTF-۱۶BE ابتدا بایت پرارزش را. نویسههای بالاتر از U+FFFF از یک جانشین بالا و یک جانشین پایین استفاده میکنند، بنابراین در هر دو ترتیب بایت، آن نویسه چهار بایت میگیرد. وقتی هیچ برچسب بیرونیای در کار نیست، نشانه به خواننده اجازه میدهد این دو سریالسازی را از هم تشخیص دهد.
پایان خطوط یک انتخاب جداگانه است
تبدیل UTF-۱۶LE به UTF-۸ مستلزم تبدیل CRLF به LF نیست. اینها لایههای متفاوتی هستند: کدگذاری نویسهها را به بایت نگاشت میکند، در حالی که پایان خط یک یا دو نویسه است که از قبل درون متن قرار دارد. دقیقاً حفظ شود توالیهای تنهای CR، LF و CRLF را در جای خود میگذارد. گزینههای پیشرفته ابتدا هر سه را یکسانسازی میکنند و سپس بهطور یکدست LF یا CRLF مینویسند.
کاری که انجام نمیدهد
.docx، PDF، متن غنی یا هر قالب دربرگیرندهٔ دیگری را که واژههای قابلمشاهدهاش درون یک قالب باینری ساختیافته قرار دارند باز نمیکند. همچنین Windows-۱۲۵۲، Shift_JIS، GBK یا کدگذاری قدیمی دیگری را تشخیص نمیدهد. این تبدیلها وقتی برچسب منبع معلوم باشد ممکناند، اما حدس خودکار وعدهٔ اصلی ابزار را — اینکه نویسهها بیسروصدا تغییر نمیکنند — تضعیف میکند.
این ابزار تبدیل کدگذاری یونیکد را انجام میدهد، نه نرمالسازی یونیکد. یک é ترکیبشده و توالی همارز متعارف آن، یعنی e بهعلاوهٔ اکسان ترکیبی، به همان شکلی که در منبع بودهاند باقی میمانند.
مراحل انجام کار
- سه بایت اول را برای EF BB BF (UTF-۸)، FF FE (UTF-۱۶LE) یا FE FF (UTF-۱۶BE) بررسی کنید. در حالت خودکار، نشانه رمزگشا را انتخاب میکند؛ بدون نشانه، بهجای حدس زدن یک صفحهکد قدیمی، UTF-۸ را الزامی کنید.
- وقتی کدگذاری منبع دستی انتخاب شده، هر نشانهٔ موجود باید با آن سازگار باشد. نشانهٔ سازگار را بردارید، سپس در حالت سختگیر (fatal) رمزگشایی کنید تا یک توالی بایت نامجاز تبدیل را متوقف کند، نه اینکه بیسروصدا به نویسهٔ جایگزین تبدیل شود.
- هر توالی CR، LF و CRLF را بهطور پیشفرض حفظ کنید. فقط در صورت انتخاب، هر سه شکل را بهعنوان عملیاتی جدا از کدگذاری نویسهها به LF یا به CRLF یکسانسازی کنید.
- نقاط کد یونیکد را بشمارید و یک جفت جانشین (surrogate) معتبر UTF-۱۶ را یک نویسهٔ تکمیلی به حساب آورید. رشتهٔ حاصل را بهصورت بایتهای UTF-۸ یا واحدهای کد دوبایتی UTF-۱۶ با ترتیب بایت انتخابشده کدگذاری کنید.
- نشانهٔ مقصد انتخابشده — EF BB BF، FF FE یا FE FF — را فقط در صورت درخواست اضافه کنید، سپس یک فایل .txt جداگانه ارائه دهید. فایل منبع هرگز تغییر نمیکند.
فرضها
- حالت خودکار عمداً به سه نشانهٔ ترتیب بایت یونیکد محدود است. فایل بدون نشانه بهطور پیشفرض UTF-۸ سختگیرانه در نظر گرفته میشود؛ Windows-۱۲۵۲، گونههای ISO-۸۸۵۹ و دیگر صفحهکدهای قدیمی را نمیتوان تنها از روی بایتها بهطور قابلاعتماد تشخیص داد.
- نشانهٔ ترتیب بایت در ابتدای فایل فراداده است و پیش از اولین نویسهٔ متن مصرف میشود. یک U+FEFF در ادامهٔ فایل محتواست و محتوا میماند.
- UTF-۸ مسئلهٔ ترتیب بایت ندارد؛ BOM آن فقط یک امضاست. UTF-۱۶LE و UTF-۱۶BE همان واحدهای کد ۱۶ بیتی را با ترتیب بایت مخالف سریالسازی میکنند.
- توالیهای نامعتبر UTF بهجای تعمیر رد میشوند. سقف ورودی ۲۵ مگابایت است و حلقههای شمارش نقاط کد و UTF-۱۶ هر ۲۵۰٬۰۰۰ واحد کد برای گزارش پیشرفت و امکان لغو، کنترل را واگذار میکنند.
پرسشهای رایج
آیا فایل متنی برای تبدیل کدگذاری آپلود میشود؟
خیر. بایتها درون یک Worker در همین تب مرورگر رمزگشایی و دوباره کدگذاری میشوند و فایل جدید بهصورت محلی ساخته میشود. اگر استفاده از یک فایل واقعی درخواستی به خارج از مبدأ Tessalor بفرستد، آزمون مرورگری تولیدشده شکست میخورد.
وقتی یک توالی نامعتبر UTF-۸ یا UTF-۱۶ پیدا شود چه میشود؟
تبدیل با یک توضیح متوقف میشود. جایگزین کردن U+FFFD میتواند سیاست بازیابی مفیدی باشد، اما داده را تغییر میدهد؛ یک مبدل عمومی نباید بدون درخواست چنین انتخابی بکند.
آیا UTF-۸ به نشانهٔ ترتیب بایت نیاز دارد؟
UTF-۸ بایتمحور است، بنابراین ابهامی در ترتیب بایت (endian) ندارد. EF BB BF فقط یک امضای کدگذاری است و در گردشکارهای مدرن وب و خط فرمان معمولاً لازم نیست، هرچند برخی نرمافزارهای قدیمیتر انتظارش را دارند.
چرا یک ایموجی میتواند هم در UTF-۸ و هم در UTF-۱۶ چهار بایت بگیرد؟
یک نویسهٔ تکمیلی یونیکد از یک توالی چهاربایتی UTF-۸ و از یک جفت واحد کد جانشین دوبایتی UTF-۱۶ استفاده میکند. همچنان یک نقطهٔ کد است و به همین دلیل شمارش نتیجه آن را دو نویسه نمیشمارد.
آیا تغییر کدگذاری، پایان خط ویندوز و یونیکس را هم تغییر میدهد؟
بهطور پیشفرض خیر. کدگذاری نویسهها را به بایت نگاشت میکند؛ CRLF و LF توالیهایی از نویسهها هستند. کنترل پیشرفته این دو کار را جدا نگه میدارد و توالی اصلی را حفظ میکند، مگر اینکه تبدیلی انتخاب شده باشد.