该JSON RFC，第2.5节，说部分：
为了转义不在“基本多语言平面”中的扩展字符，该字符表示为十二个字符的序列，对UTF-16代理对进行编码。因此，例如，仅包含G谱号字符（U + 1D11E）的字符串可以表示为“ \ uD834 \ uDD1E”。
假设我有合理的理由将JSON编码为UTF-16BE（允许）。这样做时，是否仍然需要转义基本多语言平面中没有的字符？例如，代替此：
00 5C 00 75 00 44 00 38 00 33 00 34 00 5C 00 75 00 44 00 44 00 31 00 45 \ u D 8 3 4 \ u D D 1 E
这是的24字节UTF-16BE字节序列\uD834\uDD1E，这样做是否合法：
\uD834\uDD1E
D8 34 DD 1E
即直接使用4字节的UTF-16BE值？
同样，如果我要编码与UTF-32BE相同的JSON字符串，我是否可以直接使用代码点值：
00 01 D1 1E
？
据我所知，是的，您可以直接编写UTF-16值。支持：您引用的RFC段落说明了 如果决定 转义任意Unicode的方式， 则 如何 转义 。但是，在同一部分的前面，RFC表示
__除必须转义的字符外， 所有 Unicode字符 都 可以放在引号内：引号，反斜线和控制字符（U + 0000至U + 001F）。 __ 任何字符 都 可以转义。如果字符在基本多语言平面中（U + 0000到U + FFFF），则可以将其表示为六个字符的序列…
__除必须转义的字符外， 所有 Unicode字符 都 可以放在引号内：引号，反斜线和控制字符（U + 0000至U + 001F）。 __
任何字符 都 可以转义。如果字符在基本多语言平面中（U + 0000到U + FFFF），则可以将其表示为六个字符的序列…
（已添加重点。）
对我来说，这是说只"，\和控制字符 必须 进行转义，任何其他Unicode字符 可以 被放置原样直接进入JSON文本（在任何UTF形式您正在使用）。这也对我说，即使你是编码为UTF-8，你并不需要使用\uXXXX表单以外的任何Unicode字符"，\和控制字符。
"
\
\uXXXX
（顺便说一句，这的确使我想知道该\uXXXX表单是否对控制字符以外的其他内容是否真的有用。正如另一个张贴者所说，它可能归结为您的JSON解析器实际支持的内容。）
