Как передаются данные методом post

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

Метод GET

Метод GET использует для передачи данных строку URL. Возможно, Вы обращали внимание на длинные и непонятные URLы. Например: function.php?login=Alex&email=dezyakin . В данном случае данные обрабатываются в function.php. После знака вопроса " ? " идет перечисление передаваемых параметров (параметр разделяются знаком "&") со значениями: параметру login присвоено значение Alex, а переменной email значение dezyakin. Данные будут хранится в суперглобальном массиве $_GET . Приведем пример использования метода GET представлен ниже:

Результат выполнения выше описанного кода представлен на рисунке ниже:

Обратите внимание на то, как мы считываем значения из суперглобального массива $_GET: $_GET[‘имя_переменной’] . В нашем примере имена переменных были объявлены в форме (name=login и name=email).

Совет:
Прежде чем обрабатывать полученные значения советую проверять их на существование через функции isset(имя_переменной) или empty(имя_переменной) — эти функции были рассмотрены в предыдущем уроке 2: переменные в PHP. Например:

В форме можно указать имя файла, который будет обрабатывать передаваемые значения. Делается это с помощью атрибута формы action , которому можно присвоить адрес этого файла. По умолчанию этот файл присвоен текущему файлу (т.е. обрабатывается в файле, где и расположена форма). Приведем пример, в котором данные из формы передаются на обработку в файл srcipt.php :

В файле script.php должен содержатся какой-то обработчик информации, иначе информация будет передана в пустую.

Метод GET обладает множеством недостатков:

• Пользователь видит значения передаваемых параметров;
• Пользователь может легко подделать передаваемые параметры;
• Неудобная передача бинарной информации (приходится кодировать в текстовый формат);
• Объем передаваемых данных ограничен — 8 Кбайт;

Из-за выше перечисленных недостатков метод GET применяется только в тех случаях, когда нужно передать небольшой объем данных, а также эти данные никак не засекречены.

Метод POST

Метод POST отличается от GET тем, что данные передаются в закрытой форме. Существует суперглобальный массив $_POST , из которого можно считывать данные следующим образом: $_POST[‘имя_переменной’] . Например:

Результат выполнения выше описанного кода представлен на рисунке ниже:

Как видите URL не имеет никакой приписки, но тем не менее данные были получены и выведены.

Примечание:
1) Объем передаваемых значений методом POST по умолчанию ограничен и равен 8 Мбайт. Чтобы увеличить это значение нужно изменить директиву post_max_size в php.ini.

2) В ранних версиях PHP вместо коротких названий суперглобальных массивов $_GET и $_POST использовались более длинные имена: $HTTP_GET_VARS и $HTTP_POST_VARS . По умолчанию они выключены в php 5, но Вы можете их включить в конфигурационном файле php.ini с помощью параметра register_long_arrays . В php 6 версии эти длинные названия будут недоступны.

3) Перед обработкой переменных из $_POST , советую проверять переменные на их наличие, также как это делалось с методом GET .

Следующий четвертый урок будет посвящен: типам данных в php.

В настоящее время, каждый, даже самый захудалый сайт, старается обеспечить взаимодействие с пользователем. Гостевые книги, комментарии под статьями, опросы, голосования и прочее — все это требует передачи информации от пользователя к серверу. Как именно это происходит? Эта статья о методах передачи данных GET и POST.

Чаще всего, для передачи данных, используются. ссылки! Да-да! Когда вы нажимаете на ссылку, часто, вы передаете данные сервер. Большинство современных веб-сайтов, активно эксплуатируют этот метод передачи информации. Этот метод называется GET. Когда мы нажимаем на ссылку, мы хотим получить (to get) какой-то документ с сервера. Поэтому метод передачи данных через ссылку и назвали get.

Метод GET.

Метод GET удобен тем, что прост в эксплуатации. Но у него есть недостатки. Во-первых, методом GET нельзя передавать большие объемы информации, потому что данные, передаваемые этим методом входят в соств URL, длина которого ограничена.

Пример: ссылка http://dayte2.com/?u=shaman&act=state&num=9 содержит данные, передаваемые методом GET. Эти данные идут после знака вопроса.

Так как данные, передаваемые методом GET входят в соства URL документа, их может подсмотреть любой желающий. У этого есть преимущества и недостатки. Преимущество состоит в том, что можно послать ссылку вместе с данными другу. Недостаток в том, что в строке браузера отображается и ваш, только что введенный пароль. Это одна из причин, почему данные, представляющие ценность, всегда нужно передавать методом POST.

