readutf方法限制字符串utf-8编码字节长度≤65535，因其先读2字节无符号短整型表示长度，最大值为2¹⁶−1；超限会抛utfdataformatexception，需用getbytes(standardcharsets.utf_8).length校验真实字节数。

readUTF 方法在 Java 中要求字符串的 UTF-8 编码字节长度必须 ≤ 65535（即 2¹⁶−1），否则会抛出 java.io.UTFDataFormatException: encoded string too long。这不是 bug，而是 DataInputStream.readUTF() 的协议限制：它先读取 2 字节表示长度，再按该长度读取字节并解码为字符串。

为什么 readUTF 有 65535 字节限制？

readUTF 遵循 Java 的“modified UTF-8”序列化格式：开头 2 个字节是无符号短整型（unsigned short）表示后续 UTF 字节长度。最大值为 65535，超出即非法。

• 即使字符串本身只有几万个字符，若含中文、emoji 或其他 Unicode 字符，UTF-8 编码后字节数可能远超字符数（如一个汉字占 3 字节）
• 该限制与 JVM 或 JDK 版本无关，是 DataInputStream 规范强制要求

如何判断是否真超限？

不要只看字符串长度（String.length()），而要检查其 UTF-8 编码字节数：

Java Maven Code Review

审查Java Maven项目（ZIP压缩包或GitLab仓库URL），检查代码规范、命名、模块边界、可维护性问题以及重复代码。

下载

• 用 string.getBytes(StandardCharsets.UTF_8).length 获取真实字节数
• 若结果 ≥ 65536，就一定会在 writeUTF / readUTF 流程中失败
• 注意：writeUTF 写入时也会校验，所以问题通常在写入端就已埋下（只是读取时才暴露）

替代方案：绕过 readUTF 限制

当需传输长文本时，放弃 readUTF，改用更灵活的组合方式：

• 写入端：先写入 int 类型长度（dos.writeInt(len)），再写入原始字节（dos.write(bytes)）
• 读取端：先读 int 得到长度，再用 new String(din.readNBytes(len), StandardCharsets.UTF_8)
• 或使用 BufferedReader/BufferedWriter + 行协议，或直接走 ObjectOutputStream（但要注意序列化开销和兼容性）

常见误用场景

以下情况容易踩坑：

• 日志、JSON、XML 等大文本内容直接调用 writeUTF 写入，未预估编码后体积
• 前后端混用：Java 用 DataInputStream.readUTF，而另一端（如 Python socket）手动拼接 UTF-8 字节但没做长度截断
• 升级数据格式后未同步更新读写逻辑，旧版能存的长字符串，新版 readUTF 读取时报错

不复杂但容易忽略：关键在于区分“字符数”和“UTF-8 字节数”，并在设计阶段明确传输协议边界。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南