رمزگذاری html روسی. کدگذاری صفحه HTML

امیدوارم شما را متقاعد کرده باشم و از یونیکد استفاده کنید (البته "utf-8" و "یونیکد" مترادف هستند یا به عبارت دقیق تر، utf-8 یکی از رمزگذاری های خانواده یونیکد است که دارای در بین توسعه دهندگان وب محبوبیت پیدا کرد).

حالا بیایید نگاهی دقیق تر به ابزارهای رمزگذاری فایل بیندازیم که به شما خواننده عزیز توصیه می کنم استفاده کنید.

ابزارهایی برای کار با رمزگذاری فایل های HTML

در واقع، فقط سه مورد از آنها وجود دارد:

• PSPad. ویرایشگر متن رایگان، مورد علاقه من.
• . یکی دیگر از ویرایشگرهای متن خوب و همچنین رایگان.
• دریم ویور. خب، شما با Dreamweaver از سایت من آشنا هستید.

ما مقداری فایل HTML را در PSPad بارگذاری می کنیم.و چگونه می توانیم بفهمیم که موضوع آزمایشی بارگذاری شده چه نوع رمزگذاری دارد؟ خیلی ساده، همه چیز به وضوح در نوار وضعیت (در زیر) نوشته شده است.

کدگذاری فایل HTML ویندوز-1251 را باز کنید

حال، هنگام ایجاد یک سند HTML جدید، اجازه دهید مراقب رمزگذاری آن باشیم.

بریم سراغ منوی مورد علاقه من PSPad. ما به مورد علاقه مند هستیم قالب. در آن کادر کنار رمزگذاری utf-8 را علامت می زنیم.

و بنابراین رمزگذاری فایل آینده ویندوز-1251 است

حالا در مورد چگونگی رمزگذاری فایل HTML را تغییر دهید. بله، به نظر می رسد بسیار ساده است:

شما باید روی رمزگذاری مورد نیاز در آیتم منو کلیک کنید قالبو رمزگذاری تغییر خواهد کرد. پس از آن، فایل را ذخیره کنید، دوباره کدگذاری می شود، کار انجام می شود.

مربوط به Notepad++همه چیز بسیار شبیه به وضعیتی است که در بالا توضیح داده شد. فقط برای کار با رمزگذاری ها باید از آیتم منو استفاده کنید رمزگذاری ها

تنها تفاوت این است که در مورد Notepad ++، آیتم های منو ظاهر می شوند که به طور ویژه برای تبدیل رمزگذاری طراحی شده اند. تبدیل... (به نظر من غیر ضروری است، همه چیز در PSPad ساده تر است و به همین دلیل از آن استفاده می کنم). بر این اساس، اگر می‌خواهید رمزگذاری فایل HTML خود را تغییر دهید، باید روی آنها کلیک کنید.

در میان چیزهای دیگر، هنگام ذخیره در utf-8 ما یک انتخاب داریم: بدون BOMیا با BOM. ما به عنوان مدیران وب باید از رمزگذاری استفاده کنیم UTF-8 (بدون BOM).

این همان چیزی است که ویکی‌پدیا به این سؤال پاسخ می‌دهد که BOM چیست؟

برای تعیین فرمت نمایش یونیکد در یک فایل متنی، از تکنیکی استفاده می‌شود که در آن کاراکتر U+FEFF (فاصله غیرقابل شکست با عرض صفر) که علامت ترتیب بایت (BOM) نیز نامیده می‌شود، در ابتدای متن نوشته می‌شود. . این روش بین UTF-16LE و UTF-16BE تفاوت قائل می شود زیرا کاراکتر U+FFFE وجود ندارد. همچنین گاهی اوقات برای اشاره به فرمت UTF-8 استفاده می شود، اگرچه مفهوم ترتیب بایت در این قالب صدق نمی کند.

اگر متن بالا را 10 بار بخوانید و سر خود را بخارانید، مشخص می شود: برای utf-8 BOM ما نیازی نداریم. علاوه بر این، اگر فایلی را با اسکریپت php در کدگذاری ذخیره کنید utf-8 با BOM، پس کار نخواهد کرد، زیرا کنترل کننده متوجه نخواهد شد که چه نوع مزخرفی در ابتدای فایل اسکریپت نوشته شده است (منظورم آن فضای بدون شکسته با عرض صفر است).

