先后端交互过程当中的编码

原由

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

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

1. Browser cilent: 首先，浏览器的设置里有设置编码格式，通常设置为UTF-8。

2. AJAX request: AJAX异步请求的过程当中能够设置编码，contentType:"application/x-www-form-urlencoded; charset=utf-8"

3. PHP cilent: PHP经过$_POST这个全局变量接收前端POST过来的数据，编码格式为AJAX在请求头中设置的charset=utf-8,PHP操做的过程当中能够经过iconv函数库自行转码,例如iconv("UTF-8","GB2312//IGNORE",$data)

4. connection: 在PHP与数据库链接的过程当中能够设置connection过程当中使用的编码格式，例如CodeIgniter框架能够在数据库配置文件database.php中，设置'char_set' => 'latin1'

5. 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，保存时候使用的编码，保存的时候自动转换为另外一种编码。可是若是一开始打开的时候就识别错了编码，再转换的时候一个不存在的字符也是不会完转换的。

参考资料

1. mysql的latin1 支持中文

2. UTF-8维基百科

3. VIM 文件编码识别与乱码处理

WilsonLiu's blog首发地址：http://blog.wilsonliu.cn