在一个物联往项目中，需要java云平台与一个客户端做socket定制协议的通信；然而在第一次测试时，并没有按照预想的那样完成解析。查找资料以后是因为客户端的数据读取方式为小端模式，而java默认采用大端模式。
在计算机系统中，我们是以字节为单位的，每个地址单元都对应着一个字节，一个字节为 8bit。但是在C语言中除了8bit的char之外，还有16bit的short型，32bit的long型（要看具体的编译器），另外，对于位数大于 8位的处理器，例如16位或者32位的处理器，由于寄存器宽度大于一个字节，那么必然存在着一个如何将多个字节安排的问题。因此就导致了大端存储模式和小端存储模式。
目前Intel的80x86系列芯片是唯一还在坚持使用小端的芯片，而MIPS和ARM等芯片要么采用全部大端的方式储存，要么提供选项支持大端——可以在大小端之间切换。另外，对于大小端的处理也和编译器的实现有关，在C语言中，默认是小端（但在一些对于单片机的实现中却是基于大端，比如Keil 51C），Java是平台无关的，默认是大端。在网络上传输数据普遍采用的都是大端。
如果遇到了大端与小端之间的通信。应该遵照大小端的数据读取原理，做相应的转换。（以java的大端模式为例）
现在以java的32位的int型数据为例子，做转换示例；
如下：是大端int转化为小端的byte数组：将int型的4个高位16进制数逆序放入字节数组中；
public static byte[] intToMinByteArray(int i) {
byte[] result = new byte[4];
//由高位到低位
result[3] = (byte) ((i >> 24) & 0xFF);
result[2] = (byte) ((i >> 16) & 0xFF);
result[1] = (byte) ((i >> 8) & 0xFF);
result[0] = (byte) (i & 0xFF);
return result;
}
如下是小端数组转化为大端int数的示例：采用字符串表示的16进制数来转换为Integer的api。
public static int byteLittleEndianToInt(byte[] bytes) {
String nubHexStr = "";
byte[] temp = new byte[bytes.length];
for (int i = 0; i < bytes.length; i++) {
System.out.println("值：" + bytes[bytes.length - i - 1]);
System.out.println("对应的16进制值："+Integer.toHexString(bytes[bytes.length - i - 1]));
nubHexStr += Integer.toHexString(bytes[bytes.length - i - 1]);
}
System.out.println("16进制：" + nubHexStr);
return Integer.parseInt(nubHexStr, 16);
}
以上代码来自Felix。