Опубликован: 19.05.2006 | Уровень: для всех | Доступ: платный
Лекция 5:

Представление документа HTML

< Лекция 4 || Лекция 5: 12 || Лекция 6 >
Аннотация: В этой главе мы обсудим, как документы HTML отображаются на компьютере и в Internet. В разделе "Кодовая страница" документа обсуждается вопрос о том, как абстрактные символы могут быть частью документа HTML. Символы включают буквы латиницы, кириллицы, китайские символы "водяные знаки", и т.д. В разделе "Виды кодировки" обсуждается представление символов в файле или при пересылке в Internet. Поскольку некоторые кодировки не могут прямо представить все символы, которые автор хочет включить в документ, HTML предлагает механизм, называемый ссылки-мнемоники, для изображения любых символов. Поскольку существует огромное количество символов в языках различных народов и большое разнообразие способов представления этих символов, нужен особый подход для того, чтобы документы были доступны для чтения в любом браузере в любой точке земного шара.

Кодовая страница документа

С целью улучшения взаимодействия, SGML требует, чтобы каждое приложение (приложение HTML - в том числе) специфицировало свой набор символов. Набор символов (кодовая страница) состоит из:

  • "Репертуара": набора абстрактных символов, таких как латинская буква "A", русская буква "И", китайские "водяные знаки" и т.д.
  • Позиции символа: набора цифровых ссылок на символы в " репертуаре ".

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

Набор символов ASCII недостаточен для глобальных информационных систем, таких как Web, поэтому HTML использует более полный набор символов, называемый Universal Character Set (UCS)/Универсальный Набор символов, определённый в документе [ISO10646]. Этот стандарт определяет репертуары тысяч наборов символов, используемых во всём мире.

Набор символов, определённый в [ISO10646], это символ-символ эквивалент Юникода ([UNICODE]). Оба этих стандарта время от времени дополняются новыми символами, и по этим поправкам нужно постоянно консультироваться на соответствующих Web-сайтах. В текущей спецификации ISO10646 использован для определения набора символов, в то время как UNICODE зарезервирован для ссылок на двунаправленный текстовый алгоритм.

Одного набора символов, однако, недостаточно для того, чтобы браузеры пользователя могли корректно интерпретировать документы HTML, так как они обычно кодируются как последовательность байтов в файле во время передачи по сети. Браузер пользователя должен также "знать" специфическую кодировку, используемую для трансформации документа в поток байтов.

Кодировка

То, что в этой спецификации называется кодировкой символов, известно под различными названиями в других спецификациях (что может иногда смущать). Однако общее понимание - одно во всей сети Internet.

Заголовки протоколов (protocol headers), атрибуты и параметры, относящиеся к кодировке символов, используют один термин - "charset" и одни и те же значения из регистрации [IANA] (смотри полный список в [CHARSETS]).

Параметр " charset " идентифицирует кодировку символов, которая представляет собой метод конвертации последовательности байтов в последовательность символов. Эта конвертация соответствует, по своей природе, схеме деятельности Web: серверы посылают документы HTML браузерам пользователей как поток байтов, браузеры пользователей интерпретируют его в последовательность символов.

Методы конвертации варьируются от простых один-за-другим до сложных схем переключения и алгоритмов.

Простая техника кодирования, один-байт-один-символ, недостаточна для использования символов, не входящих в "репертуар" [ISO10646].

Есть несколько различных кодировок, начиная с частичных кодировок с использованием [ISO10646], и до кодировок полного набора символов (как UCS-4).

Выбор кодировки

Средства создания документов (например, текстовые редакторы) могут кодировать документы HTML по своему усмотрению, и это зависит в основном от соглашений, используемых разработчиками программ. Эти программы для создания документов используют любую подходящую кодировку, которая отображает большую часть нужных символов, корректно обозначая эту кодировку. Отдельные символы, не входящие в соответствующую кодировку, могут быть вставлены по ссылке. Это всегда имеет отношение к набору символов документа, а не к кодировке.

