C++ 字符编码知识转载

基本常识

1.位和字节

说起编码，我们必须从最基础的说起，位和字节(别觉得这个过于简单不值一说，我还真见过很多个不能区分这两者的程序员)。位（bit）是指计算机里存放的二进制值(0/1)，而8个位组合成的“位串”称为一个字节，容易算出，8个位的组合有256（ 2⁸ ）个组合方式，其取值范围是“00000000-11111111”，常用十六进制来表示。比如“01000001”就是一个字节，其对应的十六进制值为“0x41”。

而我们通常所讲的字符编码，就是指定义一套规则，将真实世界里的字母/字符与计算机的二进制序列进行相互转化。如我们可以针对上面的字节定义如下的转换规则：

 01000001（0x41）<-> 65 <-> 'A'

即用字位序“01000001”来表示字母’A’。

2.拉丁字符

拉丁字符是当今世界使用最广泛的符号了。通常我们说的拉丁字母，指的的是基础拉丁字母,即指常见的”ABCD“等26个英文字母，这些字母与英语中一些常见的符号（如数字，标点符号）称为基础拉丁字符，这些基础拉丁字符在使用英语的国家广为流行，当然在中国，也被用来当作汉语拼音使用。在欧洲其它一些非英语国家，为满足其语言需要，在基础拉丁字符的基础上，加上一些连字符，变音字符(如’Á’)，形成了派生拉丁字母，其表示的字符范围在各种语言有所不同，而完整意义上的拉丁字符是指这些变体字符与基础拉丁字符的全集。是比基础拉丁字符集大很多的一个集合。

3.字符和字符长

字符(Character)是指人类语言最小的表义符号。在ASCII中一个字符的长度是1个字节，在Unicode中一个字符的长度是2个字节，在UTF-8中字符长度不定

编码标准

前文提到，字符编码是一套规则。既然是规则，就必须有标准。下面我就仔细说说常见的字符编码标准。

1.拉丁编码

ASCII的全称是American Standard Code for Information Interchange（美国信息交换标准代码）。顾名思义，这是现代计算机的发明国美国人设计的标准，而美国是一个英语国家，他们设定的ASCII编码也只支持基础拉丁字符。ASCII的设计也很简单，用一个字节（8个位）来表示一个字符，并保证最高位的取值永远为’0’。即表示字符含义的位数为7位，不难算出其可表达字符数为2⁷ =128个。这128个字符包括95个可打印的字符（涵盖了26个英文字母的大小写以及英文标点符号能）与33个控制字符（不可打印字符）。例如下表，就是几个简单的规则对应：

字符类型	字符	二进制	16进制	10进制
可打印字符	A	01000001	0x41	65
可打印字符	a	01100001	0x61	97
控制字符	\r	00001101	0x0D	13
控制字符	\n	00001010	0xA	10

前面说到了，ASCII是美国人设计的，只能支持基础拉丁字符，而当计算机发展到欧洲，欧洲其它不只是用的基础拉丁字符的国家（即用更大的派生拉丁字符集）该怎么办呢？

当然，最简单的办法就是将美国人没有用到的第8位也用上就好了，这样能表达的字符个数就达到了2⁸ =256个，相比较原来，增长了一倍， 这个编码规则也常被称为EASCII。EASCII基本解决了整个西欧的字符编码问题。但是对于欧洲其它地方如北欧，东欧地区，256个字符还是不够用，如是出现了ISO 8859,为解决256个字符不够用的问题，ISO 8859采取的不再是单个独立的编码规则，而是由一系列的字符集（共15个）所组成，分别称为ISO 8859-n(n=1,2,3…11,13…16,没有12)。其每个字符集对应不同的语言,如ISO 8859-1对应西欧语言，ISO 8859-2对应中欧语言等。其中大家所熟悉的Latin-1就是ISO 8859-1的别名,它表示整个西欧的字符集范围。 需要注意的一点的是，ISO 8859-n与ASCII是兼容的，即其0000000(0x00)-01111111(0x7f)范围段与ASCII保持一致，而10000000（0x80）-11111111(0xFF)范围段被扩展用到不同的字符集。

2.中文编码

