什么时候,像{和}(花括号)这样的字符应该在URL中进行百分比编码？

Question

根据RFC 3986,以下字符是保留的,需要进行百分比编码才能在URI中使用,而不是作为其保留用途: :/?#[]@!$&'()*+,;=

此外,它指定了一些特别保留的字符:a-zA-Z0-9\-._~

似乎很清楚,一般应该编码保留字符(以防止误解)而不编码未保留字符(为了便于阅读),但是如何处理不属于任何类别的字符？例如{,}并没有出现在任何一个列表中,但它们是标准的ASCII字符.

期待现代浏览器的指导,似乎它们有时会有不同的行为.例如,考虑将URL粘贴https://www.google.com/search?q={到Web浏览器的地址栏中:

• Chrome 34.0.1847.116 m不会更改它.
• Firefox 28.0不会改变它.
• Internet Explorer 9.0不会更改它.
• Safari 5.1.7将其更改为 https://www.google.com/search?q=%7B

但是,如果一个粘贴https://www.google.com/#q={(删除"搜索"并将其更改?为a #,使角色成为片段/哈希而不是查询字符串),我们会发现:

• Chrome 34.0.1847.116 m将其更改为https://www.google.com/#q=%7B(通过JavaScript)
• Firefox 28.0不会改变它.
• Internet Explorer 9.0不会更改它.
• Safari 5.1.7将其更改为https://www.google.com/#q=%7B(在执行JavaScript之前)

此外,当使用JavaScript异步执行请求时(即使用此MDN示例修改为使用URL ?q={),URL不会自动进行百分比编码.(我猜这是因为XMLHttpRequest API假定事先对URL进行编码/转义.)

我想(出于与奇怪的客户要求有关的原因)使用{和}在URL的文件名部分中没有(1)破坏事物,理想情况下也没有(2)在现代网络面板中创建丑陋的百分比编码条目浏览器的网络检查员/调试员.

Answer 1

（RFC 2396）

您应该对任何不明智的部分进行编码，并且 rfc 给出了原因。

来自 RFC 的附加信息

主要考虑 < > # %所有控制字符00-1F和7F

在 rfc 中也被标记为不明智：" { } | \ ^ [ ] `

如果您打算允许#在查询字符串值中出现，那么这是一种特殊情况，因为 a#是uri 的片段标识符。

某些不必编码的字符可以接受编码或未编码的字符，例如~

有 2 种普遍接受的编码（空格）%20和+

这是我正在使用的一些测试用例的摆弄。