如果有的话，像{和}（花括号）这样的字符应该在URL中进行百分比编码吗？

Question

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

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

似乎很清楚，一般应编码保留字符（以防止误解）而不编码未保留字符（为了便于阅读），但如何处理不属于任何类别的字符？ For示例{和}不会出现在任何一个列表中，但它们是标准的ASCII字符。

在现代浏览器中寻求指导，似乎它们有时会有不同的行为。 例如，请考虑将网址https://www.google.com/search?q={粘贴到网络浏览器的地址栏中：

• 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={（删除“搜索”并将?更改为#，则使字符成为片段/哈希的一部分而不是查询字符串）找到：

• 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异步执行请求时（即使用this MDN example修改为使用?q={的URL），URL不会自动进行百分比编码。 （我猜这是因为XMLHttpRequest API假定事先对URL进行编码/转义。）

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

Answer 1

（RFC 2396）

你应该编码任何 unwise 部分，rfc给出原因。

---

RFC的其他信息

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

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

如果您打算允许`处于查询字符串值中，那么这是一种特殊情况，因为#是uri的fragment identifier。

某些不需要编码的字符可以是编码的，也可以不是#

。

~（空格）和%20

有2种普遍接受的编码

Here's a fiddle我正在使用的一些测试用例。