Самоучитель PHP 4 - Котеров Д. В

Поле ввода пароля (password)

<input type=password name=имя [value=значение] [size=размер] [maxlen=число]

>

Полностью аналогичен тэгу <input type=text>, за исключением того, что символы, набираемые пользователем, не будут отображаться на экране. Это удобно, если нужно запросить какой-то пароль. Кстати, если в качестве маски задается значение параметра value, все будет в порядке, однако, посмотрев исходный HTML-текст страницы в браузере, можно увидеть, что он (браузер) это значение не показывает (непосредственно на странице). Сделано это, видимо, из соображений безопасности, хотя, конечно же, злоумышленник легко преодолеет такую защиту, если вы попытаетесь скрыть с ее помощью что-то важное.

Скрытое текстовое поле (hidden)

<input type=hidden name=имя value=значение

>

Создает неотображаемое (скрытое) поле. Такой объект нужен исключительно для того, чтобы передать сценарию какую-то служебную информацию, до которой пользователю нет дела, — например, параметры настройки.

Пусть, например, у нас имеется многоцелевой CGI-сценарий, который умеет принимать данные пользователя и отправлять их как почтовое сообщение. Поскольку мы бы не хотели фиксировать E-mail получателя жестко, но в то же время и не стремимся, чтобы пользователь мог его менять перед отправкой формы, оформим соответствующий тэг в виде скрытого поля:

<form action=/cgi/sendmail.cgi method=post>

<input type=hidden name=email value="admin.microsoft.com."> <h2>Пошлите сообщение администратору:</h2>

<input type=text name="text">

<input type=submit name=doSend value="Отослать"> </form>

Я подразумеваю, что сценарий анализирует свои входные параметры и посылает текст из параметра text по адресу email. А вот еще один пример использования этого сценария, но уже без скрытого поля. Сравните:

<form action=/cgi/sendmail.cgi method=post> <h2>Пошлите сообщение другу:</h2>

Его E-mail: <input type=text name=email><br> Текст: <input type=text name="text"><br>

<input type=submit name=doSend value="Отослать"> </form>

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

Часто скрытое поле используют для индикации того, что сценарий запущен в результате нажатия кнопки в форме, а не простым набором его URL в строке адреса браузера. Тем не менее, это, как уже говорилось, довольно плохой способ — лучше применять именованные кнопки submit.

В некоторых случаях именованные кнопки submit не помогают, и приходится пользоваться скрытым полем для индикации запуска сценария из формы. Про- исходит это в случае, если форма очень проста и состоит, например, всего из двух элементов — поля ввода текста и кнопки submit (пусть даже и имено- ванной). Практически все браузеры в такой ситуации позволяют пользователю просто нажать <Enter> для отправки формы, а не возиться с нажатием на submit-кнопку. При этом разумеется, данные кнопки не посылаются на сервер. Вот тогда-то нас и выручит hidden-поле, например, с именем submit: если его значение установлено, то сценарий понимает, что пользователь ввел какие-то данные, в противном случае сценарий был запущен впервые путем набора его URL или перехода по гиперссылке.

Независимый переключатель (checkbox)

<input type=checkbox name=имя value=значение

[checked]

>

Этот тэг генерирует независимый переключатель (или флажок), который может быть либо установлен, либо сброшен (квадратик с галочкой внутри или пустой соответственно). Если пользователь установил этот элемент, прежде чем нажать кнопку доставки, сценарию поступит строка имя=значение, в противном случае не придет ни- чего, будто нашего поля и не существует вовсе. Если задан атрибут checked, то переключатель будет изначально установленным, иначе — изначально сброшенным.

Зависимый переключатель (radio)

<input type=radio name=имя value=значение

[checked]

>

Включение в форму этого тэга вызывает появление на ней зависимого переключателя (или радиокнопки). Зависимый переключатель — это элемент управления, который, подобно независимому переключателю, может находиться в одном из двух состояний. С тем отличием, что если флажки не связаны друг с другом, то только одна радиокнопка из группы может быть выбрана в текущий момент. Конечно, чаще всего определяются несколько групп радиокнопок, независимых друг от друга. Наша кнопка будет действовать сообща с другими, имеющими то же значение атрибута name — иными словами, то же имя. Отсюда вытекает, что, в отличие от всех других элементов формы, две радиокнопки довольно часто имеют одинаковые имена. Если пользователь установит какую-то кнопку, сценарию будет передана строка имя=значение, причем значение будет тем, которое указано в атрибуте value выбранной кнопки (а все остальные переключатели проигнорируются, как будто неустановленные флажки). Если указан параметр checked, кнопка будет изначально выбрана, в противном случае — нет.

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

