字符编码笔记：ASCII，Unicode 和UTF-8 - 阮一峰的网络日志

一、ASCII 码

我们知道，计算机内部，所有信息最终都是一个二进制值。每一个二进制位（bit）有 0 和 1 两种状态，因此八个二进制位就可以组合出256种状态，这被称为一个字节（byte）。也就是说，一个字节一共可以用来表示256种不同的状态，每一个状态对应一个符号，就是256个符号，从 00000000 到 11111111 。

上个世纪60年代，美国制定了一套字符编码，对英语字符与二进制位之间的关系，做了统一规定。这被称为 ASCII 码，一直沿用至今。

ASCII 码一共规定了128个字符的编码，比如空格 SPACE 是32（二进制 00100000 ），大写的字母 A 是65（二进制 01000001 ）。这128个符号（包括32个不能打印出来的控制符号），只占用了一个字节的后面7位，最前面的一位统一规定为 0 。

二、非 ASCII 编码

英语用128个符号编码就够了，但是用来表示其他语言，128个符号是不够的。比如，在法语中，字母上方有注音符号，它就无法用 ASCII 码表示。于是，一些欧洲国家就决定，利用字节中闲置的最高位编入新的符号。比如，法语中的 é 的编码为130（二进制 10000010 ）。这样一来，这些欧洲国家使用的编码体系，可以表示最多256个符号。

但是，这里又出现了新的问题。不同的国家有不同的字母，因此，哪怕它们都使用256个符号的编码方式，代表的字母却不一样。比如，130在法语编码中代表了 é ，在希伯来语编码中却代表了字母 Gimel ( ג )，在俄语编码中又会代表另一个符号。但是不管怎样，所有这些编码方式中，0--127表示的符号是一样的，不一样的只是128--255的这一段。

至于亚洲国家的文字，使用的符号就更多了，汉字就多达10万左右。一个字节只能表示256种符号，肯定是不够的，就必须使用多个字节表达一个符号。比如，简体中文常见的编码方式是 GB2312，使用两个字节表示一个汉字，所以理论上最多可以表示 256 x 256 = 65536 个符号。

中文编码的问题需要专文讨论，这篇笔记不涉及。这里只指出，虽然都是用多个字节表示一个符号，但是GB类的汉字编码与后文的 Unicode 和 UTF-8 是毫无关系的。

三. Unicode

正如上一节所说，世界上存在着多种编码方式，同一个二进制数字可以被解释成不同的符号。因此，要想打开一个文本文件，就必须知道它的编码方式，否则用错误的编码方式解读，就会出现乱码。为什么电子邮件常常出现乱码？就是因为发信人和收信人使用的编码方式不一样。

可以想象，如果有一种编码，将世界上所有的符号都纳入其中。每一个符号都给予一个独一无二的编码，那么乱码问题就会消失。这就是 Unicode，就像它的名字都表示的，这是一种所有符号的编码。

Unicode 当然是一个很大的集合，现在的规模可以容纳100多万个符号。每个符号的编码都不一样，比如， U+0639 表示阿拉伯字母 Ain ， U+0041 表示英语的大写字母 A ， U+4E25 表示汉字 严 。具体的符号对应表，可以查询 unicode.org ，或者专门的汉字对应表。

四、Unicode 的问题

需要注意的是，Unicode 只是一个符号集，它只规定了符号的二进制代码，却没有规定这个二进制代码应该如何存储。

比如，汉字 严 的 Unicode 是十六进制数 4E25 ，转换成二进制数足足有15位（ 100111000100101 ），也就是说，这个符号的表示至少需要2个字节。表示其他更大的符号，可能需要3个字节或者4个字节，甚至更多。

这里就有两个严重的问题，第一个问题是，如何才能区别 Unicode 和 ASCII ？计算机怎么知道三个字节表示一个符号，而不是分别表示三个符号呢？第二个问题是，我们已经知道，英文字母只用一个字节表示就够了，如果 Unicode 统一规定，每个符号用三个或四个字节表示，那么每个英文字母前都必然有二到三个字节是 0 ，这对于存储来说是极大的浪费，文本文件的大小会因此大出二三倍，这是无法接受的。

