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

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


66

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

при упоминании о протоколе HTTP. Все это не так сложно, как иногда может показаться.

Если у вас указанная процедура не удалась, и сервер все время шлет сообщение "Bad Request", то проверьте регистр символов, в котором вы набираете команды. Все буквы должны быть заглавными, а название протокола нттр/1.1 — идти без пробелов.

Посмотрим теперь, как работает сервер. Происходит все следующим образом: он считывает заголовки запроса и дожидается маркера \п\п (или, что то же самое, "пустого" заголовка), а как только его получает, начинает разбираться — что же ему за информация пришла, и выполнять соответствующие действия.

С помощью заголовков реализуются такие механизмы, как контроль кодировок, cookies, метод POST и т. д. Если же сервер не понимает какого-то заголовка, он его либо пропускает, либо жалуется отправителю (в зависимости от воли администратора, который настраивал сервер).

Мы подошли к сути метода POST. А что, если мы в предыдущем примере зададим вместо get слово post и после последнего заголовка (маркера \п\п) начнем передавать какие-то данные? В этом случае сервер их воспримет и также передаст сценарию. Только нужно не забыть проставить заголовок content-length в соответствии с размером данных, например:

post /script.cgi http/1.l\n Host: example.com Content-length: 5\n \n

Test!

Сервер начнет обработку запроса, не дожидаясь передачи данных после маркера конца заголовков. Иными словами, сценарий запустится сразу же после отправки \п\п, а уж ждать или не ждать, пока придет строка Test! длиной 5 байтов — его дело.

Последнее означает, что сервер никак не интерпретирует posT-данные (точно так же, как он не интерпретирует некоторые заголовки), а пересылает их непосредственно сценарию. Но как же сценарий узнает, когда данные кончаются, т. е. когда ему прекращать чтение информации, поступившей от браузера? В этом ему поможет переменная окружения content_length, и именно на нее следует ориентироваться. Чуть позже мы рассмотрим этот механизм подробнее.

Зачем нужен метод POST? В основном для того, чтобы передавать большие объемы данных. Например, при загрузке файлов через Web (см. гл. 3) или при обработке больших форм. Кроме того, метод POST часто используют для эстетических целей: дело в том, что при применении GET, как вы, наверное, уже заметили, URL сценария становится довольно длинным и неизящным, а posT-запрос оставляет URL без изменения.

Метод POST

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

67

URL-кодирование

Ранее упоминалось, что и в методе get, и в методе post данные доставляются в URL-кодированном виде. Что это значит?

Удивительно, откуда взялась эта дурная традиция (может, из стремления сохранить совместимость с древними программами, которыми вот уже лет 20 никто не пользуется), но почему-то все интернет-сервисы, начиная от e-mail и заканчивая Web, как-то очень "не любят" байты со значениями, превышающими 127. Поэтому применяется изощренный способ перекодировки, который все символы в диапазонах 0—32 и 128—256 представляет в URL-кодированном виде. Например, если нам нужно закодировать символ с шестнадцатеричным кодом 9Е, это будет выглядеть так: %9е. Помимо этого, пробел представляется символом плюс (+). Поэтому готовьтесь, что вашим сценариям будут передаваться данные именно в таком виде. В частности, все буквы кириллицы преобразуются в подобную абракадабру (соответственно, размер данных увеличивается примерно в 3 раза!). Поэтому программы должны всегда быть готовы перекодировать информацию туда-сюда обратно.

URL-кодирование — это только полбеды. Дело в том, что существует еще такая неприятная проблема, как кодировки символов кириллицы. И неприятно не столько то, что они существуют, сколько то, что все они не подчиняются никакому единому логическому правилу, в отличие он ASCII.

Что такое кодировка символов?

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

Долгое время для представления кода символа использовалась ячейка памяти размером 1 байт. Это позволяло кодировать до 256 символов текста. Например, русской букве "с" соответствует код 241, а английской "с" — код 99. Выглядят оба символа одинаково, а кодируются по-разному.

Соответствие внешнего вида символа его коду называется кодировкой. Выше мы говорили про код русской буквы "с", но следовало бы при этом добавить, что это ее код в кодировке Windows-1251 (сейчас используется по умолчанию в Windows). Соответственно, код этой же буквы в кодировке KOI8-R будет другим, а именно — 211. Если текст, который пришел, допустим, в кодировке KOI8-R, просматривают в кодировке Windows-1251, получается редкостная путаница.

В последние несколько лет все более популярной становится единая "многобайтовая" кодировка Unicode (или ее "разновидность" UTF-8), в которой для кодирования символов используются два и более байтов. Это позволяет хранить в документе тексты сразу на нескольких языках— ведь возможностей однобайтовой кодировки едва-едва хватает да-

Проблема русских кодировок




  Hostland.Ru

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