rawurlencode was changed in revision 260750: http://svn.php.net/viewvc?view=revision&revision=260750

It mentions RFC3986, but after reading it seems to me that ~ should also be un-encoded in urlencode not just rawurlencode

RFC 3986, which apparently rawurlencode is to follow (though the documentation mentions the obsolete 1738 -- that should be changed):

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

For consistency, percent-encoded octets in the ranges of ALPHA
   (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E),
   underscore (%5F), or tilde (%7E) should not be created by URI
   producers and, when found in a URI, should be decoded to their
   corresponding unreserved characters by URI normalizers.

So the behavior of rawurlencode is correct in not escaping ~.

urlencode, on the other hand, mentions the encoding mechanism application/x-www-form-urlencoded. This is defined in the HTML 4.01 spec and Xforms 1.1 spec:

* http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1
* http://www.w3.org/TR/2009/REC-xforms-20091020/#serialize-urlencode

The first points to RFC 1738, under which ~ should be encoded, as it is. The second mentions reserved characters "as defined by [RFC 2396] as amended by subsequent documents in the IETF track", so it would refer to the RFC 3986, which obsoletes 2396. I'd say the current behavior is correct because it "plays safe" by following the HTML 4/RFC 1738.

As for EBCDIC, well, the support is broken anyway. urlencode/rawurlencode should receive the string in UTF-8 encoding, since that's the only way it can give meaningful results. The current implementation assumes that, in an EBCDIC system, it receives the string in EBCDIC. But yes, there's an inconsistency between the ASCII and EBCDIC version.

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

Thanks for fixing this!

I think you should also fix the inconsistency between the ASCII and EBCDIC versions before closing this. (I know EBCDIC doesn't work right, but the bug should be fixed for whenever it does work.)

Should I reopen it?

Could you please provide more information regarding the discrepancy in the EBCDIC version? I'm not familiar with EBCDIC.

In the function: php_raw_url_encode

Change:

 if (!isalnum(str[y]) && strchr("_-.", str[y]) != NULL) { 

to:

 if (!isalnum(str[y]) && strchr("_-.~", str[y]) != NULL) { 

(Around line 588, add the ~ to the EBCDIC version of the function.)

Alright, the EBCDIC version of rawurlencode has been fixed in SVN (http://bugs.php.net/bug.php?id=53248), but of course that won't show up just yet.

Once the fix is released, I'll make a note in the documentation to that effect.

Changed to "to be documented".

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.