Электронная библиотека
Программисту веб-дизайнеру
Другие материалы
Спецификация HTML 4.01, рекомендации W3C от 24 декабря 1999 года
предыдущий
следующий содержание
элементы атрибуты индекс
5 Представление документа HTML
Содержание
В этой главе мы обсудим, как документы HTML отображаются на компьютере и в Internet.
В разделе кодовая страница документа обсуждается вопрос о том, как абстрактные символы могут быть частью документа HTML. Символы включают буквы латиницы, кириллицы, китайские символы "водяные знаки", и т.д.
В разделе виды кодировки обсуждается представление символов в файле или при пересылке в Internet. Поскольку некоторые кодировки не могут прямо представить все символы, которые автор хочет включить в документ, HTML предлагает механизм, называемый ссылки-мнемоники, для изображения любых символов.
Поскольку существует огромное количество символов в языках различных народов и большое разнообразие способов представления этих символов, нужен особый подход для того, чтобы документы были доступны для чтения в любом браузере в любой точке земного шара.
5.1 Кодовая страница документа
С целью улучшения взаимодействия, 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".
Примечание. Если в определенном приложении нужно обратиться к набору символов вне [ISO10646], символы должны быть выделены в отдельное пространство (private zone), чтобы исключить конфликты с будущими версиями стандарта. Однако, это крайне не рекомендуется из соображений переносимости.
5.3 Мнемоники (символы по ссылке, по псевдониму)
Конкретная кодировка может не давать возможность отобразить все символы набора символов документа. Для таких кодировок, или если конфигурация "железа" или программного обеспечения не позволяют пользователю непосредственно вводить некоторые символы, авторы могут использовать SGML - ссылки на символы. Ссылки на символы - это механизм для ввода любых символов, не зависящий от кодового набора документа.
Ссылки на символ (мнемоники) могут быть двух видов:
Мнемоники внутри комментариев не имеют специального значения: это только лишь данные комментариев.
Примечание. HTML предоставляет другие возможности для представления символьных данных, в особенности - встроенные изображения\inline images.
Примечание. В SGML возможно отсутствие конечного символа ";" после ссылки-мнемоники в некоторых случаях (например, перед line break или непосредственно перед тегом). В других условиях это символ не может быть опущен (например, в середине слова). Мы настоятельно советуем использовать ";" во всех случаях, чтобы исключить проблемы с браузерами пользователей.
5.3.1 Цифровые мнемоники
Цифровые ссылки-мнемоники на символы определяют кодовую позицию символа в символьном наборе документа. Цифровые мнемоники бывают двух видов:
Вот несколько примеров цифровых мнемоник:
Примечание. Хотя 16-ное представление не определено в [ISO8879], это ожидается при пересмотре, как описано в [WEBSGML]. Это соглашение особенно актуально, пока стандарты символов используют 16-ные представления.
5.3.2 Символьные ссылки-мнемоники (по псевдониму)
Чтобы предоставить авторам более интуитивный способ ссылки на символы в символьном наборе документа, HTML предлагает символьные ссылки-мнемоники. Символьные мнемоники используют псевдонимы, так что авторы могут не запоминать кодовую позицию. Например, символьную мнемонику å ссылающуюся на "a" с кружком сверху , "å" запомнить легче, чем å.
HTML 4 не определяет символьные мнемоники для всех символов кодового набора. В частности, нет символьной мнемоники для русской заглавной "И". Пожалуйста, просмотрите полный список символьных мнемоник, определенных в HTML 4.
Символьные мнемоники чувствительны к регистру. Так, Å ссылается на другую букву (A с кружком в верхнем регистре), а не на å (а с кружком в нижнем регистре).
Четыре символьные мнемоники должны быть упомянуты отдельно, так как они часто используются в определенных escape-последовательностях:
Автор, желающий использовать символ "<" в тексте, должен записать "<" (ASCII десятичная 60), чтобы избежать возможных конфликтов с началом тега (стартовый ограничитель тега). Так же автор должен использовать и ">" (ASCII десятеричная 62) вместо ">", чтобы избежать конфликтов со старыми браузерами, которые некорректно распознают это как конец тега (закрывающий ограничитель тега), если он появляется в значении атрибута в кавычках.
Автор должен использовать "&" (ASCII десятичное 38) вместо "&" во избежание конфликтов с обозначением начала ссылки. Автор также должен употреблять "&" в значениях атрибутов, пока символьные мнемоники допускаются внутри значений атрибутов CDATA.
Некоторые авторы используют символьную мнемонику """ для кодирования появление двойных кавычек ("), поскольку этот символ используется как ограничитель в значениях атрибутов.
Браузер может не отображать корректно все символы в документе. Например, если у пользователя нет соответствующего шрифта, символ имеет значение, которое отсутствует во внутренней кодировке браузера, и т.д.
Поэтому вид документа во многих случаях становится непредсказуемым. В зависимости от реализации, неотображаемые символы также могут обрабатываться системой дисплея, а не самой программой. В связи с этим, мы рекомендуем следующие действия в отношении браузеров пользователей:
предыдущий следующий содержание элементы атрибуты индекс