Mysql的字符和字节

前言

前几天无意中刷脉脉的时候，看到一个人吐槽微信的拍一拍尾巴的填写报错提示，其中评论区也感觉蛮多人对汉字，字符，字节这几个概念认知不够清晰。因为我之前也是做技术的，虽然很多知识概念都忘得差不多了，但是隐隐就感觉评论区说的是错误的。

于是乎我花了点时间，在网上找了一些资料和文章等，收集一波发出来，跟大家共同学习。

以下内容都是从网上找的，我会注明出处，再加上一些自己的理解和解析，以便于非技术产品也能读懂，那么我们就开始吧。

什么是字节？

字节的百科定义是：

❝

字节（Byte）是计算机信息技术用于计量存储容量的一种计量单位。

如果你只是在纸上写字，那么就用不到字节，但是如果你要把字存入电脑，就需要占用一定的磁盘空间。我们知道，电脑只能用高电位、低电位的形式存储数据，抽象出来，那就是电脑存数据最终只能用二进制的形式，也就是用0和1表示，无论任何数据，最终存储的时候都是一段包含多个0和1的串，例如“00110101”，这里的每一个0或1被称为1位。

“位”就是最小的存储单位，然后我们把8位称为1个字节，也就是1个字节等于8位。这个概念类似于“1公里=1000米”，本质上是一回事，只是使用不同级别的单位而已。由于二进制实在太长，不方便展示，所以一般将1个字节（8位）的二进制转换成十六进制进行展示，例如将11010011转换成十六进制就是D3，这就是一个字节。

我们可以看下字符“你”在UTF-8字符集下的表示方式，在MySQL中你可以直接使用 HEX() 函数来进行转换。

ｓｅｌｅｃｔ HEX(‘你‘)        -- E4BDA0 

可以看出，使用UTF-8字符集，字符“你”需要使用3个字节来进行存储（分别是E4，BD，A0），实际存储的二进制是

111001001011110110100000 

再次说明，E4BDA0 只是 111001001011110110100000 的简写形式，两者本质上是一回事。

我们继续看一下，存储一个英文字符需要占用多少字节。

ｓｅｌｅｃｔ HEX(‘Z‘)    -- 5A 

可以看到，存储英文字符“Z”只需要一个字节。

在MySQL中，你可以直接使用 LENGTH() 函数来查看指定字符串占用的空间（字节数）。

ｓｅｌｅｃｔ LENGTH(‘你‘)    -- 3 ｓｅｌｅｃｔ LENGTH(‘Z‘)     -- 1 ｓｅｌｅｃｔ LENGTH(‘A啊a1‘) -- 6 

你可以直接记住结论：在UTF-8字符集下，一个中文字符占用3个字节，一个英文字符占用1个字节。如果要计算字符串占用的字节数，只需要按照这个方式相加即可。

什么是字符？

以下是百科对字符的定义：

❝

字符指类字形单位或符号，包括字母、数字、运算符号、标点符号和其他符号，以及一些功能性符号。

为了方便理解，你可以将字符简单地理解为你可以用输入法单独打出的任何单个的内容(空格也算是字符)。对于中文和英文而言，以下内容分别都是1个字符：

（1）1个中文字，例如“是”

（2）1个英文字母，例如“T”

（3）1个中文标点符号，例如“。”

（4）1个英文标点符号，例如“.”

所谓的“字符串”就是由以上说的一个个字符组成的，字符串就是由一个个字符拼接而成的列表，以下是Javascript代码演示：

const str = ‘A啊a1‘ console.log(str[0])    // ‘A‘ console.log(str[1])    // ‘啊‘ console.log(str[2])    // ‘a‘ console.log(str[3])    // ‘1‘ 

在MySQL中，你可以使用CHAR_LENGTH()函数，查看指定字符串的字符数。例如：

ｓｅｌｅｃｔ CHAR_LENGTH(‘A啊a1‘)        -- 4 

以上内容摘自知乎《一文搞懂字符和字节的含义》，有所删改，去掉了一些容易造成理解困难的原理等

字符编码的来龙去脉

因为计算机只能处理数字，如果要处理文本，就必须先把文本转换为数字才能处理。最早的计算机在设计时采用8个比特（bit）作为一个字节（byte），所以一个字节能表示的最大的整数就是255（二进制11111111=十进制255），如果要表示更大的整数，就必须用更多的字节。比如两个字节可以表示的最大整数是65535，4个字节可以表示的最大整数是4294967295。

由于计算机是美国人发明的，因此，最早只有127个字符被编码到计算机里，也就是大小写英文字母、数字和一些符号，这个编码表被称为ASCII编码，比如大写字母A的编码是65，小写字母z的编码是122。

但是要处理中文显然一个字节是不够的，至少需要两个字节，而且还不能和ASCII编码冲突，所以，中国制定了GB2312编码，用来把中文编进去。

