json_encode 使用 JSON_UNESCAPED_UNICODE

提出问题

PHP 原生的 json_encode 方法对中文进行编码的时候,不加参数 JSON_UNESCAPED_UNICODE 得到一串类 \uXXXX 的字符串,加参数则是我们通常看到的中文,发生了什么?

确认现象

//1.php
 1.txt

# ls -l 1.txt
-rw-r--r-- 1 root root 8 Jun 12 15:21 1.txt

# cat 1.txt
"\u597d"
//2.php
 2.txt

# ls -l 2.txt
-rw-r--r-- 1 root root 5 Jun 12 15:23 2.txt

# cat 2.txt
"好"

先说结论

我们通常使用的 json 格式都是 utf-8 编码,但它认可 utf-16 编码的转义。即,

展示正常的 utf-8编码;

\u597d 单个字符(有6个)拎出来传输的时候也都是 utf-8 编码,但在具体解析的时候,判断出有转义,将\u597d这6个字符合在一起,作为utf-16编码。

json_encode 加参数 JSON_UNESCAPED_UNICODE,不对字符进行 utf-16 转义,直接使用 utf-8。由于没有使用转义,整个字符串大小也由8字节变小为5字节。原因是转义字符 \u597d 中每个字符占了1字节,一共是6字节,而 utf-8编码只有3字节,少用了3字节。

验证

hexdump 可以查看文本文件以二进制格式。以下的 -c 参数,如果对应单字节有符合的 ascii 码,会直接以 ascii 码格式展示,否则以相应的八进制数展示;-b 参数,完全以8进制数展示每个字节。

# hexdump -c 1.txt
0000000   "   \   u   5   9   7   d   "       
0000008

//八进制格式
# hexdump -b 1.txt
0000000 042 134 165 065 071 067 144 042       
0000008


# hexdump -c 2.txt
0000000   " 345 245 275   "         
0000005

//八进制格式
# hexdump -b 2.txt
0000000 042 345 245 275 042          
0000005
以上使用 od -w1 -b 2.txt 有同 hexdump 差不多的效果

从上面输出不难看出, 对应的字节八进制数应该就是 345245275

转换成二进制,分别是 111001011010010110111101

二进制还可以转换成16进制数,但此处有一个字节序大小端的顾虑,哪一头开始的呢,是 275 还是 345 对应的是开头?

突破口是 对应的是3字节,3字节的 utf-8 编码对应的开头一定是1110(参见阮一峰的字符编码笔记:ASCII,Unicode 和 UTF-8),正好是345的开头,且字节内部也是大端。确定大端后,再联想到常说的网络字节序是大端。看了 json标准utf-16utf-32 都有大小端的区分,唯独 utf-8 没有,那么 utf-8 编码的 json 应该就是大端的了。(也想不出如果是小端的话,多字节字符怎么判断的好)

将二进制转换成16进制,分别是 E5A5BD

找一个在线编码转换的验证 验证有没有转错了,得到结果:

字符 编码10进制 编码16进制 Unicode编码10进制 Unicode编码16进制
15050173 E5A5BD 22909 597D

E5A5BD 对上了。

另一个在线的编码转换网站 得到的转换结果是 ,这实际上 utf-8 对应的 unicode码点,不是想要的 utf-8 编码,严重误导人,网上好些在线编码网站都是这样。

一些定义说明

  1. json 是一种传输协议,规定了一种文本组织结构,用于交互。json 常用 utf-8 编码, 但不是必须。
  2. unicode 是一个标准,为每一个字符唯一对应定义一个 unicode码点
  3. utf-8utf-16 等是针对 unicode码点 的编码方式。比如 utf-8 编码对应的字节数在1-4字节,由于短字节数量更少,所以优先分配给了越常使用的字符(unicode码点)。

参考

你可能感兴趣的:(json,php,unicode,utf-8)