文字编码总结

做一个试验。

新建一个文本文件，然后用记事本打开，输入“联通”，保存，关闭。

再次用记事本打开这个文本文件，你看到了什么？

这被人戏称是联通干不过移动的根本原因——连自己的名字都存不下来。

下面对字符的编码进行一下总结，会在其中说明联通消失的原因。

ASCII = American Standard Code for Information Interchange， “美国信息交换标准码”

ASCII码规定每个字符例使用1个字节来表示，也就是8位的二进制组合，那么就有00000000-11111111一共256种组合，也就是可以表示256个不同的字符。

但是实际上ASCII共计有128个，从0到127，也就是从00000000-01111111，最高位都是0。

目的：解决汉字等英文字母以外字符的显示问题。

基本方法：使用最高位是1的字符（防止与ASCII冲突），2个字节表示一个汉字。

编码转换方法举例：

这些使用 2 个字节来代表一个字符的各种文字延伸编码方式，称为 ANSI 编码。

注意ANSI编码指是“本地化”编码，在各个国家对应的编码体系是不同的。

在中文环境下以ANSI编码存储的文件，在日文环境下打开是乱码。因为一个是GB2312编码，一个是JIS编码。

（顺便吐槽，有个国标组织是很幸福的事情，日本通用的编码方式至少有四套，特么的两个公司做的系统之间通信，弄的跟国际化似的还要转换编码，比如：神奇的みずほ银行）

为了使国际间信息交流更加方便，国际组织制定了unicode字符集。

为各种语言中的每一个字符设定了统一并且唯一的数字编号，以满足跨语言、跨平台进行文本转换、处理的要求。

unicode用数字0-0x10FFFF来映射这些字符，最多可以容纳1114112个字符。

unicode编码中，不管什么文字统一使用4字节表示一个文字。

unicode中，每个字符用 4 个字节在存储、传输时会产生浪费。

UTF-8、UTF-16、UTF-32都是unicode的“紧凑”编码。都是 可变长度 编码。（所以想一下java中计算字符串长度时，碰到汉字的时候得到的到底是什么的长度？）

UTF = Unicode Transformation Format。

其中UTF-32使用32位整数编码，还是占4个字节（32bit），所以基本上不会使用。

UTF-8或UTF-16，分别由 8-bit 或 16-bit 为一个单元组成，下标值较小的编码点占用的字节数也少。

utf-8 使用 1~4 个不等的字节来存储字符编码。

以“郑”字为例，说明从unicode到utf-8的转换。

UTF-8 有一个方便的属性，即最开始128 个字符（ASCII字符）被编码为单个字节。

使用 NotePad++ 这样的文本编辑器时，可以将文件“以 UTF-8 无 BOM 格式编码”。

所谓的BOM，全称是Byte order mark。

作用是在文件最开始加入一个标识符，让文本编辑器明确知道读入的文件是以何种方式编码的。

常用的BOM如下：

记事本默认的编码是 ANSI，对于中文系统中就是 GBK 编码。

“联”字的编码是 0xc1aa，二进制 110 0 0001 10 10 1010。

“通”字的编码是 0xcda8，二进制 110 0 1101 10 10 1000

→ 这玩意跟编码规则中第二行是相符的。

所以记事本再次打开这个文件的时候，将其识别成了“UTF-8 无 BOM 格式”，所以全程按照utf-8编码规则解析，就变成了乱码。

人家移动俩字就没这事。电信啥的也都没事。

结论：当文档中的所有字符的二进制编码在C0≤AA(第一个字节)≤DF 80≤BB(第二个字节)≤BF时，记事本都无法确认文本的编码格式，就按照UTF-8的格式来显示。

在第一章提到的第三个阶段（国际化）的初期，其实有两套国际化编码。

UCS-2 是 ISO 10646标准为“通用字符集”（UCS）定义的16位 固定长度 编码。

它包含65536个编码空间，存储的是全世界最常用的65536个字符编码。

可以认为 UCS-2 是 UTF-16 的一个子集，编码相同。其实UCS-2就是原始的双字节Unicode编码。

UCS-2 这种两字节定长编码，在存储的时候，有两种格式。

参看 Notepad++ 的编码菜单，里面有“以 UCS-2 Little endian 格式编码”以及“以 UCS-2 Big endian 格式编码”

