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

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

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

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

Для забезпечення можливість взаємодії мереж 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 при типовому обміні - закодовані як сукупність електронних даних у файлі або під час передачі по мережі. Агенти користувача повинні також знати кодування символів. які використовувалися для перетворення потоку символів документа в потік байт.

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

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

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

Сервери та проксі можуть змінювати кодування символів (що називається транскодування) на льоту для виконання запитів агентів користувачів (див. Розділ 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 як ISO10646-UTF-1). Інформацію про ISO 8859-8 і двунаправленном алгоритмі см. В розділі двобічної і кодування символів.

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

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

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

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

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

Примітка. Якщо в якомусь додатку потрібно використовувати символи, що не входять в кодування [ISO10646]. цим символам повинна бути призначена персональна зона щоб уникнути конфліктів зі справжньою або майбутніми версіями стандарту. Однак це не рекомендується з міркувань переносимості.

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

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

Примітка. HTML забезпечує інші способи представлення символів, зокрема, вбудовані зображення.

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

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

Числові посилання на символи вказують код символу в наборі символів документа. Числові посилання на символи можуть також приймати дві форми:
  • Синтаксис "#D;", де D - десяткове число, вказує символ Unicode з десятковим номером D.
  • Синтаксис "#xH;" або "#XH;", де H - шістнадцяткове число, вказує на символ Unicode з шістнадцятковим номером H. Шістнадцяткові числові посилання враховують регістр.

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

  • # 229; (Десяткове) представляє букву "a" з гуртком зверху (використовувану, наприклад, в норвезькому мовою).
  • # XE5; (Шістнадцяткове) представляє той же символ.
  • # Xe5; (Шістнадцяткове) представляє той же символ.
  • # 1048; (Десяткове) представляє кириличну заголовну букву "I".
  • # X6C34; (Шістнадцяткове) представляє китайський ієрогліф "вода".

Примітка. Хоча шестнадцатеричное подання не визначено в [ISO8879]. воно очікується в новій версії, як описано в [WEBSGML]. Ця угода особливо корисно, оскільки стандарти символів зазвичай використовують шістнадцяткові уявлення.

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

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

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

Чотири посилання потрібно згадати спеціально, оскільки вони часто використовуються для вказівки спеціальних символів:
  • "Lt;" представляє знак <.
  • "Gt;" представляє знак>.
  • "-" представляє символ .
  • "" Представляє знак ".

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

Схожі статті