它们造成的结果是：1）出现了 Unicode 的多种存储方式，也就是说有许多种不同的二进制格式，可以用来表示 Unicode。2）Unicode 在很长一段时间内无法推广，直到互联网的出现。

五、UTF-8

互联网的普及，强烈要求出现一种统一的编码方式。UTF-8 就是在互联网上使用最广的一种 Unicode 的实现方式。其他实现方式还包括 UTF-16（字符用两个字节或四个字节表示）和 UTF-32（字符用四个字节表示），不过在互联网上基本不用。 重复一遍，这里的关系是，UTF-8 是 Unicode 的实现方式之一。

UTF-8 最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。

UTF-8 的编码规则很简单，只有二条：

1）对于单字节的符号，字节的第一位设为 0 ，后面7位为这个符号的 Unicode 码。因此对于英语字母，UTF-8 编码和 ASCII 码是相同的。

2）对于 n 字节的符号（ n > 1 ），第一个字节的前 n 位都设为 1 ，第 n + 1 位设为 0 ，后面字节的前两位一律设为 10 。剩下的没有提及的二进制位，全部为这个符号的 Unicode 码。

下表总结了编码规则，字母 x 表示可用编码的位。

跟据上表，解读 UTF-8 编码非常简单。如果一个字节的第一位是0，则这个字节单独就是一个字符；如果第一位是1，则连续有多少个1，就表示当前字符占用多少个字节。

下面，还是以汉字严为例，演示如何实现 UTF-8 编码。

严的 Unicode 是4E25（100111000100101），根据上表，可以发现4E25处在第三行的范围内（0000 0800 - 0000 FFFF），因此严的 UTF-8 编码需要三个字节，即格式是1110xxxx 10xxxxxx 10xxxxxx。然后，从严的最后一个二进制位开始，依次从后向前填入格式中的x，多出的位补0。这样就得到了，严的 UTF-8 编码是11100100 10111000 10100101，转换成十六进制就是E4B8A5。

六、Unicode 与 UTF-8 之间的转换

通过上一节的例子，可以看到严的 Unicode码是4E25，UTF-8 编码是E4B8A5，两者是不一样的。它们之间的转换可以通过程序实现。

Windows平台，有一个最简单的转化方法，就是使用内置的记事本小程序notepad.exe。打开文件后，点击文件菜单中的另存为命令，会跳出一个对话框，在最底部有一个编码的下拉条。

里面有四个选项：ANSI，Unicode，Unicode big endian和UTF-8。

1）ANSI是默认的编码方式。对于英文文件是ASCII编码，对于简体中文文件是GB2312编码（只针对 Windows 简体中文版，如果是繁体中文版会采用 Big5 码）。

2）Unicode编码这里指的是notepad.exe使用的 UCS-2 编码方式，即直接用两个字节存入字符的 Unicode 码，这个选项用的 little endian 格式。

3）Unicode big endian编码与上一个选项相对应。我在下一节会解释 little endian 和 big endian 的涵义。

4）UTF-8编码，也就是上一节谈到的编码方法。

选择完"编码方式"后，点击"保存"按钮，文件的编码方式就立刻转换好了。

七、Little endian 和 Big endian

上一节已经提到，UCS-2 格式可以存储 Unicode 码（码点不超过0xFFFF）。以汉字严为例，Unicode 码是4E25，需要用两个字节存储，一个字节是4E，另一个字节是25。存储的时候，4E在前，25在后，这就是 Big endian 方式；25在前，4E在后，这是 Little endian 方式。

这两个古怪的名称来自英国作家斯威夫特的《格列佛游记》。在该书中，小人国里爆发了内战，战争起因是人们争论，吃鸡蛋时究竟是从大头(Big-endian)敲开还是从小头(Little-endian)敲开。为了这件事情，前后爆发了六次战争，一个皇帝送了命，另一个皇帝丢了王位。