خوب، خوب، تنها چیزی که باقی می ماند این است که نگاه دقیق تری داشته باشیم دریم ویور.

هنگام ایجاد یک فایل جدید، توجه داشته باشید که در چه کدگذاری ایجاد می شود. برای انجام این کار، در پنجره ایجاد یک سند جدید فایل → جدید (Ctrl+N)از دکمه استفاده کنید اولویت ها...

و به آنچه به عنوان رمزگذاری پیش فرض تنظیم شده است نگاه کنید:

رمزگذاری پیش فرض فایل HTML تولید شده در Dreamweaver

رمزگذاری یک فایل HTML باز در Dreamweaverدر گفتگو امکان پذیر است ویژگی های صفحه،که از منو راه اندازی می شود تغییر → ویژگی های صفحه (Ctrl + J).

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

تشخیص رمزگذاری مرورگر

بنابراین، فایل HTML ما در رمزگذاری که انتخاب کرده ایم ذخیره می شود. حالا بیایید به سوال نگاه کنیم: مرورگر چگونه از رمزگذاری استفاده شده در یک فایل HTML مشخص می‌داند؟

در اینجا سه ​​گزینه وجود دارد:

1. ما خودمان به مرورگر می گوییم که چه رمزگذاری برای این فایل HTML تنظیم شده است.این کار با استفاده از تگ META انجام می شود

مثال بالا به مرورگر دستور می دهد که فایل HTML دانلود شده در رمزگذاری ذخیره شده است utf-8.

اگر فایل HTML در رمزگذاری ویندوز 1251 ذخیره شده است، پس:

به هر حال، هنگام رمزگذاری فایل ها، فراموش نکنید که دستورالعمل های موجود در تگ META را به موارد فعلی تغییر دهید. Dreamweaver، هنگام تغییر رمزگذاری، این کار را به صورت خودکار انجام می دهد، اما در سایر ویرایشگرهای متن، شما باید خودتان کدگذاری اعمال شده و دستورالعمل تگ META را مطابقت دهید.

HTML کامل به این شکل است (من آن را برای درک این سؤال نقل می کنم که "تگ META با دستورالعمل رمزگذاری کجا مشخص شده است؟" به خط 4 توجه کنید):

خوب و غیره

2. استفاده از فایل htaccess.گاهی اوقات سرور هدر فایل های HTML دانلود شده را مجبور می کند و کدگذاری پیش فرض را به مرورگر می گوید. در این حالت مرورگر به دستورالعمل های موجود در تگ META توجهی نمی کند، بلکه فایل HTML را در کدگذاری گزارش شده توسط سرور نمایش می دهد. برای اینکه فایل در کدگذاری مورد نیاز شما دانلود شود (اغلب میزبانی شما را مجبور می‌کند رمزگذاری ویندوز 1251 را مشخص کنید)، فایلی به نام “htaccess.” در ریشه دایرکتوری میزبانی ایجاد می‌شود.

این فایل برای پیکربندی سرور اضافی در نظر گرفته شده است. اثر دستورالعمل‌های htaccess. برای همه فایل‌ها و زیرشاخه‌هایی که در فهرستی که فایل htaccess. را ذخیره کرده‌اید، اعمال می‌شود.

شما می توانید این فایل را برای مثال در Total Commander با فشار دادن کلید میانبر ایجاد کنید Shift+F4و نام فایل ایجاد شده را مشخص کنید htaccess. در مرحله بعد، ویرایشگر متن دستورالعمل هایی را برای تنظیمات کدگذاری پیش فرض اضافی مشخص می کند.

برای فایل های HTML با کد utf-8در htaccess باید یک خط بنویسید:

AddDefaultCharset UTF-8

برای فایل های HTML در رمزگذاری ویندوز 1251:

AddDefaultCharsetWindows-1251

اگر هاست شما به طرز زیرکانه ای عاقلانه است و به این دستورالعمل ها توجه نمی کند، می توانید امتحان کنید:

