url转换成html有空格,关于html：URL是否允许包含空格？

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

特别是，有人可以指向RFC指出必须对带有空格的URL进行编码吗？

提出问题的动机：在对网站进行Beta测试时，我注意到某些URL的构造带有空格。 Firefox似乎做对了，这让我感到惊讶！ 但是我希望能够将开发人员指向RFC，以便他们觉得有必要修复这些URL。

后来出现的超集：所有无效字符是什么：stackoverflow.com/questions/1547899/

相关：在URL中，是否应使用％20或+编码空格？

根据RFC 1738：

Unsafe:

Characters can be unsafe for a number of reasons. The space

character is unsafe because significant spaces may disappear and

insignificant spaces may be introduced when URLs are transcribed or

typeset or subjected to the treatment of word-processing programs.

The characters " and ">" are unsafe because they are used as the

delimiters around URLs in free text; the quote mark (""") is used to

delimit URLs in some systems. The character "#" is unsafe and should

always be encoded because it is used in World Wide Web and in other

systems to delimit a URL from a fragment/anchor identifier that might

follow it. The character "%" is unsafe because it is used for

encodings of other characters. Other characters are unsafe because

gateways and other transport agents are known to sometimes modify

such characters. These characters are "{", "}", "|", "\", "^", "~",

"[", "]", and "`".

All unsafe characters must always be encoded within a URL. For

example, the character "#" must be encoded within URLs even in

systems that do not normally deal with fragment or anchor

identifiers, so that if the URL is copied into another system that

does use them, it will not be necessary to change the URL encoding.

1738已被2396取代。ietf.org/rfc/rfc2396.txt这是当前的Uri规范。不过在这种情况下也没关系。

而2396已被3986所取代。由于RFC是不可变的，因此许多人会弄错这一点，因此不会告诉读者它们已被废弃。提示：请改用tools.ietf.org/html/rfcnnnn，例如tools.ietf.org/html/rfc2396，它会在顶部显示缺少的元数据。

为什么必须对其进行编码？请求看起来像这样：

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

如果var确实是" foo + bar"而不是" foo bar"怎么办？

A +必须编码为％2b

我认为这是传输层的要求，而不是URI规范本身的要求。 GET显然是http：规范的属性，而不是URL规范。同样，您可能会争辩网址中的引号"必须"编码，因为否则网页可能会损坏。但这就是HTML格式限制的属性(还有其他针对的策略)，而不是URL规范的属性。

ietf.org/rfc/rfc1738.txt-应编码不安全的字符，包括空格)

@KentFredric这更可能是表示层，而不是传输层。正如Julien(几乎)所写的那样，原始URI规范(RFC 1630)包含此限制，因此无论您的个人感觉如何，它都是URI规范本身的一部分。由于URI规范是在HTTP草案之后编写的，因此很可能URI在设计时就考虑到了HTTP，包括禁止使用空格，但这并不重要，对吗？事实是规格就是规格。

简短的回答：不，您必须对空格进行编码；将空格编码为+是正确的，但只能在查询字符串中进行编码；在路径中，您必须使用%20。

嗨，我也很困惑，有时我看到这本书使用了" +"，但有时却使用了"％20"，您能举一些例子吗？用户提交表单时，表单如何编码空间？与哪个角色？

有关更多详细信息，请参见此答案。

片段/哈希部分呢？那里应该如何编码空格？

@gumkins：片段(＃及之后)未发送到服务器。实际上，您可以在任何地方使用％20或+来编码空格。

URL在RFC 3986中定义，尽管其他RFC也相关，但RFC 1738已过时。

它们中可能没有空格，还有许多其他字符。由于通常需要以某种方式表示那些禁止使用的字符，因此存在一种通过将它们转换为带有"％"前缀的ASCII十六进制等效项将它们编码为URL的方案。

尽管大多数编程语言/平台可能未正确遵循RFC标准，但它们提供了用于编码和解码URL的功能。例如，我知道PHP不会。

URL中可以包含空格字符，并且在大多数浏览器中它们都将显示为％20，但是浏览器编码规则经常更改，因此我们不能依赖于浏览器如何显示URL。

因此，您可以用任何您认为会使URL更具可读性和'Pretty';).....的字符替换URL中的空格字符。因此，首选的通用字符为"-"，" _"，" +" ....但是这些不是强制性的，因此您可以使用URL中已经不应该包含的任何字符。

请避免使用％，＆，}，{，]，[，/，>，

如您所见，Stak溢出本身使用'-'字符作为空格(％20)的替换。

祝您提问愉快。

是的，但是空格通常被编码为"％20"。

出于安全原因，传递给URL的所有参数都应进行编码。

Can someone point to an RFC indicating that a URL with a space must be encoded?

URI和URL是在RFC 3986中定义的。

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

Urls中不应包含空格。如果需要解决的话，请使用其%20的编码值

回答您的问题。我要说的是，应用程序替换将在URL中使用的值中的空格是相当普遍的。通常，这样做的原因是为了避免发生更难读取的百分比(URI)编码。

查阅此有关百分比编码的维基百科文章。

Firefox 3将在URL中的%20中在地址栏中显示为空格。

这不是对非常简单的问题的正确答案："Is a URL allowed to contain a space?"。而是评论。