MalformedInputException 是 Java NIO 中 CharsetDecoder 解码非法字节序列时抛出的运行时异常，常见于文件/HTTP 响应编码与读取编码不一致（如用 UTF-8 读 GBK 文件），需通过工具探测真实编码、依据来源指定 charset 或 fallback 重试，并在日志中记录路径、字节快照和 charset 名称以准确定位问题。
MalformedInputException 是 Java NIO 中的一个运行时异常，当使用 CharsetDecoder 解码字节流时，遇到无法按指定字符集解析的非法字节序列，就会抛出该异常。它通常不是直接由开发者手动 throw，而是底层字符解码器在检测到编码不匹配或数据损坏时自动触发。
常见触发场景：文件编码与读取编码不一致
最典型的情况是：文件实际保存为 GBK（如 Windows 记事本默认），但代码中用 UTF-8 去读取；或文件含 BOM 但解析逻辑未处理；又或者文件被截断、混入控制字符、传输损坏等。
- 用
Files.readAllLines(path, StandardCharsets.UTF_8)读取一个 GBK 编码的 .txt 文件 → 极大概率抛MalformedInputException - 用
InputStreamReader包装FileInputStream时指定错误 charset → 同样触发 - HTTP 响应体声明为 UTF-8，但服务端实际返回 GB2312 内容 → 解析响应流时也可能出现
如何定位真实编码？
不能只看文件扩展名或编辑器显示。推荐组合判断：
- 用命令行工具查看：Linux/macOS 下执行
file -i filename.txt或enca -L zh filename.txt - 用 IDE（如 IntelliJ）右下角查看当前文件编码提示，可临时切换尝试预览是否乱码
- 用十六进制编辑器（如 HxD、xxd）观察开头字节：UTF-8 BOM 是
EF BB BF，GBK 无标准 BOM，UTF-16 BE 是FE FF
稳妥的读取策略：避免硬编码 charset
不要假设所有文本都是 UTF-8。关键做法是：
- 优先依据来源明确指定编码：如 HTTP Header 的
Content-Type: text/plain; charset=gbk，数据库连接 URL 中的useUnicode=true&characterEncoding=GBK - 对本地文件，可先用
UniversalDetector（来自 ICU4J 或 juniversalchardet）做编码探测（注意：探测非 100% 准确，适合辅助决策） - 捕获
MalformedInputException并 fallback：例如先试 UTF-8，失败后改用系统默认编码或 GBK 再试一次（需业务允许容错）
调试与日志建议
抛异常时仅打印 “Input length = 1” 这类信息意义有限。应在 catch 块中补充上下文：
- 记录出问题的文件路径、前 32 字节的十六进制值（
Arrays.toString(Arrays.copyOf(bytes, Math.min(32, bytes.length)))） - 打印当前使用的 charset 名称
- 若可能，保存原始字节片段到临时文件，供后续用不同编码打开验证
