ANSI编码和Unicode编码的不同

最新推荐文章于 2024-09-27 17:06:11 发布

Jack_Chai

最新推荐文章于 2024-09-27 17:06:11 发布

阅读量1.6w

点赞数 8

分类专栏：研究成果文章标签：存储文档 windows 语言 internet

本文链接：https://blog.csdn.net/chaijunkun/article/details/4654397

版权

研究成果专栏收录该内容

57 篇文章 2 订阅

订阅专栏

本文出处：http://blog.csdn.net/chaijunkun/article/details/4654397，转载请注明。由于本人不定期会整理相关博文，会对相应内容作出完善。因此强烈建议在原始出处查看此文。

利用今天一天的时间，研究了一下ANSI编码和Unicode编码的不同，下面把我的研究成果写下来，以备

日后参考。

ANSI编码最常见的应用就是在Windows当中的记事本程序中，当新建一个记事本，默认的保存编码格式

就是ANSI，ANSI应该算是一种压缩编码了，当遇到标准的ASCII字符时，采用单字节表示，当遇到非标

准的ASCII字符(如中文)时，采用双字节表示。

Unicode编码标准已在近年来的多种新科技当中被加以采用，包含了可扩展置标语言（XML）、Java程

序语言、以及最新的操作系统中。

下面用实验的方法来进行研究这两者之间的差别:
首先要准备的软件有UltraEdit，用于对文本进行比较；其次用于分析网络字节序的辅助网站

http://bm.kdd.cc/

步入正题，在一个空白的文件夹下创建一个记事本文档“新建文本文档.txt”，在里面输入“宋体

ABC(回车)”(不包含引号，最后要在ABC后输入一个回车)，保存并关闭该文档，将此文件选中之后直

接复制、粘贴，在相同的文件夹下就产生了“复件新建文本文档.txt”，再次打开“新建文本文档

.txt”，选择菜单中的“文件”->“另存为”，在另存为对话框中，最下面有“编码”，选择Unicode

。保存，选择替换。

然后打开UltraEdit，在菜单中选择“文件”->“比较文件”(或直接按快捷键Alt+F11)，选择第一个要比较的文件为“新建文本文档.txt”，选择第二个要比较的文件为“复件新建文本文档.txt”，“比较模式”选择文件，“二方比较”，“要比较的第一个文件”为“二进制”，“编辑器平铺”选择“垂直平铺”，点击“比较”，程序自动对这两个文本文件进行比较，并以16进制的形式显示，如下图所示

根据分析，其代表的意义如下图所示

Unicode字符解释

采用Unicode编码存储的文本文档

ANSI字符解释

采用ANSI编码存储的文本文档

Windows系统中用记事本以Unicode编码保存时，头两个字节一定是FF FE，这样用来标识此文档以Unicode编码，并且提示了字节序是“小端对齐”，而这两个字节的学名叫做BOM（Byte Order Mark，字节顺序标记）。

2020年2月25日补充：额外提一句，由于BOM这两个字节数据为“不可见字符”，很多时候程序中读出来直接与后面的内容当做字符串处理会产生各种莫名其妙的问题。如果你用Java语言，推荐使用BOMInputStream（commons-io包里的一个流实现），默认情况下能自动判断字节顺序，并在读取时自动忽略，得到的内容就可以安心操作了。

下面来关注一下内容的编码部分

中文，作为一种非ASCII字符，不可能只用一个字节来表示一个汉字，至少需要用两个字节来表示，所以，中文是一种双字节字符，下图所示的是在http://bm.kdd.cc/上查询到的“宋体”两个汉字，分别用Unicode编码和ANSI编码的十六进制内容:

用Unicode编码的“宋体”

用ANSI编码的“宋体”

