W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

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

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 7 Aug 2013 08:29:24 -0500
Message-ID: <CABirCh-Zneyjc3J9yDLwcsh_NwjNL3hihu3OQ_qx-zuvj3it7Q@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WHATWG <whatwg@lists.whatwg.org>, Chang Shu <cshu01@gmail.com>
On Wed, Aug 7, 2013 at 5:28 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Tue, Aug 6, 2013 at 9:48 PM, Chang Shu <cshu01@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.

If base64 was treated as a sequence of bytes then both encoding and
decoding would be bytes to bytes, which doesn't match either of those.

base64 data is a string, though.  Having encode to a UTF-8 binary array to
convert to base64, and decode back to a string after decoding base64, would
be pretty awkward for the common case.  Signature-wise, you'd want
TextDecoder to convert from data to base64, and TextEncoder to convert from
base64 to data.

The only annoying thing is that results in the function names being
backwards (logically the former is "encoding to base64" and the latter is
"decoding base64").  That's livable, though.

Glenn Maynard
Received on Wednesday, 7 August 2013 13:29:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC