Содержание
В этой главе мы обсудим то, как документы HTML представлены в ЭВМ и в Интернет.
Раздел "набор символов документа" раскрывает вопрос, как абстрактные символы могут быть частью документа HTML. Символы включают латинскую букву "A", букву "Й" из Кириллицы, Китайский символ означающий "Вода" и т.п.
Раздел "символьные кодировки" раскрывает вопрос, как те же самые символы могут быть представлены в файле или при их передаче через Интернет. Так как несколько символьных кодировок не в состоянии непосредственно представить все символы, которые авторы могут пожелать включить в свои документы, HTML предлагает механизмы, называемые "символьными ссылками", для организации ссылок на любой символ.
Так как в человеческих языках существует огромное множество символов и обилие способов представления этих символов, следует подобрать подходящий способ, таким образом, чтобы документы могли бы быть поняты средствами просмотра в любой точке Земного шара.
В целях способствования возможности взаимодействия, SGML требует, чтобы каждое приложение (включая HTML), описывало свой "набор символов документа". Набор символов документа состоит из:
Каждый документ 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" определяет "символьную кодировку", которая является методом конвертирования последовательности байт в последовательность символов. Эта конверсия естественным образом подходит к схеме активности Сети: серверы посылают документы HTML средствам просмотра в виде потока байт; средства просмотра интерпретирует их как последовательность символов. Метод конверсии может простираться от простого соответствия "один к одному" до комплексного переключения схем или алгоритмов.
Простая технология кодирования "один байт -- один символ" не достаточна для текстовых строк относительно символьного репертуара описанного в [ISO10646]. Имеется несколько различных кодировок, являющихся частью [ISO10646] в дополнении к кодировкам вхождений набора символов (таких как UCS-4).
Авторские инструменты (например, текстовые процессоры) могут кодировать документы HTML в символьных кодировках по их выбору, и выбор, в значительной степени, зависит от соглашений, используемых системным программным обеспечением. Эти инструменты могут применяться в любых удобных кодировках, которые "перекрывают" большинство символов, содержащихся в документе, предусмотренные кодировки корректно отмечены. Случайные символы, которые выпадают из конкретной кодировки, все равно могут быть представлены символьными ссылками. Последние всегда ссылаются на алфавит документа, а не на символьную кодировку.
Cерверы и прокси- серверы могут изменять кодировку документа на лету (это называется перекодировкой), встречая запросы от средств просмотра (смотрите раздел 14.2 в [RFC2068], заголовок "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" полностью эквивалентные записи.
Данная спецификация не предписывает, какие кодировки должны поддерживаться средством просмотра.
Согласующиеся средства просмотра должны корректно отображать в Unicode все символы в любой символьной кодировке, которые они (средства) распознают (или должны вести себя так, как будто они их распознают).
Когда текст HTML передается в UTF-16 (charset=UTF-16), текстовые данные должны передаваться в "сетевом байтовом порядке" ("big-endian", байт наивысшего порядка передается первым), в соответствии с разделом 6.3 в [ISO10646], и пунктом С3 на странице 3-1 в [UNICODE].
Кроме того, для увеличения шансов корректной интерпретации, рекомендуется документы, которые передаются в кодировке UTF-16, всегда начинать с символа "Не Прерывающего Пробела, Нулевой Длины" ("ZERO-WIDTH NON-BREAKING SPACE", шестнадцатеричный код "FEFF", также называемый "Метка порядка байта", "Byte Order Mark", "BOM") который, когда значение реверсивного байта становится равным шестнадцатеричному коду "FFFE", гарантирует, что символ никогда не будет назначен. Таким образом, средство просмотра, принимающее первый байт текста с шестнадцатеричным значением "FFFE", будет знать, какие байты реверсированы в оставшемся тексте.
Не следует использовать трансформацию формата UTF-1 описанного в [ISO10646] (зарегистрированного IANA как ISO-10646-UTF-1). Дополнительную информацию относительно "ISO 8859-8" и двунаправленных алгоритмов, смотрите раздел "двунаправленность и символьные кодировки".
Как сервер может определить, какая символьная кодировка применима для документов данного сервера? Некоторые серверы просматривают несколько первых байт документа, или проверяют базу данных известных файлов и кодировок. Множество современных серверов дают Web- мастерам больше возможностей управлять конфигурацией кодировок, чем это позволяют старые серверы. Web- мастерам следует использовать эти механизмы для высылки параметра "charset" всякий раз, когда это возможно, однако следует быть осторожным и не идентифицировать документы с неправильным значением параметра "charset".
Как средство просмотра может узнать, какая символьная кодировка используется? Серверу следует предоставлять эту информацию. Наиболее простой путь для сервера -- информировать средство просмотра о символьной кодировке документа, состоит в использовании параметра "charset" в поле "Content-Type" заголовка протокола HTTP ([RFC2068], разделы 3.4 и 14.18). Вот пример заголовка, объявляющего символьную кодировку "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 для нескольких элементов. Объединением этих механизмов автор может в значительной мере улучшить возможности, в случаях, когда пользователь отыскивает ресурс, средство просмотра сможет распознавать его символьную кодировку.
В заключение: согласующиеся средства просмотра должны соблюдать нижеприведенные приоритеты при детерминировании символьной кодировки документа (приоритеты указаны от высшего -- к низшему):
В дополнение к этому списку приоритетов, средства просмотра могут использовать эвристические и пользовательские установки. Например, множество средств просмотра используют эвристику для различения различных кодировок, используемых в Японских текстах. Также, средства просмотра, как правило, имеют определяемые пользователем локальные символьные кодировки по умолчанию, которые они применяют при отсутствии других указателей.
Средства просмотра могут предоставлять механизмы, которые позволяют пользователям отменять неправильную информацию "charset". Однако если средство просмотра предоставляет подобный механизм, оно должно предлагать его только для отображения, а не для редактирования, во избежание создания Web- страницы, помеченной некорректным параметром "charset".
Примечание. Если, для специфического приложения, является необходимым ссылаться на символы, лежащие вне [ISO10646], символы должны быть приписаны частной зоне, во избежание конфликтов между представленной или будущими версиями стандарта. Однако это очень не желательно по причинам портативности.
Конкретные символьные кодировки, могут не дать возможности, представить все символы набора символов документа. Для подобных кодировок, или когда либо программная, либо аппаратная конфигурация не позволяют пользователям непосредственно вводить некоторые символы документа, могут быть использованы символьные ссылки SGML. Символьные ссылки являются независимым от символьной кодировки механизмом для ввода любого символа из набора символов документа.
Символьные ссылки в HTML могут появляться в двух видах:
Символьные ссылки в комментариях не имеют особого значения, это всего лишь данные комментариев.
Примечание. HTML предоставляет другие пути для представления символьных данных, в частности последовательные изображения.
Примечание. В SGML, в некоторых случаях, допускается устранение заключительного символа ";" после символьной ссылки (например у разрыва строки или непосредственно перед тегом). В других обстоятельствах она не может быть устранена (например, в середине слова). Мы настоятельно предлагаем использование ";" во всех случаях во избежание проблем со средствами просмотра, которые требуют, что бы этот символ был всегда представлен.
Числовые символьные ссылки определяют кодовую позицию символа в наборе символов документа. Числовые символьные ссылки могут представляться двумя способами:
Приведем несколько примеров числовых символьных ссылок:
Примечание. Несмотря на то, что шестнадцатеричное представление не определено в [ISO8879], ожидается проверка, как описано в [WEBSGML]. Данное соглашение чрезвычайно полезно, так как символьные стандарты, как правило, используют шестнадцатеричное представление.
Для того, что бы предоставить авторам интуитивно понятный путь для создания ссылок на символы из набора символов документа, HTML предлагает набор символьных сущностных ссылок. Символьные сущностные ссылки используют символические имена таким образом, что авторам нет необходимости помнить кодовые позиции. Например, символьная сущностная ссылка "å" ссылается на строчный символ "a" с кружком сверху. Значительно легче запомнить "å" чем "å".
HTML 4.0 определяет символьные сущностные ссылки не для всех символов в наборе символов документа. Например, не существует символьной сущностной ссылки для заглавной буквы "Й" из Кириллицы. Смотрите полный список символьных ссылок определенных в HTML 4.0.
Символьные сущностные ссылки чувствительны к регистру. Таким образом, Å (литера А верхнего регистра + ring) ссылается на символ, отличный от символа, на который ссылается å (литера А нижнего регистра + ring).
Четыре символьных сущностных ссылки заслуживают специального упоминания, так как они часто применяются во избежание использования специальных символов:
Авторам, желающим использовать символ "<" в тексте следует использовать "<" (десятичный ASCII- символ 60), во избежание возможных недоразумений с началом тега (разделитель, открывающий тег). Подобным образом, авторам следует использовать ">" (десятичный ASCII- символ 62) в тексте вместо ">", во избежание проблем со старыми средствами просмотра, которые некорректно воспринимают его в качестве завершения тега (разделитель, закрывающий тег), когда он появляется при цитировании значений атрибутов.
Авторам следует использовать "&" (десятичный ASCII- символ 38) вместо "&", во избежание конфликтов с символом начала символьной ссылки (разделитель, открывающий сущностную ссылки). Авторам также следует использовать "&" в значениях атрибутов, так как символьные ссылки допустимы в значениях атрибутов CDATA.
Некоторые авторы используют символьную сущностную ссылку """ для кодирования символа кавычки ("), так как этот символ может быть использован для разделения значений атрибутов.
Средство просмотра может быть не в состоянии отобразить все символы в документе, например, потому, что средство просмотра испытывает недостаток подходящих шрифтов, символ имеет значение, которое не может быть выражено во внутренних символьных кодировках средства просмотра и т.п.
В силу того, что имеется много различных предметов, которые не могут быть выполнены в данном случае, конкретный документ не предписывает никакого особого поведения. В зависимости от разработки, неотображаемые символы также могут быть обработаны основной системой отображения, а не собственным приложением. При отсутствии более сложного поведения, например, специально приспособленного для нужд особых языков сценариев, мы рекомендуем следующее поведение для средств просмотра:
Last modified: Tue Jan 27 14:12:26 1998