以上我们接触到的拉丁编码，都是单字节编码，即用一个字节来对应一个字符。但这一规则对于其它字符集更大的语言来说，并不适应，比如中文，而是出现了用多个字节表示一个字符的编码规则。常见的中文GB2312（国家简体中文字符集）就是用两个字节来表示一个汉字（注意是表示一个汉字，对于拉丁字母，GB2312还是是用一个字节来表示以兼容ASCII）。我们用下表来说明各中文编码之间的规则和兼容性。

对于中文编码，其规则实现上是很简单的，一般都是简单的字符查表即可，重要的是要注意其相互之间的兼容性问题。如如果选择BIG5字符集编码，就不能很好的兼容GB2312，当做繁转简时有可能导致个别字的冲突与不一致，但是GBK与GB2312之间就不存在这样的问题。

此处注意字符集和编码方案的区别

• 字符集 = 规定当前集合所存在的所有字符；

• 编码方案 = 字符集合中的字符以何种方式保存、传输

    比 如 ASCII 这部标准本身就直接规定了字符和字符编码的方式，所以既是字符集又是编码方案；而 GB2312 只是一个区位码形式的字符集标准，不过实际上基本都用 EUC-CN 来编码，所以提及「GB 2312」时也说的是一个字符集和编码连锁的方案；GBK 和 GB18030 等向后兼容于 GB2312 的方案也类似。于是，很多人受这些遗留方案的影响而无法理解字符集和编码的关系。对于 Unicode，字符集和编码是明确区分的。Unicode/UCS 标准首先是个统一的字符集标准。而 Unicode/UCS 标准同时也定义了几种可选的编码方案，在标准文档中称作「encoding form」，主要包括 UTF-8、UTF-16 和 UTF-32。所以，对 Unicode 方案来说，同样的基于 Unicode 字符集的文本可以用多种编码来存储、传输。所以，用「Unicode」来称呼一个编码方案不合适，并且误导。

3.Unicode

以上可以看到，针对不同的语言采用不同的编码，有可能导致冲突与不兼容性，如果我们打开一份字节序文件，如果不知道其编码规则，就无法正确解析其语义，这也是产生乱码的根本原因。有没有一种规则是全世界字符统一的呢？当然有，Unicode字符集就是一种。为了能独立表示世界上所有的字符，Unicode采用4个字节表示一个字符（此处勘误：unicode可以是两个字节或是4个字节。目前的用于实用的Unicode版本对应于UCS-2，使用16位的编码空间。也就是每个字符占用2个字节。unicode使用4字节的，叫ucs-4。）,这样理论上Unicode能表示的字符数就达到了2³¹ = 2147483648 = 21 亿左右个字符，完全可以涵盖世界上一切语言所用的符号。我们以汉字”微信“两字举例说明：

微 <->  \u5fae   <->  00000000 00000000 01011111 10101110信 <->  \u4fe1   <->  00000000 00000000 01001111 11100001

容易从上面的例子里看出，Unicode对所有的字符编码均需要四个字节，而这对于拉丁字母或汉字来说是浪费的，其前面三个或两个字节均是0,这对信息存储来说是极大的浪费。另外一个问题就是，如何区分Unicode与其它编码这也是一个问题，比如计算机怎么知道四个字节表示一个Unicode中的字符，还是分别表示四个ASCII的字符呢？

以上两个问题，困扰着Unicode，让Unicode的推广上一直面临着困难。直至UTF-8作为Unicode的一种实现后，部分问题得到解决，才得以完成推广使用。说到此，我们可以回答文章一开始提出的问题了，UTF-8是Unicode的一种编码方式，而Unicode是一个字符集，Unicode的编码方式除了UTF-8还有其它的，比如UTF-16等。

话说当初大牛Ben Thomson吃饭时，在一张餐巾纸上，设计出了UTF-8，然后回到房间，实现了第一版的UTF-8。关于UTF-8的基本规则，其实简单来说就两条（来自阮一峰老师的总结）：

规则1：对于单字节字符，字节的第一位为0，后7位为这个符号的Unicode码，所以对于拉丁字母，UTF-8与ASCII码是一致的。规则2：对于n字节(n>1)的字符，第一个字节前n位都设为1，第n+1位为0，后面字节的前两位一律设为10，剩下没有提及的位，全部为这个符号的Unicode编码。

