1、 前言

作为一名 C/C++ 程序员，字节是我们天天都要与之打交道的一个东西。我们和它熟稔到几乎已经忘记了它的存在。可是，它自己是不甘寂寞的，或迟或早地，总会在某些时候探出头来张望，然后给你一个腿儿绊。其实，只要你真正了解了它的底细，你就会畅行无阻。在本文中，我们将首先简要了解一下字节的概念，然后着重了解一下字节序问题和字节对齐问题。

注：笔者已经尽最大努力保证本文信息的正确性，但确实无法提供百分之百的担保。

2、 什么是字节

我们知道，二进制计算机(也就是我们目前接触到的几乎所有的计算机)的最小数据单位是位( bit )。一位数据只能够表示两种含义(需要说明，尽管我们通常把单个位表示的两种含义选择为相互对立的含义，但这并不是必然的，例如你可以认为 1 代表 5 个人， 0 代表 8 个人)，对于绝大多数的计算要求，单个位显然不能满足。因此，我们通常都会使用一连串的位，我们可以称之为位串( bit string ，请爱好质疑的的朋友注意，此术语非我杜撰)。由于种种原因，计算机系统都不会让你使用任意长度的位串，而是使用某个特定长度的位串。一些常见的位串长度形式具有约定好的名称，如，半字节( nibble ，貌似用的不多)代表四个位的组合，字节( byte ，主角出场!)代表 8 个位的组合。再多的还有，字( word )、双字( Double word ，通常简写为 Dword )、四字(Quad word ，经常简写为 Qword )、十字节( Ten byte ，也简写为 Tbyte )。

在这些里面，字( word )有时表示不同的含义。在 Intel 体系里， word 表示一个 16 位的数值，它是固定大小的。而在另外一些场合， word 表示了 CPU 一次可处理的数据的位数，表示一个符合 CPU 字长( word-length )的数目的位串。事实上我们接触较多的 ARM 体系中， word 就有不同的含义，它表示一个 32 位的数据(与机器字长相同)，对于 16 位大小的数据， ARM 使用了另外的一个术语，叫作半字( half-word )，请大家在文档阅读时加以注意。另外， Qword 也是 Intel 体系中的术语，其他的体系中可能并不使用。在本文中，我们按照 Intel 的惯例来使用字或者 word 这一术语。

一个字节中共有 8 个数据位，有时需要用图表逐位表述各个位。习惯上，我们按照下面的图来排列各个位的顺序，即，按照从右到左的顺序，依次为最低位(从第 0 位开始)到最高位(对于字节，则是第 7 位)：

字节是大多数现代计算机的最小存储单元，但这并不代表它是计算机可以最高效地处理的数据单位。一般的来说，计算机可以最高效地处理的数据大小，应该与其字长相同。在目前来讲，桌面平台的处理器字长正处于从 32位向 64 位过渡的时期，嵌入式设备的基本稳定在 32 位，而在某些专业领域(如高端显卡)，处理器字长早已经达到了 64 位乃至更多的 128 位。

3、 字节序问题的由来

对于字、双字这些多于一个字节的数据，如果把它们放置到内存中的某个位置上，可以看出，我们还可以将之看作是字节的序列。一个字是两个字节，双字则是四个字节。假设有以下数据： 0x12345678 、 0x9abcdef0 。在此处，我使用了我们最习惯的十六进制表示法，并给出了两个双字的值。按照惯例，我把双字的左侧视为高端，而把右侧视为低端。把它们顺序放置在起始地址为 0 的内存中，如下图所示：

由图示可知， 0x9abcdef 的相应地址为 0x04 。现在，问题来了，如果有一个内存操作，要从地址 0x06 处读取一个字，得到的结果是多少呢?答案是：不一定。

这里的本质问题在于，如何把多字节的对象存储到内存中去呢?即使使用最正常的思维去考虑这个问题，你也会发现有两种方法。第一种方法是，把最低端的字节放到指定的起始位置(即基地址处)，然后按照从低到高的字节顺序把其余字节依次放入，如下图 a ;另一种方法非常类似，但是对高端字节和低端字节的处理顺序正好相反，如下图 b (我确信你还可以想出其他的方法，但是除二字节的情况外，必然会打破字节排列顺序的一致性，我视之为反常规思维的产物，此处暂不考虑)。

图 a

图 b

在很久之前，哪一种存储方式更为合理曾经有过争论。到今天，争论的结果已经无关紧要了，紧要的是以下事实：这两种存储方式都被应用到了现实的计算机系统中。上图 a 中的排列方式为 Intel 所采用并大行其道，而图 b的排列方式则被大多数的其他平台采用(如最近被苹果公司彻底抛弃的 PowerPC )，因此上，我们不能称之为罕见的用法。之所以造成事实上的不经常见到，其原因正如我今天中午所得到的消息： Intel 的 CPU 占整个市场份额的 80% 以上。

