是否允许URI（特别是HTTP URL）包含一个或多个空格字符？如果网址必须被编码，+只是一个常用的约定，还是合法的替代？
特别是，有人可以指向一个RFC，表明带有空格的网址必须进行编码吗？
提问的动机：在对网站进行beta测试时，我注意到有些网址是用空格构建的。 Firefox似乎做对了，让我感到惊讶！但我希望能够将开发人员指向RFC，以便他们觉得需要修复这些URL。
答案 0 :(得分：91)
根据RFC 1738：
不安全：
由于多种原因，角色可能不安全。 空间 角色是不安全的，因为重要的空间可能会消失 当转录URL时，可能会引入无关紧要的空格 排版或接受文字处理程序的处理。 字符
"<"和">"不安全，因为它们被用作 自由文本中的URL分隔符;引号（"""）用于 在某些系统中划分URL。角色"#"不安全且应该 总是被编码，因为它在万维网和其他网络中使用 用于从可能的片段/锚标识符界定URL的系统 跟着它。字符"%"不安全，因为它用于 其他角色的编码。其他角色不安全因为 已知网关和其他传输代理有时会修改 这样的人物。这些字符为"{"，"}"，"|"，"\"，"^"，"~"，"["，"]"和"`"。所有不安全的字符必须始终在网址中进行编码。对于 例如，字符
"#"必须在URL中编码，即使在 通常不处理片段或锚点的系统 标识符，以便将URL复制到另一个系统中 确实使用它们，没有必要更改URL编码。
答案 1 :(得分：40)
为什么必须编码？请求如下所示：
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个字段=＆gt;有效
注意：在查询字符串中（在？之后），空格通常编码为+
GET /url?var=foo+bar HTTP/1.1
而不是
GET /url?var=foo%20bar HTTP/1.1
答案 2 :(得分：29)
答案较短：不，你必须编码一个空格; 是否正确将空格编码为+，但仅限于查询字符串;在路径中，您必须使用%20。
答案 3 :(得分：9)
网址在RFC 3986中定义，但其他RFC也相关，但RFC 1738已过时。
它们中可能没有空格，还有许多其他字符。由于这些禁用字符通常需要以某种方式表示，因此有一种方案可以将它们转换为URL，将其转换为带有“％”前缀的ASCII十六进制等效值。
大多数编程语言/平台都提供编码和解码URL的功能，但它们可能无法正确遵守RFC标准。例如，我知道PHP没有。
答案 4 :(得分：6)
URL中可以包含空格字符，并且在大多数浏览器中它们将显示为％20，但浏览器编码规则经常更改，我们无法依赖浏览器显示网址的方式。
所以相反，你可以用你认为会使URL更可读和'漂亮'的任何字符替换URL中的空格字符;）......所以首选的一般字符是“ - ”，“ _“，”+“......但这些不是强迫性的，所以你可以使用任何不应该在URL中的角色。
请避开％，＆amp;，}，{，]，[，/，＆gt;，＆lt;作为URL空间字符替换，因为它们可以在某些浏览器和平台上引发错误。
正如您所看到的，Stak溢出本身使用' - '字符作为空格（％20）替换。
有一个快乐的问题。
答案 5 :(得分：5)
是的，空格通常编码为“％20”。 传输到URL的任何参数都应该进行编码，只是为了安全起见。
答案 6 :(得分：5)
网址不中有空格。如果您需要解决一个问题，请使用其编码值%20
答案 7 :(得分：5)
有人可以指向RFC，表明必须对带空格的网址进行编码吗？
URI和URL因此在RFC 3986中定义。
如果你查看那里定义的语法，你最终会注意到空格字符永远不能成为语法上合法的URL的一部分，因此术语“带空格的URL”本身就是一个矛盾。
答案 8 :(得分：4)
回答你的问题。我会说应用程序替换将在URL中使用的值中的空格是相当常见的。这样做的原因是为了避免发生更难以读取的百分比（URI）编码。
查看此维基百科关于Percent-encoding的文章。
答案 9 :(得分：2)
Firefox 3会在URL中显示%20作为地址栏中的空格。
答案 10 :(得分：-3)
没见过。也许您可以将Web服务器配置为接受...