tomcat 7 早期版本存在对 utf-8 编码路径（尤其是日文文件夹名）的底层支持缺陷，即使配置了 uriencoding、file.encoding 和系统 locale，仍会抛出 `filenotfoundexception`；升级至 tomcat 7.0.109+ 或 tomcat 9+ 是根本解决方式。
在 CentOS 7 环境下运行 Tomcat 7 Web 应用时，若需读取或写入含日文字符的文件路径（如 /var/data/ユーザー情報/2024年報告.xlsx），即使已严格配置编码参数，仍可能遭遇 java.io.FileNotFoundException。该问题并非配置遗漏所致，而是 Tomcat 7.0.108 及更早版本中 java.io.File 路径解析与 NIO 文件系统交互时的固有缺陷：其内部未对 URI 到 Path 的转换做完整的 UTF-8 字节序列标准化处理，导致日文路径在 File.getCanonicalPath() 或 Files.walk() 等操作中被错误截断或解码失败。
值得注意的是，Docker 容器中“看似正常”，往往源于镜像默认使用 glibc 较新版本 + UTF-8 locale 强制生效（如 openjdk:8-jre-slim 默认 LANG=C.UTF-8），且容器启动时环境变量注入更彻底；而宿主机 Tomcat 常依赖 catalina.sh 中的 export，易受 shell 启动顺序、systemd 服务环境隔离（systemctl start tomcat 不自动继承用户 shell 的 LC_ALL）影响——但这只是表象，核心矛盾在于 Tomcat 7.0.108 及以前未修复 JDK 7/8 在非 ASCII 路径下的 sun.nio.fs.UnixPath 构造逻辑。
✅ 正确解决路径如下：
-
优先升级 Tomcat 版本（推荐）
- 升级至 Tomcat 7.0.109+（首个修复该问题的 7.x 版本，[官方 Changelog](https://www.php.cn/link/41ccd991e61f6d4e3ae984f745dff682 possible NPE and incorrect handling of non-ASCII characters in file paths.*）
- 或直接迁移至 Tomcat 9.0.83+ / Tomcat 10.1.15+（长期支持、JDK 11+ 优化、NIO2 路径处理更健壮）
-
验证升级后关键配置（精简有效版）
# catalina.sh — 删除重复项，保留唯一权威声明 export JAVA_OPTS="$JAVA_OPTS -Dfile.encoding=UTF-8" export CATALINA_OPTS="$CATALINA_OPTS -Djavax.servlet.request.encoding=UTF-8"
-
系统级加固（CentOS 7）
# 永久生效（写入 /etc/profile.d/tomcat-utf8.sh） export LC_ALL=en_US.UTF-8 export LANG=en_US.UTF-8 # 验证：locale | grep -E "LANG|LC_ALL"
⚠️ 注意事项：
- ❌ 避免在 catalina.sh 中混用 JAVA_OPTS 与 CATALINA_OPTS 设置同一属性（如 -Dfile.encoding），以 JAVA_OPTS 为准，重复设置可能导致 JVM 参数解析异常；
- ❌ 不要依赖 new File(path).getAbsolutePath() 处理日文路径——升级后应改用 Paths.get(path) + Files.exists() 进行 NIO2 安全校验；
- ✅ 升级后务必测试真实路径场景：
Path jpPath = Paths.get("/opt/app/データベース/顧客一覧.csv"); if (Files.exists(jpPath)) { System.out.println("✅ 日文路径识别成功: " + jpPath); }
总结：该问题本质是 Tomcat 7 早期版本对 Java NIO 文件系统与本地文件系统编码桥接的实现缺陷。任何绕过升级的“配置补丁”（如 URL 二次编码、Base64 路径映射）均治标不治本，且增加维护复杂度。升级 Tomcat 是唯一符合生产环境稳定性、安全性和可维护性要求的方案。
