Если сервер принимает & amp; вместо & amp; в URL получить запрос?

ВСТУПЛЕНИЕ
Я приведу вам пример, чтобы мой вопрос был лучше понятен. Мне не нужна «помощь» в вопросах программирования, просто информация по этой теме!

ПРИМЕР
Я опробовал API для получения информации о погоде для конкретной позиции и наткнулся на проблему. Я построил свой URL для запроса данных следующим образом:

$params['q']            = $latitude .','. $longitude; // 48.14,11.58
$params['format']       = $format; //json
$params['num_of_days']  = $numOfDays; //1
$params['key']          = self::APIKEY;

$url = 'http://api.worldweatheronline.com/free/v1/weather.ashx'
$url .= '?'. http_build_query($params);

Конечный URL выглядел так

http://api.worldweatheronline.com/free/v1/weather.ashx?q=48.13743%2C11.57549&Формат = JSON&NUM_OF_DAYS = 1&ключ = APIKEY

Однако при запросе данных для этого URL с помощью cURL я получил сообщение об ошибке, что API-ключ не был предоставлен. Как я выяснил, проблема заключалась в использовании & символы в URL. Когда я использовал http_build_query метод как это:

$url .= '?'. http_build_query($params, null, '&');

URL выглядел так: http://api.worldweatheronline.com/free/v1/weather.ashx?q=48.13743%2C11.57549&Формат = JSON&NUM_OF_DAYS = 1&ключ = APIKEY

ВОПРОС
Теперь то, что я хочу спросить, если это ожидаемое поведение от сервера. Я знаю из нескольких других API (Facebook, Foursquare и т. Д.), Что они принимают & вместо & в URL и работать, как ожидалось.

Есть ли стандарт? Если сервер сможет принять & или это «неправильно» принимать это и должно только & быть принятым? Спасибо!

0

Решение

HTML-сущности, такие как & не являются частью спецификации URI. Так далеко как RFC 3986 обеспокоен, & является символом под разделителя, поэтому, если сервер получает строку запроса, подобную этой:

foo=1&bar=2

и анализирует его для следующих пар ключ-значение:

'foo' => '1',
'amp;bar' => '2'

это ведет себя правильно.

Чтобы сделать вещи еще интереснее, ; также является зарезервированным вложенным разделителем, но:

если зарезервированный символ найден в компоненте URI и без разделителя
Роль известна для этого персонажа, то она должна интерпретироваться как
представляющий октет данных, соответствующий кодировке этого символа
в США-ASCII.

5

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]