Contact emails math...@chromium.org
Spec https://github.com/tc39/proposal-well-formed-stringify Summary A Stage 3 proposal changes JSON.stringify to prevent it from returning ill-formed Unicode strings. Motivation RFC 8259 section 8.1 <https://tools.ietf.org/html/rfc8259#section-8.1> requires JSON text exchanged outside the scope of a closed ecosystem to be encoded using UTF-8, but JSON.stringify <https://tc39.github.io/ecma262/#sec-json.stringify> can return strings including code points that have no representation in UTF-8 (specifically, surrogate code points U+D800 through U+DFFF). And contrary to the description of JSON.stringify <https://tc39.github.io/ecma262/#sec-json.stringify>, such strings are not “in UTF-16” because “isolated UTF-16 code units in the range D800₁₆..DFFF₁₆ are ill-formed” per The Unicode Standard, Version 10.0.0, Section 3.4 <https://unicode.org/versions/Unicode10.0.0/ch03.pdf#G7404> at definition D91 and excluded from being “in UTF-16” per definition D89. However, returning such invalid Unicode strings is unnecessary, because JSON strings can include Unicode escape sequences. Interoperability and compatibility risk This change is backwards-compatible, under an assumption of consumer compliance with the JSON specification. User-visible effects are limited to the replacement of some rare single UTF-16 code units in JSON.stringify output with equivalent six-character escape sequences that can be represented both in UTF-16 and in UTF-8. Any consumer accepting the current ill-formed output is unaffected by this change (this is true in particular of ECMAScript JSON.parse). Any consumer rejecting the current ill-formed output will have a new opportunity to accept its well-formed representation, although such consumers may still reject input that specifies strings including Unicode code points that are not scalar values (e.g. because they only accept I-JSON <https://tools.ietf.org/html/rfc7493> input), but those that accept it must have mechanisms for dealing with unpaired surrogates (as mentioned in the specification of JSON). This feature has a ready-to-land Firefox/SpiderMonkey implementation <https://bugzilla.mozilla.org/show_bug.cgi?id=1469021>. There are tracking bugs for Edge/Chakra <https://github.com/Microsoft/ChakraCore/issues/5735> and Safari/JavaScriptCore <https://bugs.webkit.org/show_bug.cgi?id=190110>. Is this feature fully tested? Yes. In addition to V8’s own tests ( v8/test/mjsunit/harmony/well-formed-json-stringify*.js and v8/test/cctest/test-strings*), Test262 includes tests <https://github.com/tc39/test262/search?q=%22features%3A+%5Bwell-formed-json-stringify%5D%22> for this feature <https://github.com/tc39/test262/pull/1787>. Tracking bug https://bugs.chromium.org/p/v8/issues/detail?id=7782 Link to entry on the Chrome Platform Status dashboard https://www.chromestatus.com/feature/5752304045129728 Requesting approval to ship? Yes. Note that since this is a V8/JS feature, this post is just an FYI to blink-dev — no signoff from Blink API owners is required. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
