tomcat 7 早期版本存在对 utf-8 编码路径（如含日文字符的目录名）支持不完善的问题，即使配置了 `uriencoding="utf-8"` 和 `file.encoding=utf-8`，仍可能抛出 `filenotfoundexception`；升级至 tomcat 7.0.109+ 或 tomcat 9+ 可彻底解决该问题。
在实际企业级 Java Web 应用中，当文件系统路径包含非 ASCII 字符（例如日文、中文等 Unicode 字符）时，Tomcat 的底层 I/O 处理机制需严格依赖 JVM 字符编码设置与容器自身对 URI/路径解码逻辑的支持。尽管您已全面配置了：
-
（确保 URL 路径参数正确解码） - -Dfile.encoding=UTF-8（影响 new File("日本語フォルダ") 等 API 的字节→字符串转换）
- -Djavax.servlet.request.encoding=UTF-8（规范请求体编码）
- LC_ALL=en_US.UTF-8（保障操作系统层面 locale 支持）
但 Tomcat 7.0.108 及更早版本存在一个关键缺陷：其内部 org.apache.catalina.util.URLEncoder 和 org.apache.naming.resources.FileDirContext 在处理本地文件系统路径时，未对 java.io.File 构造过程中的路径字符串做统一 UTF-8 归一化，导致在 CentOS 7 等默认 locale 非 UTF-8 的环境中，File.exists()、File.listFiles() 等调用实际发送的是被错误截断或乱码的字节序列，最终触发 FileNotFoundException。
而 Docker 容器中能正常运行，往往是因为基础镜像（如 openjdk:8-jre-slim）默认设置了 LANG=C.UTF-8 或 LC_ALL=C.UTF-8，且 Tomcat 启动脚本继承了该环境；但宿主机上仅靠 export LC_ALL=en_US.UTF-8 临时设置，若未持久化至 ~/.bashrc 或系统级 /etc/locale.conf，或 Tomcat 以 service 方式启动未加载用户环境变量，该设置即失效。
✅ 根本解决方案是升级 Tomcat：
- ✅ 推荐升级至 Tomcat 9.x 或 10.x：完全重构了 I/O 和国际化路径处理逻辑，原生支持多语言文件系统路径。
- ✅ 最低兼容升级：Tomcat 7.0.109+（发布于 2020-10-13）：官方明确修复了 Bug 64548 —— “FileDirContext fails with non-ASCII directory names on Unix-like systems”。
示例升级操作（以 Tomcat 7.0.109 为例）：
# 停止当前 Tomcat sudo systemctl stop tomcat7 # 下载并解压新版（注意替换为实际镜像源） wget https://archive.apache.org/dist/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109.tar.gz tar -xzf apache-tomcat-7.0.109.tar.gz -C /opt/ sudo ln -sf /opt/apache-tomcat-7.0.109 /opt/tomcat # 复用原有配置（server.xml、webapps、conf/ 目录等），无需重配 URIEncoding 等项 sudo cp -r /var/lib/tomcat7/conf/* /opt/tomcat/conf/ sudo cp -r /var/lib/tomcat7/webapps/* /opt/tomcat/webapps/ # 启动验证 /opt/tomcat/bin/startup.sh
⚠️ 注意事项：
- 升级前务必备份 conf/、webapps/ 和自定义 JAR；
- Tomcat 7.0.109 仍基于 Servlet 3.0，与原有应用二进制兼容，无需修改代码；
- 若使用 systemd 管理服务，需更新 tomcat.service 中的 ExecStart 路径；
- 验证方式：部署一个简单 Servlet，调用 new File("/path/to/日本語フォルダ").exists() 并输出结果。
总结：路径编码问题表象是配置缺失，实则是 Tomcat 版本能力边界所致。与其在旧版中反复调试环境变量组合，不如通过一次可控升级，获得稳定、标准、可维护的多语言路径支持。