第一个字节在前，就是"大头方式"（Big endian），第二个字节在前就是"小头方式"（Little endian）。

那么很自然的，就会出现一个问题：计算机怎么知道某一个文件到底采用哪一种方式编码？

Unicode 规范定义，每一个文件的最前面分别加入一个表示编码顺序的字符，这个字符的名字叫做"零宽度非换行空格"（zero width no-break space），用FEFF表示。这正好是两个字节，而且FF比FE大1。

如果一个文本文件的头两个字节是FE FF，就表示该文件采用大头方式；如果头两个字节是FF FE，就表示该文件采用小头方式。

下面，举一个实例。

打开"记事本"程序notepad.exe，新建一个文本文件，内容就是一个严字，依次采用ANSI，Unicode，Unicode big endian和UTF-8编码方式保存。

然后，用文本编辑软件UltraEdit 中的"十六进制功能"，观察该文件的内部编码方式。

1）ANSI：文件的编码就是两个字节D1 CF，这正是严的 GB2312 编码，这也暗示 GB2312 是采用大头方式存储的。

2）Unicode：编码是四个字节FF FE 25 4E，其中FF FE表明是小头方式存储，真正的编码是4E25。

3）Unicode big endian：编码是四个字节FE FF 4E 25，其中FE FF表明是大头方式存储。

4）UTF-8：编码是六个字节EF BB BF E4 B8 A5，前三个字节EF BB BF表示这是UTF-8编码，后三个E4B8A5就是严的具体编码，它的存储顺序与编码顺序是一致的。

九、延伸阅读

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets（关于字符集的最基本知识）

谈谈Unicode编码

RFC3629：UTF-8, a transformation format of ISO 10646（如果实现UTF-8的规定）

汉字编码中现在主要用到的有三类，包括GBK，GB2312和Big5。

1、GB2312又称国标码，由国家标准总局发布，1981年5月1日实施，通行于大陆。新加坡等地也使用此编码。它是一个简化字的编码规范，当然也包括其他的符号、字母、日文假名等，共7445个图形字符，其中汉字占6763个。我们平时说6768个汉字，实际上里边有5个编码为空白，所以总共有6763个汉字。

GB2312规定“对任意一个图形字符都采用两个字节表示，每个字节均采用七位编码表示”，习惯上称第一个字节为“高字节”，第二个字节为“低字节”。GB2312中汉字的编码范围为，第一字节0xB0-0xF7(对应十进制为176-247)，第二个字节0xA0-0xFE（对应十进制为160-254）。

GB2312将代码表分为94个区，对应第一字节（0xa1-0xfe）；每个区94个位（0xa1-0xfe），对应第二字节，两个字节的值分别为区号值和位号值加32（2OH），因此也称为区位码。01-09区为符号、数字区，16-87区为汉字区（0xb0-0xf7），10-15区、88-94区是有待进一步标准化的空白区。

2、Big5又称大五码，主要为香港与台湾使用，即是一个繁体字编码。每个汉字由两个字节构成，第一个字节的范围从0X81－0XFE（即129-255），共126种。第二个字节的范围不连续，分别为0X40－0X7E（即64-126），0XA1－0XFE（即161-254），共157种。

3、GBK是GB2312的扩展，是向上兼容的，因此GB2312中的汉字的编码与GBK中汉字的相同。另外，GBK中还包含繁体字的编码，它与Big5编码之间的关系我还没有弄明白，好像是不一致的。GBK中每个汉字仍然包含两个字节，第一个字节的范围是0x81-0xFE（即129-254），第二个字节的范围是0x40-0xFE（即64-254）。GBK中有码位23940个，包含汉字21003个。

Bill再推荐一个网站专门介绍汉字与汉字计算机化的汉典 http://www.zdic.net/
我怎么用 notepad 保存成 UTF-8 后用 UltraEdit 看还是 FF FE 25 4E啊？？？哦知道了。是UltraEdit 默认会以 UTF-16的方式打开UTF-8编码的文件，要设置或者用Hex Workshop打开就可以看到楼主所说的效果。

其实我认为，编码其实有2个意思。1.一个是把字符和数字对应起来（比如unicode和GBXXXX等）。2.还有就是相应在数字在计算机中的表示，也就是和字节序列对应起来（比如utf8，mbcs等）。
我有个问题，windows下的mbcs编码(2)用的编码(1)是不是GB系列的编码(1)，而unicode编码(2)用的是unicode编码(1)

你在文中提到：“UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度”。我在http://dev.csdn.net/develop/article/83/83012.shtm上看到：
以下是Unicode和UTF-8之间的转换关系表：

U-00000000 - U-0000007F: 0xxxxxxx

U-00000080 - U-000007FF: 110xxxxx 10xxxxxx

U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx

U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
该文中明显说到UTF-8不限于四个字节。
请问得到1-4个字节的结论是从哪里找到的？

>需要注意的是，Unicode只是一个符号集，它只规定了符号的二进制>代码，却没有规定这个二进制代码应该如何存储。
>比如，汉字“严”的unicode是十六进制数4E25，转换成二进制数足>足有15位（100111000100101），也就是说这个符号的表示至少需>要2个字节。表示其他更大的符号，可能需要3个字节或者4个字节，甚>至更多。

有一点疑问，unicode编码使用2个字节也就是16位2进制数字来表示字符，那么在存储的时候，为什么会超过2个字节以上呢？
unicode所能定义的符号总共有65536个，而且里面的每一个符号都是用2个字节表示的，包括ascii码也都是在高位补零的，麻烦楼主解释一下

非常同意ls的观点

字符编码是跨越电子通信和语言文字两大领域的庞大系统。其一是“编码”本身，伴随着电子和通信技术的发展一直在改进，同时也带来了许多legacy的产物；其二是“字符”，由于人类语言/书写系统的多样性和复杂性，将编码应用到语言文字上来又是一大难题，各种语言文字有各自的出发点和难点。因此，尝试解决这一混乱局面的UCS/Unicode实在是一项恢弘的工程。无怪乎lz在开头就说了，这个问题比他想象中复杂。

即使是现在最常见的7-bit ASCII，虽然看上去比较简单、且有些杂乱无章，实则每个字符的排布都经过了精心的设计，包括性能上的、工程上的、兼容性上的许多考虑因素。

另外，说起字符编码，就会有许多含糊不清、容易混淆的词汇，其中很多是基于历史原因，还有一些以讹传讹的和巧合的因素，这方面也是需要注意的。

对于大多数人来说，即使您已经系统地学习过数电/计算机课程，我仍然推荐阅读《编码的奥秘》。有较好的基础的人可以参考一下资料

http://scripts.sil.org/Home
http://www.unicode.org/standard/standard.html
http://msdn.microsoft.com/en-us/library/dd318661(v=VS.85).aspx

......
UTF-8文件的BOM是“EF BB BF”，但是UTF-8的字节顺序是不变的，因此这个文件头实际上不起作用。有一些编程语言是ISO-8859-1编码，所以如果用UTF-8针对这些语言编程序，就必须去掉BOM，即保存成“UTF-8—无BOM”的格式才可以，PHP语言就是这样。

UTF-8文件的BOM“EF BB BF”，它实际上就是FE FF用UTF-8编码而得到的

你好，目前被一个问题困扰。。。
是这样的，有一被压缩过的流没有解压而直接被转化成字符串了(当然是乱码了)，这是新浪的一个云应用FetchURL干的。。。我看了他们的源码，直接用apache提供的包中的EntityUitls中的toString方法转化成字符串了，所以我在发送请求的时候在加上请求头Accept-Encoding:gzip,他们没有解压就直接转化成字符串了。问题来了，我现在的作法是把这个字符串转化成字节，然后解压，具体的作法是：用String类中的getBytes(Charset),然后InputStream in1 = new GZIPInputStream(new ByteArrayInputStream(bytes1))，这里报错了，这个bytes1的字节已经不是1f 8b开头的，也就是说不是压缩过的模式了，求解。。。为什么。。难道EntityUitls，把压缩过的流转化为字符串的时候丢了字节码，还是什么情况(这里有个特例，就是ISO-8859-1可以还原，其余都不行)。。。

关于使用ISO-8859-1，我认为是因为：
“ISO-8859-1 字符集的编码范围是 0000-00FF，正好和一个字节的编码范围相对应。这种特性保证了使用 ISO-8859-1 进行编码和解码可以保持编码数值“不变”。虽然中文字符在经过网络传输时，被错误地“拆”成了两个欧洲字符，但由于输出时也是用 ISO-8859-1，结果被“拆”开的中文字的两半又被合并在一起，从而又刚好组成了一个正确的汉字。”

具体可以看搜到的这篇blog：
http://www.ibm.com/developerworks/cn/java/j-lo-chinesecoding/

"因此，第一个字节在前，就是”大头方式“（Big endian），第二个字节在前就是”小头方式“（Little endian）。
那么很自然的，就会出现一个问题：计算机怎么知道某一个文件到底采用哪一种方式编码？
Unicode规范中定义，每一个文件的最前面分别加入一个表示编码顺序的字符，这个字符的名字叫做”零宽度非换行空格“（ZERO WIDTH NO-BREAK SPACE），用FEFF表示。这正好是两个字节，而且FF比FE大1。
如果一个文本文件的头两个字节是FE FF，就表示该文件采用大头方式；如果头两个字节是FF FE，就表示该文件采用小头方式。"

文中的big endian 和 little endian，翻译成“大尾”和“小尾”是不是更恰当？理由如下：
FEFF： FF 比 FE大且FF在后面，显示就是“大尾”

另外你在延伸阅读中提到的文章也是翻译成“大尾”和“小尾” （谈谈Unicode编码）

感谢楼主！要是大学教材都用这种风格来编写，估计四年的计算机课程，真正在读书的1年就够了！！

utf-8的设计的确很巧妙：“2）对于n字节的符号（n>1），第一个字节的前n位都设为1【后面有几个字节兄弟们，就设计几个的显示位！计算机首先读到的，就是应该作为一组来解析的字节兄弟总数】，第n+1位设为0【表示显示位结束！】，后面字节的前两位一律设为10【表示这些字节都是被刚才那个leader领导的兄弟们】……”

另请教一下，对于在128—255的ASCII扩展字符，由于利用了最高位，应该就是与utf-8不一样了吧？

你好，我用uncode保存“严”，用hex查看是：e4 b8 a5 00 c4 00。而后三个字节，00 c4 00会因为的我保存一直在变化，有的时候会是 00 ee 3e，有的时候直接空了~

我用的win7

后来，经过尝试，又出现了BOM，显示为文中提到的ff fe 25 4e

这种情况最让人蛋疼了，搞不清是为什么~

Unicode的编码空间从U+0000到U+10FFFF，共有1,112,064个码位（code point）可用来映射字符. Unicode的编码空间可以划分为17个平面（plane），每个平面包含216（65,536）个码位。
17个平面的码位可表示为从U+xx0000到U+xxFFFF,其中xx表示十六进制值从0016到1016，共计17个平面。（Plane 0,1,2,....9,a,b,c,d,e,f,10）
第一个平面称为基本多语言平面（Basic Multilingual Plane, BMP），或称第零平面（Plane 0）。其他平面称为辅助平面（Supplementary Planes）。

基本多语言平面内，从U+D800到U+DFFF之间的码位区段是永久保留不映射到Unicode字符。UTF-16就利用保留下来的0xD800-0xDFFF区段的码位来对辅助平面的字符的码位进行编码。

最近在写编码方面的一个系列，搜到这里来了，感觉文中对Unicode及UTF-8这两个不同层面还是没说透，可参考我已经写好的一些http://my.oschina.net/goldenshaw/blog?catalog=536953，讲得比较详细。

另：文中说记事本用的所谓Unicode是UCS-2，其实早就应该是UTF-16了，至少我的系统里已经是UTF-16，而不是什么UCS-2，UCS-2只有两字节，根本无法保存U+FFFF以上码点的字符。

嗯，虽然有些名词概念讲的不是很清楚，但通俗易懂，还算不错。
其实博主着重过的语句主要是讲字符集和字符编码关系，例如：“UTF-8是Unicode的实现方式之一”这句话，Unicode就是字符集，它规定一个字符对应的编码，比如博主说的“严”对应的编码是4E25。而UTF-8是字符编码，它规定在内存中应该以怎样的方式来存储4E25，类似的对应Unicode字符集的字符编码还有UTF-16等。
最后补充下博主说的大端序（BE）和小端序（LE）：每个字节内的比特位不会受大端和小端的影响，例如20H，在大端和小端中的内存顺序都是00100000。

UTF-8的编码规则很简单，只有二条：
1）对于单字节的符号，字节的第一位设为0，后面7位为这个符号的unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的。
2）对于n字节的符号（n>1），第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的unicode码。

其中第2点，对于n字节的符号的理解是不是有偏差呢？
再看具体的编码：
Unicode符号范围 | UTF-8编码方式
(十六进制) | （二进制）
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
其中Unicode 0080~07FF段和 Unicode 0800~FFFF段都是两个字节，却不适用于第2)条规则的。

我也正在做一个编码的转换，请问如何将ansi编码转换成utf-8编码呢？
我曾经试着手动把unicode编码转换为Utf-8编码就是简单地遍历所有的字节数组，然后把0和1删除。不知道这样做对吗？
现在问题是怎么把ansi编码转成utf-8呢？
或者把ansi编码转成完全是字节数组的十六进制表示？

最后一行应该是 0001 0000-001F FFFF

