数据表示：字节 高位低位

常用单片机内存一个地址只能存八位二进制数,最大数据只能是255(十进制). 
  当需要储存大于255的数据时,就需要用两个以上的内存地址,低位字节中的数是原数,高位字节中的数要乘以位数再与低位字节中的数相加才是你真要的数. 
  N＝Xn*256^n+X(n-1)*256^(n-1)……X1*256+X0. 
  n……n+1个内存地址. 
  就象十进制数4321…………n=3 
  4*10^3+3*10^2+2*10+1. 

  数据指针是内存或寄存器地址,这个内存或寄存器地址内存放的就是你需要的数据.就象你到教室里去找人,别人告诉你一个座位号,这个座位上坐着的就是你要找的人,这个座位号就是人指针.如果这个数据使用多个字节则是最低位字节的地址.

 

获得一串字符串数据长度的高位字节和 低位字节的方法  

 

 

 

private  byte[] getLowHighByte( byte[] data) 
{    
     byte[] lowHighByte =  new  byte[ 2];
     int dataLen  = data.length();        
    lowHighByte[ 0]  = ( byte)(0xFF &dataLen);
    lowHighByte[ 1]  = ( byte)((0xFF00 &len) >> 8);
     return lowHighByte;
}

如上代码非常好理解  请仔细分析

      很多数据在校验过程中或者在项目过程中经常要计算

      此串数据的高位地址和低位字节。 如上方法很好的解决了

      计算高位字节和低位字节的。

 

 

---

   byte型实际上就是最大的值为FF 此代码很经典。

 

高位字节优先 低位字节优先

 

自第一台计算机诞生，其最小存储单元就被永久的定格了——一个由8个比特（bit）组成的称为字节（byte）的单位。计算机的所有内存以字节数组的方式进行编址。

当一个逻辑上长于一个字节的整形数据放置在内存中时（比如16位，32位，和64位的整数），计算机设计者需要考虑这些字节的存储顺序。一些体系结构的设计者选择了将字节的逻辑顺序与物理顺序一致，即将逻辑上较低的字节放置在物理上较低的字节上；另外一些设计者则选择了将字节的逻辑顺序与物理顺序相反，即将逻辑上较低的字节放置在物理上较高的字节上。前者被称为“little endian”，比如Intel x86系列；后者则被称为“big endian”，比如Motorola的PowerPC以及Sun Sparc。还有一些平台同时支持两种方案，由开发者决定使用哪一种。

两种选择为底层开发者带来了一定的困扰。比如，两个字节顺序不一致的平台之间进行通信，或者在两个字节顺序不一致的平台之间移植系统。这都是跨平台的例子，对于这些情况，字节顺序的问题是不能回避的。对于仅仅在一种平台上进行开发的程序员而言，如果它能够避免强制类型转换（比如将字节数组强制转换为一个长整数），一贯的以逻辑顺序来操作大于一个字节的整数，应该可以回避这个问题。但由于C语言是一种非常灵活的语言，有时候通过强制类型转换可以让代码非常精简，甚至达到非常巧妙的效果，所以，要求C程序员完全回避这个问题，几乎是不现实的。

由于Little Endian提供了逻辑顺序与物理顺序的一致性，让编程者摆脱了不一致性所带来的困扰，C语言开发者可以无所顾忌的按照自己的意愿进行强制类型转换，所以现代体系结构几乎都支持Little Endian。但Big Endian也有其优点，尤其对于汇编程序员：他们对于任意长度的整数，总是可以通过判断Byte 0的bit-7来查看一个整数的正负；对于Little Endian则不得不首先知道当前整数的长度，然后查看最高byte的bit-7来判断其正负。对于这种情况，big endian的开发者可以写出非常高效的代码。

两派的支持者争论不休，正像他们所支持名词（big endian和little endian）的典故所讲述的那样：Little Endian和Big Endian这两个名词来源于Jonathan Swift的《格利佛游记》其中交战的两个派别无法就应该从哪一端－－小端还是大端－－打开一个半熟的鸡蛋达成一致。：）在那个时代，Swift是在讽刺英国和法国之间的持续冲突，Danny Cohen，一位网络协议的早期开创者，第一次使用这两个术语来指代字节顺序，后来这个术语被广泛接纳了（摘自《深入理解计算机系统》）。

