5 Подання документа в форматі HTML

В цьому розділі обговорюється, як документи в форматі HTML представляються на комп'ютері і в Інтернет.

Розділ набір символів документа відноситься до питання про абстрактні символи, які можуть входити до складу документа в форматі HTML. У число цих символів входять латинська буква "A", кирилична буква "I", китайський ієрогліф "вода" і т.д.

Розділ кодування символів відноситься до питання про те, як ці символи можуть бути представлені у файлі або під час передачі по Інтернет. Оскільки деякі кодування можуть прямо не представляти всі символи, які автор захоче включити в документ, HTML пропонує інші механізми, звані посиланнями на символи , для посилання на будь-який символ.

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

5.1 Набір символів документа

Для забезпечення можливість взаємодії мереж SGML вимагає від кожного додатка (включаючи HTML) вказівки набору символів документа. Документ включає:

• Репертуар : Набір абстрактних символів, , таких як латинська буква "A", кирилична буква "I", китайський ієрогліф "вода" і т.д.
• Коди : Набір цілочисельних посилань на символи репертуару.

Кожен документ SGML (включаючи кожний документ HTML) - це послідовність символів з репертуару. Комп'ютерні системи ідентифікують кожен символ по його коду; наприклад, в наборі символів ASCII коди 65, 66 і 67 означають символи 'A', 'B' і 'C' відповідно.

Набору символів ASCII недостатньо для такої глобальної інформаційної системи, як Web, тому HTML використовує більш повний набір символів, званий Універсальним набором символів (Universal Character Set - UCS), і певний в [ISO10646]. Цей стандарт визначає репертуар тисяч символів, що використовуються у всьому світі.

Набір символів, визначений в [ISO10646] - це посимвольного еквівалент Unicode 2.0 ( [UNICODE] ). Обидва ці стандарту час від часу оновлюються, поповнюються новими символами, про зміни слід дізнаватися на відповідних серверах Web. У цій специфікації ISO / IEC-10646 або Unicode означають цей самий набір символів. Однак в специфікації HTML Unicode також згадується при обговоренні інших питань, таких як алгоритм двунаправленного тексту.

Набору символів документа, однак, недостатньо, щоб агенти користувачів могли коректно інтерпретувати документи HTML при типовому обміні - закодовані як сукупність електронних даних у файлі або під час передачі по мережі. Агенти користувача повинні також знати кодування символів , які використовувалися для перетворення потоку символів документа в потік байт.

5.2 Кодування символів

Кодування символів в цій специфікації мають інші назви в інших специфікаціях (що може викликати деяку плутанину). Однак це поняття в Інтернет означає приблизно одне й те саме. Одне і те ж ім'я - "charset - набір символів" - використовується в заголовках протоколів, атрибутах і параметрах, які посилаються на символи і використовують одні і ті ж значення з [IANA] реєстру (повний список див. В розділі [CHARSETS] ).

Параметр "charset" ідентифікує кодування символів, яка є способом перетворення послідовності байт в послідовність символів. Це перетворення природно вписується в схему діяльності Web: сервери відправляють документи HTML агентам користувачів у вигляді потоку байт; агенти користувачів інтерпретують їх як послідовність символів. Способи перетворення можуть змінюватися від простого відповідності один до одного до складних схем або алгоритмів перемикання.

Простий техніки кодування "один байт - один символ" недостатньо для текстових рядків з таким широким репертуаром символів, як [ISO10646] . Крім кодувань всього набору символів (наприклад, UCS-4), є деякі інші кодування частин [ISO10646] .

5.2.1 Вибір кодування

Засоби розробки (наприклад, текстові редактори) можуть кодувати документи HTML в кодуваннях за своїм вибором, і цей вибір істотно залежить від угод, використовуваних системним програмним забезпеченням. Ці кошти можуть використовувати будь-яку зручну систему кодування, що включає більшість символів в документі, за умови, що кодування коректно позначена. Деякі символи, не включені в цю систему кодування, можна представити за допомогою посилань на символи . Це завжди відноситься до набору символів документа, а не до кодування символів.

Сервери та проксі можуть змінювати кодування символів (що називається транскодування) на льоту для виконання запитів агентів користувачів (див. Розділ 14.2 [RFC2068] , заголовок запиту HTTP "Accept-Charset"). Сервери та проксі не повинні обслуговувати документ у кодуванні, що включає весь набір символів документа.

