当前位置：文江博客话题详情

空格何时应编码为加号 (+) 或 %20？

发布于 2024-08-29 06:26:05 字数 83 浏览 5 评论 0原文

有时，空格的 URL 会编码为 + 符号，有时会编码为 %20。有什么区别以及为什么会发生这种情况？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

泪冰清 2024-09-05 06:26:05

+ 表示 application/x-www-form-urlencoded 内容中仅的空格，例如 URL 的查询部分：

http://www.example.com/path/foo+bar/path?query+name=query+value

在此 URL 中，参数名称为查询名称，带空格，值为查询值，带空格，但路径中的文件夹名称字面上是foo+bar< /code>，不是 foo bar。

%20 是在这些上下文中对空格进行编码的有效方法。因此，如果您需要对字符串进行 URL 编码以包含在 URL 的一部分中，则始终可以安全地将空格替换为 %20 并将加号替换为 %2B。例如，这就是 encodeURIComponent() 在 JavaScript 中所做的事情。不幸的是，这不是 urlencode 在 PHP 中所做的事情（rawurlencode 更安全）。

另请参阅

HTML 4.01 规范 application/x-www-form- urlencoded

+ means a space only in application/x-www-form-urlencoded content, such as the query part of a URL:

http://www.example.com/path/foo+bar/path?query+name=query+value

In this URL, the parameter name is query name with a space and the value is query value with a space, but the folder name in the path is literally foo+bar, not foo bar.

%20 is a valid way to encode a space in either of these contexts. So if you need to URL-encode a string for inclusion in part of a URL, it is always safe to replace spaces with %20 and pluses with %2B. This is what, e.g., encodeURIComponent() does in JavaScript. Unfortunately it's not what urlencode does in PHP (rawurlencode is safer).

但是……真的吗？请记住，HTML 本身就是一种内容规范，带有查询字符串的 URL 可以与 HTML 以外的内容一起使用。此外，虽然 HTML 规范的更高版本继续将 + 定义为 application/x-www-form-urlencoded 内容中的合法内容，但它们完全省略了 GET 的部分请求查询字符串被定义为该类型。事实上，HTML 2.0 规范之后的任何内容中都没有提及查询字符串编码。

这给我们留下了一个问题——它有效吗？当然，有很多遗留代码支持查询字符串中的+，并且还有很多代码生成它。因此，如果使用 +，您很可能不会崩溃。（事实上，我最近对此进行了所有研究，因为我发现一个主要网站未能在 GET 查询作为空格。它们实际上无法解码任何百分比编码字符。因此您正在使用的服务可能与以下相关：好吧。）

但是从纯粹阅读规范来看，如果没有将 HTML 2.0 规范中的语言延续到更高版本中，URL 完全被 RFC 3986，这意味着空格应该转换为 %20。如果您请求的是 HTML 文档以外的任何内容，那么情况肯定会如此。

So, the answers here are all a bit incomplete. The use of a %20 to encode a space in URLs is explicitly defined in RFC 3986, which defines how a URI is built. There is no mention in this specification of using a + for encoding spaces - if you go solely by this specification, a space must be encoded as %20.

The mention of using + for encoding spaces comes from the various incarnations of the HTML specification - specifically in the section describing content type application/x-www-form-urlencoded. This is used for posting form data.

Now, the HTML 2.0 specification (RFC 1866) explicitly said, in section 8.2.2, that the query part of a GET request's URL string should be encoded as application/x-www-form-urlencoded. This, in theory, suggests that it's legal to use a + in the URL in the query string (after the ?).

But... does it really? Remember, HTML is itself a content specification, and URLs with query strings can be used with content other than HTML. Further, while the later versions of the HTML spec continue to define + as legal in application/x-www-form-urlencoded content, they completely omit the part saying that GET request query strings are defined as that type. There is, in fact, no mention whatsoever about the query string encoding in anything after the HTML 2.0 specification.

Which leaves us with the question - is it valid? Certainly there's a lot of legacy code which supports + in query strings, and a lot of code which generates it as well. So odds are good you won't break if you use +. (And, in fact, I did all the research on this recently because I discovered a major site which failed to accept %20 in a GET query as a space. They actually failed to decode any percent encoded character. So the service you're using may be relevant as well.)

But from a pure reading of the specifications, without the language from the HTML 2.0 specification carried over into later versions, URLs are covered entirely by RFC 3986, which means spaces ought to be converted to %20. And definitely that should be the case if you are requesting anything other than an HTML document.

回复收藏 0 原文

梦屿孤独相伴 2024-09-05 06:26:05

http://www.example.com/some/path/to/resource?param1=value1

问号之前的部分必须使用 % 编码（因此 %20 为空格），在问号后可以使用 %20 或 + 来表示空格。如果您需要在问号后添加实际的 +，请使用 %2B。

回复收藏 0 原文

风追烟花雨 2024-09-05 06:26:05

出于兼容性原因，最好始终将空格编码为“%20”，而不是“+”。

这是 RFC 1866（HTML 2.0 规范），它指定应对空格字符进行编码作为“application/x-www-form-urlencoded”内容类型键值对中的“+”。（参见第 8.2.1 段第 1 段）。这种表单数据的编码方式在后面的HTML规范中也给出了，查找application/x-www-form-urlencoded的相关段落。

以下是 URL 字符串的示例，其中 RFC 1866 允许将空格编码为加号：“http://example.com/over/there?name=foo+bar”。因此，根据 RFC 1866，只有在“？”之后，空格才可以用加号替换。在其他情况下，空格应编码为 %20。但由于很难确定上下文，因此最好不要将空格编码为“+”。

我建议对除 RFC 3986 中定义的“unreserved”之外的所有字符进行百分比编码，第 2.3 页。

unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

您可能希望将空格编码为“+”（一个字节）而不是“%20”（三个字节）的唯一情况是当您确定如何解释上下文，并且查询字符串的大小为本质。

For compatibility reasons, it's better to always encode spaces as "%20", not as "+".

It was RFC 1866 (HTML 2.0 specification), which specified that space characters should be encoded as "+" in "application/x-www-form-urlencoded" content-type key-value pairs. (see paragraph 8.2.1. subparagraph 1.). This way of encoding form data is also given in later HTML specifications, look for relevant paragraphs about application/x-www-form-urlencoded.

Here is an example of a URL string where RFC 1866 allows encoding spaces as pluses: "http://example.com/over/there?name=foo+bar". So, only after "?", spaces can be replaced by pluses, according to RFC 1866. In other cases, spaces should be encoded to %20. But since it's hard to determine the context, it's the best practice to never encode spaces as "+".

I would recommend to percent-encode all characters except "unreserved" defined in RFC 3986, p.2.3.

unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

The only situation when you may want to encode spaces as "+" (one byte) rather than "%20" (three bytes) is when you know for sure how to interpret the context, and when the size of the query string is of the essence.

回复收藏 0 原文