Chinaunix首页 | 论坛 | 博客
  • 博客访问: 292983
  • 博文数量: 60
  • 博客积分: 1437
  • 博客等级: 中尉
  • 技术积分: 632
  • 用 户 组: 普通用户
  • 注册时间: 2011-02-10 14:12
文章存档

2012年(7)

2011年(53)

分类: Oracle

2011-02-28 10:04:32

第一次使用bbed 恢复数据库的时候碰到这个问题,后来咨询了
才知道是这个问题,感谢熊哥:),索性今天记录下来,以下来自百度百科,发现百度百科还不错!

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
谈到字节序的问题,必然牵涉到两大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程序之前有必要进行字节序的转换工作。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
阅读(2270) | 评论(2) | 转发(0) |
给主人留下些什么吧!~~

itpub.com.cn2011-02-28 10:33:59

BBED> p kcvfhckp
struct kcvfhckp, 160 bytes                  @484     
   struct kcvcpscn, 8 bytes                 @484     
      ub4 kscnbas                           @484     &nb

itpub.com.cn2011-02-28 10:22:24

BBED> p kcvfhckp
struct kcvfhckp, 36 bytes                   @484     
   struct kcvcpscn, 8 bytes                 @484     
      ub4 kscnbas                           @484     &nb