Native base64 utility methods

Florian Bösch pyalot at gmail.com
Mon May 5 12:24:32 PDT 2014


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 <
andrea.giammarchi at gmail.com> 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 <johnjbarton at google.com>wrote:
>
>>
>>
>>
>> On Sun, May 4, 2014 at 3:00 PM, Andrea Giammarchi <
>> andrea.giammarchi at 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 standard modules for all new
>> features.
>> jjb
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140505/ecd5d25e/attachment.html>


More information about the es-discuss mailing list