Указание символьной кодировки

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

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

Для получения информации относительно " text/html", смотрите раздел " Согласования".

Протокол HTTP ([RFC2068], раздел 3.7.1) упоминает ISO-8859-1 как кодировку по умолчанию, в случае, если параметр " charset" отсутствует в поле " Content-Type" заголовка. На практике, эта рекомендация оказывается несостоятельной потому, что некоторые серверы не позволяют посылать параметр " charset", а другие могут быть не сконфигурированы для посылки этого параметра. Следовательно, средства просмотра не должны иметь никакого значения параметра " charset" по умолчанию.

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

Например, для определения того, что символьной кодировкой текущего документа, является кодировка " EUC-JP", документ должен включать следующую META- декларацию:

META- декларация должна использоваться только в тех случаях, когда символьная кодировка организована таким образом, что символы ASCII остаются самими собой (по крайней мере, до тех пор, пока элемент META грамматически разбирается). META- декларация должна появляться как можно раньше в элементе HEAD.

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

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

1. HTTP- параметр " charset" в поле " Content-Type".
2. META- декларация с установкой значения " http-equiv" равного " Content-Type" и установкой значения для " charset".
3. Установка атрибута " charset" в элементе, который указывает на внешний ресурс.

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

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

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