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

Re: String to ArrayBuffer

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 11 Jan 2012 15:03:36 -0800
Message-ID: <4F0E1548.3040307@jumis.com>
To: James Robinson <jamesr@google.com>
CC: Webapps WG <public-webapps@w3.org>
On 1/11/2012 2:49 PM, James Robinson wrote:
> On Wed, Jan 11, 2012 at 2:45 PM, Charles Pritchard <chuck@jumis.com 
> <mailto: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.

Is there any instance in practice where DOMString as exposed to the 
scripting environment is not implemented as a unicode string?
I realize that internally, DOMString may be implemented as a 16 bit 
integer + length;

>     As following file shows, DOMString to ArrayBuffer conversion is
>     about 30 lines of code (start at line 125):
>     http://code.google.com/p/stringencoding/source/browse/encoding.js
> This only seems correct for valid unicode strings, which does not 
> cover all DOMStrings.

Sure, they're checking for correctness. And it's really only about 15 lines.

Browsers do the same thing with WindowBase64, though it's specified as 
DOMString, in practice (as the notes say), it's unicode.

Web Storage, also, only works with unicode.

Received on Wednesday, 11 January 2012 23:10:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:30 UTC