Метод POST.

Как и метод GET, метод POST служит для передачи данных на сервер. Однако, данные, переданные таким образом, идут не в URL документа, а в теле запроса, после заголовков. Эти данные могут быть восприняты CGI-программой.

Когда данные отправляются методом POST, серверу приходит что-то вроде:

POST lines.pl HTTP/1.1
Accept: */*
Referer: http://dayte2.com/shaman.shtml
Accept-Language: ru
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: dayte2.com
Content-Length: 106
Connection: Keep-Alive
Cache-Control: no-cache

После анализа заголовков, сервер видит пустую строку, которая говорит об окончании заголовков. После нее сервер видит какие-то непонятные данные. Не долго думая, сервер решает, что эти данные нужны файлу, который вызывается, и посылает эти данные документу. Если этот документ — скрипт, то он получит эти данные так же, как получает данные с клавиатуры при работе с консолью, то есть, через STDIN.

Плюсы метода POST очевидны: можно передавать неограниченные объемы информации, причем, никто не увидит эту информацию после того, как вы ее отправили (имеется ввиду, в строке браузера).

Но есть и недостатки. Вы не сможете послать данные за друга. Кроме того, если необходимо «протащить» данные через несколько форм или страниц, то это вызовет дополнительные трудности.

Однако, и их можно обойти. Один из распространенных методов: формирование скрытых полей с именем и значением уже пришедших данных. У этого подхода есть недостатки:

• можно легко подделать данные, хранимые в таких полях. Это делается просто: нужно сохранить страницу с формой на диск, исправить ее html-код, подставив в скрытые поля нужные данные, а затем нажать кнопку "Отправить" так же, как будто это реальная форма. Серверу без разницы от куда пришли данные, поэтому они будут обработаны так же.
• При таком подходе приходится несколько раз оптправлять данные от клиента серверу. Скажем, вы ввели логин и пароль. На следующей странице вас просят ввести адрес и номер телефона, а в полях hidden хранят ваши логин и пароль, полученные на предыдущей странице. При отправке формы заново будут отправлены и новые данные и старые (логин и пароль).

Есть так же, методы, основанные на cookie или серверных сессиях, но это — тема отдельной статьи.

Итак, мы разобрались с главными методами передачи данных (есть еще PUT, но им никто не пользуется) . Для веб-мастера очень важно понимать как именно происходит передача данных и что происходит на сервере. Сейчас высокоуровневые языки программирования типа PHP, делают работу по извлечению данных автоматически, поэтому многие не понимают настоящий механизм.

Если вам понравилась статья, можете подписаться на RSS этого блога и всегда быть в курсе обновлений. А еще, вы можете подписаться на рассылку новостей блога по почте.

Элемент разметки FORM и его компоненты

Контейнер (элемент разметки) FORM позволяет определить в рамках HTML-документа форму ввода. В рамках этого контейнера размещаются все поля ввода, куда пользователь может поместить свою информацию. Если контейнер формы открыт, т.е. в документе указан тег начала контейнера .

В общем случае контейнер имеет следующий вид:

Атрибут NAME используется для именования формы. Это делается главным образом в JavaScript-программах. Атрибут ACTION задает URL, по которому отправляются данные из формы. Атрибут METHOD определяет метод передачи данных (фактически, речь идет о формировании сообщения, передаваемого по сети). Атрибут ENCTYPE определяет тип кодирования данных в теле сообщения и разбиение сообщения на части. Необязательный атрибут TARGET позволяет адресовать окно, в котором будет отображаться результат обработки данных из формы.

В рамках обзора применения контейнера FORM мы рассмотрим:

• передачу данных по электронной почте;
• передачу данных скрипту через атрибут ACTION ;
• передачу данных через Server S >

Инициировать обмен можно при помощи JavaScript-кода, но рассматривать данный способ программирования обмена данными мы здесь не будем.

FORM (mailto)

Контейнер FORM позволяет определить в рамках HTML-документа форму ввода. В рамках этого контейнера размещаются все поля ввода, в которые пользователь может поместить информацию. Часто автор страниц Web-сайта по тем или иным причинам не имеет возможности программировать на стороне сервера. Однако это не означает, что он не может применять формы. Формы можно применять для отправки почты. Однако, как и в любом деле, здесь есть свои особенности, например:

В данном примере ( cgimail1.htm ) мы пытаемся отправить значение поля формы n1 по электронной почте абоненту help@intuit.ru . После заполнения поля и выбора кнопки "Отправить", браузер откроет окно программы почтового клиента, что не входило в наши планы. При этом само значение поля куда-то исчезнет.

Почему открывается новое окно? Несмотря на полный произвол, который царит в Web, и жесточайшую конкуренцию между Netscape и Microsoft, логика, заложенная в архитектуру World W >HTTP и SMTP (Simple Mail Transfer Protocol, простой протокол электронной почты), сообщение может состоять из двух частей: заголовка и тела. В том виде, в каком мы используем контейнер FORM , метод доступа к ресурсу не указан и, следовательно, по умолчанию выбирается GET . У нас нет тела сообщения, а есть только заголовок.

Кроме того, в примере мы применяем схему URL mailto. Она соответствует спецификации протокола SMTP (обмен почтовыми сообщениями в Internet). В этой схеме, в отличие от схемы HTTP , расширенный путь после доменного имени стандартом не предусмотрен.

Итак, для того, чтобы получить тело сообщения, необходимо указать метод POST ( cgimail2.htm ). В этом случае сообщение должно уйти абоненту без открытия окна почтового клиента:

Любопытно, что в данном случае мы использовали протокол, отличный от HTTP — SMTP. В нем нет понятия метода доступа вообще. Тем не менее логика разбиения текстовых сообщений для всех протоколов одна и та же, как, собственно, и предполагалось при создании Web-технологии — унификация доступа к ресурсам.

На этом примере хорошо видны отличия URI от URL. В данном случае были возможны различные механизмы обработки данных в запросе на ресурс, который задается URI. Но конкретная реализация преобразования данных в запрос в рамках Web — это и есть URL, т.е. URI в рамках World Wide Web.

Расширим наш пример, добавив в него отправку абоненту внешнего файла по электронной почте. Такая задача встречается довольно часто. Например, поддержка архива электронных публикаций. Здесь нет необходимости в немедленном опубликовании материалов. Все статьи должны пройти экспертизу, которая требует определенного времени. Для этого модифицируем наш пример, добавив в него поле типа FILE :

Почему в данном случае нельзя использовать метод GET , объяснялось выше. Метод POST должен обеспечить нам размещение всего файла в теле сообщения.

Однако все это верно, пока мы работаем с текстовыми файлами и находимся в рамках RFC822. А если нам нужно передать файл с длинными строками (Postscript) или просто двоичный файл? В таком случае необходимо обратиться к формату MIME. Это можно сделать при помощи еще одного атрибута контейнера FORM — ENCTYPE :

В данном случае по почте отправляется сообщение не в стандарте RFC822, а в стандарте MIME. Тело сообщения будет состоять из нескольких частей, а файл будет преобразован в ASCII-символы в соответствии со спецификацией BASE-64. Стандартный почтовый клиент воспринимает такой файл как присоединенный и позволяет его либо просмотреть, либо сохранить на диске.

FORM (HTTP)

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

Раз запрос от клиента принимает сервер, следовательно, и инициировать изложенные выше действия должен именно он.

Механизм инициирования такой прикладной программы определен в спецификации Common Gateway Interface. Там же задан и порядок обмена данными между HTTP -сервером и программой, которая в спецификации CGI именуется скриптом.

Метод GET

Основная задача формы — это предоставление шаблона ввода данных, которые будут переданы скрипту. Сам скрипт при этом указывается через URL, который задается в атрибуте ACTION :

В данном примере скрипт просто распечатывает пару "имя поля формы — значение поля формы" в виде HTML-таблицы ( formcgi1.htm ). Правда, если присмотреться внимательно к происходящему на экране, можно обнаружить любопытную метаморфозу с URL скрипта при выборе кнопки "Отправить". В поле location окна браузера к скрипту после символа " ?" приписываются пары "поле-значение", разделенные символом " & ".

Данный запрос из формы определяют как запрос типа URLENCODED, переданный по методу GET . При передаче значений по методу GET формируется только заголовок HTTP -сообщения и не формируется его тело. Поэтому все содержание полей формы помещается в URL и таким образом передается скрипту. Из текста скрипта ( formcgi2.htm ) видно, что данные извлекаются из переменной окружения QUERY_STRING , в которую сервер помещает запрос.

Запросы, которые передаются в методе GET , можно условно разделить на два типа: ISINDEX и FORM-URLENCODED . FORM-URLENCODED мы только что рассмотрели, а ISINDEX был описан в разделах "Заголовок HTML-документа" и "Спецификация Common Gateway Interface", поэтому не будем повторяться.

Метод POST

Очевидно, что в строку URL нельзя втиснуть бесконечное число символов. И браузер, и среда, в которой функционирует сервер, имеют ограничения либо, как в случае браузера, по длине поля location, либо по длине области переменных окружения. Правда, последнее для современных систем не очень актуально. Например, операционная система IRIX 6.2 позволяет размещать в области переменных окружения данные объемом до 4 Mбайт. Тем не менее, для передачи относительно больших объемов предпочтительнее использовать метод доступа POST :

В нашем примере в контейнере FORM появился атрибут METHOD , который принял значение POST . Результат работы скрипта не изменился, но сам скрипт претерпел существенные изменения. Теперь запрос принимается со стандартного ввода, а не из переменной окружения QUERY_STRING .

При методе POST данные передаются как тело HTTP -сообщения, и скрипт читает их со стандартного ввода. При этом есть один существенный нюанс, который ограничивает круг средств разработки скриптов для приема данных по POST . Он заключается в том, что сервер не закрывает канал передачи данных скрипту после передачи последнего символа запроса. В переменной CONTENT_LENGTH сервер сообщает, сколько данных со стандартного ввода нужно считать. Таким образом, язык программирования сценариев или универсальный язык программирования должны уметь читать определенное количество символов из стандартного ввода. Например, многие разновидности командных языков UNIX (Bourn-shell, Kernel-shell и т.п.) могут читать только строками и ждут закрытия входного потока.

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

Кодирование

Существует два типа кодирования содержания (тела) HTTP -сообщения, которые можно определить в форме:

• application/x-www-form-urlencoded
• multipart/form-data

Все, что рассматривалось в данном разделе до сих пор, относилось к первому типу кодирования тела HTTP -сообщения. Первый тип кодирования выбирается по умолчанию и является основным способом. Единственное, что пока не было рассмотрено, так это то, что, собственно, представляет собой этот самый URLENCODED.

В URL документа можно использовать только символы набора Latin1. Это первая половина таблицы ASCII за вычетом первых 20 символов. Все остальные символы заменяются своими шестнадцатеричными эквивалентами. Кроме того, такие символы, как " + " или " & ", играют роль разделителей или коннекторов. Если они встречаются в значении поля, то тоже заменяются на шестнадцатеричный эквивалент. Наиболее характерно это для работы с русским алфавитом. Поэтому скрипт, который принимает запросы, должен уметь эти символы декодировать.

Второй тип применяется для передачи двоичной информации в теле HTTP -сообщения. Если проводить аналогии с электронной почтой, то multipart/form-data обеспечивает присоединение файла данных (attachment) к HTTP -запросу. Наиболее типичным примером является передача файла с машины пользователя на сервер:

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

FORM (SSI)

Когда говорят о формах, обычно предполагается, что в контейнере FORM обязательно должен быть указан адрес скрипта. Этот скрипт примет данные и "на лету" сгенерирует страницу, которая и будет возвращена пользователю. Из этого правила существует, по крайней мере, два исключения.

Во-первых, атрибут ACTION можно не указывать в том случае, если данные, введенные в форму, обрабатываются JavaScript-программой. В этом случае достаточно дать форме имя, чтобы к ее элементам (контейнерам) можно было обращаться. Передачу данных можно реализовать через метод submit , который будет выполняться при нажатии на гипертекстовую ссылку, например, formssi1.htm . Более подробно данный материал описан в главе "Программирование на JavaScript".

Во-вторых, принять данные можно через скрипт, который встроен в документ как Server Side Include. Этот способ мы рассмотрим более подробно.

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

то после перезагрузки документа мы получим этот же документ, только в URL после символа " ?" будет добавлено содержание формы ( formssi2.htm ).

Если теперь несколько видоизменить документ — вставить в него Server Side Include — получим:

Сам скрипт принимает запрос из QUERY_STRING и распечатывает его в виде HTML-таблицы ( formssi3.htm ). При этом результат распечатывается вслед за формой после горизонтального отчеркивания.

Точно так же можно обработать данные и методом POST , только для этого необходимо указать его в атрибуте METHOD контейнера FORM .