这两种排列方式通常用小端( little endian )和大端( big endian )来称谓。这两个奇怪的名字据说来源于童话《格列佛游记》，其中小人国里的公民为了鸡蛋到底是应该从小的一头打开还是大的一头打开而大起争执。 Intel的方式对应于“小端”，顺便说一句，大端的方式也有一个大公司的名字作为其代表，即最近开始没落的 Motorola。如果有谁了解过 TIFF 图像文件格式，就会发现其文件头中用以标识文件数据字节序的标志就是“ II ”和“ MM”，分别对应于 Intel 和 Motorola 的首字母。值得提醒一下，小端方式的排列与位的排列顺序相一致，看上去似乎更协调一些。

现在我们可以回答上面的问题了。对于小端字节序，我们取到的字，其值为 0x9abc ，而如果是大端字节序的话，就会取到 0xdef0 。

4、 何时会出现字节序问题

字节序问题主要出现在数据在不同平台之间进行交换时，交换的途径可能是网络传输，也可能是文件复制。例如，如果你设计了一种可能会应用于不同平台的文件格式，其中存储了某些数据结构，则对于大小大于一个字节的数据就要明确地规定其遵循的字节序，以便各平台上的处理程序可以在使用数据时实现做必要的转换。

举一个实际的例子。 Java 是一个跨平台的编程语言，其可执行文件(扩展名为 .class ，使用的是一种机器无关的字节码指令集)在理论上可以运行于所有的实现了 Java 运行时的平台(包含有与特定平台相关特性的除外)。编译后的 .class 中一定保存有诸如 Integer 这样类型的数据，这就涉及到了字节序的确定，否则 .class 必然不能被采用了不同字节序的平台同时正确加载并运行。事实上， Java 语言采用的为大端字节序，这个一点都不奇怪，因为当初 SUN 公司自己的 SPARC 架构就是采用的大端字节序。同样的问题和解决问题的方式，也存在于操作系统新贵 android 系统上。

网络传输则是另一个典型场景。 TCP/IP 所采用的网络传输字节序标准也是大端字节序，这个也不必奇怪，因为 TCP/IP 是从 UNIX 系统发展起来的，而绝大部分的 UNIX 系统在很长的一段时间内都没有运行于 Intel 体系架构上的版本。

处理字节序问题的手段非常简单，也就是对数据进行必要的转换：将十六进制的数字从两端开始交换，直至移动到数据的中心，交换完成为止。交换的结果就好像物体与镜面之内的成像互换了位置，因此也被称为镜像交换(mirror-image swap )。请参看下图：

5、 如何在程序中判断字节序

在实际的工作中，有时需要对字节序进行判断，然后予以不同的处理。一般的来说，编译后的程序通常只能运行在特定的平台之上，其所采用的字节序方式在编译时即可确定，在这种情况下，程序源代码中通常是把字节序的判别作为条件编译的判断语句，而不会判断代码放在真正的可执行代码中。

在这里，需要使用我们的老朋友 —— 宏。以下是一个真实的跨平台工程中代码，清晰起见，我稍做了修改：

#define SGE_LITTLE_ENDIAN 1234

#define SGE_BIG_ENDIAN 4321

#ifndef SGE_BYTEORDER

#if defined(__hppa__) || /

defined(__m68k__) || defined(mc68000) || defined(_M_M68K) || /

(defined(__MIPS__) && defined(__MISPEB__)) || /

defined(__ppc__) || defined(__POWERPC__) || defined(_M_PPC) || /

defined(__sparc__)

#define SGE_BYTEORDER SGE_BIG_ENDIAN

#else

#define SGE_BYTEORDER SGE_LITTLE_ENDIAN

#endif

#endif

以上为根据平台的预定义宏所作的前期工作，将之存入一个头文件中，然后包含到源代码文件中使用。

在需要进行判断的时候，则像以下代码这样使用：

#if SGE_BYTEORDER == SGE_BIG_ENDIAN

#define SwapWordLe(w) SwapWord(w)

#else

#define SwapWordLe(w) (w)

#endif

由于这两个宏实际上被定义成了常量数值，因此也可以被用到可执行代码中，进行执行期的动态判断：

if(SGE_BYTEORDER == SGE_BIG_ENDIAN)

return r << 16 | g << 8 | b;

else

return r | g << 8 | b << 16;

追根寻源，上面的这种判断需要依赖编译器及其所在平台的预定义宏。下面介绍一种执行期动态判断的方法，则不需要有宏的参与，而是巧妙地利用了字节序的本质。代码如下：

int IsLittleEndian()