Charset غیرفعال در AddDefaultCharset خاموش است

اگر این کار نکرد، فقط از میزبان خود بپرسید که برای غیرفعال کردن رمزگذاری پیش فرض چه کاری باید انجام دهید :). همه اینها به تنظیمات سرور خاص ارائه دهنده هاست بستگی دارد.

3. دستورالعمل PHP که رمزگذاری پیش فرض را مشخص می کند.در فایلی که باید در کدگذاری مورد نظر نمایش داده شود، با وجود تنظیمات سرور ارائه دهنده هاست، در همان ابتدا دستورالعملی با کد php نشان داده شده است:

این کد php یک هدر سرور ارسال می کند که رمزگذاری پیش فرض مرورگر را نشان می دهد. در مثال بالا از رمزگذاری utf-8 برای نمایش صفحه استفاده خواهد شد.

معمولاً هیچ ترفندی در تنظیمات سرور ارائه دهنده میزبانی برای مقابله با چنین ضایعاتی وجود ندارد.

من می خواهم توجه داشته باشم که برای اینکه سرور دستورات PHP را پردازش کند، فایل html باید پسوند داشته باشد php(به عنوان مثال index.php).

آیا سوال دیگری در مورد رمزگذاری دارید؟ در نظرات بنویسید. ما باید این مشکلات را یک بار برای همیشه حل کنیم :)

دلیل اینکه بفهمیم UTF-8 چگونه کار می کند و یونیکد چیست، این واقعیت است که VBScript توابع داخلی برای کار با UTF-8 ندارد. و از آنجایی که نتوانستم چیزی را پیدا کنم که کار کند، مجبور شدم خودم آن را بنویسم/تمام کنم. به نظر من تجربه در هر صورت مفید است. برای درک بهتر، از نظریه شروع می کنم.

درباره یونیکد

• تنها 255 کاراکتر وجود دارد، و حتی در آن زمان نیز برخی از آنها گرافیکی نیستند.
• امکان باز کردن یک سند با رمزگذاری متفاوت از آنچه در آن ایجاد شده است.
• برای هر کدگذاری باید فونت ایجاد شود.

درباره UTF-8

ما در UTF-8 کدگذاری می کنیم

• هر کاراکتر را به یونیکد تبدیل می کنیم.
• بررسی می کنیم که نماد از کدام محدوده است.
• اگر کد نماد کمتر از 128 باشد، آن را بدون تغییر به نتیجه اضافه می کنیم.
• اگر کد کاراکتر کمتر از 2048 باشد، 6 بیت آخر و 5 بیت اول کد کاراکتر را می گیریم. به 5 بیت اول 0xC0 اضافه می کنیم و بایت اول دنباله را می گیریم و 0x80 را به 6 بیت آخر اضافه می کنیم و بایت دوم را می گیریم. الحاق کنید و به نتیجه اضافه کنید.
• می‌توانیم به روشی مشابه برای کدهای بزرگ ادامه دهیم، اما اگر کاراکتر فراتر از U+FFFF باشد، باید با جانشین‌های UTF-16 مقابله کنیم.

رمزگشایی UTF-8

• ما به دنبال اولین کاراکتر فرم 11xxxxxx هستیم
• ما تمام بایت های بعدی فرم را 10xxxxxx می شماریم
• اگر دنباله دو بایت و اولین بایت 110xxxxx باشد، پیشوندها را قطع کرده و با هم جمع می کنیم و اولین بایت را در 0x40 ضرب می کنیم.
• به همین ترتیب برای سکانس های طولانی تر.
• کل دنباله را با کاراکتر یونیکد مورد نظر جایگزین کنید.

یکی از رایج ترین مشکلاتی که یک مبتدی با آن مواجه است مدیر وب سایت(و نه فقط مبتدیان)، این مشکل کدنویسی در سایت. حتی برای من همیشه هنگام ایجاد وب سایت ظاهر می شود " ابراکادابرا"اما، خوشبختانه، من به خوبی می دانم که چگونه این مشکل را حل کنم، بنابراین همه چیز را ظرف چند ثانیه مرتب کردم. و در این مقاله سعی می کنم به همان سرعت به شما آموزش دهم. حل مشکلات مربوط به کدنویسی در سایت.