你可以想得到的是，全世界有上百种语言，日本把日文编到Shift_JIS里，韩国把韩文编到Euc-kr里，各国有各国的标准，就会不可避免地出现冲突，结果就是，在多语言混合的文本中，显示出来会有乱码。

因此，Unicode应运而生。Unicode把所有语言都统一到一套编码里，这样就不会再有乱码问题了。

Unicode标准也在不断发展，但最常用的是用两个字节表示一个字符（如果要用到非常偏僻的字符，就需要4个字节）。现代操作系统和大多数编程语言都直接支持Unicode。

现在，捋一捋ASCII编码和Unicode编码的区别：ASCII编码是1个字节，而Unicode编码通常是2个字节。

字母A用ASCII编码是十进制的65，二进制的01000001；

字符0用ASCII编码是十进制的48，二进制的00110000，注意字符‘0‘和整数0是不同的；

汉字中已经超出了ASCII编码的范围，用Unicode编码是十进制的20013，二进制的01001110 00101101。

你可以猜测，如果把ASCII编码的A用Unicode编码，只需要在前面补0就可以，因此，A的Unicode编码是00000000 01000001。

新的问题又出现了：如果统一成Unicode编码，乱码问题从此消失了。但是，如果你写的文本基本上全部是英文的话，用Unicode编码比ASCII编码需要多一倍的存储空间，在存储和传输上就十分不划算。

所以，本着节约的精神，又出现了把Unicode编码转化为“可变长编码”的 UTF-8 编码。

UTF-8编码把一个Unicode字符根据不同的数字大小编码成1-6个字节，常用的英文字母被编码成1个字节，汉字通常是3个字节，只有很生僻的字符才会被编码成4-6个字节。如果你要传输的文本包含大量英文字符，用UTF-8编码就能节省空间：

从上面的表格还可以发现，UTF-8编码有一个额外的好处，就是ASCII编码实际上可以被看成是UTF-8编码的一部分，所以，大量只支持ASCII编码的历史遗留软件可以在UTF-8编码下继续工作。

搞清楚了ASCII、Unicode和UTF-8的关系，我们就可以总结一下现在计算机系统通用的字符编码工作方式：

在计算机内存中，统一使用Unicode编码，当需要保存到硬盘或者需要传输的时候，就转换为UTF-8编码。

用记事本编辑的时候，从文件读取的UTF-8字符被转换为Unicode字符到内存里，编辑完成后，保存的时候再把Unicode转换为UTF-8保存到文件：

浏览网页的时候，服务器会把动态生成的Unicode内容转换为UTF-8再传输到浏览器：

所以你看到很多网页的源码上会有类似的信息，表示该网页正是用的UTF-8编码。

以上内容摘自《廖雪峰的官方网站——Python教程：字符串和编码》。

皮酱叨叨一下

关于字符和字节的概念，其实很多搞技术的朋友很早的时候都会接触，但是原理性的东西往往其实用的不多或者说藏得很深，所以就造成了只会用工具或技术但是不懂其原理的人有很多。

对于产品经理来说，并没有什么资格来谈技术相关的科普或者是纠错等，我纯粹是出于个人兴趣然后针对这个问题去找了一些科普知识来分享给大家。

显然上面脉脉评论区的回答并不正确，字符就是字符，并不存在什么“一个汉字等于两个字符”这种说法。

当然“一个汉字等于两个字节”这种说法也不严谨，上面也提到了对于编码集为GB2312的时候，一个汉字是占用两个字节来存储的，但是对于UTF-8的编码集来说，一个汉字是用三个字节来存储的，同时对于一些生僻字或者异形字，可能是需要4-6个字节存储。而目前大家用的最多，最广的编码集就是UTF-8，所以可以说大多数情况下，一个汉字是占用三个字节的。

如果遇到大佬要跟你抬杠，搞字眼游戏。那咱就认怂，反正原理咱知道了就行，争这个口舌之快没什么意义。

现在我们回到最开始的问题：微信的报错提示应该怎么写？

我刚刚用微信拍一拍的小尾巴试了下，发现微信已经调整了报错提示，当输入超过8个汉字的时候会提示“最多可输入8个文字”。

同时我也试了输入一些片假名，平假名，还有俄文，藏语等，发现都是一样的提示。文字只能输入8个，但是字母和数字可以输入16个，标点符号全角可以输入8个，半角可以输入16个。

这个技术的限制方案是怎么做的，作为产品的我，不懂，也不用理解。对于普通用户来说，更不用知道了。只需要在使用的时候能知道自己输入的是否过长，是否能够提交成功即可。

这次微信小小的改动其实做的挺好的，直接在输入的时候校验长度是否合理，而不是非要提交之后才能知道是否超过了长度，提升了不少友好度，同时也将给出的文案提醒也改了，将汉字改成了文字，更加准确一些，也容易让用户理解（比叫做字符好一点）。

所以，这一波，你理解了汉字，字符和字节的关系了吗？

后续如果要写相应的报错文案的时候，可别搞错了哦！

END