通过，根据以上规则，可以建立一个Unicode取值范围与UTF-8字节序表示的对应关系，如下表，

 如果unicode是ucs-2，则utf-8的长度为1-3个字节；如果unicode是ucs-4,则utf-8的长度是1-6个字节，第一个字节的高位1的数目指明了这个utf-8的字符使用的byte数目。

1.每个英文字母、数字所占的空间为1 Byte；

2.泛欧语系、斯拉夫语字母占2 Bytes；

3.汉字占3 Bytes。

举例来说，’微’的Unicode是’\u5fae’，二进制表示是”00000000 00000000 01011111 10101110“，其取值就位于’0000 0800-0000 FFFF’之间，所以其UTF-8编码为’11100101 10111110 10101110’ （加粗部分为固定编码内容）。

通过以上简单规则，UTF-8采取变字节的方式，解决了我们前文提到的关于Unicode的两大问题。同时，作为中文使用者需要注意的一点是Unicode(UTF-8)与GBK，GB2312这些汉字编码规则是完全不兼容的，也就是说这两者之间不能通过任何算法来进行转换,如需转换，一般通过GBK查表的方式来进行。

常见问题及解答

1.windows Notepad中的编码ANSI保存选项，代表什么含义？

ANSI是windows的默认的当前地区的编码方式，对于英文文件是ASCII编码，对于简体中文文件是GB2312编码（只针对Windows简体中文版，如果是繁体中文版会采用Big5码）。所以，如果将一个UTF-8编码的文件，另存为ANSI的方式，对于中文部分会产生乱码。

windows Notepad中的编码Unicode保存选项，代表什么含义？

所谓的「Unicode」指的是 UTF-16LE，即Unicode 16位Little endian编码方式。由BOM选择大尾还是小尾，如果不存在BOM，则按照小尾方式解析

windows Notepad中的编码UTF-8保存选项，代表什么含义？

所谓的「Unicode」指的是带 BOM 的 UTF-8。

 

2.什么是UTF-8的BOM？

BOM的全称是Byte Order Mark，byte order mark（BOM），用来判断字节流的字节序。在传输字节流前，先传输被作为BOM的字符。

UCS规范建议我们在传输字节流前，先传输字符"Zero Width No-Break Space"。这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little-Endian的。因此字符"Zero Width No-Break Space"又被称作BOM。

UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"Zero Width No-Break Space"的UTF-8编码是EF BB BF。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。

UTF-8编码的文件中，BOM占三个字节。如果用记事本把一个文本文件另存为UTF-8编码方式的话，用UE打开这个文件，切换到十六进制编辑状态就可以看到开头的EF BB BF了。这是个标识UTF-8编码文件的好办法，软件通过BOM来识别这个文件是否是UTF-8编码，很多软件还要求读入的文件必须带BOM。可是，还是有很多软件不能识别BOM。

Windows平台下的UTF-8文档中的BOM是微软给UTF-8编码加上的，用于标识文件使用的是UTF-8编码，即在UTF-8编码的文件起始位置，加入三个字节“EE BB BF”。这是微软特有的，标准并不推荐包含BOM的方式。采用加BOM的UTF-8编码文件，对于一些只支持标准UTF-8编码的环境，可能导致问题。比如，在Go语言编程中，对于包含BOM的代码文件，会导致编译出错。

下边是utf的BOM：

UTF-8　║　EF BB BF

UTF-16LE　║　FF FE

UTF-16BE　║　FE FF

UTF-32LE　║　FF FE 00 00

UTF-32BE　║　00 00 FE FF

这个字节序不要出现在传输中，例如：在进行组包发送数据时，当字符使用utf-8编码时，会多出BOM，所以要先截除BOM，然后进行传输，这点是要注意的。对于utf-8编码的字符，要向前截除3个字节。

在utf-8下的的记事本上，“赵”字的全16进制格式是：EF BB BF E8 B5 B5

其中后3个字节是“赵”字的utf8编码，而前三个字节就是BOM了。

然后再以字母M来试一下，因为这个字母是Ascii码表中的值（这样说不太准确），或者说它是127之内的值，所以utf-8编码格式与ascii一样。（尽管如此，做为utf-8编码，文本串最前边还是多出3个字节，BOM）