اولین چیزی که شایان ذکر است این است که تمام مشکلات ظاهری "abracadabra" با عدم تطابق بین رمزگذاری سند و رمزگذاری تنظیم شده توسط مرورگر همراه است. بیایید بگوییم یک سند در ویندوز-1251، اما به دلایلی مرورگر نمایش داده می شود UTF-8. و منشأ چنین اختلافی ممکن است دلایل زیر باشد.

دلیل اول

متا تگ اشتباه نوشته شده است نوع محتوا. مراقب باشید، همیشه باید حاوی رمزگذاری باشد که سند شما در آن نوشته شده است.

دلیل دوم

به نظر می رسد که متا تگ به شکلی که شما می خواهید نوشته شده است و مرورگر دقیقا همان چیزی را که شما می خواهید نمایش می دهد، اما به دلایلی همچنان مشکلاتی در رمزگذاری وجود دارد. مقصر در اینجا تقریباً به طور قطع این است که خود سند رمزگذاری متفاوتی دارد. اگر در آن کار می کنید Notepad++، سپس در پایین سمت راست نام رمزگذاری سند فعلی وجود دارد (به عنوان مثال، ANSI). اگر متا تگ قرار دهید UTF-8، و خود سند در آن نوشته شده است ANSI، سپس تبدیل به را انجام دهید UTF-8(از طریق منو" رمزگذاری ها"و نقطه" بدون BOM به UTF-8 تبدیل کنید").

دلیل سوم

دلیل چهارم

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

تنظیم نام "utf8"

بجای " utf8ممکن است رمزگذاری متفاوتی وجود داشته باشد. پس از آن، تمام داده‌های پایگاه داده باید با رمزگذاری صحیح خارج شوند.

در این مقاله، امیدوارم حداقل توضیح داده باشم، 90٪ از مشکلات مربوط به ظاهر "بیهوده" در سایت است. اکنون باید در کوتاه ترین زمان با مشکلی محبوب و ساده مانند رمزگذاری نادرست مقابله کنید.

هنگام ایجاد یک وب سایت، وب مسترهای مبتدی اغلب سؤالاتی دارند: از چه رمزگذاری برای وب سایت استفاده کنند، چگونه UTF-8 با windows-1251 متفاوت است، و چگونه آن را در META Charset صفحات HTML سایت وارد کنند. پاسخ تمام این سوالات در این مقاله آمده است.

رمزگذاری سایت چیست و چگونه کار می کند؟

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

همین اتفاق در مورد صفحات HTML سایت می افتد. اگر سند، به عنوان مثال، در رمزگذاری UTF-8 ذخیره شده است، و خود سند حاوی یک تگ META است که نشان می دهد این رمزگذاری ویندوز-1251 است، مرورگر دوباره داده های ذخیره شده در فایل را با جدول رمزگذاری مقایسه می کند. به آن مشخص شده است و از آنجایی که کاراکترها بر اساس -متفاوت کدگذاری می شوند، مرورگر مجموعه نامفهومی از کاراکترها را به جای متن معمول نمایش می دهد، یا ممکن است برخی از حروف به شکل عادی باشند، در حالی که حروف یا نمادهای دیگر ممکن است نمایش داده شوند. مثلا به صورت علامت سوال تمام موارد فوق برای نمایش نام فایل ها نیز صدق می کند.

هنگام ایجاد یک سند جدید در یک ویرایشگر متن، بهتر است بلافاصله مطمئن شوید که رمزگذاری مورد نظر انتخاب شده است. ویرایشگرهای مدرن به شما این امکان را می دهند که متن یک سند باز را از یک رمزگذاری به دیگری تبدیل کنید و Notepad استاندارد به شما امکان می دهد فقط هنگام ذخیره فایل، کدگذاری را انتخاب کنید.

رایج ترین رمزگذاری ها

