Java ByteBuffer 怎么按协议切换大端和小端读取整数

我第一次排查 Java 二进制解析错值时，直觉先去看字段偏移，后来才发现四个字节根本没有读错，只是被另一种字节序解释了。ByteBuffer 的多字节读取默认使用大端序；如果协议字段是小端序，就在读取该字段前调用 order(ByteOrder.LITTLE_ENDIAN)。字节序只决定同一组字节怎样组成整数，position 是否推进则由你使用相对读取还是绝对读取决定。

官方地址：https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/nio/ByteBuffer.html

先判断错的是字节序还是读取位置

假设协议中的四个字节是 01 02 03 04。按大端序读取，最高有效字节在前，结果是 0x01020304；按小端序读取，最低有效字节在前，结果是 0x04030201。两次读取使用了完全相同的字节，差异来自解释规则，不是数据自动发生了变化。

排查时可以先记录三件事：当前 order() 的值、读取前的 position()，以及 remaining() 是否至少有目标类型需要的字节数。若数值像是每四个字节倒序，优先查字节序；若每个字段都从错误的偏移开始，优先查 position 或字段长度。

默认大端，按字段切换小端

ByteBuffer.allocate 和 ByteBuffer.wrap 创建的缓冲区初始都是 BIG_ENDIAN。协议明确要求小端时，先设置顺序，再调用相应的多字节读取方法。order 返回当前缓冲区本身，因此可以链式调用，但在排错代码里分开写通常更容易确认状态。

import java.nio.ByteBuffer;
import java.nio.ByteOrder;

public class ByteOrderReadDemo {
    public static void main(String[] args) {
        byte[] bytes = {0x01, 0x02, 0x03, 0x04};

        // 默认按大端序解释：高位字节在前。
        ByteBuffer bigEndian = ByteBuffer.wrap(bytes);
        int bigValue = bigEndian.getInt();

        // 协议若声明小端序，必须在读取前切换顺序。
        ByteBuffer littleEndian = ByteBuffer.wrap(bytes);
        littleEndian.order(ByteOrder.LITTLE_ENDIAN);
        int littleValue = littleEndian.getInt();

        // 用十六进制输出，方便对照原始字节和协议文档。
        System.out.printf("big=0x%08X, little=0x%08X%n", bigValue, littleValue);
    }
}

这里的两个缓冲区各自从位置 0 开始，所以 getInt() 都能消费四个字节。不能把“把 ByteOrder 改成小端”理解为反转底层数组；它只改变后续多字节读写的解释方式。

用 position 区分相对读取与绝对读取

相对方法 getInt() 从当前位置取四个字节，成功后 position 增加 4；绝对方法 getInt(index) 从指定字节索引读取，position 保持不变。协议解析中经常需要先读一个公共头，再按固定偏移检查字段，此时两种方法的差别很关键。

ByteBuffer buffer = ByteBuffer.allocate(8)
        .order(ByteOrder.LITTLE_ENDIAN);
buffer.putInt(100).putInt(200);
buffer.flip();

// 相对读取会推进 position：0 -> 4。
int header = buffer.getInt();
int payloadLength = buffer.getInt();

// 重新定位后用绝对读取，读取不会改变当前 position。
buffer.rewind();
int secondField = buffer.getInt(4);
int stillAt = buffer.position();

// header=100，payloadLength=200，secondField=200，stillAt=0。
System.out.println(header + "," + payloadLength + "," + secondField + "," + stillAt);

如果排查日志显示数值正确但下一字段错位，重点看是否混用了相对读取、position(int)、rewind() 或 flip()。字节序正确并不代表游标正确。

混合字段时在读取前恢复字节序

有些二进制格式会把不同来源的数据拼在一起，字段各自规定字节序。不要依赖“上一次设置过什么”，而是在每个多字节字段读取前明确设置。下面的示例把前四个字节作为大端整数，后四个字节作为小端整数。

byte[] record = {
        0x00, 0x00, 0x00, 0x2A, // 大端字段：42
        0x2B, 0x00, 0x00, 0x00  // 小端字段：43
};
ByteBuffer mixed = ByteBuffer.wrap(record);

// 先按第一个字段的协议读取，成功后 position 前进四个字节。
mixed.order(ByteOrder.BIG_ENDIAN);
int version = mixed.getInt();

// 第二个字段使用另一种顺序，显式切换避免依赖隐含状态。
mixed.order(ByteOrder.LITTLE_ENDIAN);
int count = mixed.getInt();

// 两个字段都读取完成，position 应等于 limit。
System.out.println("version=" + version + ", count=" + count
        + ", remaining=" + mixed.remaining());

这个写法的重点不是“混合字节序一定要共用一个 buffer”，而是把字段边界和读取规则写在一起。若字段数量较多，可以为每种规则封装小函数，但函数仍应明确接收并检查当前缓冲区状态。

检查 remaining，避免把边界问题误判成字节序问题

getInt() 需要四个可读字节。若 remaining() 小于 4，调用相对读取会抛出 BufferUnderflowException；这不是大小端设置错误，而是输入数据不完整、limit 设置过小，或者前一个字段消费过多。

static int readInt(ByteBuffer buffer, ByteOrder order) {
    // 先设置本字段的解释规则，避免沿用调用方的隐含状态。
    buffer.order(order);
    if (buffer.remaining() 

排查顺序建议固定为：先打印原始字节和 remaining()，再确认读取前的 order()，最后检查 position 是否按字段长度推进。这样能把“数据不够”“偏移错了”和“解释反了”分成三类问题。

视图缓冲区要注意创建时的字节序

asIntBuffer() 等视图会按照创建时的字节序解释底层字节，而且视图自己的 position、limit、mark 与原始 ByteBuffer 独立。若需要另一种字节序，先在原始缓冲区上设置好 order，再创建视图；不要创建后再修改原始缓冲区的顺序并期待视图自动切换。

import java.nio.ByteBuffer;
import java.nio.ByteOrder;
import java.nio.IntBuffer;

ByteBuffer bytes = ByteBuffer.wrap(new byte[] {
        0x01, 0x00, 0x00, 0x00
});

// 视图创建前设置小端，视图按小端解释第一个 int。
bytes.order(ByteOrder.LITTLE_ENDIAN);
IntBuffer ints = bytes.asIntBuffer();
int value = ints.get();

// 原始 ByteBuffer 与视图有各自的游标；不要混用 position 做同一套计数。
System.out.println("value=" + value + ", bytePosition=" + bytes.position());

一份可复用的排查清单

对我来说，实际接入协议解析器时，把“字段长度、字节序、读取方式、position 变化”放在同一个小段代码里，比依赖全局缓冲区状态更容易维护。先用一组手算过的字节对照解释结果，再接入真实报文，是成本最低、也最容易复现的一步。

常见问题

ByteBuffer 默认是大端还是小端？

默认是 BIG_ENDIAN。使用 wrap 或 allocate 后，如果协议是小端，需要显式调用 order(ByteOrder.LITTLE_ENDIAN)。

order 会改变 position 吗？

不会。order 只改变多字节值的解释方式；position 是否变化取决于后续使用相对读取还是绝对读取。

为什么 getInt(index) 读完后 position 没变？

带索引的 getInt(index) 是绝对读取，索引以字节为单位，不会推进当前 position。需要连续读取时应使用无索引的相对方法。