ChatGPT解决这个技术问题 Extra ChatGPT

When should space be encoded to plus (+) or %20? [duplicate]

This question already has answers here: URL encoding the space character: + or %20? (5 answers) Closed 8 months ago.

Sometimes the spaces get URL encoded to the + sign, and some other times to %20. What is the difference and why should this happen?


P
Peter Mortensen

+ 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).

See Also

HTML 4.01 Specification application/x-www-form-urlencoded


really I am confused, My Question is, when the browser do the first form, and when do the second fomr?
The browser will create a query+name=query+value parameter from a form with <input name="query name" value="query value">. It will not create query%20name from a form, but it's totally safe to use that instead, eg. if you're putting a form submission together youself for an XMLHttpRequest. If you have a URL with a space in it, like <a href="http://www.example.com/foo bar/">, then the browser will encode that to %20 for you to fix your mistake, but that's probably best not relied on.
what function on javascript make foo bar to foo+bar ?
@Sisir: there isn't a JS function that will do URL-form-encoding. You can naturally do encodeURIComponent(s).replace(/%20/g, '+') if you really need +
That's a very, very confusing example of something that's form-urlencoded. It has nothing to do with URLs.
P
Peter Mortensen

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.


To add to your answer, Chrome by default encodes spaces in URLs as %20 (<a href="?q=a b">), but when you send a form, it uses the + sign. You can override that by explicitly using the + sign (<a href="?q=a+b">), or by sending the form using XMLHTTPRequest.
It's really hard to understand purpose of adding URLSearchParams developers.google.com/web/updates/2016/01/urlsearchparams, which works in some legacy way (serialize SPACE into '+'). It's even not supported in IE11!
c
cerberos

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

The part before the question mark must use % encoding (so %20 for space), after the question mark you can use either %20 or + for a space. If you need an actual + after the question mark use %2B.


@DaveVandenEynde Why not?
because it's wrong. It's part of the old application/x-www-form-urlencoded media type that doesn't apply to URLs. Also, decodeURIComponent doesn't decode it.
Yeah it's probably copied over from RFC 1630 and never really was a standard. tools.ietf.org/html/rfc3986 is the standard (updated again for IPv6 or something). Sure browsers still "support" it but what does that mean? It's either the server or client code that reads the query string and decodes it, not the browser. The browser simply passes it back and forth, and since the + is a reserved character it will be preserved by the browser.
Google uses +'s for spaces in it's search urls (google.com/#q=perl+equivalent+to+php+urlencode+spaces+as+%2B).
FYI: Rails also decodes spaces in with + by default ({ foo: 'bar bar'}.to_query => foo=bar+bar)
P
Peter Mortensen

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.


In .Net Framework UrlEncode uses ‘+’ in QueryString, but in modern .Net Core %20 is used
@MiFreidgeimSO-stopbeingevil Thank you for letting us know. It seems that the modern .Net Core decided to be more consistent and compatible.
P
Peter Mortensen

What's the difference? See the other answers.

When should we use + instead of %20? Use + if, for some reason, you want to make the URL query string (?.....) or hash fragment (#....) more readable. Example: You can actually read this:

https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces (%2B = +)

But the following is a lot harder to read (at least to me):

https://www.google.se/#q=google%20doesn%27t%20oops%20:%20%20this%20text%20%2B%20is%20different%20spaces

I would think + is unlikely to break anything, since Google uses + (see the 1st link above) and they've probably thought about this. I'm going to use + myself just because readable + Google thinks it's OK.


I say the "readability" argument is the best defense for '+'. The "google does it" argument is fallacious en.wikipedia.org/wiki/Argument_from_authority
@FlipMcF The fallacious argument-from-authority Wikipedia page is about "when an authority is cited on a topic outside their area of expertise or when the authority cited is not a true expert" — I think, however, that computers, HTTP and URL encoding is stuff within Google's area of expertise.
@FlipMcF Citing google's behavior, in this case, is a valid argument to using "+" in URLs. It's not that google is an authority, but that google is probably the biggest internet company and if they do something in some way, it is highly unlikely that browsers will one day decide to stop supporting that practice. Also, google chrome is one of the browsers with highest share, and they will support whatever google wants to. All in all, I'd say that no one using "+" instead of "%20" will have a hard time because of that in the foreseeable future.
I would love to continue this argument somewhere else, where there is an appeal to popularity to refuse to acknowledge an appeal to authority. At least we can all agree on one thing: '+' is superior to '%20'
Actually the URL with %20 is a lot easier to read because (desktop) browsers show the decoded URL at the bottom of the window if you move the mouse cursor over the link. Plus signs are displayed unchanged.