在Unicode编码中，“宋”这个汉字的编码为5B 8B，按照二进制的说法，5B是高八位，8B是低八位，然而，对照着前面所标注的结果，用Unicode编码的文本文件中，先存储的是8B这个低八位，然后再存储的5B这个高八位，这就是Windows内部在处理Unicode字符的时候与其他系统(如Mac OS)的不同，Windows先处理Unicode字符的低八位，然后再处理高八位；而有的系统是先处理高八位，再处理低八位，这就是为什么在Internet上要规定“网络字节序”。(2011.3.29 更正：本地字节序处理顺序只与CPU架构有关，与操作系统无关，之前误以为Mac OS与Windows不同是因为Mac机之前使用的是PPC处理器，该处理器采用大端对齐方式，而从Mac OS 10.4开始出现了支持Intel x86 CPU的系统，这时基于Intel x86架构处理器的Mac机字节序变为小端对齐。另外，本文中所述Unicode编码也不严谨，应为UTF16编码。特此更正)

在ANSI编码中，完全不存在这个问题，“宋”的ANSI编码为CB CE，在存储这些字符的时候也是按照先高八位，后低八位的方式存储的。

以上讨论了中文在Unicode和ANSI编码中的特点，下面看一下ASCII字符在这两种编码中的特点：

在Unicode中，所有字符都是以两个字节来存储的(2011.6.22更正：在UTF-16编码格式中，并非所有字符都是以两个字节来存储的。试想一下，如果仅仅用两个字节来存储一个字符，编码空间为65536个，这个数量连中文都包含不全。之前的理解有偏差，UTF-16编码是以两个字节为基本编码单位来存储的。如果一个字符超出了这两个字节所能表示的空间，则会再次申请两个字节来编码。特此更正)，而ASCII字符仅用一个字节就可以表示，那么另外一个字节的内容就会被置为00。采用Unicode会产生的缺点就是：如果一篇文章里全是英文，那么，采用Unicode方式编码存储，所占用的存储空间会大约增加一倍(因为头部还要多两个字节的FF FE标识)，但是采用Unicode编码的好处就是适合同一文档中采用不同语言的文字，因此Unicode编码广泛应用于xml语言和编写多语言程序。

在本文的第二组图中，可以看到，采用Unicode编码的大写英文字母A，其编码为00 41(之前曾经解释了Windows在处理Unicode字符的时候先处理低八位，后处理高八位)，因为Unicode存储的任何字符都占用2个字节的空间，所以在解码的时候就两个字节两个字节地取。如果发现高八位不是00，则认为这两个字节表示一个非ASCII字符，反之如果发现高八位为00，则可知，该字符为ASCII字符，于是取出低八位，再根据ASCII码表查到对应字符，因为取出的低八位认为表示的是一个ASCII字符，所以字符空间为2的8次方，也就是256个，因此采用Unicode编码表式的ASCII字符属于扩展的ASCII字符集。

在第二组图的ANSI编码解释中可以看到，存储一个大写英文字母A仅用了一个字节，内容为41。十六进制的41转换为八位的二进制后应该是 01000001，可以看到，此二进制数的最高位为0，ANSI编码在存储ASCII字符时采用的是传统的ASCII字符集，其字符数量为128，正好2的7次方就是128，因此最高位一定是0。汉字“宋”的ANSI编码为CB CE，将这两个字节的十六进制数转换为二进制，结果为[11001011][11001110] ，每个字节的最高位都是1，由此可以推断在解码的时候，一次读取一个字节的内容，看一下该字节的最高位是否为1，如果为1，暂存该字节，并读取下一个字节，新读取的这个字节的最高位应该也为1，这样将两个字节合并然后去查询对应的字符；如果第一次读到的一个字节最高位为0，那么就按此字节的内容直接查询传统的ASCII码表，找到对应的字符。

最后再分析Windows中的回车换行特点。在开始的时候为了准备这个实验用的文本文档，在输入完ABC后又输入了一个回车。但是通过分析得知，在文本存储的时候并不是仅存了一个“回车”，还存了一个“换行”，而且是先存储的“回车”后存储的“换行”(见ASCII码表：0D->回车；0A->换行)，这与Linux/Unix中的换行方式不同，在Linux/Unix中仅用一个0D(回车)就可以令文本换行。如果将一个在Linux/Unix中编写的文本文档直接拷贝到Windows中打开(最简单的可以在Windows下查看百度首页的源代码)，就会看到这些文字几乎都是连着的，没有换行，那是因为在该文档中并没有显式地存储0A(换行符)，虽然这篇文章在Linux/Unix中看起来很正常。