URIEncoding="UTF-8"必须显式配置在server.xml的每个Connector标签内，否则Tomcat默认用ISO-8859-1解码URL路径导致中文路径404；该设置与环境变量、日志编码、JVM文件编码无关，且需配合系统locale为UTF-8及浏览器发送UTF-8编码URL方可生效。
server.xml 中 Connector 的 URIEncoding 必须显式设置
即使你已正确配置 CATALINA_HOME 和 PATH，Tomcat 仍默认用 ISO-8859-1 解码 URL 路径，导致中文路径返回 404。这不是环境变量问题，而是 HTTP 连接器的编码行为未对齐。
打开 $CATALINA_HOME/conf/server.xml，定位到 <Connector> 标签（通常在 port="8080" 处），确认其中包含：
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
URIEncoding="UTF-8" />
-
URIEncoding="UTF-8"必须写在<Connector>标签内，不能放在注释里或标签外 - Tomcat 8+ 虽默认尝试 UTF-8，但仅当未显式声明时才 fallback；生产环境务必显式写出，避免版本差异或容器启动参数干扰
- 如果存在多个
<Connector>（如 HTTPS 或 AJP），每个都需要单独加URIEncoding="UTF-8"
Linux 系统 locale 不匹配会导致中文路径失效
Windows 下改完 server.xml 常能立刻生效，但 Linux 下常被忽略：Tomcat 进程继承系统 locale，若 LANG 不是 UTF-8，文件系统层可能无法正确定位含中文的路径。
执行 locale 查看当前设置，关键字段应类似：
LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8
- 若输出中
LANG是zh_CN.GB18030或空值，需临时测试：export LANG=en_US.UTF-8，再启动 Tomcat - 永久生效请修改
/etc/sysconfig/i18n（CentOS/RHEL）或/etc/default/locale（Ubuntu/Debian），确保LANG="en_US.UTF-8"或LANG="zh_CN.UTF-8" - 不要只改用户级
~/.bashrc，Tomcat 作为服务运行时通常不读取用户 shell 配置
logging.properties 和 catalina.bat 的编码设置影响日志可读性，但不解决 404
很多人误以为改了控制台乱码就能解决路径问题，其实这是两个独立层面：
-
logging.properties中的java.util.logging.ConsoleHandler.encoding只控制日志输出字符集，设为GBK或UTF-8影响的是错误信息是否显示成方块，不影响请求路由 -
catalina.bat（Windows）或catalina.sh（Linux）中添加JAVA_OPTS="-Dfile.encoding=UTF-8"主要影响 Java 字符串操作和文件读写，默认不干预 URL 解码逻辑 - 这两项改错不会导致 404，但会掩盖真实错误——比如你看到一堆 ，就可能错过 “No such file or directory” 这类关键提示
浏览器地址栏输入中文路径时，需确认实际发送的编码
现代浏览器（Chrome/Firefox/Edge）对地址栏中文会自动做 UTF-8 编码再发送，但某些旧版 IE 或嵌入式 WebView 可能用系统默认编码（如 GBK），此时即使 Tomcat 设了 URIEncoding="UTF-8" 也解不出原始路径。
- 用浏览器开发者工具的 Network 面板查看 Request URL，确认实际发送的是
%E4%B8%AD%E6%96%87.jsp（UTF-8）还是%D6%D0%CE%C4.jsp（GBK） - 若发现是 GBK 编码，说明前端环境不可控，此时必须在代码层兜底：用
new String(request.getRequestURI().getBytes("ISO-8859-1"), "GBK")手动还原（仅限无法统一前端的情况） - 更稳妥的做法是避免直接暴露中文路径，用英文别名 + 后端映射（如
/doc/123→ 实际读取/文档/说明.pdf）
