On May 16, 2011, at 2:23 PM, Shawn Steele wrote: > I’m having some (ok, a great deal of) confusion between the DOM Encoding and > the JavaScript encoding and whatever. I’d assumed that if I had a web page > in some encoding, that it was converted to UTF-16 (well, UCS-2), and that’s > what the JavaScript engine did it’s work on. I confess to not having done > much encoding stuff in JS in the last decade. > > In UTF-8, individually encoded surrogates are illegal (and a security risk). > Eg: you shouldn’t be able to encode D800/DC00 as two 3 byte sequences, they > should be a single 6 byte sequence. Having not played with the js > encoding/decoding in quite some time, I’m not sure what they do in that case, > but hopefully it isn’t illegal UTF-8. (You also shouldn’t be able to have > half a surrogate pair in UTF-16, but many things are pretty lax about that.)
I don't know enough about DOM behavior as I probably should, but the implication of the DOMString spec. is that if HTML source code contains a text element with supplemental characters (using any encoding recognized by a browser) then if the text of that element is accessed from JavaScript it will see each supplemental character as two JavaScript character that taken together are the UTF-16 encoding of the original supplemental character. I'm not proposing any changes in that regard. There is a chicken and egg issue here. The DOM will never evolved to directly support non UTF-16 encoded supplemental characters unless ECMAScript first provides such support. It may take 20 years to get there but that clock won't even start until ECMAScript provides the necessary support. Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
