Java中 DataInputStream 读取字符串时 readUTF 超过 65535 字节报错排查
DataInputStream的readUTF方法因使用2字节无符号短整型记录长度，限制字符串UTF-8编码字节数不超过65535，超出会抛出异常。需通过writeInt写入字节长度后直接传输原始字节来绕过限制，并注意区分字符数与UTF-8编码字节数。
你可能遇到过这样的情况：用 DataInputStream 的 readUTF 方法读取字符串时，突然抛出一个 ja va.io.UTFDataFormatException: encoded string too long 的错误。这不是什么奇怪的 bug，而是 readUTF 本身的一道“硬门槛”——它要求字符串的 UTF-8 编码字节长度不能超过 65535（也就是 216−1）。
这个限制的根源在于 readUTF 的工作方式。它先读 2 个字节，这两个字节是一个无符号短整型，用来表示后续 UTF 编码字节的长度。2 个字节能表示的最大值就是 65535，超出这个范围，协议层面就不认了。
这里有个很容易被忽略的点：字符串的字符数和它的 UTF-8 编码字节数，完全是两码事。一个字符串可能只有几万个字符，但里面只要混入中文、emoji 或其他 Unicode 字符，编码后的体积就可能迅速膨胀（一个汉字就要占 3 个字节）。而这个限制跟 JVM 或 JDK 版本无关，是 DataInputStream 规范中雷打不动的强制要求。
如何判断是否真的超限了？
别只盯着 String.length() 看，那个数字是字符数，对判断这个限制没什么帮助。真正要查的是 UTF-8 编码后的字节数：
- 用
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，完全没有预估编码后的体积
- 前后端混用时，Ja va 端用 DataInputStream.readUTF，而另一端（比如 Python 的 socket）手动拼接 UTF-8 字节，却没有做长度截断
- 升级数据格式后，读写逻辑没同步更新。旧版本能存的长字符串，新版本一读就报错
说到底，这个问题不复杂，但确实容易忽略。关键在于区分“字符数”和“UTF-8 字节数”，并且在设计阶段就把传输协议的边界明确下来。
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
AirBuddy 3 是面向 macOS 的蓝牙外设增强工具，可集中查看 AirPods、Beats 与苹果设备电量，提供快速连接、播放控制、电量提醒、桌面小组件和多台 Mac 外设接力等功能。
AirServer macOS版可把 Mac 转换为无线投屏接收端，通过 AirPlay 或 Google Cast 接收手机、平板和电脑画面，并支持多设备同时连接、高清镜像及会话录制，适合家庭娱乐、课堂教学、会议演示和应用展示。
Autodesk Maya 是面向影视、电视、动画和游戏行业的专业三维制作软件，集多边形与 NURBS 建模、角色绑定、关键帧和动作捕捉动画、Bifrost 特效模拟、材质开发及 Arnold 渲染于一体，
AirServer Windows版可把电脑变成AirPlay、Google Cast和Miracast无线投屏接收端，适合会议演示、课堂教学及家庭大屏分享。发送设备通常无需另装客户端，并可同时接收和智能排列多个镜像会话。