二手交易网站开发,汕头e京网,电商模式,网站开发推进计划表什么是字符集 什么是字符编码 UTF-8和Unicode的关系 UTF-8编码简介 为什么会出现乱码 如何识别乱码的本来想要表达的文字 常见问题处理之Emoji 本文将简述字符集#xff0c;字符编码的概念。以及在遭遇乱码时的一些常用诊断技巧 背景#xff1a;字符集和编码无疑是IT菜鸟甚至… 什么是字符集 什么是字符编码 UTF-8和Unicode的关系 UTF-8编码简介 为什么会出现乱码 如何识别乱码的本来想要表达的文字 常见问题处理之Emoji 本文将简述字符集字符编码的概念。以及在遭遇乱码时的一些常用诊断技巧 背景字符集和编码无疑是IT菜鸟甚至是各种大神的头痛问题。当遇到纷繁复杂的字符集各种火星文和乱码时问题的定位往往变得非常困难。本文就将会从原理方面对字符集和编码做个简单的科普介绍同时也会介绍一些通用的乱码故障定位的方法以方便读者以后能够更从容的定位相关问题。在正式介绍之前先做个小申明如果你希望非常精确的理解各个名词的解释那么可以查阅wikipedia。本文是博主通过自己理解消化后并转化成易懂浅显的表述后的介绍。 什么是字符集 在介绍字符集之前我们先了解下为什么要有字符集。我们在计算机屏幕上看到的是实体化的文字而在计算机存储介质中存放的实际是二进制的比特流。那么在这两者之间的转换规则就需要一个统一的标准否则把我们的U盘插到老板的电脑上文档就乱码了小伙伴QQ上传过来的文件在我们本地打开又乱码了。于是为了实现转换标准各种字符集标准就出现了。简单的说字符集就规定了某个文字对应的二进制数字存放方式编码和某串二进制数值代表了哪个文字解码的转换关系。 那么为什么会有那么多字符集标准呢这个问题实际非常容易回答。问问自己为什么我们的插头拿到英国就不能用了呢为什么显示器同时有DVIVGAHDMIDP这么多接口呢很多规范和标准在最初制定时并不会意识到这将会是以后全球普适的准则或者处于组织本身利益就想从本质上区别于现有标准。于是就产生了那么多具有相同效果但又不相互兼容的标准了。 说了那么多我们来看一个实际例子下面就是屌这个字在各种编码下的十六进制和二进制编码结果怎么样有没有一种很屌的感觉 字符集 16进制编码 对应的二进制数据UTF-80xE5B18C1110 0101 1011 0001 1000 1100UTF-160x5C4C1011 1000 1001 1000GBK0x8CC51000 1100 1100 0101 什么是字符编码 字符集只是一个规则集合的名字对应到真实生活中字符集就是对某种语言的称呼。例如英语汉语日语。对于一个字符集来说要正确编码转码一个字符需要三个关键元素字库表character repertoire、编码字符集coded character set、字符编码character encoding form。其中字库表是一个相当于所有可读或者可显示字符的数据库字库表决定了整个字符集能够展现表示的所有字符的范围。编码字符集即用一个编码值code point来表示一个字符在字库中的位置。字符编码将编码字符集和实际存储数值之间的转换关系。一般来说都会直接将code point的值作为编码后的值直接存储。例如在ASCII中A在表中排第65位而编码后A的数值是0100 0001也即十进制的65的二进制转换结果。 看到这里可能很多读者都会有和我当初一样的疑问字库表和编码字符集看来是必不可少的那既然字库表中的每一个字符都有一个自己的序号直接把序号作为存储内容就好了。为什么还要多此一举通过字符编码把序号转换成另外一种存储格式呢其实原因也比较容易理解统一字库表的目的是为了能够涵盖世界上所有的字符但实际使用过程中会发现真正用的上的字符相对整个字库表来说比例非常低。例如中文地区的程序几乎不会需要日语字符而一些英语国家甚至简单的ASCII字库表就能满足基本需求。而如果把每个字符都用字库表中的序号来存储的话每个字符就需要3个字节这里以Unicode字库为例这样对于原本用仅占一个字符的ASCII编码的英语地区国家显然是一个额外成本存储体积是原来的三倍。算的直接一些同样一块硬盘用ASCII可以存1500篇文章而用3字节Unicode序号存储只能存500篇。于是就出现了UTF-8这样的变长编码。在UTF-8编码中原本只需要一个字节的ASCII字符仍然只占一个字节。而像中文及日语这样的复杂字符就需要2个到3个字节来存储。 UTF-8和Unicode的关系 看完上面两个概念解释那么解释UTF-8和Unicode的关系就比较简单了。Unicode就是上文中提到的编码字符集而UTF-8就是字符编码即Unicode规则字库的一种实现形式。随着互联网的发展对同一字库集的要求越来越迫切Unicode标准也就自然而然的出现。它几乎涵盖了各个国家语言可能出现的符号和文字并将为他们编号。详见Unicode on Wikipedia。Unicode的编号从0000开始一直到10FFFF共分为16个Plane每个Plane中有65536个字符。而UTF-8则只实现了第一个Plane可见UTF-8虽然是一个当今接受度最广的字符集编码但是它并没有涵盖整个Unicode的字库这也造成了它在某些场景下对于特殊字符的处理困难下文会有提到。 UTF-8编码简介 为了更好的理解后面的实际应用我们这里简单的介绍下UTF-8的编码实现方法。即UTF-8的物理存储和Unicode序号的转换关系。 UTF-8编码为变长编码。最小编码单位code unit为一个字节。一个字节的前1-3个bit为描述性部分后面为实际序号部分。 如果一个字节的第一位为0那么代表当前字符为单字节字符占用一个字节的空间。0之后的所有部分7个bit代表在Unicode中的序号。如果一个字节以110开头那么代表当前字符为双字节字符占用2个字节的空间。110之后的所有部分5个bit加上后一个字节的除10外的部分6个bit代表在Unicode中的序号。且第二个字节以10开头如果一个字节以1110开头那么代表当前字符为三字节字符占用2个字节的空间。110之后的所有部分5个bit加上后两个字节的除10外的部分12个bit代表在Unicode中的序号。且第二、第三个字节以10开头如果一个字节以10开头那么代表当前字节为多字节字符的第二个字节。10之后的所有部分6个bit和之前的部分一同组成在Unicode中的序号。 具体每个字节的特征可见下表其中x代表序号部分把各个字节中的所有x部分拼接在一起就组成了在Unicode字库中的序号 Byte 1 Byte 2 Byte30xxx xxxx 110x xxxx10xx xxxx 1110 xxxx10xx xxxx10xx xxxx 我们分别看三个从一个字节到三个字节的UTF-8编码例子 实际字符在Unicode字库序号的十六进制在Unicode字库序号的二进制UTF-8编码后的二进制UTF-8编码后的十六进制$0024010 01000010 010024¢00A2000 1010 00101100 0010 1010 0010C2 A2€20AC0010 0000 1010 11001110 0010 1000 0010 1010 1100E2 82 AC 细心的读者不难从以上的简单介绍中得出以下规律 3个字节的UTF-8十六进制编码一定是以E开头的2个字节的UTF-8十六进制编码一定是以C或D开头的1个字节的UTF-8十六进制编码一定是以比8小的数字开头的 为什么会出现乱码 乱码也就是英文常说的mojibake由日语的文字化け音译。 简单的说乱码的出现是因为编码和解码时用了不同或者不兼容的字符集。对应到真实生活中就好比是一个英国人为了表示祝福在纸上写了bless编码过程。而一个法国人拿到了这张纸由于在法语中bless表示受伤的意思所以认为他想表达的是受伤解码过程。这个就是一个现实生活中的乱码情况。在计算机科学中一样一个用UTF-8编码后的字符用GBK去解码。由于两个字符集的字库表不一样同一个汉字在两个字符表的位置也不同最终就会出现乱码。 我们来看一个例子假设我们用UTF-8编码存储很屌两个字会有如下转换 字符 UTF-8编码后的十六进制很E5BE88屌E5B18C 于是我们得到了E5BE88E5B18C这么一串数值。而显示时我们用GBK解码进行展示通过查表我们获得以下信息 两个字节的十六进制数值 GBK解码后对应的字符E5BE寰88E5堝B18C睂 解码后我们就得到了寰堝睂这么一个错误的结果更要命的是连字符个数都变了。 如何识别乱码的本来想要表达的文字 要从乱码字符中反解出原来的正确文字需要对各个字符集编码规则有较为深刻的掌握。但是原理很简单这里用最常见的UTF-8被错误用GBK展示时的乱码为例来说明具体反解和识别过程。 第1步 编码 假设我们在页面上看到寰堝睂这样的乱码而又得知我们的浏览器当前使用GBK编码。那么第一步我们就能先通过GBK把乱码编码成二进制表达式。当然查表编码效率很低我们也可以用以下SQL语句直接通过MySQL客户端来做编码工作 mysql [localhost] {msandbox} select hex(convert(寰堝睂 using gbk));
-------------------------------------
| hex(convert(寰堝睂 using gbk)) |
-------------------------------------
| E5BE88E5B18C |
-------------------------------------
1 row in set (0.01 sec) 第2步 识别 现在我们得到了解码后的二进制字符串E5BE88E5B18C。然后我们将它按字节拆开。 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6E5BE88E5B18C 然后套用之前UTF-8编码介绍章节中总结出的规律就不难发现这6个字节的数据符合UTF-8编码规则。如果整个数据流都符合这个规则的话我们就能大胆假设乱码之前的编码字符集是UTF-8 第3步 解码 然后我们就能拿着E5BE88E5B18C用UTF-8解码查看乱码前的文字了。当然我们可以不查表直接通过SQL获得结果 mysql [localhost] {msandbox} ((none)) select convert(0xE5BE88E5B18C using utf8);
------------------------------------
| convert(0xE5BE88E5B18C using utf8) |
------------------------------------
| 很屌 |
------------------------------------
1 row in set (0.00 sec) 常见问题处理之Emoji 所谓Emoji就是一种在Unicode位于\u1F601-\u1F64F区段的字符。这个显然超过了目前常用的UTF-8字符集的编码范围\u0000-\uFFFF。Emoji表情随着IOS的普及和微信的支持越来越常见。下面就是几个常见的Emoji: 那么Emoji字符表情会对我们平时的开发运维带来什么影响呢最常见的问题就在于将他存入MySQL数据库的时候。一般来说MySQL数据库的默认字符集都会配置成UTF-8三字节而utf8mb4在5.5以后才被支持也很少会有DBA主动将系统默认字符集改成utf8mb4。那么问题就来了当我们把一个需要4字节UTF-8编码才能表示的字符存入数据库的时候就会报错ERROR 1366: Incorrect string value: \xF0\x9D\x8C\x86 for column 。 如果认真阅读了上面的解释那么这个报错也就不难看懂了。我们试图将一串Bytes插入到一列中而这串Bytes的第一个字节是\xF0意味着这是一个四字节的UTF-8编码。但是当MySQL表和列字符集配置为UTF-8的时候是无法存储这样的字符的所以报了错。 那么遇到这种情况我们如何解决呢有两种方式升级MySQL到5.6或更高版本并且将表字符集切换至utf8mb4。第二种方法就是在把内容存入到数据库之前做一次过滤将Emoji字符替换成一段特殊的文字编码然后再存入数据库中。之后从数据库获取或者前端展示时再将这段特殊文字编码转换成Emoji显示。第二种方法我们假设用-*-1F601-*-来替代4字节的Emoji那么具体实现python代码可以参见Stackoverflow上的回答 reference 如何配置Python默认字符集 字符编码笔记ASCIIUnicode和UTF-8 Unicode中文编码表 Emoji Unicode Table Every Developer Should Know About The Encoding
