Re: JSON strings cannot point to post-BMP Unicode codepoints?
- From RFC 4672 http://www.ietf.org/rfc/rfc4627.txt?number=4627
To escape an extended character that is not in the Basic Multilingual
Plane, the character is represented as a twelve-character sequence,
encoding the UTF-16 surrogate pair. So, for example, a string
containing only the G clef character (U+1D11E) may be represented as
- Shriramana Sharma wrote:
> http://en.wikipedia.org/wiki/JSON says: "The default characterYes, you can put post-BMP codepoints directly as part of the string
> encoding for JSON is UTF8; it also supports UTF16 and UTF32." but I'm
> not sure about it because it is not mentioned explicitly on the
> json.org page and it is also not very clear to me as to what exactly
> that statement means. Does it mean that even though there is no \U
> notation, I can directly input post-BMP codepoints as part of the
> string literals? The json.org page does say "any-Unicode-character".
> In this case even the \u notation is only there as a just-in-case?
> (Even if so, why not \U too just-in-case?)
literals. If there are control characters outside of the BMP in your
text they could still be encoded as surrogate pairs. This isn't the
- Shriramana Sharma scripsit:
> However, if that restriction of *four* hex digits is meant to beIt can be represented either as the actual character, 4 bytes in any
> enforced, then it means that post-BMP codepoints (such as 0x11005
> BRAHMI LETTER A) cannot be represented in such strings directly, but
> that they have to be manually (i.e. by the program outputting JSON-ed
> data) decomposed into their equivalent UTF16 surrogate pairs (for
> instance, 0xd804 0xdc05).
of UTF-8, UTF-16, or UTF-32; or else as two consecutive ASCII escapes:
> IMHO this is an unnecessary restriction.JSON is backward compatible by design with ECMAScript 3, which does not
support the \U escape.
> Does it mean that even though there is no \U notation, I can directlyCorrect.
> input post-BMP codepoints as part of the string literals?
> In this case even the \u notation is only there as a just-in-case?Just so.
There are three kinds of people in the world: John Cowan
those who can count, cowan@...
and those who can't.
- There's some contradiction in the json RFC. If the encoding 'shall be Unicode'
and default is UTF-8 as is stated, then ALL normal planes, including those
outside of the BMP can be encoded w/o any special escaping (excluding the
special set chars escaped for JSON). UTF16 doesn't apply, right?
See http://en.wikipedia.org/wiki/Plane_%28Unicode%29, where it says it is NOT a
UTF-8 limit, being inside the BMP, but UTF16. It goes further to say that with
ONLY 4 bytes, utf-8 can represent twice as many code points as UTF16 using
If I have read everything correctly.
Never, ever approach a computer saying or even thinking "I will just do this
From: douglascrockford <douglas@...>
Sent: Sun, April 7, 2013 11:30:30 AM
Subject: [json] Re: JSON strings cannot point to post-BMP Unicode codepoints?
Unicode was going to be a 16-bit character set. Unicode later grew into a 21-bit
[Non-text portions of this message have been removed]
- Dennis Gearon scripsit:
> There's some contradiction in the json RFC. If the encoding 'shall beThat's right. However, escapes are handy for representing stray Unicode
> Unicode' and default is UTF-8 as is stated, then ALL normal planes,
> including those outside of the BMP can be encoded w/o any special
> escaping (excluding the special set chars escaped for JSON).
characters that aren't easy to type, just as in HTML or XML. Unlike
those languages, JSON requires two consecutive escapes to represent a
What's ambiguous is whether a JSON document like
with an unpaired escaped surrogate, is valid or not. It is valid in
and I say it is implicitly forbidden by the definition in section 1 that
a string is a sequence of zero or more Unicode characters, because U+D800
is not a Unicode character.
> UTF16 doesn't apply, right?UTF-16 is a perfectly cromulent encoding for JSON, though probably not
> See http://en.wikipedia.org/wiki/Plane_%28Unicode%29, where it saysUTF-8 and UTF-16 can represent the exact same range of code points,
> it is NOT a UTF-8 limit, being inside the BMP, but UTF16. It goes
> further to say that with ONLY 4 bytes, utf-8 can represent twice as
> many code points as UTF16 using surrogate pairs.
namely 0-10FFFF excluding D800-DFFF. Any UTF-8 byte sequence that
purports to represent any other code point has been illegal for a long
We pledge allegiance to the penguin John Cowan
and to the intellectual property regime cowan@...
for which he stands, one world under http://www.ccil.org/~cowan
Linux, with free music and open source
software for all. --Julian Dibbell on Brazil, edited
- Hello people and thanks for your responses. I hope I understand
standard dictates that it would not be advisable for JSON to
unilaterally add the extension of \U, but since any valid Unicode
characters can be part of string literals (encoded in the appropriate
encoding) I guess this is not too much of a problem. Thank you.