W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: String to ArrayBuffer

From: Kenneth Russell <kbr@google.com>
Date: Wed, 11 Jan 2012 15:12:09 -0800
Message-ID: <CAMYvS2egK1d2sax+_LkOvtzwk5RjT28UNUuOpnca=NZ_MTVwsQ@mail.gmail.com>
To: Charles Pritchard <chuck@jumis.com>
Cc: James Robinson <jamesr@google.com>, Webapps WG <public-webapps@w3.org>, Joshua Bell <jsbell@google.com>
The StringEncoding proposal is the best path forward because it
provides correct behavior in all cases. Adding String conversions
directly to the typed array spec will introduce dependencies that are
strongly undesirable, and make it much harder to implement the core
spec. Hopefully Josh can provide an update on how the StringEncoding
proposal is going.

-Ken

On Wed, Jan 11, 2012 at 3:05 PM, Charles Pritchard <chuck@jumis.com> wrote:
> On 1/11/2012 2:49 PM, James Robinson wrote:
>
>
>
> On Wed, Jan 11, 2012 at 2:45 PM, Charles Pritchard <chuck@jumis.com> wrote:
>>
>> Currently, we can asynchronously use BlobBuilder with FileReader to get an
>> array buffer from a string.
>> We can of course, use code to convert String.fromCharCode into a
>> Uint8Array, but it's ugly.
>>
>> The StringEncoding proposal seems a bit much for most web use:
>> http://wiki.whatwg.org/wiki/StringEncoding
>>
>> All we really ever do is work on DOMString, and that's covered by UTF8.
>
>
> DOMString is not UTF8 or necessarily unicode.  It's a sequence of 16 bit
> integers and a length.
>
>
>
> To clarify, I'd want ArrayBuffer(DOMString) to work with unicode and throw
> an error if the DOMString is not valid unicode.
> This is consistent with other Web Apps APIs.
>
> For feature detection, the method should be wrapped in a try-catch block
> anyway.
>
> -Charles
Received on Wednesday, 11 January 2012 23:19:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT