readUTF方法限制字符串UTF-8编码字节长度≤65535，因其先读2字节无符号短整型表示长度，最大值为2¹⁶−1；超限会抛UTFDataFormatException，需用getBytes(StandardCharsets.UTF_8).length校验真实字节数。
readUTF 方法在 Java 中要求字符串的 UTF-8 编码字节长度必须 ≤ 65535（即 216−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 编码字节数：
- 用
string.getBytes(StandardCharsets.UTF_8).length获取真实字节数 - 若结果 ≥ 65536，就一定会在 writeUTF / readUTF 流程中失败
- 注意：writeUTF 写入时也会校验，所以问题通常在写入端就已埋下（只是读取时才暴露）
替代方案：绕过 readUTF 限制
当需传输长文本时，放弃 readUTF，改用更灵活的组合方式：
立即学习“Java免费学习笔记（深入）”；
- 写入端：先写入 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 字节数”，并在设计阶段明确传输协议边界。
