Re: [Json] A possible summary of the discussion so far on code points and characters

Carsten Bormann <> Sun, 09 June 2013 02:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CE3621F973A for <>; Sat, 8 Jun 2013 19:30:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.019
X-Spam-Status: No, score=-106.019 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rIdZt-D8ldK5 for <>; Sat, 8 Jun 2013 19:30:02 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:30c9::12]) by (Postfix) with ESMTP id DA91C21F972E for <>; Sat, 8 Jun 2013 19:30:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id r592Txd7006955; Sun, 9 Jun 2013 04:29:59 +0200 (CEST)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4AD65367F; Sun, 9 Jun 2013 04:29:59 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=utf-8
From: Carsten Bormann <>
In-Reply-To: <>
Date: Sun, 9 Jun 2013 04:29:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: R S <>
X-Mailer: Apple Mail (2.1503)
Subject: Re: [Json] A possible summary of the discussion so far on code points and characters
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 09 Jun 2013 02:30:08 -0000

On Jun 9, 2013, at 03:24, R S <> wrote:

> We should document what currently works.

A survey of which implementations react to what input in which way would be nice, indeed, but is not the purpose of this spec update.

Changing the JSON spec retroactively to put in a requirement for handling strings in UTF-16 code units so that unpaired surrogates might work more uniformly is something different.

(BTW, your examples show that two JSON implementations handle Unicode non-characters nicely, which is great and probably something to be recommended, but doesn't have anything to do with switching to UTF-16 code units.  Now let's put in a couple of (paired!) surrogates to show how well the code units work:

>>> print(json.loads('{"a": "\ud800\udd51" }')["a"])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in position 0: surrogates not allowed
>>> print(json.loads('{"a": "\\ud800\\udd51" }')["a"])

... which demonstrates nicely what I have been saying: Don't put unescaped surrogates into your JSON texts, because there is no equivalence at the UTF-16 code unit level.)

There is only a single place where the UTF-16 legacy of JavaScript shines through in JSON today:

   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

And that is OK because it is just a slightly weird representation of the character.

> > (It is not aligned with JSON's main purpose.)
> I am not sure what the rationale for that statement is.

The first sentence of RFC 4627:


   JavaScript Object Notation (JSON) is a lightweight, text-based,
   language-independent data interchange format.

Grüße, Carsten