PHP 原生的 json_encode
方法对中文进行编码的时候,不加参数 JSON_UNESCAPED_UNICODE
获得一串类 \uXXXX
的字符串,加参数则是咱们一般看到的中文,发生了什么?php
//1.php <?php echo json_encode('好'); # php 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 <?php echo json_encode('好', JSON_UNESCAPED_UNICODE); php 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
编码的转义。即,html
展现正常的 好
是utf-8
编码;linux
\u597d
单个字符(有6个)拎出来传输的时候也都是 utf-8
编码,但在具体解析的时候,判断出有转义,将\
、u
、5
、9
、7
、d
这6个字符合在一块儿,做为utf-16
编码。json
json_encode
加参数 JSON_UNESCAPED_UNICODE
,不对字符进行 utf-16
转义,直接使用 utf-8
。因为没有使用转义,整个字符串大小也由8字节变小为5字节。缘由是转义字符 \u597d
中每一个字符占了1字节,一共是6字节,而 好
的utf-8
编码只有3字节,少用了3字节。segmentfault
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
差很少的效果
从上面输出不难看出,好
对应的字节八进制数应该就是 345
、245
、275
。工具
转换成二进制,分别是 11100101
、10100101
、10111101
。学习
二进制还能够转换成16进制数,但此处有一个字节序大小端的顾虑,哪一头开始的呢,是 275
仍是 345
对应的是开头?网站
突破口是 好
对应的是3字节,3字节的 utf-8
编码对应的开头必定是1110
(参见阮一峰的字符编码笔记:ASCII,Unicode 和 UTF-8),正好是345
的开头,且字节内部也是大端。肯定大端后,再联想到常说的网络字节序是大端。看了 json标准,utf-16
、utf-32
都有大小端的区分,惟独 utf-8
没有,那么 utf-8
编码的 json
应该就是大端的了。(也想不出若是是小端的话,多字节字符怎么判断的好)编码
将二进制转换成16进制,分别是 E5
、A5
、BD
,
找一个在线编码转换的验证 验证有没有转错了,获得结果:
字符 | 编码10进制 | 编码16进制 | Unicode编码10进制 | Unicode编码16进制 |
---|---|---|---|---|
好 | 15050173 | E5A5BD | 22909 | 597D |
E5A5BD 对上了。
另外一个在线的编码转换网站 获得的转换结果是 好
,这实际上 utf-8
对应的 unicode码点
,不是想要的 utf-8
编码,严重误导人,网上好些在线编码网站都是这样。
json
是一种传输协议,规定了一种文本组织结构,用于交互。json
经常使用 utf-8
编码, 但不是必须。unicode
是一个标准,为每个字符惟一对应定义一个 unicode码点
。utf-8
、utf-16
等是针对 unicode码点
的编码方式。好比 utf-8
编码对应的字节数在1-4字节,因为短字节数量更少,因此优先分配给了越常使用的字符(unicode码点
)。