以UTF-16或UTF-32编码JSON

Pau*_*cas 12 unicode json character-encoding

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
Run Code Online (Sandbox Code Playgroud)

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

D8 34 DD 1E
Run Code Online (Sandbox Code Playgroud)

即,直接使用4字节UTF-16BE值?

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

00 01 D1 1E
Run Code Online (Sandbox Code Playgroud)

Chr*_*ery 18

据我所知,是的,您可以直接编写UTF-16值.支持:您引用的RFC段落解释了如果您决定转义它,如何转义任意Unicode .然而,在同一部分的早期,RFC说

除了必须转义的字符外,所有 Unicode字符可以放在引号内:引号,反向固定和控制字符(U + 0000到U + 001F).

任何角色都可能被转义.如果角色在基本多语言平面(U + 0000到U + FFFF)中,那么它可以表示为六个字符的序列......

(重点补充.)

对我来说,这是说只",\和控制字符必须进行转义,任何其他Unicode字符可以被放置原样直接进入JSON文本(在任何UTF形式您正在使用).这也对我说,即使你是编码为UTF-8,你并不需要使用\uXXXX表单以外的任何Unicode字符",\和控制字符.

(顺便说一句,这确实让我想知道这个\uXXXX表单是否真的对控制字符以外的任何东西都有用.正如另一张海报所说,它可能归结为你的JSON解析器实际支持的东西.)

  • +1.`\ u`表单对JSONP的使用比直接JSON更多,因为(a)你无法确定包含页面正在使用什么`charset`并在`<script'的`Content-Type`中设置`charset` >`不可靠; (b)字符U + 2028和U + 2029在JavaScript中是非法的(因此也就是JSONP) - 这是JSON允许它们的一些疏忽. (4认同)