<分区>
我知道 %20 和 + 都解码为相同的二进制值(一个空格)，并且对于大多数网络服务器，尤其是那些映射到物理文件的网络服务器，它们将指向相同的资源。
但我的问题是，网址必须像http://www.example.org/hello%20world指向与 http://www.example.org/hello+world 相同的资源, 它们在规范上是否相同？
在 HTTP/1.0 + 中没有映射到空间，所以我专门询问 HTTP/1.1。
<分区>
我知道 %20 和 + 都解码为相同的二进制值(一个空格)，并且对于大多数网络服务器，尤其是那些映射到物理文件的网络服务器，它们将指向相同的资源。
但我的问题是，网址必须像http://www.example.org/hello%20world指向与 http://www.example.org/hello+world 相同的资源, 它们在规范上是否相同？
在 HTTP/1.0 + 中没有映射到空间，所以我专门询问 HTTP/1.1。
最佳答案
仅在查询字符串中:加号是保留字符，因此必须进行编码以在路径或查询字符串中传递实际的“+”。它用作空格的替代品是 W3C Recommendation仅适用于查询字符串:
Within the query string, the plus sign is reserved as shorthand notation for a space. Therefore, real plus signs must be encoded. This method was used to make query URIs easier to pass in systems which did not allow spaces.
URI 比较(RFC 2616):
When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions:
- A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of "/".Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
保留字符 ( RFC 2396 )
";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","
因此，在第三次复飞时:没有任何官方声明它们是同一件事。按字面意义使用“+”将 http://example.org/hello+world 指向名为 hello+world 的目录是不正确的，但没有任何说明应该这样做被认为等同于一个空格。
关于http - http url 中的 %20 和 + 是否相同？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3991874/