需要特别指出的是，通常所提到的Little Endian和Big Endian仅仅指字节顺序。在硬件设计者的术语中，对于一个字节内部的bit顺序也分Little Endian和Big Endian，但对于程序员而言，这些bit顺序的不同是透明的，也就是说，程序员只需要按照逻辑顺序来看待和操作字节内部的bit即可。

Endian的不同不仅仅带来字节顺序的不同，还有更多的问题。如果C程序员在定义一个结构体时，使用了bitwise的域定义，比如：

struct foo {
 int  a:3;
 int b:7;
 int c:13;
 int d:9;
};

这个结构体的一个对象会占用4个字节。由于a,b,c,d的类型都是int，所以他们都在以int32为单位的整数上分配bit，另外，由于他们的bit数量正好等于int32的bit数，所以，它们都分配于一个int所占用的空间。关键问题在于这些字节在这4个字节内是分配顺序是怎么样的？

对于little endian，其分配顺序与逻辑顺序是一致的，即在byte[0]的bit[0~2]上分配a，在byte[0]的bit[3,7]以及byte[1]的bit[0,1]上分配b，依次类推。

对于big endian，其方案会带来很大的问题。其分配顺序为：

字节物理顺序：从低到高；
字节内bit顺序：从高到底；

也就是说，big endian在bitwise的分配方案上，从字节顺序到bit顺序都反过来了（因为其正向存储顺序为：字节从高到底，bit从低到高（从程序员的观点看））。换句话说：big endian的bit分配顺序为，按照bit的逻辑顺序，从高到底进行分配。

          

                     |--------|--------|--------|--------|
Logical Byte Order   | byte 3 | byte 2 | byte 1 | byte 0 |
                     |--------|--------|--------|--------|

Bitwise allocation   |-a-|---b---|------c------|----d----|

请注意，并不是硬件平台使用的这种方案，而是C语言编译器。这是一种荒谬的方案，我想可能是C语言编译器的早期开发者希望通过编译器屏蔽掉big endian和little endian在bitwise allocation上的差异，而都与物理存储顺序一致。但由于其采用了bit order的反向分配，反而加剧了这种差异，随后的编译器为了保持兼容，也只好将错误延续了下来。

基于这种原因，在C语言中直接使用bitwise的方式定义结构体是一种危险的方式，因为这些代码是平台依赖的。当进行跨平台移植的时候必须重新定义这些结构体。

有两种方式可以消除这种风险：

1、使用逻辑移位的方式来操作bit；以上面的例子为例，我们可以这么做：

struct foo {
 int value;
};

#define SET_A(f,a)  do { (f) |= ((a)&0x7); } while(0)
#define SET_B(f,b)  do { (f) |= (((b)&0x7F)<<3); } while(0)
#define SET_C(f,c)  do { (f) |= (((c)&0x1FFF)<<10); } while(0)
#define SET_D(f,d)  do { (f) |= (((d)&0x1FF)<<23); } while(0)

#define GET_A(f)  ((f)&0x7)
#define GET_B(f)  (((f)>>3)&0x7F)
#define GET_C(f)  (((f)>>10)&0x1FFF)
#define GET_D(f)  (((f)>>23)&0x1FF)

2、对于big endian,我们可以使用相反的顺序来声明bitwise fields。仍然以上例为例：

#if LITTLE_ENDIAN
#define BITWISE(type,a,b,c,d)  type a, b, c, d
#else
#define BITWISE(type,a,b,c,d)  type d, c, b, a
#endif

struct foo {
 BITWISE(int, a:3, b:7, c:13, d:9);
};

对于little endian，逻辑顺序与物理顺序一致，只需要按照原样定义；而对于big endian，由于其整体的bit顺序恰好与逻辑顺序是相反的，所以，我们将顺序反过来，使其bit的分配顺序与逻辑顺序一致即可。

转载于:https://www.cnblogs.com/jonson1126/archive/2012/12/13/2816895.html