Native base64 utility methods
claude.pache at gmail.com
Mon May 5 01:48:55 PDT 2014
Le 5 mai 2014 à 09:54, Mathias Bynens <mathias at qiwi.be> a écrit :
> On 5 May 2014, at 00:00, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
>> as generic global utility it would be also nice to make it compatible with all strings.
> For backwards compatibility reasons, `atob`/`btoa` should probably continue to work in exactly the same way they work now (i.e as per http://whatwg.org/html/webappapis.html#atob). Otherwise, any existing code that uses `atob`/`btoa` before UTF-8-decoding or after UTF-8-encoding, including your snippet, would suddenly break.
> Like you demonstrated, it’s easy enough to encode or decode the input using UTF-8 or any other character encoding before passing to `atob`/`btoa`. (E.g. http://mothereff.in/base64)
I'd say that it is "hacky enough" rather than "easy enough" to encode or decode the input using UTF-8. In my view, if `atob` and `btoa` were to enter in ES, it should be in Appendix B (the deprecated legacy features of web browsers), where it would be in good company with the other utility that does an implicit confusion between binary and ISO-8859-1-encoded strings, namely `escape/unescape`. We should be able to define a better designed function (and with a less silly name, while we're at it).
More information about the es-discuss