[whatwg] API for encoding/decoding ArrayBuffers into text

[Henri Sivonen]

On Wed, Mar 14, 2012 at 12:49 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> Something that has come up a couple of times with content authors
> lately has been the desire to convert an ArrayBuffer (or part thereof)
> into a decoded string. Similarly being able to encode a string into an
> ArrayBuffer (or part thereof).
>
> Something as simple as
>
> DOMString decode(ArrayBufferView source, DOMString encoding);
> ArrayBufferView encode(DOMString source, DOMString encoding,
> [optional] ArrayBufferView destination);

It saddens me that this allows non-UTF-8 encodings. However, since use
cases for non-UTF-8 encodings were mentioned in this thread, I suggest
that the set of supported encodings be an enumerated set of encodings
stated in a spec and browsers MUST NOT support other encodings. The
set should probably be the set offered in the encoding popup at
http://validator.nu/?charset or a subset thereof (containing at least
UTF-8 of course). (That set was derived by researching the
intersection of the encodings supported by browsers, Python and the
JDK.)

> would go a very long way.

Are you sure that it's not necessary to support streaming conversion?
The suggested API design assumes you always have the entire data
sequence in a single DOMString or ArrayBufferView.

> The question is where to stick these
> functions. Internationalization doesn't have a obvious object we can
> hang functions off of (unlike, for example crypto), and the above
> names are much too generic to turn into global functions.

If we deem streaming conversion unnecessary, I'd put the methods on
DOMString and ArrayBufferView. It would be terribly sad to let the
schedules of various working groups affect the API design.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/