Кнопка отправки формы (submit)

<input type=submit [name=имя] value=текст_кнопки

>

Создает кнопку подтверждения с именем name (если этот атрибут указан) и названием (текстом, выводимым поверх кнопки), присвоенным атрибуту value. Как уже говорилось, если задан параметр name, после нажатия кнопки отправки сценарию вместе с другими парами будет передана и пара имя=текст_кнопки (если нажата не эта кнопка, а другая, будет передана строка другой, нажатой, кнопки). Это особенно удобно, когда в форме должно быть несколько кнопок submit, определяющих различные действия (например, кнопки Сохранить и Удалить в сценарии работы с записью какой-то базы данных) — в таком случае чрезвычайно легко установить, какая же кнопка была нажата, и предпринять нужные действия.

Кнопка сброса формы (reset)

<input type=reset value=текст_кнопки

>

Пожалуй, это самый простой элемент формы. Тэг создает кнопку, при нажатии на которую все элементы формы в браузере будут сброшены (точнее, установлены в то состояние, которое было задано в их атрибутах по умолчанию). Причем отправка формы не производится, т. е. для сценария кнопка reset незаметна.

Рисунок для отправки формы (image)

<input type=image [name=имя] src=изображение

>

Создает рисунок, при щелчке на котором кнопкой мыши будет происходить то же, что и при нажатии на кнопку submit, за тем исключением, что сценарию также будут пересланы координаты в пикселах того места, где произведен щелчок (отсчитываемые от левого верхнего угла рисунка). Придут они в форме: имя.x=X&имя.y=Y, где (X, Y) — координаты точки. Если же атрибут name не задан, то координаты поступят в формате: x=X&y=Y.

Тэг <textarea> — многострочное поле ввода текста

Теперь посмотрим, что же из себя представляет тэг <textarea>. Смысл у него тот же, что и у <input type=text>, разве что может быть отправлена не одна строка текста, а сразу несколько. Формат тэга следующий:

<textarea name=имя

[width=ширина][height=высота] [wrap=тип]

>Текст, который будет изначально отображен в текстовом поле</textarea>

Как легко видеть, этот тэг имеет закрывающий парный. Параметр width задает ширину поля ввода в символах, а height — его высоту. Параметр wrap определяет, как будет выглядеть текст в поле ввода. Он может иметь одно из трех значений (по умолчанию подразумевается none).

rVirtual — наиболее удобный тип вывода. Справа от текстового поля выводится полоса прокрутки, и текст, который набирает пользователь, внешне выглядит разбитым на строки в соответствии с шириной поля ввода, причем перенос осуществляется по словам. Однако символ новой строки вставляется в текст только при нажатии <Enter>.

rPhysical — зависит от реализации браузера, обычно очень похож на none.

rNone — текст отображается в том виде, в котором заносится. Если он не умещается в текстовое поле, активизируются линейки прокрутки (в том числе, и горизонтальная).

После отправки формы текст, который ввел пользователь, будет, как обычно, представлен парой имя=текст, аналогично тэгу однострочного поля ввода

<input type=text>.

Тэг <select> — список

У нас остался последний тэг — <select>. Он представляет собой выпадающий (или раскрытый) список. Одновременно могут быть выбрана одна или несколько строк. Формат этого тэга следующий:

<select name=имя [size=размер] [multiple]>

<option [value1=значение1][selected]>Строка1</option> <option [value2=значение2][selected]>Строка2</option>

. . .

<option [valueN=значениеN][selected]>СтрокаN</option> </select>

Мы видим, что и этот тэг имеет парный закрывающий. Кроме того, его существование немыслимо без тэгов <option>, которые и определяют содержимое списка.

Параметр size задает, сколько строк будет занимать список. Если size равен 1, то список будет выпадающим, в противном случае — занимает size строк и имеет полосы прокрутки. Если указан атрибут multiple, то будет разрешено выбирать сразу несколько элементов из списка, а иначе — только один. Кроме того, атрибут multiple не имеет смысла для выпадающего списка.

