前后端交互过程中的编码

起因

最近在写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里面有个特殊叫做零宽度空格(\FE\FF)而\FF\FE是不存在的编码,所以在Unicode的标准里可以人为的在开始加入这个字符(这个字符在任何字体下都是没有宽度的,在中文字符里面没有任何的效果跟没有一样,是为了照顾东南亚某些语言的显示而设置的)。这样就便于文本编辑器检查字符和字节顺序,但是在代码里include这种文件经常会出问题(这可是个大坑,编译器会认为这是一个非法字符,可是你又看不到)。

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

参考资料

  1. mysql的latin1 支持中文
  2. UTF-8维基百科
  3. VIM 文件编码识别与乱码处理
分享 留言