РНР 5 в подлиннике

Страница 33 из 554


68

Часть I. Основы Web-программирования

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

Вообще, любой текст в электронном виде, не содержащий прикрепленную информацию о его кодировке, можно считать бесполезным. Таким образом, чаще всего эта информация бывает явно указана, а если система, на которой производится отображение текста, не. поддерживает его кодировку, выполняется перекодирование. Казалось бы, чего сложного, — выполнить по таблице автоматическое преобразование одного текста в другой. Однако после знакомства с разнообразными программными продуктами складывается такое впечатление, что эта проблема сложнее, чем создание искусственного интеллекта! А дело все в том, что "интеллектуальные" серверы вместо того, чтобы присылать и принимать текст всегда в фиксированной кодировке и переложить эту проблему на плечи браузеров, иногда сами занимаются перекодировкой. И браузеры в своем большинстве — тоже. Поэтому иногда текст приходит "зашифрованным" с помощью сразу каких-то двух экзотических кодировок, что окончательно его портит.

Существуют даже специальные программы, которые пытаются раскодировать текст, который по ошибке был преобразован несколько раз и потому приобрел нечитаемый вид. Одна из них— почтовый декодер Лебедева, работающий в online-режиме. Само наличие таких программ красноречиво свидетельствует, как далеко все зашло в вопросе о статусе русских кодировок.

Что может быть глупее? А все по той причине, что нет строгого стандарта на кириллицу и что, якобы, где-то в мире существуют браузеры, которые не умеют перекодировать информацию. Скажите на милость, зачем они тогда вообще нужны, если не умеют делать даже такой простой вещи, как табличные преобразования? Или это сделано для тех, кто читает Web-страницы не через браузер, а по telnet? И почему же из-за жалкой горстки пользователей должна страдать остальная часть населения

Ну, ладно-ладно, автор этих строк уже успокоился и сожалеет, что влез на стол и кричал. Давайте продолжим.

Протокол HTTP и язык HTML поддерживают два разных способа указания кодировки документа.

□ Указание сценарием (или сервером) заголовка вида Content-type: text/html; charset=windows-1251

(например, для кодировки Windows-1251 и MIME-типа text/html).

□ Указание тега

<meta http-equiv="Content-Type" content="text/html; chars е t=windows-1251">

прямо в HTML-документе (обычно в секции <head>).

По сути, оба метода одинаковы: браузеру тем или иным способом передается заголовок content-type с указанной кодировкой.

страны?

Глава 2. Интерфейс CGI и HTTP

69

Русский Apache" и кодировка

Какой из приведенных способов идеологически более правильный? Считается, что второй: ведь кодировка документа — это неотъемлемая часть самого документа, а потому она должна быть интегрирована в него.

Но давайте рассмотрим ситуацию, когда браузер пользователя "не понимает" той кодировки, которая указана в документе. Например, он поддерживает KOI8-R, но не поддерживает Windows-1251, или наоборот.

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

При каждом запросе браузер передает серверу заголовок Accept-charset, в котором указывает предпочтительную для него кодировку. Если у хостинг-провайдера установлен так называемый "русский Apache" (Apache с поддержкой популярного некогда модуля mod_charset, сайт которого — http://apache.Iexa.ru), существует вероятность, что сервер (например, Apache) динамически перекодирует документ в ту кодировку, которую запросил клиент, и вернет ему страницу в правильной кодировке. Конечно, Apache также подправит имя кодировки в заголовке content-Type, который посылается браузеру.

Но ведь сервер "ничего не знает" ни о HTML, ни о теге <meta>. А значит, он не сможет исправить кодировку в этом теге, если автор страницы укажет ее там! Приходим к выводу, что указание кодировки при помощи тега <meta> может быть несовместимо с "русским Apache". Мы должны отказаться либо от одного, либо от другого. В противном случае возможны весьма неприятные ситуации, и один из примеров мы здесь рассмотрим.

Пример сбойной конфигурации

Пусть на сервере установлен "русский Apache", кодировка документов — Windows-1251. Во всех HTML-файлах присутствует тег <meta> с указанием той же самой кодировки.

Казалось бы, все верно: в обоих местах указана одинаковая кодировка, и проблем быть не должно. К сожалению, это не так!

Представим себе браузер, умеющий работать со всеми кодировками, но по умолчанию он желает видеть KOI8-R. На сервер приходит запрос:

GET / HTTP/1.1 Host: example.com Accept-charset: K0I8-R

Запускается модуль "русского Apache", который видит, что клиент требует выдать ему документ в формате K0I8-R. Он также знает, что файлы на сервере хранятся в кодировке Windows-1251. Не долго думая, сервер перекодирует страницу, меняет заголовок content-Type и отправляет ответ назад в браузер.

Но ведь он не может изменить тег <meta>!




  Hostland.Ru

 «Бесплатный хостинг Hostland.Su» © 2006