13

根据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）在现代网络面板中创建难看的百分比编码条目}浏览器的网络检查器/调试器。

4

1 回答 1

5

（RFC 2396）

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

来自 RFC 的附加信息

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

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

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

一些不必编码的字符，无论是否编码都可以接受，例如~

（空格）%20和+

这是我正在使用的一些测试用例的小提琴。

于 2014-09-17T18:26:16.077 回答