登录
首页 >  数据库 >  MySQL

前后端交互过程中的编码

来源:SegmentFault

时间:2023-01-14 14:02:52 331浏览 收藏

知识点掌握了,还需要不断练习才能熟练运用。下面golang学习网给大家带来一个数据库开发实战,手把手教大家学习《前后端交互过程中的编码》,在实现功能的过程中也带大家重新温习相关知识点,温故而知新,回头看看说不定又有不一样的感悟!

起因

最近在写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

以上就是本文的全部内容了,是否有顺利帮助你解决问题?若是能给你带来学习上的帮助,请大家多多支持golang学习网!更多关于数据库的相关知识,也可关注golang学习网公众号。

声明:本文转载于:SegmentFault 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>
评论列表