I give a +1 for native support of base64 encoding/decoding in ES
I actually did a basic polyfill like module to add support of the standard W3C
atob() / btoa() API over browsers (they don't all support it) and servers
(mainly tested on Wakanda and Node.js)
My main concerns were, as already
Mathias Bynens wrote:
(but it requires `ArrayBuffer` / `Uint8Array`).
In ES6, so no problem proposing Text{En,De}coder for ES7.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 5 May 2014, at 20:22, Andrea Giammarchi andrea.giammar...@gmail.com wrote:
@mathias didn't mean to change atob and btoa rather add two extra methods
such encode/decode for strings (could land without problems in the
String.prototype, IMO) with less silly names whatever definition of silly
On 5 May 2014, at 00:00, Andrea Giammarchi andrea.giammar...@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
Le 5 mai 2014 à 09:54, Mathias Bynens math...@qiwi.be a écrit :
On 5 May 2014, at 00:00, Andrea Giammarchi andrea.giammar...@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`
On 5 May 2014, at 10:48, Claude Pache claude.pa...@gmail.com wrote:
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
Le 5 mai 2014 à 12:03, Mathias Bynens math...@qiwi.be a écrit :
On 5 May 2014, at 10:48, Claude Pache claude.pa...@gmail.com wrote:
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
On Sun, May 4, 2014 at 3:00 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
+1 and as generic global utility it would be also nice to make it
compatible with all strings.
A language with modules does not need nor should it rely on stuff more
favorite features onto global. We need
@john I don't really care about the namespace/module as long as this matter
moves from W3C spec to ES one.
@mathias didn't mean to change atob and btoa rather add two extra methods
such encode/decode for strings (could land without problems in the
String.prototype, IMO) with less silly names
I'd like highlight the fact that binary data handling in JS these days is
mainly done via ArrayBuffers and TypedArrayViews. To that end, I've written
a base64 to Uint8Array decoder like so:
https://gist.github.com/pyalot/4530137
I don't quite see how atob/btoa without a usable binary type
To convert from base64 to ASCII and vice versa, browsers have had global `atob`
and `btoa` functions for a while now. At the moment, these are defined in the
HTML standard: http://whatwg.org/html/webappapis.html#atob
However, such utility methods are not only useful in browsers. How about
+1 and as generic global utility it would be also nice to make it
compatible with all strings.
I have this good old object: http://devpro.it/code/214.html
that indeed needs to normalize before encoding or decoding or errors might
happen quite frequently in user-land:
{
atob: atob,
12 matches
Mail list logo
