MalformedInputException是RuntimeException子类，非受检异常，无需强制try-catch；它在字节序列与声明编码不匹配时抛出（如用UTF-8解码GBK内容），应通过预判编码、设置容错策略或降级尝试多种编码来规避。
Java中MalformedInputException是java.nio.charset包下的**非受检异常（RuntimeException）**，它**不是受检异常**。所以问题前提有误——你无法、也不需要“捕获并处理”它来满足编译器的受检异常检查。真正需要关注的是：它在什么场景下抛出？为什么容易被误认为“必须try-catch”？如何正确规避或响应？
MalformedInputException本质是运行时编码解析失败
它继承自CharacterCodingException，而后者是RuntimeException的子类。典型触发场景：
- 用
StandardCharsets.UTF_8解码一段实际为GBK编码的字节数组（比如读取Windows记事本保存的中文文件） - 调用
CharsetDecoder.decode(ByteBuffer)时遇到非法UTF-8序列（如孤立的0xC0、0xED等高位字节） - 使用
Files.readString(path, UTF_8)（Java 11+）读取乱码文件
它反映的是**数据与声明编码不一致**，属于数据质量问题，而非API调用错误，因此设计为非受检异常。
别try-catch它，要提前预防或优雅降级
强行捕获MalformedInputException往往掩盖根本问题。更合理的做法是：
立即学习“Java免费学习笔记（深入）”；
-
明确源头编码：读文件前确认其真实编码（可用工具如
file -i、Notepad++编码识别，或约定协议） -
用Decoder设置容错策略：通过
CharsetDecoder.onMalformedInput(CodingErrorAction.REPLACE)或.REPLACE让解码器用替代非法字符，避免崩溃 - 降级尝试多种编码：对不确定来源的文本（如HTTP响应体、用户上传文件），按优先级依次尝试UTF-8 → GBK → ISO-8859-1，首个不抛此异常的即为候选编码
如果真要捕获，确保逻辑合理
仅在明确需要区分“编码错误”和“其他IO异常”时才捕获它，且应配合日志和业务处理：
try {
String content = Files.readString(path, StandardCharsets.UTF_8);
} catch (MalformedInputException e) {
log.warn("UTF-8 decode failed for {}, fallback to GBK", path, e);
// 降级逻辑...
} catch (IOException e) {
throw new UncheckedIOException(e); // 其他IO问题仍需处理
}
注意：不要只catch它而忽略IOException——文件不存在、权限不足等仍是受检异常，必须处理。
常见误区提醒
很多人以为new String(bytes, "UTF-8")会抛受检异常，其实它抛的是UnsupportedEncodingException（已过时），而现代写法new String(bytes, StandardCharsets.UTF_8)完全不会抛任何异常。真正的风险点在NIO的CharsetDecoder和Files.readString/readLines等方法。
