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).

—Claude

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).