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

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


100

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

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

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

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

Что такое cookies и "с чем их едят"?

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

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

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

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

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

Глава 3. CGI изнутри

101

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

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

Не правда ли, последний способ представляет собой идеальное решение для нашей проблемы? Действительно, теперь сценарию гостевой книги достаточно получить у пользователя его данные, запомнить их в cookies (как это сделать — см. разд. "Установка cookie" далее в этой главе), а затем работать, будто ничего и не произошло. Конечно, перед выводом HTML-документа формы обязательно придется проставить значения value для некоторых элементов (которые, ясно, извлечены из соответствующих cookies).

Но не все так гладко. Конечно, и у этой схемы есть недостатки. Первый из них — не все браузеры поддерживают cookies, а пользователи тех, которые поддерживают, иногда имеют обыкновение отключать cookies — якобы для большей безопасности (хотя безопасность тут совсем ни при чем, дело в самих этих пользователях). Второй недостаток заключается в том, что каждый браузер хранит свои cookies отдельно. То есть cookies, установленные при пользовании Internet Explorer, не будут "видны" при работе в Netscape Navigator, и наоборот.

Но, согласитесь, все же это почти не умаляет достоинств cookies — в конце концов, обычно пользователи работают только в одном из перечисленных браузеров. Кстати, все чаще в Internet Explorer. На момент написания этих строк указанный браузер имеет в несколько раз большие возможности, чем Netscape Navigator (работая при этом, правда, несколько медленнее). Что ж... Время покажет, кто из них выживет.

Но мы несколько отклонились от темы. Как уже упоминалось, каждому cookie сопоставлено время его жизни, которое хранится вместе с ним. Кроме этого, имеется также информация об имени сервера, установившего этот cookie, и URL каталога, в котором находился сценарий-хозяин в момент инициализации (за некоторыми исключениями).

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




  Hostland.Ru

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