Native base64 utility methods

Claude Pache claude.pache at
Mon May 5 01:48:55 PDT 2014

Le 5 mai 2014 à 09:54, Mathias Bynens <mathias at> a écrit :

> On 5 May 2014, at 00:00, Andrea Giammarchi <andrea.giammarchi at> 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 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.

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 mailing list