HTTP查询和URI编码疑问[关闭]答案

【问题标题】：HTTP query and URI encoding doubts [closed]HTTP查询和URI编码疑问[关闭]
【发布时间】：2012-10-16 17:27:28
【问题描述】：

最近我正在研究 HTTP 查询字符串，同时想知道 Web 服务访问接口 API 的可能性。而且它似乎很不明确。

事实上，RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax) 并没有说明查询字符串片段的格式，而是定义了允许哪些字符以及如何编码其他字符。（我稍后会回到这个。）

我发现的唯一内容是关于如何将表单转换为查询字符串 (HTML 4.01; 17.13.4 Form content types, application/x-www-form-urlencoded) 的 HTML 规范。 HTML 5 算法似乎足够接近 (4.10.22.5 URL-encoded form data)。

这看起来不错。毕竟为什么有人要为其他人设置查询字符串格式。做什么的？但是还有其他（除了 HTML）完善的标准吗？其他人使用不同的格式吗？

这里的一个附带问题是处理表单字段名称中的 []。 PHP 使用它来确保一个字段的多次出现都出现在$_GET 超全局变量中。（否则只有最后一次出现。）

但从RFC 3986 看来，查询字符串中似乎既不允许使用[，也不允许使用]。然而，我对各种浏览器的实验表明，没有浏览器对这些字符进行编码，它们就在 URI 中......

这是现实生活中的实践吗？还是我测试不正确？我在 IIS 7 上使用 PHP 5.3.17 进行了测试。使用 Internet Explorer、Firefox 和 Chrome。然后我比较了$_SERVER['QUERY_STRING']和$_GET中的内容。

另一个问题是现实生活中对分号分隔的支持。

HTML 4.01 规范 (B.2.2 Ampersands in URI attribute values) 建议 HTTP 服务器接受分号 (;) 作为参数分隔符（与与符号 & 相对）。

有服务器支持吗？有人用这个吗？是否值得为此烦恼（在考虑允许的 Web 服务查询字符串格式时）？

那么非ASCII字符支持怎么样？

HTML 4.01 规范 (B.2.1 Non-ASCII characters in URI attribute values) 清楚地重申了首先描述 RFC 的 URI：URI 中不允许使用非 ASCII 字符。然而，规范考虑了现有实践（使用非法 URI）并建议将此类字符更改为 UTF-8 编码，然后使用 URI 标准十六进制编码处理每个字节。

从我的测试看来，例如 Chrome 和 Firefox 就是这样做的。但 Internet Explorer 并没有，而是照原样发送这些字符。 PHP 部分解决了这个问题。 $_SERVER['QUERY_STRING'] 和 $_GET 包含这些字符。但是$_SERVER['REQUEST_URI'] 包含?。

是否有任何标准或做法来处理此类案件？

另一个相关的问题是作者应该如何发布（通过 URI）名称包含非 ASCII（例如国家）字符的资源？考虑到所有各方（HTML 代码、浏览器发送请求、浏览器保存文件磁盘、服务器接收和处理请求以及服务器存储文件），它似乎几乎不可能始终如一地工作。或者至少我从来没有成功过。

当涉及到网页时，我已经习惯了，并且总是用相应的拉丁基本字符替换国家字符。但是，当涉及到外部文件（PDF、图像……）时，“降级”名称会“感觉不对”。特别是如果希望用户将这些文件保存在磁盘上..如何处理这个问题？

【问题讨论】：

您的问题实际上至少包含 5-6 个单独的问题。请考虑将此问题拆分为多个可以分别回答的问题。现在我需要提供一篇文章来给出一个全面的答案。它不适合本网站的问答形式。
如果您需要将查询中的特定字符传递给您的 Web 服务，您应该考虑其他方式来实现 Web 服务 API，例如 XML/SOAP 或 JSON/JSONP，它们是与 REST 一样广泛使用。
我提出了新的（单独的）问题：stackoverflow.com/questions/12928077/http-query-string-format、stackoverflow.com/questions/12928173/http-query-string-and、stackoverflow.com/questions/12928215/…、stackoverflow.com/questions/12928295/national-characters-in-uri 和 stackoverflow.com/questions/12928368/…。所以这个问题现在应该结束了。

标签： http url uri query-string urlencode

【解决方案1】：

您是否检查过 HTTP 规范 (RFC2616)？

看看这些部分：

实用的建议是使用Base64 对您希望包含危险字符的字段进行编码，然后在后端对其进行解码。

顺便说一句。你的问题真的很长。它减少了有人深入研究它的机会。

【讨论】：

【解决方案2】：

事实上 RFC 3986（统一资源标识符 (URI)：通用语法）没有说明查询字符串片段的格式

是的，在第 3.4 节中：

query       = *( pchar / "/" / "?" )

pchar 在第 3.3 节中定义：

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

最后定义允许哪些字符以及如何编码其他字符。

没错。那就是定义查询字符串片段的格式。

但是从 RFC 3986 看来，查询字符串中既不允许 [ 也 ] 也不允许。

正式地说，是的。但并非所有浏览器都这样做，这对它们来说是错误的行为。我见过的所有官方规范（而且 3986 并不是唯一的一个）都说这些字符必须是百分比编码的。

那么非ASCII字符支持怎么样？

URI 中不允许使用非 ASCII 字符。它们必须是字符集编码和百分比编码。实际使用的字符集是特定于服务器的，没有规范允许 URI 指定使用的字符集。各种规范都推荐UTF-8，但不要求UTF-8，国外有些服务器确实不使用UTF-8。

取代 URL/URI 规范的 IRI 规范 (RFC 3987) 支持完整的 Unicode 字符集，但 IRI 仍然相对较新，许多服务器还不支持它们。但是，RFC 确实定义了将 IRI 转换为 URI 的算法，反之亦然。

如有疑问，请对您不确定的所有内容进行百分比编码。服务器需要在存在时支持对它们进行解码，然后再根据需要处理解码后的数据。

【讨论】：