Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:
реклама
Проектированеи вентиляции - https://vtlstroy.ru/uslugi/proektirovanie-ventilyatsii/. , Банкротство физических лиц под ключ: что это юрист для людеи Банкротство физических лиц.

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Несколько слов о <META HTTP-EQUIV...>

Алексей Тутубалин

Тег <META HTTP-EQUIV ...> был разработан и введен встандарт HTML (он, как минимум, упоминается в Draft на HTML 3.2) для того, чтобы указать HTTP-серверу какие именно заголовки HTTP он может выставить. Как написано в draft HTML-3.2, это именно пожелание для сервера ине более.

Драфт HTML 4.0 в этом смысле более четок - он позволяет WWW-клиенту учитывать тег <META HTTP-EQUIV> при определении кодировки, но при наличии HTTP-заголовка "Content-Type:... charset=...", кодировка должна определяться по HTTP-заголовку.

К сожалению, авторы WWW-броузеров (это относится и к Netscape Navigator и к Microsoft Internet Explorer) либо не читают стандартов, либо читают их как-тостранно. Возможно, у них даже благие намерения. Когда такие броузеры встречают в документе таг:

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows1251">

они перестают обращать внимание на корректный (т.е. соответствующий реальной кодировке) HTTP-заголовок Content-Type: и отображают документ в соответствии со своими представлениями об этом Charset (т.е. Netscape меняет шрифт на тот, который установлен для koi8-r, а MS IEперекодирует из KOI8 в cp1251). Более того, эти броузеры обращают внимание на этот тег даже в том случае, когда он встречается внутри <BODY> ... </BODY>, что уже ни в какие ворота не лезет (интересно, что они будут делать, когда в документе есть несколько противоречивых <META HTTP-EQUIV...> ?).

По большому счету, понятно почему авторы броузеров так поступают - это вполне объяснимое желание быть святее папы римского и одновременно помочь несчастным владельцам серверов с HTTP/0.9 (у этого протокола нет заголовка Content-type).

Эта проблема так и оставалась бы чисто теоретической, но к несчастьюочень распространенные редакторы HTML-файлов (прежде всего MS FrontPage, MS Internet Word Assistant да и много всяких прочих) просто обожают вставлять этот тег в документы и отучить их никак не получается. Таким образом, проблема имеется. Возможных вариантов ее решения несколько:

  1. Привести содержимое <META HTTP-EQUIV...> в соответствие с реальностью. Этот способ кажется идеальным на первый взгляд, но на самом деле имеет свои недостатки. Основных недостатков два:
    • Требуется анализ (парсинг) всех HTML-файлов, выдаваемых сервером от начала и до конца. Анализа только <HEAD>...</HEAD> недостаточно т.к. броузеры воспринимают <META> и внутри <BODY>. Анализ всех HTML-файлов - процедура достаточно трудоемкая, как для программиста, так и для компьютера; производительность HTTP-сервера может заметно упасть. Впрочем, эта проблема решаема, как минимум теоретически.
    • HTTP-протокол позволяет запросу (и ответу) от клиента до сервера проходить через произвольное число PROXY-серверов. При этом стандарт явно разрешает PROXY модифицировать содержимое ответа (и запроса), учитывая только данные HTTP-заголовка. Как следствие, перекодирующий PROXY-сервер может перекодировать HTTP-ответ в форму, приемлемую (как думает proxy) для клиента не анализируя сам поток данных. Как следствие, мы получаем ту же проблему - в HTTP-заголовке одно, а в <META...> - другое. При этом PROXY делает все в точном соответствии со стандартом и обвинить автора PROXY-сервера ни в чем нельзя. Проконтролировать все возможные PROXY, которые могут находиться между клиентом и сервером тоже невозможно.
  2. Таким образом, мы приходим ко второму очевидному решению - <META HTTP-EQUIV..> нужно просто удалять. В этом случае все распространенные броузеры будут использовать значение HTTP-заголовка Content-Type, уважающие себя (и HTTP-протокол) PROXY-серверы тоже будут вести себя корректно. Этот метод воплощен в 'Russian Apache' начиная с версии PL18.
  3. Вообще говоря, есть и третий способ. А именно - увидев в документе <META HTTP-EQUIV...> прекратить всяческие попытки перекодировки, поставить HTTP-заголовок Content-Type в соответствующее положение (как предлагает стандарт HTML) и отдать документ AS-IS. Несмотря на соответствие стандартам, использование этого способа в 'Russian Apache' реально невозможно. Например, нельзя отдать документ в кодировке Windows-1251 пользователю, работающему под Unix - у него скорее всего не будет шрифтов, необходимых для чтения этого документа.

Оставить комментарий

Комментарий:
можно использовать BB-коды
Максимальная длина комментария - 4000 символов.
 
Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог