tomcat 7 早期版本存在对 utf-8 编码路径（尤其是含日文等 unicode 文件夹名）的底层支持缺陷，即使配置了 uriencoding、file.encoding 和系统 locale，仍可能抛出 `filenotfoundexception`；升级至 tomcat 7.0.109+ 或 tomcat 9+ 是根本解决方案。
在实际企业级 Java Web 部署中，当应用需访问含日文、中文等非 ASCII 字符的文件系统路径（如 /opt/app/data/ユーザー資料/）时，常遇到 FileNotFoundException 或 java.io.File.isDirectory() 返回 false 等异常行为。该问题在 CentOS 7 主机环境复现明显，却在 Docker 容器中“意外”正常——这并非配置差异所致，而是JVM 文件系统层与 Tomcat 内部路径解析逻辑在旧版中的双重编码兼容性缺陷。
尽管你已正确完成以下关键配置：
- server.xml 中设置
- catalina.sh 中导出 -Dfile.encoding=UTF-8 和 -Djavax.servlet.request.encoding=UTF-8
- 系统级设置 LC_ALL=en_US.UTF-8
这些措施能解决 URL 参数、表单提交和响应输出的编码问题，但无法修复 Tomcat 7.0.108 及更早版本中 org.apache.catalina.webresources.StandardRoot 对本地文件路径的字节解码逻辑缺陷：其内部使用平台默认编码（而非显式 UTF-8）构造 File 对象，导致含多字节 UTF-8 字符的路径被错误截断或解析失败。
✅ 验证方法：
在 Servlet 中添加调试代码，打印真实路径字节序列：
String path = "/opt/app/日本語フォルダ";
File f = new File(path);
System.out.println("Path: " + path);
System.out.println("Bytes (UTF-8): " + Arrays.toString(path.getBytes(StandardCharsets.UTF_8)));
System.out.println("Exists: " + f.exists()); // 很可能为 false⚠️ 注意事项：
- 不要依赖 new String(bytes, "ISO-8859-1") 类似方式“绕过”问题——这是危险的临时 hack，易引发乱码或安全漏洞；
- Docker 容器中看似正常，往往是因为基础镜像（如 openjdk:8-jre-slim）默认启用 UTF-8 locale，且部分容器运行时会强制覆盖 JVM 的 file.encoding，掩盖了 Tomcat 层缺陷；
- 升级后务必移除 catalina.sh 中重复的 -Dfile.encoding=UTF-8（Tomcat 9+ 默认强制 UTF-8，冗余参数可能干扰）；
- 若必须维持 Tomcat 7，最低安全版本为 7.0.109（2020 年 10 月发布），其修复了 Bug 64523 ——即 StandardRoot 对 getResource() 路径的 UTF-8 解码逻辑。
? 推荐操作步骤：
- 下载 Tomcat 9.0.x 最新版 或 Tomcat 7.0.109+；
- 备份 conf/、webapps/ 和 logs/ 目录；
- 替换 $CATALINA_HOME，迁移配置（注意 server.xml 中 URIEncoding 在 Tomcat 9+ 已默认生效，可保留但非必需）；
- 启动并用日文路径资源测试：curl "http://localhost:8080/app/list?dir=日本語フォルダ"。
总结：字符编码问题表象是配置缺失，根源常是组件版本陈旧。面对路径级 Unicode 支持，优先升级中间件而非堆砌 JVM 参数——这是保障国际化 Web 应用健壮性的关键工程实践。
