знает, когда данные кончаются, т. е. когда ему 
пре- 
кращать чтение информации, поступившей от браузера? В этом ему поможет пере- 
менная окружения Content-Length, и именно на нее следует ориентироваться. Чуть 
позже мы рассмотрим этот механизм подробнее. 
Зачем нужен метод POST? В основном для того, чтобы передавать большие объемы 
данных. Например, при загрузке файлов через Web (см. ниже) или при обработке 
больших форм. Кроме того, метод POST часто используют для эстетических целей: 
дело в том, что при применении GET, как вы, наверное, уже заметили, URL 
сценария 
становится довольно длинным и неизящным, а POST-запрос оставляет URL без изме- 
нения. 
Кодировки и форматы данных 
Ранее упоминалось, что и в методе GET, и в методе POST данные доставляются в 
URL-кодированном виде. Что это значит? 
Уж не знаю, откуда взялась эта дурная традиция (может, из стремления сохранить 
совместимость с древними программами, которыми вот уже лет 20 никто не пользу- 
ется), но почему-то все Интернет-сервисы — начиная от 
E-mail и заканчивая Web — как-то очень "не любят" байты со значениями, превы- 
шающими 127. Поэтому применяется изощренный способ перекодировки, который 
все символы в диапазонах 0 .. 32 и 128 .. 256 представляет в URL-кодированном 
ви- 
де. Например, если нам нужно закодировать символ с шестнадцатеричным кодом 9E, 

Часть I. Основы Web-программирования 36 
это будет выглядеть так: %9E. Помимо этого, пробел представляется символом плюс 

(+). Так что будьте готовы к тому, что вашим сценариям будут передаваться 
данные 
именно в таком виде. 
В частности, все буквы кириллицы преобразуются в подобную абракадабру (соответ- 

ственно, размер данных увеличивается примерно в 3 раза!). Поэтому программы 
должны всегда быть готовы перекодировать информацию туда-сюда-обратно. 
Но это только пол-беды. Дело в том, что существует еще такая неприятная 
проблема, 
как кодировки символов кириллицы. И неприятно не столько то, что они существуют,
 
сколько то, что они все не подчиняются никакому единому логическому правилу, в 
отличие он ASCII. Если при этом текст, который пришел, допустим, в кодировке 
KOI-8-R, просматривают в WIN-кодировке, получается редкостная путаница. 
Казалось бы, чего сложного — выполнить автоматическое перекодирование в чита- 
бельный вид полученного текста (кстати говоря, относительно часто этот текст 
даже 
снабжен указанием, в какой же он кодировке). Однако, насмотревшись на разнооб- 
разные программные продукты, складывается такое впечатление, что эта проблема 
сложнее, чем создание искусственного интеллекта! А дело все в том, что 
"интеллек- 
туальные" серверы вместо того, чтобы присылать и принимать текст всегда в 
фикси- 
рованной кодировке и переложить эту проблему на плечи браузеров, зачем-то сами 
занимаются перекодировкой. И браузеры в своем большинстве — тоже. Так что ино- 
гда бывает, что текст приходит "зашифрованным" с помощью каких-то двух экзоти- 
ческих кодировок, что окончательно его портит. 
Существуют даже специальные программы, которые пытаются раскодировать 
текст, который по ошибке был преобразован несколько раз и потому приобрел 
нечитаемый вид. Одна из них — почтовый декодер Лебедева, работающий в 
online-режиме. Само наличие таких программ красноречиво свидетельствует, 
как далеко все зашло в вопросе о статусе русских кодировок. 
Что может быть глупее? А все по той причине, что нет строгого стандарта на 
кирил- 
лицу и что, якобы, где-то в мире существуют браузеры, которые не умеют 
перекоди- 
ровать информацию. Скажите на милость, зачем они тогда вообще нужны, если не 
умеют делать даже такой простой вещи, как табличные преобразования? Или это 
сде- 
лано для тех, кто читает Web-страницы не через браузер, а по telnet'у? И почему 
же 
из-за жалкой горстки пользователей должна страдать остальная часть населения 
страны? 
Ну ладно-ладно, я уже успокоился. Прошу прощения, что влез на стол и кричал. 
Да- 
вайте продолжим. 

Глава 2. Интер