PHP Lang
  1. PHP Lang
  3. PHP "php: // input" vs $ _POST
Intereting Posts
Можно ли отключить переменную сеанса с определенным и переменным индексом? Как и зачем использовать фигурные скобки: return $ this -> {$ this-> action} (); Объединение двух массивов по ID в PHP Попробуйте Catch с предупреждениями PHP Как заставить MySQL возвращать UTF-8? Частная система чата MYSQL-запрос ORDERBY и GROUPBY Разница между «как $ key => $ value» и «as $ value» в PHP foreach Laravel eloquent – Отношения для многих как получить контакты gmail, yahoomail, hotmail с помощью imap в php? .htaccess не работает на xampp (windows 7) php Mysql Группирование и упорядочение пользовательских сообщений вместе preg_replace non-alpha, оставить одиночные пробелы упорядочение списка файлов в папке с использованием php Как сделать маршруты в Laravel без учета регистра? DNS не работает в PHP (но в целом)

PHP "php: // input" vs $ _POST

Мне было предложено использовать метод php://input вместо $_POST при взаимодействии с запросами Ajax из JQuery. То, что я не понимаю, – это преимущества использования этого против глобального метода $_POST или $_GET .

Причина в том, что php://input возвращает все необработанные данные после HTTP-заголовков запроса независимо от типа содержимого.

PHP суперглобальный $_POST , только предполагается обернуть данные, которые либо

  • application/x-www-form-urlencoded (стандартный тип контента для простых форм-сообщений) или
  • multipart/form-data-encoded (в основном используется для загрузки файлов)

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

Итак, если вы просто POST доброй старой HTML- form , запрос выглядит примерно так: 

 POST /page.php HTTP/1.1 key1=value1&key2=value2&key3=value3

Но если вы много работаете с Ajax, этот probaby также включает обмен более сложными данными с типами (string, int, bool) и структурами (массивы, объекты), поэтому в большинстве случаев JSON – лучший выбор. Но запрос с полезной нагрузкой JSON будет выглядеть примерно так: 

 POST /page.php HTTP/1.1 {"key1":"value1","key2":"value2","key3":"value3"}

Теперь контент будет application/json (или, по крайней мере, ни один из вышеупомянутых), поэтому PHP $_POST -wrapper не знает, как справиться с этим (пока).

Данные все еще существуют, вы просто не можете получить к нему доступ через оболочку. Поэтому вам нужно получить его самостоятельно в необработанном формате с помощью file_get_contents('php://input') ( при условии, что это не multipart/form-data -encoded ).

Это также способ доступа к XML-данным или любому другому нестандартному типу контента.

php://input может дать вам необработанные байты данных. Это полезно, если POSTed-данные представляют собой кодированную JSON структуру, что часто бывает в случае запроса AJAX POST.

Вот как это сделать: 

  /** * Returns the JSON encoded POST data, if any, as an object. * * @return Object|null */ private function retrieveJsonPostData() { // get the raw POST data $rawData = file_get_contents("php://input"); // this returns null if not valid json return json_decode($rawData); }

Массив $_POST более полезен, когда вы обрабатываете данные о ключевом значении из формы, представленной традиционным POST. Это работает только в том случае, если данные POSTed находятся в распознанном формате, обычно application/x-www-form-urlencoded (см. http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4 для получения подробной информации).

Если почтовые данные неверны, $ _POST не будет содержать ничего. Тем не менее, вход php: // будет иметь неверную строку.

Например, есть некоторые приложения ajax, которые не формируют правильную последовательность ввода ключевого слова для загрузки файла и просто выгружают весь файл в виде пост-данных без имен переменных или чего-то еще. $ _POST будет пустым, $ _FILES также пуст, а вход php: // будет содержать точный файл, написанный как строка.