[whatwg] "binary" encoding

Joshua Bell jsbell at chromium.org
Tue Jun 12 11:45:57 PDT 2012


On Tue, Jun 12, 2012 at 2:29 AM, Simon Pieters <simonp at opera.com> wrote:

> On Mon, 11 Jun 2012 18:20:55 +0200, Joshua Bell <jsbell at 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
strawman:

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.)



More information about the whatwg mailing list