Прискорююча кнопка n назначена для пропусків при навігації по сторінкам. Пропуск для переходу на початок контента.

Даний документ є перекладом. У випадку будь-яких невідповідностей і помилок остання версія документу англійською мовою повинна розглядатися як офіційна. Першопочаткове авторське право належить W3C, як це вказано нижче.

Перекладач: Alexandr, Art life

s_gotoW3cHome Інтернаціоналізація
 

Вибір і застосування кодування

Аудиторія: шифрувальники XHTML/HTML (використовуючи редактори або скрипти), розробники скриптів (PHP, JSP, і т.д.), шифрувальники CSS, Менеджери веб-проектів, і кожен, хто не знайомий із кодуванням символів і потребує допомоги в питаннях щодо вибору і застосування кодувань символів.

Примітка: Зміни були внесені до написаного англійською мовою оригіналу, так як цей документ був переведений. Дивіться журнал змін.

Питання

Яке кодування символів я повинен використовувати для мого контенту, і як я можу застосувати його?

Ввідна інформація

Контент складається з послідовності символів. Символи представляють букви алфавіту, розділові знаки і т. д. Але контент зберігається в комп'ютері у вигляді послідовності байтів, які мають числові значення. Іноді більше, ніж один байт використовується для представлення одного символу. Як коди, що використовуються в шпигунстві, так і спосіб у який послідовність байтів перетворюється в символи залежить від того, який ключ використовувався для кодування тексту. У цьому контексті, той ключ називається кодуванням символів.

На вибір є багато кодувань символів. Ця стаття дає просту пораду: яке кодування використовувати для вашого контенту, і як його застосувати, тобто як насправді створити документ з цим кодуванням.

Якщо вам потрібно краще зрозуміти, які є символи та кодування символів, дивіться статтю Кодування символів для початківців.

Відповідь

Якщо ви маєте можливість, то використовуйте UTF-8

HTML сторінка може бути тільки в одному кодуванні. Ви не можете кодувати різні частини документу різними кодуваннями.

Таке кодування Unicode, як UTF-8 може підтримувати багато мов і може пристосовувати сторінки і форми до будь-якого змішування цих мов. Його використання також усуває необхідність серверної логіки індивідуально визначати кодування кожної обслуговуваної сторінки або подання кожної вхідної форми. Це значно знижує складність роботи з багатомовним сайтом або додатком.

Кодування Unicode дозволяє змішувати на одній сторінці набагато більше мов, ніж будь-яке інше кодування.

Майже немає перешкод до використання Unicode в ці дні. Справді, в серпні 2010 року Google повідомили, що понад 50% Веб-сайтів в їх вибірці з кількох мільярдів сторінок використовували UTF-8. Додайте до цього ASCII веб-сторінки (оскільки ASCII є підмножиною UTF-8), і цифра сягає близько 70%.

Існують три різних кодування символів Unicode: UTF-8, UTF-16 та UTF-32 (дивіться Набори символів, закодовані набори символів і кодування). З цих трьох, UTF-8 рекомендується для використання для веб-контенту. Насправді в даний час проект специфікації HTML5 говорить "Авторам рекомендується використовувати UTF-8. Програми для перевірки відповідності можуть консультувати авторів по використанню успадкування кодувань. Засоби розробки повинні за умовчанням використовувати UTF-8 для новостворених документів."

Зверніть увагу, зокрема, що всі символи ASCII в кодуванні UTF-8 використовують ті ж самі байти, що й в кодуванні ASCII, що часто допомагає досягнути сумісності та зворотної сумісності.

Підтримка даного кодування, особливо такого, як Unicode, не обов'язково означає, що клієнтський додаток буде коректно відображати текст. Численні скрипти, наприклад, арабський та індійський, вимагають додаткових правил для перетворення послідовності символів в пам'яті у відповідну послідовність символів шрифту для відображення.

Якщо ви не використовуєте Unicode. Виберіть кодування, яке дає максимальну можливість безпосередньо представляти символи і зводить до мінімуму необхідність представляти їх використовуючи екрановані символи.

Якщо у вас є можливість вибрати конкретну мову, скрипт, або групу мов, виберіть кодування, яке найчастіше підтримується, і перевірте, що клієнтські додатки адекватно підтримують обране кодування.

