是否允许包含空格的URL？

是否允许URI(特别是HTTP URL)包含一个或多个空格字符？如果必须对URL 进行编码,这+只是一个常用的约定,还是合法的替代方案？

特别是,有人可以指向一个RFC,表明必须编码带空格的URL 吗？

问题的动机:在对网站进行beta测试时,我注意到有些网址是用空格构建的.Firefox似乎做对了,让我感到惊讶!但我希望能够将开发人员指向RFC,以便他们觉得需要修复这些URL.

1> Marc Novakow..：

---

根据RFC 1738:

不安全:

出于多种原因,角色可能不安全. 空间字符是不安全的,因为当URL被转录或排版或受到文字处理程序的处理时,重要的空格可能会消失并且可能引入无关紧要的空间. 字符"<"和">",因为它们被用作在周围自由文本网址的分隔符是不安全的; quote mark(""")用于分隔某些系统中的URL.该字符"#"是不安全的,应该始终进行编码,因为它在万维网和其他系统中用于从可能跟随它的片段/锚标识符中分隔URL.人物"%"是不安全的,因为它用于其他字符的编码.其他字符是不安全的,因为已知网关和其他传输代理有时会修改这些字符.这些字符是"{","}","|","\","^","~", "[","]",和"`".

所有不安全的字符必须始终在URL中编码.例如,"#"即使在通常不处理片段或锚标识符的系统中,字符也必须在URL中编码,因此如果将URL复制到另一个使用它们的系统中,则无需更改URL编码.

---

2396已被3986取代.许多人都错了,因为RFC是不可改变的,因此不会告诉读者他们已经过时了.提示:使用http://tools.ietf.org/html/rfcnnnn,例如http://tools.ietf.org/html/rfc2396,它会在顶部显示缺少的元数据.

2> Julien..：

---

为什么必须编码？请求如下所示:

GET /url HTTP/1.1
(Ignoring headers)

有3个字段由空格分隔.如果你在网址中加了一个空格:

GET /url end_url HTTP/1.1

你知道有4个字段,HTTP服务器会告诉你这是一个无效的请求.

GET /url%20end_url HTTP/1.1

3个字段=>有效

注意:在查询字符串中(在？之后),空格通常编码为+

GET /url?var=foo+bar HTTP/1.1 

而不是

GET /url?var=foo%20bar HTTP/1.1 

---

我认为这是传输层的要求,而不是URI规范本身的要求.GET显然是http:规范的属性,而不是URL规范.同样地,你可以争论网址中的引号"必须"被编码,因为否则网页会破坏.但这是HTML格式限制的属性(还有其他策略),而不是URL规范的属性.

3> Peter Hilton..：

---

更短的答案:不,你必须编码一个空格; 将空格编码为正确+,但仅在查询字符串中; 在你必须使用的路径中%20.

4> Rob Williams..：

---

URL在RFC 3986中定义,但其他RFC也是相关的,但RFC 1738已过时.

它们可能没有空格,还有许多其他字符.由于这些禁用字符通常需要以某种方式表示,因此有一种方案可以将它们转换为带有"%"前缀的ASCII十六进制等效值的URL.

大多数编程语言/平台提供用于编码和解码URL的功能,尽管它们可能不正确地遵守RFC标准.例如,我知道PHP没有.

5> user54650..：

---

是的,空间通常编码为"%20".出于安全原因,应该对传递给URL的任何参数进行编码.

6> A.M Web Surf..：

---

URL中可以包含空格字符,并且在大多数浏览器中它们将显示为%20,但浏览器编码规则经常更改,我们无法依赖浏览器如何显示URL.

所以相反,你可以用你认为会使URL更具可读性和'漂亮'的任何字符替换URL中的空格字符.)所以首选的一般字符是" - ","_", "+"....但这些不是强制性的,所以你可以使用任何不应该在URL中的角色.

请避免%,&,},{,],[,/,>,<作为URL空间字符替换,因为它们可能会在某些浏览器和平台上引发错误.

正如您所看到的,Stak溢出本身使用' - '字符作为空格(%20)替换.

有一个快乐的质疑.

7> Chris Ballan..：

---

网址应不会有他们的空间。如果需要解决的话，请使用其编码值%20

8> Julian Resch..：

---

有人可以指向RFC,指示必须编码带空格的URL吗？

URI和RFC因此在RFC 3986中定义.

如果你看一下那里定义的语法,你最终会注意到空格字符永远不能成为语法上合法的URL的一部分,因此术语"带空格的URL"本身就是一个矛盾.