3.为什么数据库Latin1字符集（单字节）可以存储中文呢？

其实不管需要使用几个字节来表示一个字符，但最小的存储单位都是字节,所以，只要能保证传输和存储的字节顺序不会乱即可。作为数据库，只是作为存储的使用的话，只要能保证存储的顺序与写入的顺序一致，然后再按相同的字节顺序读出即可，翻译成语义字符的任务交给应用程序。比如’微’的UTF-8编码是’0xE5 0xBE 0xAE’，那数据库也存储’0xE5 0xBE 0xAE’三个字节，其它应用按顺序从数据库读取，再按UTF-8编码进行展现。这当然是一个看似完美的方案，但是只要写入，存储，读取过程中岔出任何别的编码，都可能导致乱码。

4.UCS-2和UTF-16有什么区别？

UTF-16和UCS-2都是Unicode的编码方式。

Unicode使用一个确定的名字和一个叫做码位（code point）的整数来定义一个字符。例如©字符被命名为“copyright sign”并且有一个值为U+00A9（0xA9，十进制169）的码位。

Unicode的码空间从U+0000到U+10FFFF，共有1,112,064个码位(code point)可用来映射字符. Unicode的码空间可以划分为17个平面(plane)，每个平面包含2¹⁶(65,536)个码位。每个平面的码位可表示为从U+xx0000到U+xxFFFF, 其中xx表示十六进制值从00₁₆ 到10₁₆，共计17个平面。

第一个Unicode平面(码位从U+0000至U+FFFF)包含了最常用的字符，该平面被称为基本多语言平面（Basic Multilingual Plane），缩写为BMP。其他平面称为辅助平面(Supplementary Planes)。

UCS-2 (2-byte Universal Character Set)是一种定长的编码方式，UCS-2仅仅简单的使用一个16位码元来表示码位，也就是说在0到0xFFFF的码位范围内，它和UTF-16基本一致。

 

UTF-16 (16-bit Unicode Transformation Format)是UCS-2的拓展，它可以表示BMP以为的字符。UTF-16使用一个或者两个16位的码元来表示码位，这样就可以对0到0x10FFFF的码位进行编码。

 

例如，在UCS-2和UTF-16中，BMP中的字符U+00A9 copyright sign（©）都被编码为0x00A9。

 

但是在BMP之外的字符，例如

，只能用UTF-16进行编码，使用两个16为码元来表示：0xD834 0xDF06。这被称作代理对，值得注意的是一个代理对仅仅表示一个字符，而不是两个。UCS-2并没有代理对的概念，所以会将0xD834 0xDF06解释为两个字符。

 

简单的说，UTF-16可看成是UCS-2的父集。在没有辅助平面字符（surrogate code points）前，UTF-16与UCS-2所指的是同一的意思。（严格的说这并不正确，因为在UTF-16中从U+D800到U+DFFF的码位不对应于任何字符，而在使用UCS-2的时代，U+D800到U+DFFF内的值被占用。）但当引入辅助平面字符后，就称为UTF-16了。

参考链接：http://zh.wikipedia.org/wiki/UTF-16

来源： <http://demon.tw/programming/utf-16-ucs-2.html>

 

UCS和Unicode有什么区别？

UCS是通用字符集（universal character set）,它是有ISO制定的标准字符集。包括U CS-2和UCS-4

UCS-2使用 2个字节编码 ，UCS-4使用 4个字节编码 。有人说UCS和Unicode是一个东西，这种说法是不正确的，他们是两个不同组织制定的标准，只是后来这两个组织（Unicode联盟和ISO）为了更好地服务世界人民，而达成共识，统一了双方的标准，使用相同的字码和字库。这就使得Unicode里面的字符编码和UCS里面的编码基本一致，虽然UCS-4超出了unicode的范围，但是UCS-4承诺不使用大于0x10ffff的码位编码字符。

来源： <http://blog.sina.com.cn/s/blog_748bd2ad010178ua.html>

 

5.什么情况下，表示信息丢失？

对于mysql数据库，我们可以通过hex(colname)函数（其它数据库也有类似的函数，一些文本文件编辑器也具有这个功能），查看实际存储的字节内容，如：

