最近我正在研究 HTTP 查询字符串，同时想知道 Web 服务访问接口API的可能性。而且它似乎非常不明确。
事实上，RFC 3986（统一资源标识符（URI）：通用语法）没有说明查询字符串片段的格式，并以定义允许的字符以及如何编码其他字符结束。（我稍后会回到这个。）
我发现的唯一内容是关于如何将表单转换为查询字符串的 HTML 规范（HTML 4.01；17.13.4 表单内容类型，application/x-www-form-urlencoded）。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 URI 属性值中的与号）建议 HTTP 服务器接受分号 ( ;) 作为参数分隔符（与 & 号相反&）。
有服务器支持吗？有人用这个吗？是否值得为此烦恼（在考虑允许的 Web 服务查询字符串格式时）？
那么非ASCII字符支持怎么样？
HTML 4.01 规范（B.2.1 URI 属性值中的非 ASCII 字符）清楚地重申了首先描述 RFC 的 URI：URI 中不允许使用非 ASCII 字符。然而，规范考虑了现有实践（使用非法 URI）并建议将此类字符更改为 UTF-8 编码，然后使用 URI 标准十六进制编码处理每个字节。
从我的测试看来，例如 Chrome 和 Firefox 就是这样做的。但 Internet Explorer 并没有，而是照原样发送这些字符。PHP 部分解决了这个问题。$_SERVER['QUERY_STRING']并$_GET包含那些字符。但取而代之的是$_SERVER['REQUEST_URI']包含。?
是否有任何标准或做法来处理此类案件？
另一个相关的问题是作者应该如何发布（通过 URI）名称包含非 ASCII（例如国家）字符的资源？考虑到所有各方（HTML 代码、浏览器发送请求、浏览器保存文件磁盘、服务器接收和处理请求以及服务器存储文件），它似乎几乎不可能始终如一地工作。或者至少我从来没有成功过。
当涉及到网页时，我已经习惯了，并且总是用相应的拉丁语基本字符替换国家字符。但是，当涉及到外部文件（PDF、图像……）时，“降级”名称会“感觉不对”。特别是如果希望用户将这些文件保存在磁盘上..如何处理这个问题？