服务器应该接受& 而不是在URL获取请求？

Question

INTRO
我会给你一个例子,所以我的问题可能更容易理解.我在编程问题上不需要"帮助",只需要关于这个主题的信息!

示例
我尝试了一个用于获取特定位置的天气信息的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&format=json&num_of_days=1&key=APIKEY

但是,当使用cURL请求此URL的数据时,我收到了未提供api-key的错误.我发现,问题是&在URL 中使用符号.当我使用这样的http_build_query方法时:

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

网址如下所示:http://api.worldweatheronline.com/free/v1/weather.ashx？q = 48.13743 %2C11.57549&format = json&num_of_days = 1&key = APIKEY

问题
现在我想问一下,如果这是服务器的预期行为.我从其他几个API(Facebook,Foursquare等)中了解到,他们接受&而不是&在URL中工作,并且按预期工作.

有标准吗？服务器是否应该接受&或接受它是"错误的"并且只能&被接受？谢谢!

Answer 1

类似的HTML实体&不是URI规范的一部分.就RFC 3986而言,&是一个子分隔符,因此如果服务器收到如下的查询字符串:

foo=1&bar=2

并将其解析为以下键值对:

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

它行为正确.

为了使事情更有趣,;也是一个保留的子分隔符,但是:

如果在URI组件中找到保留字符且该字符不知道分隔角色,则必须将其解释为表示与该字符在US-ASCII中的编码对应的数据八位字节.