Серверы и proxy-серверы могут изменять кодировку символов (это называется transcoding ) "на ходу", чтобы принять запрос пользовательского браузера (смотри раздел 14.2 в [RFC2616], заголовок запроса "Accept-Charset" HTTP). Серверы и прокси-серверы не должны обязательно обслуживать документ в той кодировке, которая покрывает весь набор символов этого документа.

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

Эта спецификация не предписывает, какие кодировки браузер должен поддерживать.

Соответствие браузеров. Браузеры должны отвечать отображению, по ISO 10646, всех символов в любой кодировке, которые ими распознаются (или они должны действовать, как если бы они распознавали их).

Замечания по специальной кодировке

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

Кроме того, для того, чтобы увеличить шансы правильной интерпретации документа, рекомендуется, чтобы документ, передаваемый как UTF-16, всегда начинался символом ZERO-WIDTH NON-BREAKING SPACE (шестнадцатеричная FEFF, называемая также Byte Order Mark (BOM)), которая при перестановке байтов становится FFFE, символом, гарантирующим, что он никогда не будет установлен. Таким образом, браузер пользователя, получив FFFE как первый байт текста, сможет определить, что этот байт зарезервирован для напоминания о кодировке UTF-16.

UTF-1 формат трансформации [ISO10646] (зарегистрированный IANA как ISO-10646-UTF-1), не должен использоваться.

Об ISO 8859-8 и двунаправленном алгоритме см. раздел "Информация о языке и направлении текста" .

Определение кодировки

Как сервер определяет кодировку документа? Некоторые серверы проверяют несколько первых байтов документа или проверяют информацию в базе данных об известных файлах и кодировках. Многие современные серверы дают Web-мастеру больше возможностей для контроля за конфигурацией наборов символов. Web-мастера должны использовать эти механизмы для передачи сведений "charset" всегда, когда это возможно, и не обозначать документ неправильным значением параметра " charset ".

Как браузер пользователя распознаёт кодировку документа?

Эту информацию должен предоставлять сервер. Прямой путь для этого - использование параметра " charset " заголовочного поля " Content-Type " протокола HTTP ([RFC2616], разделы 3.4 и 14.17). Например, следующий заголовок HTTP объявляет кодировку EUC-JP:

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

Пожалуйста, просмотрите определение text/html в разделе "Соответствие: требования и рекомендации" .

Протокол HTTP ([RFC2616], раздел 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-значащие байтовые позиции для символов ASCII (хотя бы до того, как элемент META уже разобран). Объявление META должно появиться в элементе HEAD как можно раньше.

Для случаев, когда ни HTTP-протокол, ни элемент META не дают информации о кодировке страницы, HTML предоставляет атрибут charset в некоторых элементах. Комбинируя эти возможности, автор повышает шансы того, что браузер пользователя, получив документ, правильно распознает кодировку страницы.

Суммируя вышесказанное: браузеры, соответствующие требованиям, должны соблюдать следующие приоритеты при определении кодировки документа (от высшего приоритета к низшему):

  1. HTTP параметр " charset " в поле " Content-Type ".
  2. Объявление META с " http-equiv ", установленным в " Content-Type ", и значением, установленным в " charset ".
  3. Атрибут charset, установленный в элементе, обозначающем внешний ресурс.

В дополнение к этому списку приоритетов, браузер может использовать heuristics и пользовательские установки. Например, многие браузеры используют heuristics для различения кодировок японского текста. Также браузеры обычно используют локальные кодировки по умолчанию, определяемые пользователем, которые применяются при отсутствии других указателей.

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

Примечание. Если в определённом приложении нужно обратиться к набору символов вне [ISO10646], символы должны быть выделены в отдельное пространство (private zone), чтобы исключить конфликты с будущими версиями стандарта. Однако, это крайне не рекомендуется из соображений переносимости.
< Лекция 4 || Лекция 5: 12 || Лекция 6 >
Ирина Кириллова
Ирина Кириллова

Нажимаю на ссылку на дополнительный материал и дополнение к информации-меня возвращает на первую страницу лекции. Подскажите, что делать? Или дополнительный материал платный?

Евгений Летенков
Евгений Летенков
Россия, Москва, РУДН, 2005
Иван Бокарёв
Иван Бокарёв
Австрия