前后端交互过程中的编码

2016-07-25 21:00:00

起因

最近在写PHP，本身对PHP不太熟练。然后遇到编码这个问题，困扰了大半天，索性，系统探索解决一番。

前后端交互过程中涉及的编码

Browser cilent: 首先，浏览器的设置里有设置编码格式，一般设置为UTF-8。
AJAX request: AJAX异步请求的过程中可以设置编码，contentType:"application/x-www-form-urlencoded; charset=utf-8"
PHP cilent: PHP通过$_POST这个全局变量接收前端POST过来的数据，编码格式为AJAX在请求头中设置的charset=utf-8,PHP操作的过程中可以通过iconv函数库自行转码,例如iconv("UTF-8","GB2312//IGNORE",$data)
connection: 在PHP与数据库连接的过程中可以设置connection过程中使用的编码格式，例如CodeIgniter框架可以在数据库配置文件database.php中，设置'char_set' => 'latin1'
databases: 数据会先把数据从php客户端的编码转为转为connection中设置的编码，再以字节流的形式传输并插入数据库。

字符编码

常用的编码分为

UTF-8 万国码，就是它是一种变长的编码方式
latin1 又称“西欧语言”，是mysql数据库默认设置。为单字节编码
gb2312 一共收录了7445个字符，包括6763个汉字和682个其它符号。
GBK 汉字内码扩展规范,支持繁体与简体和许多符号

UTF-8

走上国际化就靠它了。现在推荐使用UTF-8，这样外国人打开我们的网站的时候不需要转码，直接就能使用。
不多说了，大家都认识。

看一下他的编码特质
UTF-8的设计有以下的多字符组序列的特质

单字节字符的最高有效比特永远为0。
多字节序列中的首个字符组的几个最高有效比特决定了序列的长度。最高有效位为110的是2字节序列，而1110的是三字节序列，如此类推。
多字节序列中其余的字节中的首两个最高有效比特为10。

UTF-8的这些特质，保证了一个字符的字节序列不会包含在另一个字符的字节序列中。这确保了以字节为基础的部分字符串比对（sub-string match）
方法可以适用于在文字中搜索字或词。有些比较旧的可变长度8位编码（如Shift JIS）没有这个特质，故字符串比对的算法变得相当复杂。虽然这增加了UTF-8
编码的字符串的信息冗余，但是利多于弊。另外，数据压缩并非Unicode的目的，所以不可混为一谈。即使在发送过程中有部分字节因错误或干扰而完全丢失，
还是有可能在下一个字符的起点重新同步，令受损范围受到限制。

另一方面，由于其字节序列设计，如果一个疑似为字符串的序列被验证为UTF-8编码，那么我们可以有把握地说它是UTF-8字符串。一段两字节随机序列碰巧为合法的UTF-8而非ASCII的概率为32分1。对于三字节序列的概率为256分1，对更长的序列的概率就更低了。

latin1

latin1编码是单字节编码，向下兼容ASCII，其编码范围是0x00-0xFF，0x00-0x7F之间完全和ASCII一致，0x80-0x9F之间是控制字符，0xA0-0xFF之间是文字符号。

因为latin1编码范围使用了单字节内的所有空间，在支持latin1的系统中传输和存储其他任何编码的字节流都不会被抛弃。换言之，把其他任何编码的字节流当作latin1编码看待都没有问题。
这是个很重要的特性，MySQL数据库默认编码是Latin1就是利用了这个特性，latin1编码是一个8位的容器。

把一个gbk编码的串写入latin1的表，不会有任何问题，保存的是原封不动的字节流，从表中读取已写入的串也不会有任何问题，且读出的字节流就和当初写入的完全一致。

读取出来以后，如果在终端下，就会理解成locale类型（如果locale系gbk，当时写入的gbk中文串可正常回显）读取出来以后，如果要写入文件，则文件编码方式即当时写入的字节流编码，如gbk写入的，读出存入文件后，文件编码也是gbk！
但是如果混着写（utf-8 + gbk),那编辑器就犯蒙了，就可能会显示会有乱码。

当然，基于可维护的角度，还是统一为UTF-8编码格式，以免出现乱码。

GBK与gb2312

因为历史原因，很多网页和数据库依然使用这个编码格式
应该逐步升级为UTF-8。

文件编码

每个文件都设置了其编码的格式,大部分推荐使用UTF-8。

VIM文件编码示例

一个文本文件，vim打开的时候按某种编码A打开，转换成某种编码B，然后保存的时候转换成另一种编码C，其他文本编辑器类似，可能没有vim这么可以设置和自动完成。
编码B：对于整个文件没有影响，只是事关显示的，就是vim与操作系统交互时候使用的编码。

编码A：使用 set fileencodings=ucs-bom,utf-8,gbk,cp936,latin-1设置。vim 按照设置的顺序检查检测文件的编码。因为某些编码里不存在某些二进制序列的组合，所以如果检测到就认为不是这种编码，检查下一种编码，否则就认为是这一种。因为latin-1可以出现任何二进制序列的组合，所以如果放到第一个，那么将永远以latin-1显示。

在一般的二进制文件里是不存在字符编码的标记的。但是Unicode里面有个特殊叫做零宽度空格（FEFF）而FFFE是不存在的编码，所以在Unicode的标准里可以人为的在开始加入这个字符（这个字符在任何字体下都是没有宽度的，在中文字符里面没有任何的效果跟没有一样，是为了照顾东南亚某些语言的显示而设置的）。这样就便于文本编辑器检查字符和字节顺序，但是在代码里include这种文件经常会出问题（这可是个大坑，编译器会认为这是一个非法字符，可是你又看不到）。

编码B：set fileencoding=utf-8，保存时候使用的编码，保存的时候自动转换为另一种编码。但是如果一开始打开的时候就识别错了编码，再转换的时候一个不存在的字符也是不会完转换的。