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，这样做是否合法：
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 字符都可以直接放置到 JSON 文本中（以您使用的任何 UTF 格式）。它还告诉我，即使您将编码为 UTF-8，您也不需要将格式用于除、和控制字符\uXXXX之外的任何 Unicode字符。"\
（顺便说一句，这确实让我想知道该\uXXXX表单是否真的对控制字符以外的任何东西有用。正如另一张海报所说，它可能归结为您的 JSON 解析器实际支持的内容。）
我们探索了一个想法，它在 Azure Datafactory 中得到了发挥。在 sink 部分（Json File）中将编码格式转换为 US-ASCII。源保持相同的 REST API 链接：
