W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2012

[whatwg] API for encoding/decoding ArrayBuffers into text

From: Glenn Maynard <glenn@zewt.org>
Date: Sat, 24 Mar 2012 08:52:15 -0500
Message-ID: <CABirCh8xPNTCzma0aCtNnaq_08Lu0juWb5DOD9_uHYczaj2PUQ@mail.gmail.com>
On Thu, Mar 22, 2012 at 8:58 AM, Anne van Kesteren <annevk at opera.com> wrote:

> Another way would be to have a second optional argument that indicates
> whether more bytes are coming (defaults to false), but I'm not sure of the
> chances that would be used correctly. The reasons you outline are probably
> why many browser implementations deal with EOF poorly too.


It might not improve it, but I don't think it'd be worse.  If you didn't
use it correctly for an encoding where it matters, the breakage would be
obvious.

Also, the previous "automatically-streaming" API has another possible
misuse: constructing a single encoder, then calling it repeatedly for
unrelated strings, without calling eof() between them (trailing bytes would
become U+FFFD in the next string).  That'd be a less likely mistake with
this, too.

Here's a suggestion, working from that:

encoder = Encoder("euc-kr");
view = encoder.encode(str1, {continues: true});
view = encoder.encode(str2, {continues: true});
view = encoder.encode(str3, {continues: false});

An alternative way to end the stream:

encoder = Encoder("euc-kr");
view = encoder.encode(str1, {continues: true});
view = encoder.encode(str2, {continues: true});
view = encoder.encode(str3, {continues: true});
view = encoder.encode("", {continues: false});
// or view = encoder.encode(""); // equivalent; continues defaults to false
// or view = encoder.encode(); // maybe equivalent, if the first parameter
is optional

The simplest usage is concise enough that we don't really need a separate
str.encode() method:

view = Encoder("euc-kr").encode(str);

If it has an eof() method, it'd just be a literal wrapper for
encoder.encode(), but it can probably be omitted.

-- 
Glenn Maynard
Received on Saturday, 24 March 2012 06:52:15 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:40 UTC