Каждая строка списка определяется своим тэгом <option>. Если в нем задан атрибут value, как это часто бывает, то соответствующая строка списка будет идентифицироваться его значением, а если не задан, то самим текстом этой строки (считается, что value равно самой строке). Кроме того, если указан параметр selected, то данная строка будет изначально выбранной. Кстати, чуть не забыл: закрывающие тэги </option> можно опускать, если упрощение не создает конфликтов с синтаксисом HTML (в действительности это можно делать почти всегда).

Давайте теперь посмотрим, в какой форме пересылаются данные списка сценарию. Ну, со списком одиночного выбора вроде бы ясно — просто передается пара имя=значение, где имя — имя тэга <select>, а значение — идентификатор выбранного элемента (то есть, либо атрибут value, либо сама строка элемента списка).

Списки множественного выбора (multiple)

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

имя=значение1&имя=значение2&...&имя=значениеN

Кстати говоря, совершенно не уникальный случай — то, что с одним именем связано сразу несколько значений. Действительно, нам никто не мешает создавать и другие тэги с идентичными именами. Это часто делается, например, для переключателейфлажков:

<input type=checkbox name=имя value="Один">Один<br> <input type=checkbox name=имя value="Два">Два<br> <input type=checkbox name=имя value="Три">Три<br>

Если теперь пользователь установит сразу все флажки, то сценарию поступит строка (конечно, в URL-кодированном виде):

имя=Один&имя=Два&имя=Три

Из всего сказанного следует не очень утешительный вывод: при разборе строки параметров в сценарии мы не можем полагаться на то, что каждой переменной соответствует только одно значение. Нам придется учитывать, что их может быть не "один", а "много". А это очень неприятно с точки зрения программирования — особенно на Си.

Попутно мы обнаружили, что любой multiple-список может быть представлен набором флажков (независимых переключателей), а любой не-miltiple — в виде нескольких радиокнопок. Так что, вообще говоря, тэг <select> — некоторое функциональное излишество, и с точки зрения сценария вполне может заменяться флажками и радиокнопками.

Загрузка файлов

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

Иногда бывает просто необходимо позволить пользователю не только заполнить текстовые поля формы и установить соответствующие переключатели, но также и указать несколько файлов, которые будут впоследствии загружены с компьютера пользо-

вателя на сервер. Для этого в языке HTML предусмотрены специальные средства. Рассмотрим их подробнее.

Формат данных

В свое время я говорил, что все данные из формы при передаче их на сервер упаковываются в строку при помощи символов ?, & и =. Легко видеть, что при загрузке файлов такой способ, хотя и приемлем, но будет существенно увеличивать размер передаваемой информации. Действительно, ведь большинство файлов — бинарные, а мы знаем, что при URL-кодировании данные таких файлов сильно "распухают" — примерно в три раза (например, простой нулевой байт при URL-кодировании превратится в %00). Это сильно замедлит передачу и увеличит нагрузку на канал. И вот, отчасти специально для решения указанной проблемы был изобретен другой формат передачи данных, отличный от того, который мы до сих пор рассматривали. В нем уже не используются пресловутые символы ? и &. Кроме того, похоже, в случае применения такого формата передачи может быть задействован только метод POST, но не метод GET. Нас это вполне устроит — ведь файлы обычно большие, и доставлять их через GET вряд ли разумно...

Если нужно указать браузеру, что в какой-то форме следует применять другой формат передачи, следует в соответствующем тэге <form> задать атрибут enctype=multipart/form-data. (Кстати говоря, если этот атрибут не указан, то форма считается обычной, что эквивалентно enctype=application/x-www-form- urlencoded — именно так обозначается привычный нам формат передачи.) После этого данные, поступившие от нашей формы, будут выглядеть как несколько блоков информации (по одному на элемент формы). Каждый такой блок очень напоминает HTTP-формат "заголовки-данные", используемый при традиционном формате передачи. Выглядит блок примерно так (\n, как всегда, обозначает символ перевода строки):

-----------------Идентификатор_начала\n Content-Disposition: form-data; name="имя"\n \n

значение\n

Например, пусть у нас есть форма:

Листинг 3.7. Multipart-форма

<form action=... enctype=multipart/form-data method=post> Name: <input type=text name="Name" value="Мое имя"><br> Box: <input type=checkbox name="Box" value=1 checked><br>