通过查看存储的字节序，我们可以从根本上了解存储的内容是什么编码了。而当发现存储的内容全部是’3F’时，就表明存储的内容由于编码问题，信息已经丢失了，无法再找回。

之所以出现这种信息丢失的情况，一般是将不能相互转换的字符集之间做了转换，比如我们在前文说到，UTF-8只能一个个字节地变成Latin-1，但是根本不能转换的，因为两者之间没有转换规则，Unicode的字符对应范围也根本不在Latin-1范围内，所以只能用’?(0x3F)’代替了。

总结：

本文从基础知识与实际中碰到的问题上，解析了字符编码相关内容。而之所以要从头介绍字符编码的基础知识，是为了更好的从原理上了解与解决日常碰到的编码问题，只有从根本上了解了不同字符集的规则及其之间的关系与兼容性，才能更好的解决碰到的乱码问题，也能避免由于程序中不正确的编码转换导致的信息丢失问题。

来源： <http://blog.csdn.net/huangkangying/article/details/39163719>

Big Endian 和 Little Endian

Peter Lee 2008-04-20

 

一、字节序

来自：http://ayazh.gjjblog.com/archives/1058846/

谈到字节序的问题，必然牵涉到两大CPU派系。那就是Motorola的PowerPC系列CPU和Intel的x86系列CPU。PowerPC系列采用big endian方式存储数据，而x86系列则采用little endian方式存储数据。那么究竟什么是big endian，什么又是little endian呢？

     其实big endian是指低地址存放最高有效字节（MSB），而little endian则是低地址存放最低有效字节（LSB）。

     用文字说明可能比较抽象，下面用图像加以说明。比如数字0x12345678在两种不同字节序CPU中的存储顺序如下所示：

Big Endian

   低地址                                            高地址
   ----------------------------------------->
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     12     |      34    |     56      |     78    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Little Endian

   低地址                                            高地址
   ----------------------------------------->
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     78     |      56    |     34      |     12    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     从上面两图可以看出，采用big endian方式存储数据是符合我们人类的思维习惯的。而little endian，!@#$%^&*，见鬼去吧 -_-|||

     为什么要注意字节序的问题呢？你可能这么问。当然，如果你写的程序只在单机环境下面运行，并且不和别人的程序打交道，那么你完全可以忽略字节序的存在。但是，如果你的程序要跟别人的程序产生交互呢？在这里我想说说两种语言。C/C++语言编写的程序里数据存储顺序是跟编译平台所在的CPU相关的，而JAVA编写的程序则唯一采用big endian方式来存储数据。试想，如果你用C/C++语言在x86平台下编写的程序跟别人的JAVA程序互通时会产生什么结果？就拿上面的0x12345678来说，你的程序传递给别人的一个数据，将指向0x12345678的指针传给了JAVA程序，由于JAVA采取big endian方式存储数据，很自然的它会将你的数据翻译为0x78563412。什么？竟然变成另外一个数字了？是的，就是这种后果。因此，在你的C程序传给JAVA程序之前有必要进行字节序的转换工作。

     无独有偶，所有网络协议也都是采用big endian的方式来传输数据的。所以有时我们也会把big endian方式称之为网络字节序。当两台采用不同字节序的主机通信时，在发送数据之前都必须经过字节序的转换成为网络字节序后再进行传输。ANSI C中提供了下面四个转换字节序的宏。

big endian：最高字节在地址最低位，最低字节在地址最高位，依次排列。 
little endian：最低字节在最低位，最高字节在最高位，反序排列。

endian指的是当物理上的最小单元比逻辑上的最小单元小时，逻辑到物理的单元排布关系。咱们接触到的物理单元最小都是byte，在通信领域中，这里往往是bit，不过原理也是类似的。

一个例子：
如果我们将0x1234abcd写入到以0x0000开始的内存中，则结果为
                big-endian     little-endian
0x0000     0x12              0xcd
0x0001     0x34              0xab
0x0002     0xab              0x34
0x0003     0xcd              0x12


目前应该little endian是主流，因为在数据类型转换的时候（尤其是指针转换）不用考虑地址问题。

 

二、Big Endian 和 Little Endian名词的由来

