4 ms·
Right exactly. The conventional ways of writing it would be \U0001F914 -- must be exactly 8 digits \u{1f914} -- 1 to 6 digits Almost all languages h
by chubot 3y ago
Right exactly. The conventional ways of writing it would be
\U0001F914 -- must be exactly 8 digits
\u{1f914} -- 1 to 6 digits
Almost all languages have these now, but JavaScript didn't when JSON was invented.
The "J8 strings" extension mentioned technically only needs \a syntax for bytes, which is \yff since \xff is (oddly) a synonym for \u00ff and thus unsuitable.
But I also want to add \u{123456} because it allows people to move away from the weird UTF-16 legacy in a UTF-8 format.
- poorlyknit 3y agoYea, it seems weird to me that they decided to do that in ECMAScript in the first place. The user/programmer should never have to interface with surrogates unless they are doing something specific to UTF-16.
- masklinn 3y agoJavascript was released about 6 months before unicode 2.0, and furthermore was in various ways designed to be close to Java, whose strings are sequences of 16 bits code units. Because this is part of the string interface it’s not really fixable. Not only that but while Unicode 2.0 was released in June 1996, it wasn’t necessarily super sought after for a while, lots of people were wary of utf8 and while 16 bit code units was fine 32 was a bit much. While it was singularly late to the party, it took MySQL until 2010 to support non-BMP content, unless you were willing to store content as blobs. Java and Javascript similarly took a while just to give access to actual codepoints, in Java5 (2004, String#codePointAt, it took until Java 8 for an iterator to be added with CharSequence#codePoints) and ES6 (2015, String.prototype.codePointAt and String.prototype[@@iterator])