unicode编码转utf8编码js实现，代码感觉写的不是很好，看到可以简化一下，
var unicodeToUTF8 = function(unicode) {
if(unicode >= 0x00000000 && unicode return unicode;
else if(unicode >= 0x00000080 && unicode var r1 = (((unicode & 0x7C0) >> 6)|0xC0) var r2 = (unicode & 0x03F)|0x80;
return r1 | r2;
else if(unicode >= 0x00000800 && unicode var r1 = (((unicode & 0xF000) >> 12)|0xE0) var r2 = (((unicode & 0x0FC0) >> 6)|0x80) var r3 = ((unicode & 0x003F)|0x80);
return r1 | r2 | r3;
else if(unicode >= 0x00010000 && unicode var r1 = (((unicode & 0x1C0000) >> 18)|0xE0) var r2 = (((unicode & 0x03F000) >> 12)|0x80) var r3 = (((unicode & 0x000FC0) >> 6)|0x80) var r4 = ((unicode & 0x00003F)|0x80);
return r1 | r2 | r3 | r4;
else {
return false;

统一码的编码方式与ISO 10646的通用字符集概念相对应。目前实际应用的统一码版本对应于UCS-2，使用16位的编码空间。也就是每个字符占用2个字节。这样理论上一共最多可以表示216（即65536）个字符。基本满足各种语言的使用。实际上当前版本的统一码并未完全使用这16位编码，而是保留了大量空间以作为特殊使用或将来扩展。

上述16位统一码字符构成基本多文种平面。最新（但未实际广泛使用）的统一码版本定义了16个辅助平面，两者合起来至少需要占据21位的编码空间，比3字节略少。但事实上辅助平面字符仍然占用4字节编码空间，与UCS-4保持一致。未来版本会扩充到ISO 10646-1实现级别3，即涵盖UCS-4的所有字符。UCS-4是一个更大的尚未填充完全的31位字符集，加上恒为0的首位，共需占据32位，即4字节。理论上最多能表示231个字符，完全可以涵盖一切语言所用的符号。

基本多文种平面的字符的编码为U+hhhh，其中每个h代表一个十六进制数字，与UCS-2编码完全相同。而其对应的4字节UCS-4编码后两个字节一致，前两个字节则所有位均为0。

关于统一码和ISO 10646及UCS的详细关系，见通用字符集。
维基百科上，有辅助平面字符

Unicode符号范围(十六进制) | UTF-8编码方式（二进制）
--------------------|---------------------------------------------
0000 0000 - 0000 007F | 0xxxxxxx
0000 0080 - 0000 07FF | 110xxxxx 10xxxxxx
0000 0800 - 0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000 - 0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

的最后一行应该为

老师好，下面这句话我应该怎么理解呢？
《这里就有两个严重的问题，第一个问题是，如何才能区别Unicode和ASCII？计算机怎么知道三个字节表示一个符号，而不是分别表示三个符号呢？》

既然不同的编码会用不同的编码解读，那么怎么会出现不能区分Unicode和ASCII的问题？我用ASCII解读不就可以了吗？

所以我太懂这个问题的怎么出现的？

既然不同的编码会用不同的编码解读，那么怎么会出现不能区分Unicode和ASCII的问题？我用ASCII解读不就可以了吗？

所以我太懂这个问题的怎么出现的？

用unicode编码的文件，所有的字符都用两个字节编码，ASCII也是,所以不会存在这个区分的问题

参考这个utf8编码对照表更清晰，来自https://en.wikipedia.org/wiki/UTF-8

Number Bit for first last
of bytes code points code points code points Byte 1 Byte 2 Byte 3 Byte 4
1 7 U+0000 U+007F 0xxxxxxx
2 11 U+0080 U+07FF 110xxxxx 10xxxxxx
3 16 U+0800 U+FFFF 1110xxxx 10xxxxxx 10xxxxxx
4 21 U+10000 U+10FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

读了你很多文章了，这篇也有收获。这个例子做了一个unicode到UTF-8字符集的掩码运算，mark到这里备忘。
汉字严的 unicode码点 4E25
0100 1110 0010 0101
1110 xxxx 10xx xxxx 10xx xxxx
1110 0100 1011 1000 1010 0101

为了兼容世界所有字符，重新编了一套Unicode，每个符号给予独一无二的编码，
现在可容纳100多万字符，这就意味着Unicode的编码变得特别多，也就不可能用1个
字节表示ASCII吗，因为解码的时候所有比特连在一起，会将你本来用来表示ascii码的
一个字节混淆（因为unicode编码太多，此ascii的编码可能与Unicode某个编码中的某
一段重复）;所以必须加长用来表示ascii的编码，以进行区别，但这就带来一个浪费内
存的问题。
所以出现了utf8,它用前N+1个比特表示它的长度N（除了单字节是用一个0比特表示,这时
的utf8编码与ascii编码一致，都是一个字节）,后面的编码直接从Unicode编码里面拿。所以它
不是全新的编码，是Unicode的一种实现方式，相比而言节省了内存（尤其是在以英文居多的时候）。

一个字节不是8位吗？那FF是一个字节啊，0001 0000-0010 FFFF这不是8个字节吗？什么情况……，我理解错了吗？
2001.3 发行版本3.1，收录字符 94,205；

大家都知道 2 字节可表示的字符数理论上是 2^16=65,536，对照Unicode发行版本，直到 3.1 发行以前，Unicode 字符码点与UTF-16编码都是相同的。

现在都 2021 年了，win10 系统上 notepad 已不再有 unicode 的编码选项，但我猜想之前版本的 Unicode 选项的出现可能是基于以上的历史原因。

这两天，深入了解了一些字符与编码，惊叹前辈们的智慧之后，又觉得太麻烦了，怎么这么麻烦!？累觉不爱

一个字节不是8位吗？那FF是一个字节啊，0001 0000-0010 FFFF这不是8个字节吗？什么情况……，我理解错了吗？

Win10里记事本可选编码已经没有Unicode了，改为UTF16-LE/BE、[BOM] UTF8、ANSI。

看了好多评论。我也新学习，可能细节是有错误，但几者的关系，来龙去脉感觉很流畅。