摘要：前后端交互过程中涉及的编码首先，浏览器的设置里有设置编码格式，一般设置为。按照设置的顺序检查检测文件的编码。
起因
最近在写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，对更长的序列的概率就更低了。
latin1latin1编码是单字节编码，向下兼容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，保存时候使用的编码，保存的时候自动转换为另一种编码。但是如果一开始打开的时候就识别错了编码，再转换的时候一个不存在的字符也是不会完转换的。
参考资料mysql的latin1 支持中文
UTF-8维基百科
VIM 文件编码识别与乱码处理
WilsonLiu"s blog首发地址：http://blog.wilsonliu.cn
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/86428.html
摘要：前后端交互过程中涉及的编码首先，浏览器的设置里有设置编码格式，一般设置为。按照设置的顺序检查检测文件的编码。 起因 最近在写PHP，本身对PHP不太熟练。然后遇到编码这个问题，困扰了大半天，索性，系统探索解决一番。 前后端交互过程中涉及的编码 Browser cilent: 首先，浏览器的设置里有设置编码格式，一般设置为UTF-8。 AJAX request: AJAX异步请求的过程...
摘要：前后端交互过程中涉及的编码首先，浏览器的设置里有设置编码格式，一般设置为。按照设置的顺序检查检测文件的编码。 起因 最近在写PHP，本身对PHP不太熟练。然后遇到编码这个问题，困扰了大半天，索性，系统探索解决一番。 前后端交互过程中涉及的编码 Browser cilent: 首先，浏览器的设置里有设置编码格式，一般设置为UTF-8。 AJAX request: AJAX异步请求的过程...
摘要：与响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。 JavaScript中几个最重要的大知识点 面向对象 DOM事件 异步交互ajax AJAX AJAX是异步的javascript和xml（Asynchronous Javascript And XML）的缩写，用于网页局部刷新，提升用户浏览体验 通常前端程序员关于AJAX的掌握仅仅停留在会用AJAX发送...
摘要：更新尝试了一下实现前后端分离，新的文章如下前后端分离之初试更新可另外用实现前后端分离，这篇文章可能局限性太大，只是个人的入门实践刚刚学习前端快一年，后台方面了解甚少，于是决定踩踩坑，学习一下。 2018.9.6更新：尝试了一下REST framework实现前后端分离，新的文章如下Django前后端分离之REST framework初试 2018.8.27更新：可另外用 restful...
阅读 2840·2023-04-25 15:44
阅读 1751·2019-08-30 13:11
阅读 2710·2019-08-30 11:11
阅读 2821·2019-08-29 17:21
阅读 1194·2019-08-29 15:38
阅读 748·2019-08-29 12:49
阅读 1674·2019-08-28 18:19
阅读 3124·2019-08-26 14:01
