(PHP 4, PHP 5, PHP 7)
urlencode — URL-кодирование строки
Описание
Эта функция удобна, когда закодированная строка будет использоваться в запросе, как часть URL, также это удобный способ для передачи переменных другим страницам.
Список параметров
Строка, которая должны быть закодирована.
Возвращаемые значения
Возвращает строку, в которой все не цифробуквенные символы, кроме -_. должны быть заменены знаком процента (%), за которым следует два шестнадцатеричных числа, а пробелы кодируются как знак сложения (+). Строка кодируется тем же способом, что и POST данные WWW-формы, то есть по типу контента application/x-www-form-urlencoded. Это отличается от » RFC 3986 кодирования (см. rawurlencode() ) тем, что, по историческим соображениям, пробелы кодируются как знак «плюс» (+).
Примеры
Пример #1 Пример использования urlencode()
Пример #2 Пример использования urlencode() и htmlentities()
Примечания
Будьте внимательны с переменными, которые могут совпадать с элементами HTML. Такие сущности как &, © и £ разбираются браузером и используется как реальная сущность, а не желаемое имя переменной. Это очевидный конфликт, на который W3C указывает в течение многих лет. См. подробности: »
PHP поддерживает изменение разделителя аргументов на рекомендуемый W3C символ «точку с запятой» путём изменения директивы arg_separator в .ini файле. К сожалению, большинство пользовательских приложений не отправляют данные формы в формате с разделителем «точка с запятой». Более переносимый способ решить эту проблему — это использовать & вместо & в качестве разделителя. Вам не нужно будет для этого изменять PHP-директиву arg_separator. Оставьте разделитель как &, но кодируйте ваши URL с помощью htmlentities() или htmlspecialchars() .
Смотрите также
- urldecode() — Декодирование URL-кодированной строки
- htmlentities() — Преобразует все возможные символы в соответствующие HTML-сущности
- rawurlencode() — URL-кодирование строки согласно RFC 3986
- rawurldecode() — Декодирование URL-кодированной строки
- » RFC 3986
Для HTTP запроса типа POST существует два варианта передачи полей из HTML форм, а именно, используя алгоритм application/x-www-form-urlencoded и multipart/form-data . Алгоритм первого типа создавался давным-давно, когда в языке HTML еще не предусматривали возможность передачи файлов через HTML формы.
Со временем возникла необходимость через формы отсылать еще и файлы. Тогда консорциум W3C взялся за доработку формата POST запроса. К тому времени уже достаточно широко применялся формат MIME (Multipurpose Internet Mail Extensions — многоцелевые расширения протокола для формирования Mail сообщений), поэтому, чтобы не изобретать велосипед заново, решили использовать часть данного формата формирования сообщений для создания POST запросов в протоколе HTTP.
Главное отличие multipart/form-data от application/x-www-form-urlencoded в том, что тело запроса теперь можно поделить на разделы, которые разделяются границами. Каждый раздел может иметь свой собственный заголовок для описания данных, которые в нем хранятся, т.е. в одном запросе можно передавать данные различных типов (как в теле письма можно одновременно с текстом передавать файлы). Пример запроса:
Boundary (граница) — это последовательность байтов, которая не должна встречаться внутри передаваемых данных. Content-Length — суммарный объём, включая дочерние заголовки. Само содержимое полей при этом оставляется «как есть».
CURL, multipart/form-data
Файл get.php на сервере :
Важный момент: на форуме PHPCLUB.RU встретил упоминание, что может потребоваться указание полного пути файла — иначе CURL выдает ошибку.
CURL, application/x-www-form-urlencoded
Файл get.php на сервере :
Сокеты, multipart/form-data
Файл get.php на сервере :
Сокеты, application/x-www-form-urlencoded
Файл get.php на сервере :
Метод PUT
Описанные выше способы работают для относительно небольших файлов (примерно до 2-х мегабайт, для получения более точного значения необходимо смотреть в настройках PHP максимальный объем принимаемых данных методом POST). Чтобы обойти это ограничение, будем передавать файл методом PUT:
Я смог использовать клиентское расширение Advanced Rest для Chrome, чтобы отправлять запросы POST на определенный сервер HTTPS, и я получаю код состояния: 200 — ОК с теми же полями тела, что и в этом коде, но когда я запускаю следующий код я получаю этот ответ: 403 — доступ запрещен.
Я также заметил, что когда я использую Advanced Rest Client Extension для Chrome и если я устанавливаю Content-Type на application / json, я должен ввести логин и пароль, которые я не знаю, что это такое, потому что даже если я введите идентификатор и секретный ключ, который у меня есть в коде, он возвращает 401 Несанкционированный. Поэтому я предполагаю, что этот код, который я написал, не принуждает его к типу содержимого: application / x-www-form-urlencoded, но я не уверен. Спасибо за любую помощь в этом вопросе!
Решение
Можете ли вы попробовать так и посмотреть, поможет ли это:
Я предполагаю, что сайт ожидает простой аутентификации на вершине secret_key что вы уже предоставили.
Также есть возможность отправить Cookie, поэтому на всякий случай лучше сохранить его и использовать снова при следующих вызовах Curl.