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

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

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

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

byte-order mark (BOM) в HTML

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

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

Питання

Що таке byte-order mark, і що мені необхідно знати про нього при створенні HTML?

Відповідь

Що таке byte-order mark?

На початку Unicode файлу ви можете знайти декілька байтів, що відображають Unicode місце коду U+FEFF ZERO WIDTH NON-BREAKING SPACE (ZWNBSP). Ця комбінація байтів відома, як byte-order mark (BOM).

Коли символ закодований в UTF-16, його 2 або 4 байти можна впорядкувати двома різними способами (little-endian або big-endian). Зображення нижче показує це. byte-order mark вказує, який порядок використовується, так що додатки можуть негайно розшифрувати контент. UTF-16 контент повинен завжди починаються з BOM.

Байти представляють BOM.

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

Що я маю знати про BOM?

Коли BOM використовується на сторінках або редакторах для контенту закодованого в UTF-8, іноді він може представити прогалини або короткі послідовності символів, що мають дивний вигляд (такі як ). Саме тому, за наявності вибору, для сумісності, як правило, краще упустити BOM в UTF-8 контенті.

Більше інформації про те, як виявити і видалити byte-order mark, дивіться Показ проблем, пов'язаних з UTF-8 BOM. Використовуючи Інформатор W3C Інтернаціоналізації ви можете дізнатися де сторінка містить BOM: на початку чи далі в контенті.

Якщо ваш редактор дозволяє вам вказати чи хочете ви BOM при збереженні контенту в UTF-8, то ви завжди повинні говорити ні.

BOM в перевагах на діалоговій панелі.

Якщо ви використовуєте UTF-16. Згідно зі специфікацією HTML5, якщо ваша сторінка закодована як UTF-16, то ви повинні використовувати byte-order mark в HTML. Це буде використовуватися, щоб вказати браузеру кодування сторінки.

Рекомендується використовувати UTF-8, а не UTF-16, якщо ви використовуєте кодування Unicode. Це буде традиційно для більшості людей.

 

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

Потреба використовувати BOM для контенту закодованого в UTF-16 в HTML5 означає, що ви не повинні обслуговувати HTML5 документи позначені як "UTF16BE" або "UTF16LE". Це тому, що Стандарт Unicode говорить, що ви не повинні використовувати BOM, коли текст позначений як одне з тих кодувань. Тому, якщо ви хочете призначити кодування в заголовку HTTP (що не заборонено HTML5 специфікацією), ви повинні використовувати тільки IANA charset назву "UTF-16".

Відзначимо, що це виключно про маркування контенту. Звичайно, фактична послідовність байтів однакова, чи ви позначаєте контент як UTF-16 і додаєте BOM, чи ви позначаєте його як UTF16LE або UTF-16BE.

 

Доречі

byte-order mark також використовується для тексту позначеного як UTF-32, і не повинен використовуватися для тексту позначеного як UTF-32BE або UTF-32LE. Проте, настійливо не рекомендується використовувати UTF-32 для HTML контенту, саме тому ми не згадували його до цих пір.

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

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

Нові джерела

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

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

‎@webi18n

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

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

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

Переклад Англійського контенту від 2010-08-10. Переклад останнього оновлення 2011-04-01 10:00 GMT

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