از پاراگراف قبلی، قبلاً می دانید رمزگذاری چیست و چرا نوشتن صحیح آن در کد صفحات سایت بسیار مهم است. اکنون بیایید دریابیم که کدام یک از بسیاری از رمزگذاری ها برای سایت آینده بهتر است. از آنجایی که رایج ترین و آسان ترین سیستم عامل همیشه سیستم عامل ویندوز بوده است، اکثر توسعه دهندگان وب صفحات HTML را در رمزگذاری ویندوز-1251 (ANSI) ایجاد کردند که به طور پیش فرض استفاده می شد. اما windows-1251 تعداد بسیار زیادی از حروف و نمادها را پشتیبانی نمی کند و توسعه دهندگان می خواهند از فلش ها، قلب ها، مربع ها و سایر نمادها در متن های خود استفاده کنند، از جمله نیاز به ترکیب کلمات از زبان های مختلف در یک سند، بنابراین مدتهاست که جایگزین UTF-8 توسعه یافته تر شده است و اکثر توسعه دهندگان از این رمزگذاری استفاده می کنند.

مشکلات رمزگذاری نه تنها در صفحه HTML

سایت، چه صرفاً مجموعه‌ای از اسناد HTML ایستا یا اسکریپت‌های پویا پیچیده باشد که صفحات را در لحظه تولید می‌کنند، بر روی یک وب سرور میزبانی می‌شود که با یک رمزگذاری خاص نیز کار می‌کند. و اگر سرور اطلاعات را در یک رمزگذاری ارائه می‌کند و صفحات یا اسکریپت‌های شما در یک رمزگذاری متفاوت ذخیره می‌شوند، ممکن است دوباره مشکلاتی در نمایش صفحات در مرورگر کاربر وجود داشته باشد. بسیاری از هاست ها به شما این امکان را می دهند که تنظیمات را تغییر دهید و کدگذاری را مطابق با کد مورد استفاده در فایل های سایت از طریق کنترل پنل انتخاب کنید، یا اگر هاست از وب سرور محبوب آپاچی استفاده می کند، می توانید آن را در فایل htaccess. بنویسید.

تقریباً هیچ وب سایت مدرنی نمی تواند بدون استفاده از پایگاه داده MySQL کار کند و همچنین می تواند به منبع مشکلات رمزگذاری تبدیل شود. اگر فایل های سایت در یک کدگذاری ذخیره شده باشند و اطلاعات پایگاه داده در دیگری باشد، می توان در صفحه آن قسمت از اطلاعاتی که از پایگاه داده خروجی می شود به صورت همان علامت سوال یا علامت های نامفهوم دیگر نمایش داد. . برای جلوگیری از مشکل در رمزگذاری، باید برای وب سرور، پایگاه داده MySQL، در اسکریپت ها، در صفحات HTML سایت و در تگ META که در کد HTML نوشته شده است، یکسان باشد. اگر مشکلی در نمایش متن وجود دارد، تمام موارد بالا را برای مشکل بررسی کنید.

META Charset از سند HTML

برای اینکه به مرورگر و موتورهای جستجو بگویید صفحات سایت در چه رمزگذاری ذخیره می شوند، یک META Charset در کد آنها نوشته می شود.

برای رمزگذاری ویندوز 1251:

برای رمزگذاری UTF-8:

اکنون می دانید که کدگذاری سایت چیست و در صورت نمایش نادرست متن در هر قسمت از سایت، کجا باید به دنبال مشکلات باشید.

کپی مطلب ممنوع

). و در اینجا ما در مورد جنبه عملی استفاده از UTF-8 صحبت خواهیم کرد.

مزیت اصلی

با رمزگذاری UTF-8، می توانید مستقیماً هر کاراکتری از کل مجموعه یونیکد را در سند خود قرار دهید.رمزگذاری های قدیمی (مانند Windows-1251 یا KOI8-R) بیش از 256 کاراکتر ارائه نمی دهند، اما یونیکد بیش از 100000 کاراکتر دارد. از جمله آنها می توان به علائم چاپی (خط تیره، علامت نقل قول، بیضی، آپستروف، فاصله بدون شکستن، خط فاصله بدون شکستن، و غیره)، کاراکترهای خاص (№، §، ©، ‰، ×، و غیره)، حروف با نشانه و لیگاتورها (é، è، Ü، Æ، ø، fi، و غیره)، نمادهای تقریباً تمام الفبای موجود در جهان (α، Ω، א، ת، ѣ، 伲، 儻، و غیره)، تصویر و نمادها ( →، ■،، ☺ و غیره) و بسیاری از نمادهای دیگر.