Розглянемо рішення, яке зводить до мінімуму складність при роботі з кількома мовами і скриптами.

Уникайте цих кодувань

Специфікація HTML5 називає кілька кодувань, які ви повинні уникати.

В документах не повинні використовуватися: JIS_C6226-1983, JIS_X0212-1990, HZ-GB-2312, JOHAB (Windows code page 1361), кодування основані на ISO-2022, або кодування основані на EBCDIC. Це тому, що вони дозволяють місцям коду ASCII, відображати такі символи, які не являються символами ASCII, що створює загрозу безпеки.

Документи не повинні використовувати CESU-8, UTF-7, BOCU-1, або SCSU кодування, оскільки вони ніколи не були призначені для Веб-контенту.

Специфікація також не рекомендує використовувати UTF-32.

Застосування кодування до вашого контенту

Як автору контенту вам необхідно перевірити, що ваш редактор або скрипти зберігають текст в кодуванні, яке ви вибрали.

Розробники також повинні переконатися, що різні частини системи можуть взаємодіяти одна з одною, розуміти, які кодування символів використовуються, і підтримувати всі необхідні кодування і символи.

Важливо розуміти, що тільки призначення кодування всередині документу або на сервері за допомогою одного з методів, описаних нижче, як правило, не змінить байтів; вам необхідно зберегти текст у тому кодуванні, щоб застосувати його до вашого контенту. (Призначення тільки допомагає браузеру інтерпретувати послідовності байтів, в яких збережений текст.)

Стаття Налаштування кодування у додатках для Веб розробки консультує як встановити кодування сторінки під час її збереження, для кількох середовищ, що редагуються.

Якщо у вас є можливість, то краще налаштуйте кодування UTF-8 за замовчуванням для нових документів у вашому редакторі. На слідуючому малюнку показано, як ви могли б це зробити в preferences (налаштуваннях) такого редактору, як Dreamweaver.

Нові налаштування DreamWeaver дозволяють вам вказати кодування за умовчанням.

Вам також можливо доведеться перевірити, чи ваш сервер обробляє документи з правильними призначеннями HTTP, так як в іншому випадку він буде визначити цю інформацію з документу (дивіться наступний розділ).

Чому браузер як і раніше не розпізнає кодування?

Скажімо, наприклад, що ви зберегли свої дані як UTF-8. Хоча ви зберегли дані в правильному кодуванні, і навіть якщо ви вказали на сторінці, що її кодування UTF-8, ваш сервер може як і раніше обслуговувати сторінку з супроводжуючим заголовком HTTP, який говорить, що це щось інше.

Будь-яке призначення, в заголовку HTTP замінить інформацію всередині сторінки, що створює проблеми для вашого контенту.

Ви не можете контролювати призначення, які приходять із заголовком HTTP і, можливо, вам доведеться звернутися за допомогою до людей, які керують сервером. З іншого боку є способи за допомогою яких ви можете виправити становище на сервері, якщо у вас обмежений доступ до файлів установки сервера або генерація сторінок за допомогою мов скриптів. Наприклад, дивіться Налаштування HTTP charset параметру для отримання додаткової інформації про те, як змінювати кодування інформації, або локально, для набору файлів на сервері, або для генерованого за допомогою скриптової мови контенту.

Як правило, перш ніж зробити це, вам потрібно перевірити, чи є це насправді проблема чи немає. Ви можете використовувати W3C Internationalization Checker щоб дізнатися, яке кодування символів призначене, якщо нічого, не зазначено в HTTP заголовку. Крім того, стаття Перевірка HTTP заголовків вказує на деякі інші інструменти для перевірки закодованої інформації, переданої сервером.

Розкажіть нам про те, що Ви думаєте.

Підписатися на RSS джерело.

Нові джерела

Новини головної сторінки

Twitter (Новини головної сторінки)

‎@webi18n

Додаткові матеріали

Автор: Richard Ishida, W3C. Перекладач: Alexandr, Art life.

Допустимий XHTML 1.0!
Допустимий CSS!
Кодування UTF-8!

Переклад Англійського контенту від 2010-08-12. Переклад останнього оновлення 2011-03-18 23:00 GMT

Для перегляду історії внесення змін до перекладу натисність qa-choosing-encodings в блоге i18n.