{

const static union

{

unsigned int i;

unsigned char c[4];

} u = { 0x00000001 };

return u.c[0];

}

动手画一下内存布局即可了解其原理。还有更简练的写法，作为练习，请大家自行去寻找。

在结束对字节序的讨论之前，特别提醒一下， ARM 体系的 CPU 在字节序上与 Intel 的体系结构是一致的。

6、 字节对齐问题的产生

冯诺依曼体系的计算机，通过地址总线来寻址内存(假设 n 为地址总线的位数，则最多可以寻址 2n 个内存位置)。根据地址总线的位数，我们可以知道 CPU 与内存的一次交互(也即一次内存访问)能够读写的数据的大小。显然地，对于 8 位的 CPU ，是一个字节，对于 16 位 CPU 则是一个字， 32 位 CPU 则是一个双字，依此类推。这是 CPU 与生俱来的最本质、最快捷的访问方式。在实际的计算需求中，如果访问的数据量超过了一次访问的限度，则很显然需要进行多次访问，如果是少于的话，则需要对从内存中取回的数据进行适当的裁剪。裁剪操作有可能是CPU 自身支持的，也有可能是需要用软件来实现的。

有的系统是支持寻址到单个字节所在的位置的(称为可字节寻址)，而有的则不可以，只能寻址到符合某些条件的地址上。对于 Intel/ARM 体系结构的 CPU ，我们在宏观上可以认为它们都支持字节寻址(但是 ARM 家族的CPU 在内存访问时有其他约束，下文有详细叙述)。

出现这样的限制是有原因的，终极因素就在于内存访问的粒度与字长的关联上。用 32 位 CPU 来说，它对于地址为 4 的倍数处的内存访问是最自然的，其余的地址就要做一些额外的工作。例如，我们要访问地址为 0x03 处的一个双字，对于 80x86 体系，事实上将会导致 CPU 的两次内存访问，取回 0x00 以及 0x04 处的两个双字，分别进行适当的截取之后再拼装为一个双字返回。对于其他的体系，设计者可能认为 CPU 不应该承担数据拼装的工作，因而就选择产生一个硬件异常。

在硬件和 / 或操作系统的约束下，进行数据访问时对数据所在的起始位置以及数据的大小都需要遵循一定的规则 ，与这些规则相关的问题，都可以称之为字节对齐问题。

举例来说。在 HP-UX (惠普公司的一个服务器产品平台， UNIX 的一种)平台中，系统严禁对奇地址直接进行访问，假设你视这一原则于不顾：

int i = 0; // 编译器保证 i 的起始地址不是奇地址

char c = *((char*)&i + 1); // 强制在奇地址处访问

其执行结果就是内核转储( core dump )，为应用程序最严重的错误。(特别注明：此处代码为记忆中的情形，目前笔者已经没有验证环境了)

在不同的硬件体系架构下，字节对齐关系到三方面的问题，一是数据访问的可行性问题，二是数据访问的效率问题，三是数据访问的正确性问题。

字节对齐问题给程序员在编码时带来了额外的注意点，并且对最终程序执行的正确性也带来了一定的不确定因素。相同的代码在不同的平台上，甚至在相同的平台上采用不同的编译选项，都可能有不同的执行结果。

如果所有的系统都和 HP-UX 的表现一样的话，事情要简单一些，问题通常会在比较早的时间内就可以暴露出来。遗憾的是，我们目前所面对的平台不是这样，这些平台的设计者为最大程度地减少对开发人员的干扰而作了辛苦的努力，使得我们在很多时候都感觉不到字节对齐问题的存在。但另一方面，也制造出了把问题隐藏得更深的机会。

效果最好的努力是 Intel 的体系架构。 80x86 允许你对整个内存进行字节寻址，在不超过机器字长的情况下可以访问任意数目的字节(很显然，大多数情况下就是 1 字节、 2 字节、 3 字节、 4 字节这四种情况)。

ARM 体系的 CPU 似乎做了一定的努力，但是其结果和其他体系相比呈现一种很奇怪的状态。由于笔者没有对ARM 整个系列的 CPU 进行过完整的了解，因此此处的论述可能并不完整。 ARM CPU 允许对内存进行字节寻址，但在访问时有额外的要求。即：如果你要访问一个字(注意本文惯例，此处的字是两字节大小，与 ARM 平台的标准术语不同)，那么起始地址必须在一个字的边界上，如果访问一个双字，则起始地址必须位于一个双字的边界上(其余数据类型请参考 ARM 的知识库文档)。这意味着，你不能在 0x03 这样的地址处访问一个字或者一个双字。但是，令人痛苦的事情到来了，如果你非要这么访问，大多数的 CPU 不会有显式的异常，而是返回错误的数据，其余的一些 CPU 则会造成程序崩溃。

关键词： 字节 ARM