[whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob

K. Gadd kg at luminance.org
Wed Aug 7 12:52:55 PDT 2013


JSIL currently ships a hand-rolled typed array to/from base64
implementation due not being able to use btoa/atob; if they were improved
to support typed arrays as described that would be an improvement for some
of my use cases. It'd need to be necessary to detect the presence of the
feature at runtime, though.

I should also point out that in general string decoding/encoding targetting
typed arrays is a really important use case for JSIL (and as I understand
things, it is also important for emscripten/embind). Right now moving
between JS strings and a fake heap in a typed array is really expensive,
and you need to do it any time you leave the domain of your application and
talk to HTML5 APIs like canvas, XHR, etc. Base64 isn't the only kind of
encode/decode that matters; I'd argue that UTF8 and UTF16 are equally
deserving of similar functionality being exposed - if not more deserving.


On Wed, Aug 7, 2013 at 3:28 AM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Tue, Aug 6, 2013 at 9:48 PM, Chang Shu <cshu01 at gmail.com> wrote:
> > But it appears to me we have to introduce
> > another pair of coders, say BinaryDecoder/BinaryEncoder, in addition
> > to TextDecoder/TextEncode since the signatures of the decode/encode
> > functions are different.
>
> So TextDecoder is bytes to string and TextEncoder is string to bytes.
> If we always represent the base64-variant as a sequence of bytes the
> signature seems fine. If you want to get a string out of those bytes
> again you could utf-8 decode it for instance.
>
> I'd be interested in knowing what the level of interest is outside of
> Google for this feature.
>
>
> --
> http://annevankesteren.nl/
>



More information about the whatwg mailing list