比如“郑”的编码是 90D1 （没错，对于这个字的编码，unicode、ucs-2和utf-16是相同的）

如果存储为 90D1，叫做BE（Big endian）；倒过来存为 D190 的话，称为LE（Little endian）。

习惯windows系统的人可能根本没见过LE，但是在Unix/Linux中这种情况并不少见。

在 UCS-2/unicode（兼容） 编码标准中，规定在每一个文件的最前面分别加入一个表示编码顺序的字符，这个字符的名字叫做"零宽度非换行空格"（zero width no-break space）。

→ 等等，文件头上的信息不是BOM吗？

完整的BOM编码

也就是说，表达编码种类以及BE、LE的工作都是由BOM来完成的

其实Linux默认UTF-8编码应该不带BOM的。

尽管 Unicode 标准允许在 UTF-8 中使用 BOM，但不含 BOM 的 UTF-8 才是标准形式，在 UTF-8 文件中放置 BOM 主要是微软的习惯。

因为把带有BOM的小端（LE）的 UTF-16 称作「Unicode」也是微软的习惯

猜（参看联通事件）

mysql支持的 utf8 编码最大字符长度为3字节，而标准的utf-8最大字符长度为4字节。

三个字节的 UTF-8 最大能编码的 Unicode 字符是 0xffff，也就是 Unicode 中所谓的“基本多文种平面（BMP）”。能够应对绝大多数应用场景。

（MySQL刚开发的时候，unicode本身也没有提出“辅助平面”，所以3字节的设计是无可厚非的）

但是包括 Emoji 表情、一些特殊汉字在内的字符是无法存储的。

MySQL 5.5.3 版本以后，推出utf8mb4字符集，用来对应标准的utf-8。

可以参看这篇文章中的“Unicode 介绍”一节

Unicode 及编码方式概述

简单来说，就是把所有字符统一转换成可见字符。

Base64是一种基于64个可打印字符来表示二进制数据的表示方法。

（ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/）

Base64常用于在通常处理文本数据的场合，表示、传输、存储一些二进制数据，包括MIME的电子邮件及XML的一些复杂数据。

由于 2的6次幂=64，所以Base64编码中，以6个比特为一个单元，对应某个可打印字符。

比如，3个字节一共24比特，那么就对应4个Base64单元。

也就是说，编码后的数据长度为原来的 4/3。

若原数据长度不是3的倍数时且剩下1个输入数据，则在编码结果后加2个=；若剩下2个输入数据，则在编码结果后加1个=。

举例：

如果要编码的字节数不能被3整除，最后会多出1个或2个字节，那么可以使用下面的方法进行处理：先使用0字节值在末尾补足，使其能够被3整除，然后再进行Base64的编码。在编码后的Base64文本后加上一个或两个=号，代表补足的字节数。也就是说，当最后剩余两个八位字节（2个byte）时，最后一个6位的Base64字节块有四位是0值，最后附加上两个等号；如果最后剩余一个八位字节（1个byte）时，最后一个6位的base字节块有两位是0值，最后附加一个等号。

UTF-7是一个修改版Base64（Modified Base64）。

主要是将UTF-16的数据，用Base64的方法编码为可打印的ASCII字符序列。目的是传输Unicode数据。

主要的区别在于不用等号=补余，因为该字符通常需要大量的转译。

URL编码(URL encoding)，也称作百分号编码(Percent-encoding)。

适用于统一资源标识符(URI)的编码，也用于为"application/x-www-form-urlencoded" MIME准备数据。

将需要转码的字符转为16进制，然后从右到左，取4位(不足4位直接处理)，每2位做一位，前面加上%，编码成%XY格式。

举例1：

空格ASCII码是32，对应16进制是20，那么urlencode编码结果是:%20,但在最新标准（RFC-1738）中空格对应的是+。

举例2：

“中”的GB2312码是0xD6D0，那么urlencode编码结果是:%D6%D0

不知道你说的这个65535限制是什么意思，text类型只能放 2^16-1 就是 65535个字符，如果想放大数据量的话，你应该修改为MEDIUMBLOB 或 MEDIUMTEXT类型，可以放 2^24-1就是16777215应该足够大了吧

---