在一个物联往项目中,需要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。