没有按照预想的那样完成解析,是因为客户端的数据读取方式为小端模式，而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);
    }

你用wireshark抓包看看呢，我并不没出现这个问题呢，看图