这两个术语来自于 Jonathan Swift 的《《格利佛游记》其中交战的两个派别无法就应该从哪一端－－小端还是大端－－打开一个半熟的鸡蛋达成一致。：）

“endian”这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开，由此曾发生过六次叛乱，其中一个皇帝送了命，另一个丢了王位。

我们一般将endian翻译成“字节序”，将big endian和little endian称作“大尾”和“小尾”。

在那个时代，Swift是在讽刺英国和法国之间的持续冲突，Danny Cohen，一位网络协议的早期开创者，第一次使用这两个术语来指代字节顺序，后来这个术语被广泛接纳了

 

三、Big Endian 和 Little Endian优劣

来自：Dr. William T. Verts, April 19, 1996

Big Endian

判别一个数的正负很容易，只要取offset0处的一个字节就能确认。

Little Endian

长度为1，2，4字节的数，排列方式都是一样的，数据类型转换非常方便。

 

四、一些常见文件的字节序

来自：Dr. William T. Verts, April 19, 1996

 

Common file formats and their endian order are as follows:

• Adobe Photoshop -- Big Endian
• BMP (Windows and OS/2 Bitmaps) -- Little Endian
• DXF (AutoCad) -- Variable
• GIF -- Little Endian
• IMG (GEM Raster) -- Big Endian
• JPEG -- Big Endian
• FLI (Autodesk Animator) -- Little Endian
• MacPaint -- Big Endian
• PCX (PC Paintbrush) -- Little Endian
• PostScript -- Not Applicable (text!)
• POV (Persistence of Vision ray-tracer) -- Not Applicable (text!)
• QTM (Quicktime Movies) -- Little Endian (on a Mac!) （PeterLee注Big Endian in my opinion）
• Microsoft RIFF (.WAV & .AVI) -- Both
• Microsoft RTF (Rich Text Format) -- Little Endian
• SGI (Silicon Graphics) -- Big Endian
• Sun Raster -- Big Endian
• TGA (Targa) -- Little Endian
• TIFF -- Both, Endian identifier encoded into file
• WPG (WordPerfect Graphics Metafile) -- Big Endian (on a PC!)
• XWD (X Window Dump) -- Both, Endian identifier encoded into file

 

五、比特序

来自：http://ayazh.gjjblog.com/archives/1058846/

我在8月9号的《Big Endian和Little Endian》一文中谈了字节序的问题。可是有朋友仍然会问，CPU存储一个字节的数据时其字节内的8个比特之间的顺序是否也有big endian和little endian之分？或者说是否有比特序的不同？ 
     实际上，这个比特序是同样存在的。下面以数字0xB4（10110100）用图加以说明。 
Big Endian

   msb                                                         lsb
   ---------------------------------------------->
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   1  |   0  |   1  |   1  |   0  |   1  |   0  |   0  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Little Endian

   lsb                                                         msb
   ---------------------------------------------->
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   0  |   0  |   1  |   0  |   1  |   1  |   0  |   1  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     实际上，由于CPU存储数据操作的最小单位是一个字节，其内部的比特序是什么样对我们的程序来说是一个黑盒子。也就是说，你给我一个指向0xB4这个数的指针，对于big endian方式的CPU来说，它是从左往右依次读取这个数的8个比特；而对于little endian方式的CPU来说，则正好相反，是从右往左依次读取这个数的8个比特。而我们的程序通过这个指针访问后得到的数就是0xB4，字节内部的比特序对于程序来说是不可见的，其实这点对于单机上的字节序来说也是一样的。 

     那可能有人又会问，如果是网络传输呢？会不会出问题？是不是也要通过什么函数转换一下比特序？嗯，这个问题提得很好。假设little endian方式的CPU要传给big endian方式CPU一个字节的话，其本身在传输之前会在本地就读出这个8比特的数，然后再按照网络字节序的顺序来传输这8个比特，这样的话到了接收端不会出现任何问题。而假如要传输一个32比特的数的话，由于这个数在littel endian方存储时占了4个字节，而网络传输是以字节为单位进行的，little endian方的CPU读出第一个字节后发送，实际上这个字节是原数的LSB，到了接收方反倒成了MSB从而发生混乱。

来源： <http://blog.csdn.net/sunshine1314/article/details/2309655>