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

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


74

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

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

Приведенная схема минимизации количества документов стандартна и весьма универсальна (ее применяют 99% сценариев, которые можно найти в Интернете). Она еще и удобна для пользователя, потому что не создает "мертвых" ссылок (любой URL сценария, который он наберет, пусть даже и без параметров, будет корректным). Однако программирование этой схемы на С (и на некоторых других языках) вызывает определенные проблемы. Язык РНР таких проблем лишен.

Кодировка входных данных

Напомним, что текст, указанный в URL после знака ?, будет доступен в скрипте через переменную окружения query_string. Данные же, переданные методом post, попадут во входной поток ввода сценария. При этом ни браузер, ни сервер никак все эти данные не интерпретируют. Иными словами, в query_string и во входном потоке оказывается в точности то же самое, что было указано в адресной строке или передано браузером методом post.

Выше мы обсуждали проблемы кодировки документа, "русский Apache" и связанные с ними приемы настройки сервера. Мы говорили только о кодировке страницы, генерируемой скриптом, но ни словом не обмолвились о кодировке данных, которые передаются в обратном направлении — из браузера сценарию. Это не спроста. Дело в том, что вопрос, в какой кодировке пришли данные методом get или post, полностью бессмыслен. Данные приходят всегда в бинарном виде, т. е. в точности так, как их отправит браузер.

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

Главная проблема заключается в том, что при этом браузер посылает данные в виде обычного потока байтов, не снабжая его информацией о кодировке. К сожалению, так устроен протокол HTTP: в нем есть отдельный заголовок для указания кодировки страницы, но отсутствует для кодировки запроса.

Из этого следуют очень интересные выводы. Например, пусть скрипт располагается на сайте с кодировкой Windows-1251 и ожидает принять свои данные в той же ко-

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

75

дировке. Но кто-то взял и вызвал скрипт из другой формы, которая располагалась на К018-странице (как мы знаем, это всегда можно сделать — скрипт и форма, его вызывающая, полностью независимы). В результате данные придут в кодировке KOI8-R, но сценарий об этом никогда не узнает.

Резюме

В данной главе мы получили базовое представление о протоколе HTTP и интерфейсе CGI, используемых в Web. Мы также узнали, какую роль играют заголовки протокола HTTP при обмене данными между браузером и сервером и затронули непростой вопрос о различных кодировках кириллицы, применяемых в Интернете.




  Hostland.Ru

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