Area: <input type=textarea name="Area">Это какой-то текст</textarea><br> <input type=submit>

Заметьте, что несколько дефисов и число (которое мы ранее назвали Идентификатор_начала) предшествуют каждому блоку. Более того, строка из дефисов и этого числа служит своеобразным маркером, который разделяет блоки. Очевидно, эта строка должна быть уникальной во всех данных. Именно так ее и формирует браузер. Правда, сказанное означает, что сегодня идентификатор будет одним, а завтра, возможно, совсем другим. Так что нам придется, прежде чем анализировать данные, считать этот идентификатор в буфер (им будет последовательность символов до первого символа \n).

Стандарт протокола HTTP говорит нам, что идентификатор начала также дол- жен быть доступен через одну из переменных окружения. Но я не помню и не хочу знать ее название — сейчас объясню, почему. Некоторые браузеры (осо- бенно старые) путают этот идентификатор и присылают его неправильно — с двумя предшествующими минусами (а остальные — без них), так что сцена- рии, не рассчитывающие на такой подвох, перестанут работать. Никогда не полагайтесь на эту переменную окружения (даже если узнаете, как она назы- вается)! Вместо этого читайте последовательность символов до первого пере- вода строки и воспринимайте именно ее как разделитель.

Далее алгоритм разбора должен быть следующим: в цикле мы пропускаем символы идентификатора и перевода строки, извлекаем подстроку имя="что-то" (не обращая внимания на Content-Disposition), дожидаемся двух символов перевода строки и затем считаем значением соответствующего поля все те данные, которые размещены до строки \nИдентификатор (или же до конца, если такой строки больше нет). Как видите, все довольно просто.

Стандарт HTTP предписывает, чтобы перевод строки содержал два символа — \r\n, а не один \n. Как вы уже, наверное, чувствуете, существуют браузеры, которые об этом и не догадываются и посылают только один \n. Так что, будь- те готовы к тому, чтобы правильно обрабатывать и эту ситуацию.

Тэг загрузки файла (file)

Теперь вернемся к тому, с чего начали — к загрузке файлов. Сначала выясним, какой тэг надо вставить в форму, чтобы в ней появился соответствующий элемент управления — поле ввода текста с кнопкой Browse справа. Таким тэгом является разновид-

ность <input>:

<input type=file name=имя_элемента

[value=имя_файла]

>

Пусть пользователь выбрал какой-то файл (скажем, с именем каталог\ имя_файла) и нажал кнопку отправки. В этом случае для нашего элемента формы создается один блок примерно такого вида:

----------------127462537625367\n

Content-Disposition: form-data; name="имя_элемента"; Ä filename="каталог\имя_файла"\n \n

........

Бинарные данные этого файла любой длины. Здесь могут быть совершенно любые байты без всякого ограничения.

........

\n

Мы видим, что сценарию вместе с содержимым файла передается и его имя в системе пользователя (параметр filename).

На этом, пожалуй, и завершим обозрение возможностей загрузки файлов.

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

Что такое Cookies и с чем их едят

Сначала хотелось бы сказать пару слов насчет самого термина Cookies (это множественное число, произносится как "кукис" или, более "русифицировано", "куки"). В буквальном переводе слово звучит как "печенье", и почему компания Netscape так назвала свое изобретение, не совсем ясно. А поскольку писать "печенье" несколько неудобно, чтобы не вызывать несвоевременных гастрономических ассоциаций, везде, где можно, я буду применять именно слово Cookies, с большой буквы, во множественном числе и мужского рода. Кстати, в единственном числе это понятие записывается Cookie и произносится на русский манер — "кука".

Начну с примера. Скажем, мы хотим завести гостевую книгу: пользователь вводит свое имя, E-mail, адрес домашней странички (и другую информацию о себе), наконец, текст сообщения, и после нажатия на кнопку его мысль отправляется в путешествие по проводам и серверам, чтобы в конце концов попасть в некую базу данных на нашем сервере и остаться там на веки вечные. М-да….

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

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

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

Второй способ подразумевает использование Cookies. Cookie — это небольшая именованная порция информации, которая хранится в каталоге браузера пользователя (а не на сервере, заметьте!), но которую сервер (а точнее, сценарий) волен в любой момент изменить. Кстати, сценарий также получает все Cookies, которые сохранены на удаленном компьютере, при каждом своем запуске, так что он может в любой момент