java tcp 16进制_Java Tcp 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);

}