以UTF-16或UTF-32编码JSON

Question

JSON RFC, section 2.5，部分说：

  

转义不在Basic Multilingual中的扩展字符   平面，角色表示为十二个字符的序列，   编码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

这是\uD834\uDD1E的24字节UTF-16BE字节序列，这样做是合法的：

D8 34 DD 1E

即，直接使用4字节的UTF-16BE值？

同样，如果我要编码与UTF-32BE相同的JSON字符串，我可以直接使用代码点值：

00 01 D1 1E

Answer 1

据我所知，是的，您可以直接编写UTF-16值。支持：您引用的RFC段落解释了如果您决定逃避任何Unicode ，。但是，在同一部分的早期，RFC说

  

所有 Unicode字符 可能 可以放在报价单中   标记除了必须转义的字符：引用   标记，反向实线和控制字符（U + 0000到   U + 001F）。

     

任何字符 可能 都会被转义。如果角色在   基本多语言平面（U + 0000到U + FFFF），然后它可能是   表示为六个字符的序列...

（强调补充。）

对我而言，这表示只有"，\和控制字符 必须 才能转义，并且其他任何Unicode字符可以直接放入JSON文本中（以您使用的任何UTF格式）。它还告诉我，即使您编码为UTF-8，也不需要将\uXXXX表单用于"，\以外的任何Unicode字符，以及控制人物。

（顺便说一下，这确实让我想知道\uXXXX形式是否对控制字符以外的任何其他形式都有用。正如另一张海报所说，它可能归结为你的JSON解析器实际支持的内容。）

Answer 2

我们探索了一种想法，并且在Azure Datafactory中得到了应用。在接收器部分（Json文件）中将编码格式转换为US-ASCII。源仍然是相同的REST API链接：