跨平台问题-字节序

【大端(Big Endian)与小端(Little Endian)简介】

Byte Endian是指字节在内存中的组织,所以也称它为Byte Ordering,或Byte Order。

对于数据中跨越多个字节的对象, 我们必须为它建立这样的约定:

(1) 它的地址是多少?

(2) 它的字节在内存中是如何组织的?

针对第一个问题,有这样的解释:

对于跨越多个字节的对象,一般它所占的字节都是连续的,它的地址等于它所占字节最低地址。(链表可能是个例外, 但链表的地址可看作链表头的地址)。

比如: int x, 它的地址为0×100。 那么它占据了内存中的Ox100, 0×101, 0×102, 0×103这四个字节(32位系统,所以int占用4个字节)。

上面只是内存字节组织的一种情况: 多字节对象在内存中的组织有一般有两种约定。 考虑一个W位的整数。

它的各位表达如下:[Xw-1, Xw-2, ... , X1, X0],它的

MSB (Most Significant Byte, 最高有效字节)为 [Xw-1, Xw-2, ... Xw-8];

LSB (Least Significant Byte, 最低有效字节)为 [X7,X6,..., X0]。

其余的字节位于MSB, LSB之间。

LSB和MSB谁位于内存的最低地址, 即谁代表该对象的地址?

这就引出了大端(Big Endian)与小端(Little Endian)的问题。

如果LSB在MSB前面, 既LSB是低地址, 则该机器是小端; 反之则是大端。

DEC (Digital Equipment Corporation,现在是Compaq公司的一部分)和Intel的机器(X86平台)一般采用小端。

IBM, Motorola(Power PC), Sun的机器一般采用大端。

当然,这不代表所有情况。有的CPU即能工作于小端, 又能工作于大端, 比如ARM, Alpha,摩托罗拉的PowerPC。 具体情形参考处理器手册。

具体这类CPU是大端还是小端,应该和具体设置有关。

(如,Power PC支持little-endian字节序,但在默认配置时是big-endian字节序)

一般来说,大部分用户的操作系统(如windows, FreeBsd,Linux)是Little Endian的。少部分,如MAC OS ,是Big Endian 的。

所以说,Little Endian还是Big Endian与操作系统和芯片类型都有关系。

Linux系统中,你可以在/usr/include/中(包括子目录)查找字符串BYTE_ORDER(或

_BYTE_ORDER, __BYTE_ORDER),确定其值。BYTE_ORDER中文称为字节序。这个值一般在endian.h或machine/endian.h文件中可以找到,有时在feature.h中,不同的操作系统可能有所不同。

对于一个数0×1122

使用Little Endian方式时,低字节存储0×22,高字节存储0×11

而使用Big Endian方式时, 低字节存储0×11, 高字节存储0×22

经一网友指正,才知道,上面的描述,是不准确的.

想了下,觉得如下描述可能更合适:

使用Little Endian方式存储数据时,数据的LSB相对最没意义的数据位,存放在低地址位置,这里的LSB也就是22了.也即,

低地址存储0×22, 高地址存储0×11

而使用Big Endian方式存储数据时,数据的MSB最有意义的数据位,存放在低地址位置,这里的MSB也就是11了.也即

低地址存储0×11, 高地址存储0×22

助记:

1)所谓MSB (Most Significant Byte),名字很复杂,不知是否有人没搞懂,反正我开始看到这个词时候,就很糊涂,有点不完全理解.其实简单说MSB就是,一个数字中,最重要的那位,

举例来说,12004,中文读作,一万两千零四,那最高位的1,就表示了一万,此处就称作MSB,最有意义的位.

2)一般常见的数据存储,用文字写出来的时候,其内容书写格式,多数是从低地址到高地址.(更符合人类思维的原因)

举例,一个16进制数是 0×11 22 33, 而存放的位置是

地址0×3000 中存放11

地址0×3001 中存放22

地址0×3002 中存放33

连起来就写成地址0×3000-0×3002中存放了数据0×112233.

而这种存放和表示方式,正好符合大端.

解释的有点乱,希望有人能看懂.

如果还有哪里有误,还请各位继续指正.谢谢.

【用函数判断系统是Big Endian还是Little Endian】

bool IsBig_Endian()

//如果字节序为big-endian,返回true;

//反之为   little-endian,返回false

{

unsigned short test = 0×1122;

if(*( (unsigned char*) &test ) == 0×11)

return TRUE;

else

return FALSE;

}//IsBig_Endian()

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,098评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,213评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,960评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,519评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,512评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,533评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,914评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,574评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,804评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,563评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,644评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,350评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,933评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,908评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,146评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,847评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,361评论 2 342

推荐阅读更多精彩内容