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

Question

简介
我会给你一个例子，这样我的问题可能会更好理解。我在编程方面不需要“帮助”，只需要关于这个主题的信息！

示例
我为特定职位尝试了API for getting weather information 并偶然发现了一个问题。我建立了我的 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);

最终到达网址如下所示

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 格式。