是否允许URL包含空格？
URI（特别是HTTP URL）是否允许包含一个或多个空格字符？ 如果一个URL 必须被编码，那么+是一个普遍遵循的约定，还是一个合法的替代？
特别是，有人可以指向一个RFC，指出一个空格的URL 必须被编码？
问题的动机：在testing一个网站的时候，我注意到一些URL是用空格构build的。 Firefox似乎做了正确的事情，这让我感到惊讶！ 但我希望能够将开发人员指向RFC，以便他们觉得需要修复这些URL。
根据RFC 1738 ：
不安全：
字符可能由于多种原因而不安全。 空格字符是不安全的，因为重要空格可能会消失，当URL被转录或排版或受到文字处理程序的处理时，可能引入不重要的空格。 字符
"<"和">"是不安全的，因为它们被用作自由文本中的URL周围的分隔符; 在某些系统中，引号（"""）用于分隔URL，字符"#"是不安全的，应该总是被编码，因为它在万维网和其他系统中被用来从片段/定界符标识符可能跟着它，字符"%"是不安全的，因为它用于其他字符的编码，其他字符是不安全的，因为网关和其他传输代理有时会修改这些字符，这些字符是"{"，"}"，"|"，"\"，"^"，"~"，"["，"]"和"`"。所有不安全的字符必须始终在URL中进行编码 。 例如，即使在通常不处理片段或锚点标识符的系统中，字符
"#"必须在URL中编码，以便如果URL被复制到另一个使用它们的系统中，则不需要更改url编码。
为什么要编码？ 请求看起来像这样：
GET /url HTTP/1.1 (Ignoring headers)
有3个空格分隔的字段。 如果你在你的url中放置一个空格：
GET /url end_url HTTP/1.1
你知道有4个字段，HTTP服务器会告诉你这是一个无效的请求。
GET /url%20end_url HTTP/1.1
3个字段=>有效
注意：在查询string（？）之后，空格通常被编码为+
GET /url?var=foo+bar HTTP/1.1
而不是
GET /url?var=foo%20bar HTTP/1.1
较短的答案：不，你必须编码一个空格; 将空格编码为+ ，但仅在查询string中是正确的; 在path中你必须使用%20 。
URL是在RFC 3986中定义的，尽pipe其他的RFC也是相关的，但是RFC 1738已经过时了。
他们可能没有空格，还有其他许多angular色。 由于那些被禁止的字符通常需要以某种方式表示，所以有一种scheme将它们编码成一个URL，通过将它们转换成ASCIIhex等同于“％”的前缀。
大多数编程语言/平台提供编码和解码URL的function，尽pipe它们可能不能很好地遵守RFC标准。 例如，我知道PHP不。
是的，虽然空间通常编码为“％20”。 传递给URL的任何参数都应该进行编码，只是为了安全起见。
有人可以指向一个RFC，指出一个空格的URL必须被编码？
URI和URL，在RFC 3986中定义。
如果你看看在那里定义的语法，你最终会注意到空格字符永远不会成为句法合法URL的一部分，因此术语“带空格的URL”本身就是一个矛盾。
这是一个很棒的网页，向您展示了如何使用多种不同的技术进行编码。
http://andrewu.co.uk/tools/uriencoder/
回答你的问题。 我想说，应用程序replaceURL中使用的值的空格是相当常见的。 这样做的原因是为了避免更难以阅读的百分比（URI）编码。
看看这个关于百分比编码的维基百科文章。
URL可以有一个空格字符，它们将在大多数浏览器中显示为％20，但是浏览器编码规则经常变化，我们不能依赖于浏览器如何显示URL。
所以相反，你可以用URL中的空格字符来replace你认为能使URL更易读和“漂亮”的任何字符;）所以，一般的字符是“ – ”，“_”，“ “+”….但是这些不是强迫，所以你可以使用任何不应该在URL中的字符已经。
请避免将％，＆，}，{，]，[，/，>，<作为URL空格字符replace，因为它们可能会在某些浏览器和平台上引发错误。
正如你所看到的Stak溢出本身使用' – '字符作为空间（％20）replace。
有一个快乐的提问。
url不应该有空格。 如果您需要解决这个问题，请使用其编码值%20
Firefox 3将在地址栏中以空格显示%20 s。
没有看到。 也许你可以configurationWeb服务器来接受…
