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

Carsten Bormann <> Sun, 09 June 2013 00:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A60A21F944F for <>; Sat, 8 Jun 2013 17:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.732
X-Spam-Status: No, score=-105.732 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xsXgQKYzHoAM for <>; Sat, 8 Jun 2013 17:39:29 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:30c9::12]) by (Postfix) with ESMTP id 64C1621F92B8 for <>; Sat, 8 Jun 2013 17:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id r590dKXi027556; Sun, 9 Jun 2013 02:39:20 +0200 (CEST)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 45BAD3679; Sun, 9 Jun 2013 02:39:20 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <>
In-Reply-To: <>
Date: Sun, 9 Jun 2013 02:39:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Paul Hoffman <>
X-Mailer: Apple Mail (2.1503)
Cc: "" <>, R S <>
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 00:39:36 -0000

On Jun 8, 2013, at 23:09, Paul Hoffman <> wrote:

> On Jun 8, 2013, at 1:52 PM, R S <> wrote:
>> A seventh point of view, which I happen to agree with: JSON strings are a sequence of code units.

That is not a very precise or useful statement if it refers to Unicode "code units", because code units can be bytes ("UTF-8 code units"), 16-bit values (UTF-16), or 32-bit values (UTF-32).
In actual JSON interchange, the code units are bytes (unless you are using the hypothetical UTF-16 or UTF-32 form of JSON).
Rob might have been trying to say "UTF-16 code units".

This view is most natural to those who think JSON should be useful as an interchange format for the "use a JavaScript string as a vector of unconstrained 16-bit values" hack.
(It is not aligned with JSON's main purpose.)

> That aligns with (2).

Not at all: It is different, and it is at a different level.

>> 2) The ABNF is more liberal about what can be in a string than that statement:
>>      char = unescaped /
>>          escape ( ...
>>              %x75 4HEXDIG )  ; uXXXX                U+XXXX
>>      ...
>>      unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

RFC 4234 is about characters and this excerpt from RFC 4627 makes it clear that its usage of ABNF is based on Unicode characters/Unicode "code points", not about UTF-16 "code units" (which would stop at 0xFFFF).

Now the ABNF is about the representation, not about the data model, so this has no bearing on whether at the data model level the "characters" in a string are Unicode characters, Unicode code points, or UTF-16 code units.

(For the latter case, if you happen to have a sequence of a high-surrogate (0xD800..0xDBFF) and a low-surrogate (0xDC00..0xDFFF), that sequence will look like a single 0x10000 to 0x10FFFF in the Unicode character/"code point" view and can be interchanged natively.  Any other usage of the surrogate "code units" will need to use a \uXXXX escape, because they can't be represented in Unicode.)

Grüße, Carsten