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 (indexable by byte, get the byte values out) should work. On Mon, May 5, 2014 at 8:22 PM, Andrea Giammarchi < [email protected]> wrote: > @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" whatever definition of silly > we have ^_^ > > Also interesting the @claude info on ISO strings ... yes, any UTF-8 > compatible support is what I meant, doing in JS land > unescape(encodeURIComponent(str)) feels very hacky, and it's slow, indeed > > take care > > > On Mon, May 5, 2014 at 8:16 AM, John Barton <[email protected]>wrote: > >> >> >> >> On Sun, May 4, 2014 at 3:00 PM, Andrea Giammarchi < >> [email protected]> 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 standard modules for all new >> features. >> jjb >> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
