Javascript escape()/unescape() NO LONGER suitable for URI manipulation
Jungshik writes:
This is to announce that escape()/unescape() was changed recently to make them compliant to ECMA 262 (ECMAscript edition 3). It's fixed in bug 44272. As a result, escape() and unescape() MUST NOT be used for URI manipulation any more. For URI tweaking, you have to use encodeURI(), encodeURIComponent(), decodeURIComponent(), and decodeURI(), instead. In bug 225695, I've been working on a tree-wide sweep to replace escape()/unescape() for the URI manipulation with en/decodeURI(Component). I'm making this announcement to make sure that no one checks in new patches that use escape()/unescape() the old-fashioned way (non-standard way). For details, refer to two bugs mentioned above and the following documents ECMA 262 and MSDN
Ads:
 |
 |
old escape(): encode in page's charset, then %hh
new escape(): %hh, %uhhhh for everything over unicode 256.
encodeURIComponent(): encode in UTF-8, then %hh
For chrome, which is interpreted as UTF-8, the switch from escape() to encodeURIComponent is necessary and correct. For Mozilla-specific web sites that relied on Mozilla's quirky escape() behavior, the answer is not clear. For English-only sites, escape() is better until Netscape 4 finishes dying.
Btw, encodeURIComponent rocks. I used in the "Blogidate XML Well-formedness" bookmarklet to create the body of "data:text/xml;charset=UTF-8," URLs, allowing the bookmarklet to work with XHTML that contains Japanese text.