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

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

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

Каждый документ 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 в некоторых элементах. Комбинируя эти возможности, автор повышает шансы того, что браузер пользователя, получив документ, правильно распознает кодировку страницы.

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

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

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

Мнемоники (символы по ссылке, по псевдониму)

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

Ссылки на символ (мнемоники) могут быть двух видов:

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

Цифровые мнемоники

Цифровые ссылки-мнемоники на символы определяют кодовую позицию символа в символьном наборе документа. Цифровые мнемоники бывают двух видов:

Вот несколько примеров цифровых мнемоник:

Символьные ссылки-мнемоники (по псевдониму)

Чтобы предоставить авторам более интуитивный способ ссылки на символы в символьном наборе документа, HTML предлагает символьные ссылки-мнемоники. Символьные мнемоники используют псевдонимы, так что авторы могут не запоминать кодовую позицию. Например, символьную мнемонику aring; ссылающуюся на "a" с кружком сверху , " aring; " запомнить легче, чем #229;.

HTML 4 не определяет символьные мнемоники для всех символов кодового набора. В частности, нет символьной мнемоники для русской заглавной "И". Пожалуйста, просмотрите полный список символьных мнемоник, определённых в HTML 4.

Символьные мнемоники чувствительны к регистру. Так, Aring; ссылается на другую букву (A с кружком в верхнем регистре ), а не на aring; (а с кружком в нижнем регистре ).

Четыре символьные мнемоники должны быть упомянуты отдельно, так как они часто используются в определённых escape-последовательностях:

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

Автор должен использовать " amp; " (ASCII десятичное 38) вместо " " во избежание конфликтов с обозначением начала ссылки. Автор также должен употреблять " amp; " в значениях атрибутов, пока символьные мнемоники допускаются внутри значений атрибутов CDATA.

Некоторые авторы используют символьную мнемонику " quot; " для кодирования двойных кавычек ( " ), поскольку этот символ используется как ограничитель в значениях атрибутов.

Неотображаемые символы

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

Поэтому вид документа во многих случаях становится непредсказуемым. В зависимости от реализации, неотображаемые символы также могут обрабатываться системой дисплея, а не самой программой. В связи с этим, мы рекомендуем следующие действия в отношении браузеров пользователей: