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

[whatwg] API for encoding/decoding ArrayBuffers into text

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 22 Mar 2012 14:58:09 +0100
Message-ID: <op.wbkrq72d64w2qv@annevk-macbookpro.local>
On Thu, 22 Mar 2012 14:47:05 +0100, Glenn Maynard <glenn at zewt.org> wrote:
> A problem with this is that the bugs resulting from not calling eof() are
> subtle.  The only thing eof() would ever do, I think, is return U+FFFD
> characters if there are leftover characters in the internal buffer; if  
> you
> never call eof(), you'll never get incorrect results unless you test with
> invalid inputs.
> It's minor, as subtle-edge-cases-that-people-won't-get-right go, but it's
> at least worth a mention.  Maybe people who would use this API instead of
> the simpler non-streaming version (which could be a thin wrapper on this)
> in the first place are also more likely to get this right.
> I'm guessing a common, incorrect pattern would be:
> string = new Encoder("euc-kr").encode(bytes);
> which would *not* be equivalent to bytes.encode("euc-kr").

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.

Anne van Kesteren
Received on Thursday, 22 March 2012 06:58:09 UTC

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