FileInputStream读中文路径XML抛FileNotFoundException的根源是JVM用系统编码（如GBK）解码路径，导致字节序列与文件系统不匹配；应改用Files.newInputStream(Paths.get("路径"))或File.getCanonicalPath()绕过编码问题。
Java用FileInputStream读中文路径XML直接抛FileNotFoundException
不是文件不存在，是JVM默认用系统编码（比如Windows的GBK）解码路径字符串，而FileInputStream底层调用系统API时，传入的路径字节序列和实际文件系统期待的不一致。尤其在IDE里运行时，项目路径含中文，new FileInputStream("配置/参数.xml")大概率炸。
- 别用
FileInputStream直接构造——它不处理路径编码转换，只认字节流入口 - 改用
Files.newInputStream(Paths.get("配置/参数.xml"))，Paths.get()会按JVM默认字符集正确解析路径字符串，再交由NIO底层适配系统API - 如果必须用老式
File对象，至少包装一层：new FileInputStream(file.getCanonicalPath())，getCanonicalPath()会触发一次真实路径规范化，间接绕过部分编码错位
DOM解析器报org.xml.sax.SAXParseException: Invalid byte 1 of 1-byte UTF-8 sequence
这错误看着像XML内容编码问题，但根源常在路径本身——当Java把中文路径错误解码成乱码后，打开的其实是个不存在或权限异常的“假文件”，返回的输入流可能为空、截断，或者被系统返回一个含BOM/错误头的临时错误页，DOM解析器一读就崩。
- 先验证路径是否真能打开：
Files.exists(Paths.get("数据/用户.xml"))返回true再往下走 - 不要依赖
DocumentBuilder.parse(new File(...))，它内部仍走FileInputStream老路；统一用DocumentBuilder.parse(Files.newInputStream(path)) - 显式指定XML声明编码（如
<?xml version="1.0" encoding="UTF-8"?>），并确保文件物理存储确实是该编码——编辑器保存时选对编码，别让Notepad偷偷存成ANSI
Spring ClassPathResource在打包后读不到中文路径XML
ClassPathResource本身不处理文件系统路径，它走的是类路径查找逻辑。问题出在：Maven打包时，默认不会把含中文的资源名原样放进JAR（尤其Windows下，jar命令对非ASCII路径支持弱），或者IDE编译输出目录里中文文件名被转义/丢失。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 开发期别把XML放
src/main/resources/配置/这种中文目录下——改用英文路径，如src/main/resources/conf/ - 如果必须保留中文语义，把文件名改成拼音或下划线命名：
user_config.xml代替用户配置.xml，路径层级全用英文 - 运行时检查JAR包内容：
jar -tf your-app.jar | grep "配置"，如果根本搜不到，说明打包阶段已被过滤或编码损坏，就得查maven-resources-plugin的encoding配置是否设为UTF-8
用URLDecoder.decode()手动解码路径字符串反而更糟
有人看到路径变成%E7%94%A8%E6%88%B7.xml就想用URLDecoder.decode(path, "UTF-8")，但这是典型误用——只有HTTP URL里的百分号编码才适用这个方法，文件系统路径不是URL，file:///C:/项目/用户.xml里的中文是直接Unicode字符，不是编码后的字节序列。
立即学习“Java免费学习笔记（深入）”；
-
URLDecoder只用于处理request.getQueryString()或URLEncoder.encode()生成的字符串，对getResource().getPath()结果做decode基本等于自造bug - 如果从
getResource()拿到的是file:开头URL，提取路径用url.toURI().getPath()，它会自动完成从URL编码到本地路径的转换 - 最稳做法：所有路径操作统一走
Paths.get()+Files工具类，避开String到File的隐式转换链
真正麻烦的不是读取动作本身，而是路径在JVM启动参数、IDE工作目录、Maven生命周期、JAR打包机制之间被反复转码又解码——只要其中一环用错字符集，前面写的逻辑全白搭。盯住Paths.get()和Files这两个入口，其他都是干扰项。