به «جدول نمادها» در رایانه خود نگاه کنید. با رمزگذاری UTF-8، می توانید هر کاراکتری را مستقیماً از این جدول بگیرید و مستقیماً در سند خود قرار دهید. اگر به یک علامت کپی رایت، مدرک تحصیلی یا انتگرال نیاز دارید، نیازی نیست به دنبال فونت خاصی باشید، این علامت را در قالب گرافیکی ارائه دهید، یا ترفند دیگری را ارائه دهید. در رمزگذاری UTF-8، هر کاراکتری، اعم از کسری ⅓ یا نویسه چینی، می‌تواند مانند حرف لاتین "A"، "ы" روسی یا علامت "+" در یک سند استفاده شود.

در رمزگذاری های قدیمی تر، امکان درج کاراکترهای خاص در یک سند با استفاده از جایگزینی وجود داشت ( منابع). به عنوان مثال، خط em مطابق با جایگزین & mdash ; (همچنین & # 8212 ; یا & # x2014 ; ) و حرف یونانی "pi" جایگزین & pi می شود. (همچنین & # 960 ; یا & # x3c0 ; ). برای اکثر کاراکترها فقط جایگزین های عددی وجود داشت: برای مثال، برای کسر ⅓ - & # 8531 ; یا & # x2153 ; ، برای علامت موسیقی "تخت" - & # 9837 ; یا & # x266d ; ، برای خط فاصله بدون شکست - & # 8209 ; یا & # x2011 ; . البته این خیلی ناخوشایند است. اولا، خیلی طولانی است: به عنوان مثال، به جای یک کاراکتر "♭" باید هفت را وارد کنید: & # 9837 ; . ثانیاً، یک سند با جایگزینی برای مشاهده و ویرایش ناخوشایند است. زمانی که در سند مستقیماً کاراکترهایی را که باید وجود داشته باشند و نه کدهایی مانند & mdash ; یا & # x3c0 ; .

روزی روزگاری، توسعه دهندگان صفحات وب مجبور به استفاده از چنین جایگزین های دست و پا گیر بودند، زیرا رمزگذاری UTF-8 هنوز وجود نداشت. اما اکنون می توانید هم جایگزینی ها و هم رمزگذاری های قدیمی را فراموش کنید.

افسانه ها در مورد معایب

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

مرورگرها از UTF-8 به خوبی پشتیبانی نمی کنند؟

گفته می‌شود که برخی از کاربران هنوز مرورگرهای قدیمی‌تری دارند که قادر به رندر کردن صفحات در UTF-8 نیستند. این کاملا مزخرف است. حتی اینترنت اکسپلورر 4 و نت اسکیپ 4 که هیچ کس مدت زیادی از آنها استفاده نکرده است، UTF-8 را کاملاً درک می کنند. و مرورگرهای مدرن تر - حتی بیشتر.

UTF-8 به هیچ وجه یک رمزگذاری «جدید» یا «جوان» نیست؛ بیش از ده سال است که با موفقیت مورد استفاده قرار گرفته است. اگر یک توسعه‌دهنده خاص اخیراً در مورد آن مطلع شده یا هنوز نمی‌داند، این فقدان صلاحیت‌های او است، نه کدنویسی او.

آیا با UTF-8 در سرور وب خود مشکل دارید؟

گاهی اوقات توسعه‌دهندگان مبتدی شکایت می‌کنند: «من صفحه‌ای را در UTF-8 روی سرور قرار دادم، اما به‌هم ریختگی نشان داده می‌شود». در واقع، این مشکل با طیف گسترده ای از رمزگذاری ها اتفاق می افتد و به هیچ ویژگی خاصی از UTF-8 مربوط نمی شود. مشکل اینجاست که صفحه در یک کدگذاری ساخته شده است و سرور دیگری را در هدرهای HTTP گزارش می دهد. لازم است تنظیمات سرور با کدگذاری واقعی صفحات وب مطابقت داشته باشد. باز هم می گویم که این کار باید با هر کدگذاری انجام شود.

آیا فایل‌های UTF-8 فضای زیادی را اشغال می‌کنند؟

آنها می گویند که اسناد در UTF-8 دو برابر بزرگتر از رمزگذاری های قدیمی است. این یک افسانه از دسته "زنگ شنیدم، اما نمی دانم کجاست" است. در واقع، هر چند وقت یکبار لازم نیست. به عنوان مثال، اگر یک سند فقط از کاراکترهای ASCII (حروف لاتین، اعداد، علائم نگارشی و غیره) تشکیل شده باشد، در رمزگذاری UTF-8 دقیقاً همان تعداد بایت را اشغال خواهد کرد که در سایر موارد. اگر سندی فقط شامل حروف الفبای روسی باشد و هیچ کاراکتر دیگری نداشته باشد (که می بینید بسیار نادر است)، در UTF-8 در واقع دو برابر بزرگتر می شود. و اگر برای مثال دارای حروف روسی و عربی باشد، در UTF‑8 نصف بزرگی آن مثلاً در Windows-1251 یا Asmo-708 خواهد بود.

همان صفحه ای که در حال حاضر می خوانید 35 کیلوبایت با رمزگذاری UTF-8 است. و اگر آن را به عنوان مثال به Windows-1251 ترجمه کنید، 26 کیلوبایت اشغال می کند. به هر حال، هنگام مقایسه صفحات، ببینید چقدر خواندن کد در UTF-8 آسان تر است.

هنگام صحبت در مورد "وزن" صفحات وب، باید توجه داشت که عمده این وزن معمولاً کد HTML نیست، بلکه تصاویر است. (و همچنین، احتمالاً، اشیاء دیگر: فیلم های فلش، فایل های جاوا اسکریپت، و غیره) در نتیجه، حتی در مواردی که یک سند UTF-8 بزرگ شده است، این تقریباً در کل داده ها نامحسوس است. به نظر من، ساختن کد "متورم" به میزان چند درصد هزینه ارزانی برای UTF-8 است که ما با آن شروع کردیم.

کسانی که به وزن اهمیت می‌دهند، ابتدا باید ویژگی‌های قدیمی HTML (مانند cellpadding یا valign) و نویسه‌های عام را برای کاراکترهایی که به آن‌ها نیازی ندارند (مانند & mdash ; برای em dash یا & nbsp; برای فضای غیرقابل شکست) حذف کنند. در واقع، گاهی اوقات به حد جنون می رسد - یکی اصرار می کند: "من صفحاتی را در UTF-8 نمی سازم، زیرا آنها را بزرگتر می کند" - و در عین حال کدهایی با ویژگی ها و جایگزین های وحشتناک ایجاد می کند که بدون آنها می تواند پنج برابر کوتاه تر باشد.

زبان های برنامه نویسی سمت سرور و پایگاه داده ها از UTF-8 به خوبی پشتیبانی نمی کنند؟

کسی خواهد گفت: «تا زمانی که ما با صفحات وب استاتیک سروکار داریم، همه اینها خوب است. اما اگر از PHP و MySQL استفاده می کنیم، بهتر است UTF-8 را فراموش کنیم. این هم درست نیست. در دوران باستان، در واقع، برخی از زبان های برنامه نویسی و سیستم های مدیریت پایگاه داده نمی توانستند با UTF-8 کار کنند. اما در حال حاضر تمام زبان های برنامه نویسی مدرن و پایگاه های داده در ارتباط عالی با این رمزگذاری هستند. اما نباید از زبان‌ها و پایگاه‌های اطلاعاتی قدیمی استفاده کنید: هر چه سیستم‌های شما قدیمی‌تر باشند، هک کردن آن‌ها آسان‌تر است.

با این حال، فراموش نکنید که جهان دائما در حال تغییر است. شاید در آینده دلایلی پیش بیاید که ما را مجبور کند UTF-8 را کنار بگذاریم و به کدگذاری حتی پیشرفته‌تر روی بیاوریم. وقتی این اتفاق افتاد حتما به شما اطلاع خواهم داد.