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 mentioned in this thread: - limitation to ISO strings - explicit exclusion of binary support by the current specification (must throw an error) I think there is 3 approaches for such API: - 2 raw global methods as atob() and btoa(), potentially base64Encode() and base64Decode() or whatever - 2 methods of a dedicated namespace as JSON.stringify() / JSON.parse(), potentially Base64.stringify() / Base64.parse() - Dedicated prototype methods (base64Decode/base64Encode or fromBase64/toBase64) to each concerned constructors like: -> String.prototype -> Typed Array prototypes I'm not fan of the first option (2 raw global methods) I'll use the second option in a below but think the third one may be easier to extend binary format supports In a perfect world I'd love to see something simple similar to (use the namespace approach in this sample): Base64.stringify( any ) -> return a string Base64.parse( string, format ) -> return expected instance object where format could be either depending of this working group choice: - a string specifying the expected returned format (ex: "Uint8Array", "Uint16Array"...) - a reference to the constructor of the expected format (ex: Uint8Array) my personal choice would be for the constructor reference for 2 reasons: - while coding, the developer would have native autocompletion to fill this parameter value - at runtime, an exception would be natively throw if the constructor is not supported by the environment (and then obviously by the parse() method) As said, I care about extensibility of "binary format supports" Fact the Typed Array will be native in ES6 is awesome to have some formats available by default Still note that nowadays we also have: - Blob, File, data URL (formated in base64), ImageData (canvas) from HTML5 standards - Buffer in node.js, wakanda - ByteString & ByteArray supported by some CommonJS platforms and by CommonNode A registerFormatHandler( encoder, decoder) method could then be a plus On 5 mai 2014, at 21:24, Florian Bösch <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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]<mailto:[email protected]>> wrote: On Sun, May 4, 2014 at 3:00 PM, Andrea Giammarchi <[email protected]<mailto:[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 [cid:[email protected]] Alexandre Morgaut Wakanda Community Manager Email : [email protected]<mailto:[email protected]> Web : www.4D.com<http://www.4D.com> 4D SAS 60, rue d'Alsace 92110 Clichy - France Standard : +33 1 40 87 92 00 _______________________________________________ es-discuss mailing list [email protected]<mailto:[email protected]> https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected]<mailto:[email protected]> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
