Unicode编码大揭秘

在UTF-8中，0-127号的字符用1个字节来表示，使用和US-ASCII相同的编码。这意味着1980年代写的文档用UTF-8打开一点问题都没有。只有128号及以上的字符才用2个，3个或者4个字节来表示。因此，UTF-8被称作可变长度编码。

回到文章开始的问题，来自你老朋友的附件的字节流如下：
复制代码 代码如下:
0100100001000101010011000100110001001111

这个字节流在ASCII和UTF-8中表示相同的字符：HELLO

UTF-16

另一个流行的可变长度编码方案是UTF-16，它使用2个或者4个字节来存储字符。然而，人们逐渐意识到UTF-16可能会浪费存储空间，但那是另一个话题了。

低字节序(Little Endian)和高字节序(Big Endian)

Endian读作End-ian或者Indian。这个术语的起源可以追溯到格列佛游记。（小说中，小人国为水煮蛋应该从大的一端（Big-End）剥开还是小的一端（Little-End）剥开而争论，争论的双方分别被称为“大端派”和“小端派”。）

低字节序和高字节序只是一个关于在内存中存储和读取一段字节（被称作words）的约定。这意味着当你让计算机用UTF-16把字母A（占两个字节）存在内存中时，使用哪种字节序方案决定了你把第一个字节放在第二个字节的前面还是后面。这么说有点不太容易懂，让我们来看一个例子：当你使用UTF-16存下来自你朋友的附件时，在不同的系统中它的后半部分可能是这样的：

00 68 00 65 00 6C 00 6C 00 6F（高字节序，高位字节被存在前面）

68 00 65 00 6C 00 6C 00 6F 00（低字节序，低位字节被存在前面）

字节序方案只是一个微处理器架构设计者的偏好问题，例如，Intel使用低字节序，Motorola使用高字节序。

字节顺序标记(BOM)

如果你经常要在高低字节序的系统间转换文档，并且希望区分字节序，还有一种奇怪的约定，被称作BOM。BOM是一个设计得很巧妙的字符，用来放在文档的开头告诉阅读器该文档的字节序。在UTF-16中，它是通过在第一个字节放置FE FF来实现的。在不同字节序的文档中，它会被显示成FF FE或者FE FF，清楚的把这篇文档的字节序告诉了解释器。

BOM尽管很有用，但并不是很简洁，因为还有一个类似的概念，称作「魔术字」(Magic Byte)，很多年来一直被用来表明文件的格式。BOM和魔术字间的关系一直没有被清楚的定义过，因此有的解释器会搞混它们。

恭喜你读到这里，你一定是一个很有耐心的读者。

还记得文章开头的问题吗，既然没有「纯文本」文件这回事，那你的文本编辑器和浏览器为什么每次都能正确的显示内容呢？答案是，那些软件欺骗了你，这也是为什么那么多人对编码一无所知。当软件不能确定编码的时候，它会猜测。大部分时候，它会猜测是否是涵盖了ASCII码的UTF-8，还是ISO-8859-1，也有可能猜其他能想到的任意字符集。因为英文中使用的拉丁字母表在几乎所有的字符集中都能显示，包括UTF-8，所以即使编码猜错了，英文字母看起来也是正确的。

但是，如果你在浏览网页时看到#65533;符号，这意味着这个网页的编码不是你的浏览器猜测的那个。这时你可以点开浏览器的查看——gt;字符编码菜单来尝试不同的编码。

总结

如果你没时间读整篇文章或者你仅仅是略读了一下前面的内容。那请你确保你能理解下面的几条：

这个世界上从来没有纯文本这回事，如果你想读出一个字符串，你必须知道它的编码。

Unicode是一个简单的标准，用来把字符映射到数字上。Unicode协会的人会帮你处理所有幕后的问题，包括为新字符指定编码。

Unicode并不告诉你字符是怎么编码成字节的。这是被编码方案决定的，通过UTF来指定。

还有最重要的：

永远记得通过Content-Type或者meta charset标签来显式指定你的文档的编码。这样浏览器就不需要猜测你使用的编码了，他们会准确的使用你指定的编码来渲染文档。

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!