Широко використовуються в Web кодування - ISO-8859-1 (також називається "Latin-1"; використовується для більшості західноєвропейських мов), ISO-8859-5 (з підтримкою кирилиці), SHIFT_JIS (японська кодування), EUC-JP (ще одна японська кодування) і UTF-8 (варіант кодування ISO 10646, який використовує різну кількість байт для різних символів). Назви кодувань символів не враховують регістр, так що, наприклад, "SHIFT_JIS", "Shift_JIS" і "shift_jis" еквівалентні.

Ця специфікація не визначає, які кодування символів повинен підтримувати агент користувача.

Відповідні агенти користувачів повинні коректно відображати в Unicode всі символи в будь-яких кодуваннях, які вони можуть розпізнавати.

Зауваження про певні кодуваннях  

Коли текст HTML передається в UTF-16 (charset = UTF-16), текстові дані повинні передаватися в мережевому порядку байт ( "big-endian", байт вищого порядку - перший) відповідно до [ISO10646] , розділ 6.3 і [UNICODE] , положення C3, сторінка 3-1.

Більш того, щоб підвищити ймовірність правильної інтерпретації, рекомендується передавати документи UTF-16, завжди починається зі знаку неподільні ПРОБЕЛ НУЛЬОВИЙ ШИРИНИ (шістнадцятковий код FEFF, також називається Міткою порядку байтів (Byte Order Mark - BOM)), який при зверненні байт стає шістнадцятковим FFFE , ніколи не призначається символом. Таким чином, агент користувача, який отримав шістнадцятковий код FFFE в якості перших байтів тексту знатиме, що в іншому тексті байти потрібно звернути.

Не слід використовувати формат трансформації UTF-1 [ISO10646] (зареєстрований IANA як ISO-10646-UTF-1). Інформацію про ISO 8859-8 і двунаправленном алгоритмі см. В розділі двобічної і кодування символів .

5.2.2 Зазначення кодування символів

Як сервер визначає, яка кодування символів застосовується в документі? Деякі сервери перевіряють перші кілька байт документа або звіряються з базою даних відомих файлів і кодувань. Багато сучасні сервери Web надають адміністраторам більше можливостей управління конфігурацією набору символів, ніж старі сервери. Адміністратори серверів Web повинні при можливості використовувати такі механізми для відправки параметра "charset", але повинні подбати про те, щоб не встановити для документів помилкове значення параметра "charset".

Як агент користувача дізнається, яка використовувалася кодування символів? Цю інформацію надає сервер. Кращим способом проінформувати агента користувача про кодування символів документа - використовувати параметр "charset" в поле заголовка "Content-Type" протоколу HTTP ( [RFC2068] , розділи 3.4 і 14.18) Наприклад, наступний заголовок HTTP оголошує, що використовується кодування EUC-JP:

 Content-Type: text / html;  charset = EUC-JP

Визначення text / html см. В розділі відповідність .

Протокол HTTP ( [RFC2068] , розділ 3.7.1) вважає ISO-8859-1 кодуванням символів за замовчуванням, якщо параметр "charset" в поле заголовка "Content-Type" відсутня. На практиці ця рекомендація марна, оскільки деякі сервери не дозволяють відправляти параметр "charset", а деякі можуть не бути налаштовані для відправки цього параметр. Тому агенти користувачів не повинні припускати ніякого значення параметра "charset".

Для вказівки обмежень сервера або конфігурації документи HTML можуть включати явну інформацію про кодування символів документа; для надання такої інформації агентам користувача може використовуватися елемент META .

Наприклад, щоб вказати, що кодуванням символів у поточному документі є "EUC-JP", включіть таке оголошення META :

 <META http-equiv = "Content-Type" content = "text / html; charset = EUC-JP">

Оголошення META повинне використовуватися, тільки якщо кодування символів впорядкована так, що символи ASCII стоять на своєму місці (по крайней мере, при розборі елемента META ). Оголошення META повинні бути в тексті якомога раніше в елементі HEAD .

У випадках, коли ні протокол HTTP, ні елемент META не надають інформації про кодування документа, HTML надає атрибут charset для деяких елементів. Об'єднавши всі ці механізми, автор може істотно підвищити шанси на те, що, коли користувач завантажує ресурс, агент користувача розпізнає кодування символів.

