最近我正在研究 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、图像……)时,“降级”名称会“感觉不对”。特别是如果希望用户将这些文件保存在磁盘上..如何处理这个问题?