最佳答案
在 HTTP URL 的路径部分中，斜杠(“/”)相当于编码的斜杠(“% 2F”)
我有一个在 URL 的路径部分(而不是查询字符串)对待“/”和“% 2F”不同的网站。根据 RFC 或现实世界，这是一件坏事吗？
我问这个问题是因为我不断遇到一些令人惊讶的事情，比如我正在使用的 Web 框架(Ruby on Rails) ，以及它下面的层次(Passer，Apache，例如，我必须为 Apache 启用“ ALLOW _ ENCODED _ SLASHES”)。我现在倾向于完全摆脱编码斜杠，但我不知道我是否应该归档错误报告，我看到了奇怪的行为，包括编码斜杠。
至于为什么我有编码斜杠放在首位，基本上我有这样的路线:
:controller/:foo/:bar
Where: foo 类似于可以包含斜杠的路径。我认为最直接的方法就是只用 URL 转义 foo，这样斜杠就会被路由机制忽略。现在我有些怀疑，很明显框架并不真正支持这一点，但是根据 RFC，这样做是错误的吗？
以下是我收集到的一些信息:
RFC 1738(URL) :
通常，当一个八位组由一个字符表示时和当它被编码时，URL 具有相同的解释。但是，对于保留字符则不是这样: 对为特定方案保留的字符进行编码可能会更改 URL 的语义。
RFC 2396(URI) :
这些字符被称为“保留”，因为它们在 URI 组件中的使用仅限于其保留用途。如果 URI 组件的数据与保留用途冲突，那么在形成 URI 之前必须转义冲突的数据。
(这里的转义是否意味着编码保留字符以外的其他内容?)
RFC 2616(HTTP/1.1) :
“保留”和“不安全”集(参见 RFC 2396[42])中的字符以外的其他字符相当于它们的“%”“ HEX”编码。
Rails 也有 这个漏洞报告，它们似乎期望编码后的斜杠有不同的表现:
是的，我期待不同的结果，因为它们指向不同的资源。
它在根目录中查找文本文件‘ foo/bar’。非转义版本在 foo 目录中查找文件栏。
从 RFC 中可以清楚地看出，原始与编码对于无保留字符是等价的，但是保留字符的故事是怎样的呢？