Підводячи підсумки, відповідні агенти користувачів при визначенні кодування символів документа (від вищого пріоритету до нижчого) повинні керуватися наступними джерелами відповідно до пріоритетом :

1. Параметр "charset" протоколу HTTP в поле "Content-Type".
2. Оголошення META , в якому для "http-equiv" встановлено "Content-Type" і встановлено значення для "charset".
3. Атрибут charset встановлюється на елемент, що позначає зовнішній ресурс.

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

Агенти користувачів можуть забезпечувати механізм, що дозволяє користувачам змінювати некоректну інформацію про набір символів. Однак якщо агент користувача пропонує такий механізм, він повинен пропонувати його тільки для перегляду, а не для зміни, щоб уникнути створення Web-сторінок з некоректним параметром "charset".

5.3 Посилання на символи

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

Посилання на символи в HTML можуть приймати дві форми:

• Числові посилання на символи (десяткові або шістнадцяткові).
• Посилання на комбінації символів.

Посилання на символи в коментарі не мають значення; вони є тільки даними коментарів.

5.3.1 Числові посилання на символи

Числові посилання на символи вказують код символу в наборі символів документа. Числові посилання на символи можуть також приймати дві форми:

• Синтаксис "& # D;", де D - десяткове число, вказує символ Unicode з десятковим номером D.
• Синтаксис "& # x H;" або "& # X H;", де H - шістнадцяткове число, вказує на символ Unicode з шістнадцятковим номером H. Шістнадцятиричні числові посилання враховують регістр.

Ось деякі приклади числових посилань на символи:

5.3.2 Комбінації посилань на символи

Щоб дати авторам більш ініціативний спосіб використання символів, HTML пропонує набір character entity references. Комбінації посилань на символи використовують символічні імена, так що авторам не доведеться запам'ятовувати коди. Наприклад, комбінація & aring; позначає символ "a" нижнього регістра з гуртком зверху; "& Aring;" легше запам'ятати, ніж & # 229 ;.

HTML 4.0 не визначає character entity reference для кожного символу. Наприклад, для кириличної літери "I" немає character entity reference. Див. Повний список посилань на символи, певні в HTML 4.0.

Комбінації посилань на символи враховують регістр. Так, & Aring; вказує на інший символ (A з гуртком верхнього регістру), а не на & aring; (A з гуртком нижнього регістру).

Чотири посилання потрібно згадати спеціально, оскільки вони часто використовуються для вказівки спеціальних символів:

• "& Lt;" представляє знак <.
• "& Gt;" представляє знак>.
• "& Amp;" представляє символ &.
• "& Quot; представляє знак".

Автори, які хочуть помістити в текст символ "<", повинні використовувати посилання "& lt;" (Десятковий код ASCII 60), щоб уникнути можливої ​​плутанини з початком тега (відкриває роздільник початкового тега). Точно так само слід використовувати "& gt;" (Десятковий код ASCII 62) замість ">", щоб уникнути проблем зі старими версіями агентів користувачів, некоректно приймають їх за закінчення тега (закриває роздільник тега).

Авторам слід використовувати "& amp;" (Десятковий код ASCII 38) замість "&" щоб уникнути плутанини з посиланнями на символи (відкриває роздільник entity reference). Авторам також слід використовувати "& amp;" в значеннях атрибутів, оскільки посилання на символи усередині значень атрибута CDATA дозволені.

Деякі автори використовують character entity reference "& quot;" для кодування примірників подвійних лапок ( "), оскільки цей символ може використовуватися для поділу значень атрибутів.

5.4 не відображаються символи

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

Оскільки в цьому випадку є кілька варіантів, цей документ не наказує певної тактики. Залежно від застосування недруковані символи можуть також оброблятися додатковою системою відображення, а не самим додатком. У разі більш складного поведінки, наприклад, налаштованого для певного сценарію або мови, рекомендуємо наступне поведінка для агентів користувачів:

1. Прийміть явно видимий, але непомітний механізм для попередження користувача про відсутніх ресурсах.
2. Якщо відсутні символи представляються в іншому числовому поданні, використовуйте шестнадцатеричную (НЕ десяткову) форму, оскільки ця форма використовується в стандартах наборів символів.