[whatwg] API for encoding/decoding ArrayBuffers into text

Joshua Bell jsbell at chromium.org
Wed Mar 14 10:08:14 PDT 2012

On Wed, Mar 14, 2012 at 9:14 AM, Joshua Bell <jsbell at chromium.org> wrote:

> On Wed, Mar 14, 2012 at 1:14 AM, Cedric Vivier <cedricv at neonux.com> wrote:
>> For this, base64 encoding/decoding is typically used (so that it
>> doesn't conflict with the XML or JSON container) and thus more or less
>> efficiently implemented in JavaScript (just like we had to
>> encode/decode strings in JS to/from XHR a while ago).
>> Would it make sense to support encoding="base64" in this API?
> Having implemented a library that handled both text encodings and
> base16/base64 encoding, I can offer the opinion that the nomenclature gets
> very confusing since the encode/decode semantics are reversed.
> binary_buffer = encode(text_content)
> text_content = decode(binary_buffer)
> vs.
> binary_buffer = decode(base64_data)
> base64_data = encode(binary_buffer)
> When you try to unify these and have the same API accept "UTF-8" and
> "BASE64" encodings by name it's difficult to keep track of which of
> encode/decode you want; one will seem backwards. (This is one advantage of
> the atob()/btoa() API naming approach.)

And extending that thought, such confusion is lessened if you can avoid the
loaded words encode/decode and associate the operations with either one of
the target types, e.g. buffer.writeString/readString, or

More information about the whatwg mailing list