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 men
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 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
> we have ^_^
Agreed
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 (indexab
@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" wha
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 ne
Le 5 mai 2014 à 12:03, Mathias Bynens a écrit :
> On 5 May 2014, at 10:48, Claude Pache 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 utilit
On 5 May 2014, at 10:48, Claude Pache 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
> between binary and IS
Le 5 mai 2014 à 09:54, Mathias Bynens a écrit :
> On 5 May 2014, at 00:00, Andrea Giammarchi
> 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
On 5 May 2014, at 00:00, Andrea Giammarchi 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
+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,
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 adding
12 matches
Mail list logo