是否允许包含空格的URL?

Joe*_*nte 124 html url encoding http

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

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

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

Mar*_*ski 95

根据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,它会在顶部显示缺少的元数据. (39认同)
  • 1738 已被 2396 取代。 http://www.ietf.org/rfc/rfc2396.txt 这是当前的 Uri 规范。不过在这种情况下没关系。 (2认同)

Jul*_*ien 42

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

GET /url HTTP/1.1
(Ignoring headers)
Run Code Online (Sandbox Code Playgroud)

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

GET /url end_url HTTP/1.1
Run Code Online (Sandbox Code Playgroud)

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

GET /url%20end_url HTTP/1.1
Run Code Online (Sandbox Code Playgroud)

3个字段=>有效

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

GET /url?var=foo+bar HTTP/1.1 
Run Code Online (Sandbox Code Playgroud)

而不是

GET /url?var=foo%20bar HTTP/1.1 
Run Code Online (Sandbox Code Playgroud)

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

Pet*_*ton 33

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


Rob*_*ams 9

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

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

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


use*_*650 6

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


A.M*_*fer 6

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

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

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

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

有一个快乐的质疑.


Chr*_*nce 5

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


Jul*_*hke 5

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

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

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