[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