Joshua Bell has been working on a string encoding and decoding API that supports the needed encodings, and which is separable from the core typed array API:
http://wiki.whatwg.org/wiki/StringEncoding This is the direction I prefer. String encoding and decoding seems to be a complex enough problem that it should be expressed separately from the typed array spec itself. -Ken On Tue, Mar 13, 2012 at 5:59 PM, Ian Hickson <i...@hixie.ch> wrote: > On Tue, 13 Mar 2012, Jonas Sicking wrote: >> >> Something that has come up a couple of times with content authors >> lately has been the desire to convert an ArrayBuffer (or part thereof) >> into a decoded string. Similarly being able to encode a string into an >> ArrayBuffer (or part thereof). >> >> Something as simple as >> >> DOMString decode(ArrayBufferView source, DOMString encoding); >> ArrayBufferView encode(DOMString source, DOMString encoding, >> [optional] ArrayBufferView destination); >> >> would go a very long way. The question is where to stick these >> functions. Internationalization doesn't have a obvious object we can >> hang functions off of (unlike, for example crypto), and the above >> names are much too generic to turn into global functions. > > Shouldn't this just be another ArrayBufferView type with special > semantics, like Uint8ClampedArray? DOMStringArray or some such? And/or a > getString()/setString() method pair on DataView? > > Incidentally I _strongly_ suggest we only support UTF-8 here. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'