On Dec 2, 2009, at 12:06 PM, Michael Nordman wrote:
Arguably, seems like a bug that invalid string values are let thru
the door to start with?
ECMAScript Strings are essentially sequences of arbitrary 16-bit
values. Sometimes Web apps take advantage of this to use a String as a
hacky way to represent binary data. I don't think we should reject
such strings arbitrarily.
Since users can't effectively store invalid UTF16 character
sequences in FF or IE,
I tend to think this is a bug in FF/IE. Nothing in the spec gives
license to reject particular Strings.
is there really any downside to using UTF8 text encoding in WebKit?
@Jeremy, this isn't a matter of letting users choose the text
encoding, this is entirely an implementation detail of WebStorage.
I think it would be fine to use a more compact encoding
opportunistically, as long as we can still handle an arbitrary
JavaScript String. Perhaps we should use UTF-8 if and only if the
conversion succeeds, or perhaps even use Latin1 as the alternative.
Downsides
* The code change to get UTF8 by default in new databases, tiny.
* Migrating pre-existing databases to the new encoding. Somewhat of
a hassle. But maybe doesn't need to be done, pre-existing files
could continue to use UTF16, while newly created dbs could use UTF8
(the text encoding is chosen at database creation time and stuck
that way forever thereafter).
* Its possible that some app is already depending on the ability to
store invalid character sequences (on the iPhone say), and this
would be a breaking change for that app.
The preload everything characteristic is a separate issue altogether.
On Wed, Dec 2, 2009 at 11:15 AM, Jeremy Orlow <[email protected]>
wrote:
IE chokes ("invalid procedure call or argument") and Firefox mangles
the data for LocalStorage (but works fine for SessionStorage).
On Wed, Dec 2, 2009 at 10:54 AM, Darin Adler <[email protected]> wrote:
On Dec 2, 2009, at 10:48 AM, Jeremy Orlow wrote:
> How can you construct invalid UTF-16 sequences?
http://unicode.org/faq/utf_bom.html#utf16-7
-- Darin
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
