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

Re: [whatwg] "binary" encoding

From: Joshua Bell <jsbell@chromium.org>
Date: Tue, 12 Jun 2012 11:45:57 -0700
Message-ID: <CAD649j7G5WDnagC4gDcC58c2zo8x64H7c=i65aOyC6p8P4wLuA@mail.gmail.com>
To: WHATWG <whatwg@whatwg.org>
On Tue, Jun 12, 2012 at 2:29 AM, Simon Pieters <simonp@opera.com> wrote:

> On Mon, 11 Jun 2012 18:20:55 +0200, Joshua Bell <jsbell@chromium.org>
> wrote:
>  http://wiki.whatwg.org/wiki/**StringEncoding<http://wiki.whatwg.org/wiki/StringEncoding>
>  defines a binary encoding
>>> (basically the official iso-8859-1 where it is not mapped to
>>> windows-1252).
>> .... which is residue from earlier iterations. Intended use case was
>> interop with legacy JS that used the lower 8 bits of strings to hold
>> binary
>> data, e.g. with APIs like atob()/btoa().
> I think we should drop this and extend atob() and btoa() to be able to
> convert base64 strings to ArrayBuffer[View?] and back directly.

Agreed (I wanted a little more consensus before removing it).

Now that we can get binary data into script directly will there still be
active use of base64 + ArrayBuffers that will benefit from platform
support? Anyone want to tackle specifying the atob/btoa extensions? As a

partial interface ArrayBufferView {
    DOMString toBase64();

partial interface ArrayBuffer {
    static ArrayBuffer fromBase64(DOMString string);

These don't handle data streaming scenarios, however.

(This is completely orthogonal to Anne's question about whether a "binary"
encoding should be specified somewhere to describe current implementations.)
Received on Tuesday, 12 June 2012 18:46:34 UTC

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