I think Joern was the one that implemented that replacement, will ask him.

John changed that as part of [3115].

Please remove the .replace(/%20/g, "+") from jQuery.param -- if it was the right thing to do, it would already be part of encodeURIComponent.

I agree that this should be removed. To see it at work, create a simple page that has a JS action that does a decodeURIComponent() and then re-encodes it with the .replace() and click on it a couple times, the URLs will go from:

foo bar,baz

foo+bar%2Cbaz

foo%2Bbar%2Cbaz

Very annoying.

jQuery conforms to the HTML 4.01 specification, which defines the application/x-www-form-urlencoded content type.

#10119 is a duplicate of this ticket.

Ugh... the HTML 4.01 specifications are a pretty strong argument, but it still sucks.

I know tons of people that tweak their jQuery to remove this behavior to save themselves a lot of headaches.

Most things seem to play nicely with spaces as %20... while replacing with + seems to more often cause problems (mostly encountered with other javascript based code that often seems to assume you used encodeURIComponent and thus the process can be reversed with decodeURIComponent... teaches them for assuming!)

Interestingly,

mailto:bloke@somewhere?subject=Hello+World

The subject line still has the +

whereas:-

mailto:bloke@somewhere?subject=Hello%20World

works (yes, yes, different standards, but I wonder why they made an exception for spaces in forms rather than just sticking to rfc1738).

rfc1738

#11369 is a duplicate of this ticket.

value = value.replace(/%20/g, " ");

While it is correct to conform to http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1 for form data, it is not correct to use that specification for the generic encoding of a URI. The correct document to use is RFC 3986 (http://tools.ietf.org/html/rfc3986) "Uniform Resource Identifier (URI): Generic Syntax". No + encoding of space characters is ever defined, and percent-ecoding the space character is explicitly mentioned:

Section 2.1 (http://tools.ietf.org/html/rfc3986#section-2.1):

A percent-encoding mechanism is used to represent a data octet in a

component when that octet's corresponding character is outside the

allowed set or is being used as a delimiter of, or within, the

component. A percent-encoded octet is encoded as a character

triplet, consisting of the percent character "%" followed by the two

hexadecimal digits representing that octet's numeric value. For

example, "%20" is the percent-encoding for the binary octet

"00100000" (ABNF: %x20), which in US-ASCII corresponds to the space

character (SP). Section 2.4 describes when percent-encoding and

decoding is applied.

Reopen, please, and fix it. This makes is compatible to the native javascript url en/decode functions, which all encode " " as "%20", but do not decode "+" as " ".

HTML URL Encoding Reference

I'll add my +1 (or is it %2B1?)

The replacing with + appears unnecessary, and a bit annoying for a lot of people.

Thanks for contributing, but please don't post +1's that don't include new information.

+1 doesn't change the reason we closed it. If you have a valid reason for reopening other than it annoys you, we're willing to here it, but the reason we're not fixing is clearly laid out in this report.

There are four reasons to re-open this bug.

1. The RFC relied upon by JQuery to leave this as unfixed only relates to form encoded content. As mentioned by a previous poster, the appropriate RFC for general URI encoding is http://tools.ietf.org/html/rfc3986#section-2.1

2. OAUTH authenticated clients must reverse this replacement made by JQuery prior to computing the signature component of the OAUTH header.

http://tools.ietf.org/html/rfc5849#section-3.6

3. When posting data to nodejs based servers, again the JQuery replacment must be specifically accounted for as it is incompatible with native javascript url encoding and decoding functions.

4. Although multiple practical circumstances show a preference for encoding space as %20 and the appropriate RFC also prefers this encoding, there is no practical benefit to encoding space as '+'.

This should most definitely be changed, or for backwards compatibility reasons add an option to toggle this functionality. In fact, unless this is changed, the documentation is wrong. There are two functions for a reason.

Param Docs

Description: Create a serialized representation of an array or object, suitable for use in a URL query string or Ajax request.

Serialize Docs

Description: Encode a set of form elements as a string for submission.

Clearly, param should be using standards for URI data (%20), as Michael Walters stated above, while serialize should use standards for form data. Param could take an optional parameter to serialize data using the + character for supporting serialize internally, and for backwards compatibility. Unfortunately if this parameter is exposed as a boolean, it will conflict with the traditional parameter used to support jQuery pre-1.4