DataInputStream 读取原始数据方法详解

DataInputStream 并非万能二进制读取器，它严格依赖 Java 原生二进制格式——必须由配套的 DataOutputStream 写入，才能正确解析 int、double 等原始类型；若用 FileOutputStream 等直接写入字节，或混入 C/C++、文本、JSON 等非标准数据，轻则读出诡异数值（如 123 变成 -858993460），重则抛出 EOFException 或 Stream Closed 异常；其读取完全依赖精确的字节位置和顺序，类型调用错位、跳过/重读、重复关闭底层流都会导致连锁偏移和崩溃，而跨平台安全的前提，是全程坚守 Java 的大端约定与 writeXXX/readXXX 的配对使用。

为什么 DataInputStream 读不到你写进去的 int 或 double？

因为 DataInputStream 不解析数据含义，只按 Java 的二进制格式（大端、固定字节长）读取——如果你用 FileOutputStream 直接写 int 的字节，它不认识；必须用 DataOutputStream 配套写，否则字节布局对不上。

• 常见错误现象：EOFException 或读出极大/极小的异常数值（比如本该是 123，却读成 -858993460）
• 使用场景：读取由 Java 程序用 DataOutputStream.writeXXX() 写入的二进制文件，例如配置快照、序列化简单结构体
• 不适用场景：读取 C/C++ 写的二进制文件（字节序/对齐/浮点格式可能不同）、文本文件、JSON 或任何非 Java 原生二进制格式

readInt() 和 readDouble() 怎么保证不读错位置？

它们严格按顺序消费字节：每次调用 readInt() 向前跳 4 字节，readDouble() 跳 8 字节。一旦顺序错、类型错、或中间有跳过/重读，后续所有读取都会偏移。

• 参数差异：无参数，全靠当前流位置；没有“从第 N 字节开始读”这种选项
• 容易踩的坑：readByte() 后立刻 readInt()，结果把 byte 当作 int 的第一个字节读了——实际 int 还剩 3 字节没读完，下一次 readInt() 就从错位处开始
• 建议：用 mark()/reset() 前先确认底层流支持（FileInputStream 支持，但包装后可能不支持）；更稳妥的是记录已读字节数，手动跳转用 skipBytes(n)

遇到 IOException: Stream Closed 怎么办？

不是流真的关了，而是你重复关闭了同一个 DataInputStream，或者它的底层 FileInputStream 被提前关了——DataInputStream 关闭时会顺带关掉它包装的流。

• 常见错误：在 try-with-resources 里声明了 FileInputStream 和 DataInputStream 两个变量，导致关两次
• 正确做法：只用一个资源变量，即 try (DataInputStream dis = new DataInputStream(new FileInputStream("data.bin"))) { ... }
• 性能影响：多层包装本身开销极小，但重复关闭会抛异常，且可能导致后续读取失败（即使异常被捕获）

跨平台读写要注意字节序和文件结尾

Java 所有 writeXXX() 方法固定用大端（network byte order），这点没问题；但问题常出在文件末尾有没有多余字节、是否被截断，或者 Windows/Linux 换行符干扰（虽然二进制文件不该含换行符）。

• 兼容性影响：只要用 DataOutputStream 写，Java 程序间读写完全一致；但若文件被其他语言修改过，哪怕只加了一个字节，readLong() 就可能触发 EOFException
• 实操建议：读之前用 available() 判断剩余字节数是否足够（注意：该方法在某些流上不可靠，FileInputStream 可用）；更稳的方式是捕获 EOFException 并视为“数据结束”，而不是当错误处理
• 容易被忽略的地方：readUTF() 读的是 Java 修改版 UTF-8（带 2 字节长度前缀），不是标准 UTF-8；如果文件里混了普通字符串字节，这里会直接崩

本篇关于《DataInputStream 读取原始数据方法详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！