上周处理了一个挺典型的中间件现场问题客户反馈TongWeb集中管理平台上通过控制台上传的部署包和配置文件文件名在管理界面里变成了一串乱码服务器上实际落盘的文件名也是乱的。排到后面发现根子不在TongWeb本身而是集中管理进程在启动时压根没带上LANG环境变量JVM在Linux下拿不到正确的locale就用ASCII默认值去创建和读取文件名中文自然全废。这类问题在Tomcat、Resin等Java应用服务器上同样会出现排查思路完全通用。这篇文章就把整个定位过程和修复方案完整记录下来。从现象确认、JVM字符集机制、环境变量排查到脚本修复一步步说清楚中间会穿插一些我在实际处理中总结的判断技巧给正在跟中间件、Linux环境变量和Java编码问题较劲的同学做个参考。1. 现象确认先搞清是文件名乱码还是文件内容乱码乱码问题最怕一上来就猜。接到反馈说TongWeb集中管理乱码后我第一件事不是翻配置而是把乱码的具体位置和形态问清楚因为同样是乱码背后的原因路径完全不一样。1.1 三种乱码形态的判断方法我把现场反馈的现象分成了三类每一类都对应不同的检查方向乱码位置典型表现首要排查方向控制台Web页面上的文件名显示为鏂囦欢、测试或????JVM字符集、HTTP响应编码、前端页面编码服务器磁盘上的实际文件名ls看到乱码或问号LANG/locale、sun.jnu.encoding文件内容打开后乱码日志、配置内容不可读file.encoding、流读取编码、文件本身编码这次客户说的是上传的war包在管理列表里显示名字乱码同时他们自己登录服务器在部署目录下ls看到的文件名也是乱的。两个现象同时出现基本可以锁定是第二个方向服务器落盘时文件名就已经写坏了控制台显示的乱码只是把坏结果展示出来而已。1.2 排除Web页面编码的干扰集中管理控制台本身是B/S架构页面还有一层HTTP传输编码。所以我第一步先把服务端落盘的文件名拉出来看确认是源头就坏了还是传输/展示坏了。在TongWeb集中管理的部署目录执行ls -l /opt/tongweb/console/uploads/看到的结果是类似??????.war或者鏂囦欢.war这种。说明问题发生在文件创建环节而不是浏览器或HTTP层。这时候重点就转移到服务器环境和JVM启动参数上。注意如果服务器上文件名是正常的只有控制台界面乱码那方向就要切到Tomcat/TongWeb的URI编码配置和JSP页面编码上别混在一起排查。我见过有人拿着文件名乱码的结论去改了一堆server.xml的URIEncoding结果磁盘上文件名本来就是坏的白忙一场。2. 根因拆解LANG环境变量和JVM字符集到底什么关系确认是文件创建时乱码之后下一步是搞明白为什么LANG的缺失会导致Java写出乱码文件名。这中间有一个不太容易注意到的链路。2.1 Java的两个字符集属性file.encoding 和 sun.jnu.encodingJava在Linux下运行时有两个和编码强相关的系统属性file.encodingJVM内部处理字符串、读写文本文件时使用的默认字符集影响的是文件内容。sun.jnu.encodingJVM与操作系统交互时使用的字符集影响的是文件名的创建、读取和传递。这两个属性在JDK 8及更早版本里如果没有显式指定默认值都来源于操作系统的locale设置。而Linux的locale信息主要就是通过LANG、LC_ALL这类环境变量传递给进程的。2.2 JDK8的默认字符集取值链路TongWeb目前的常见部署环境以JDK 8为主。JDK 8在Linux下获取默认字符集的简化逻辑是启动时读取LANG、LC_ALL等环境变量。如果没有设置glibc会回退到C/POSIXlocale。JVM根据locale信息推断默认字符集最终落到ANSI_X3.4-1968也就是US-ASCII。这个值会同时赋给file.encoding和sun.jnu.encoding。也就是说当集中管理进程启动时LANG为空JVM会觉得自己活在纯ASCII世界里。这时候如果Java代码要创建一个中文文件名的文件sun.jnu.encoding是ASCII中文字符无法表示落盘的文件名就会变成问号或转义乱码序列。我用一个生活化的类比帮大家理解这就好比你在一个只说英语的窗口办事递上去一张写满中文的表格。对方不是不给你办而是他根本不认识这些字只能在回执上写。你看到的乱码就是那个。2.3 为什么手动启动正常集中管理启动就出问题这是整个问题里最容易让人困惑的一点客户说我自己在服务器上敲启动脚本就没事一用集中管理启动就乱码。原因在于当你在终端里手动执行启动脚本时Shell已经通过/etc/profile、~/.bashrc等登录脚本加载了用户环境里面通常有export LANGzh_CN.UTF-8。Java继承了这个环境变量一切正常。但集中管理平台启动被管理节点时通常是通过某种后台进程或远程执行通道触发的它没有走用户登录Shell的初始化流程。如果启动脚本本身没有显式export LANGJava进程拿到的环境里LANG就是空的locale 直接回退到POSIX。同一个脚本手动跑和后台跑结果不一样就是这个原因。2.4 补充JDK高版本的变化顺带说一句JDK 18引入了JEP 400把默认字符集改成了UTF-8不再依赖locale。所以如果你用的是JDK 18及以上这个问题理论上不会出现。但现实是很多生产环境的TongWeb还在JDK 8上跑而且即便在JDK 11、17上sun.jnu.encoding在部分场景下依然可能跟随locale变化。所以这个排查思路在相当长一段时间内还是有价值的。3. 完整排查链路从现象到LANG的定位过程这一节把当时的排查步骤完整还原一遍每一步都给出命令和判断依据方便你在类似问题上直接复用。3.1 第一步确认JVM实际拿到的字符集先用一个最小化Java程序直接打印JVM的默认字符集属性这是最直观的验证方式。我当时的做法是把下面这段代码放到服务器上编译执行import java.nio.charset.Charset; public class CharsetCheck { public static void main(String[] args) { System.out.println(defaultCharset Charset.defaultCharset()); System.out.println(file.encoding System.getProperty(file.encoding)); System.out.println(sun.jnu.encoding System.getProperty(sun.jnu.encoding)); } }编译和运行javac CharsetCheck.java java CharsetCheck如果你是在正常SSH终端里跑的大概率输出是defaultCharsetUTF-8 file.encodingUTF-8 sun.jnu.encodingUTF-8但这只能证明你手动跑Java没问题不能证明TongWeb集中管理进程没问题。不过它能帮你确认JDK本身没有被动过手脚比如某些项目会在JAVA_TOOL_OPTIONS里强行指定字符集。3.2 第二步找到集中管理进程检查实际环境变量这是整个排查的转折点。先找到TongWeb相关进程的PIDps -ef | grep tongweb然后查看这个进程的实际环境变量cat /proc/PID/environ | tr \0 \n | grep -E LANG|LC_/proc/PID/environ记录的是进程启动那一刻的环境变量快照这个是伪造不了的。执行后发现输出为空或者只有LC_CTYPE之类的零散项但没有LANG基本就坐实了问题方向。提示/proc/PID/environ里的环境变量之间是用\0分隔的直接cat会连成一行。用tr \0 \n转换一下才能看得清楚。这个细节很容易忽略我第一次查的时候就直接cat结果看到一堆字符挤在一起差点以为是乱码。3.3 第三步对比不同启动方式的环境差异为了确认是集中管理启动方式导致的问题我做了个对照实验在SSH终端里手动执行TongWeb的启动脚本找到新进程PID。查看新进程的/proc/PID/environ确认里面有LANGzh_CN.UTF-8。再通过集中管理平台启动一次按同样方式检查发现没有LANG。同样的服务器、同样的脚本、同样的JDK唯一区别就是启动方式。到这个程度根因已经基本锁定了。3.4 第四步定位集中管理调用的具体启动脚本TongWeb集中管理在后台启动节点时最终还是落到某个Shell脚本上。我进入安装目录的bin目录把脚本列表拉出来看ls -l /opt/tongweb/bin/常见的TongWeb脚本包括startConsole.sh启动集中管理控制台startservernohup.sh以nohup方式启动业务节点setenv.sh环境变量预加载脚本startserver.sh常规启动脚本逐个检查脚本内容确认脚本里有没有export LANG相关的配置。这个环节不能只看TongWeb自带的脚本还要留意有没有catalina.sh之类的Tomcat风格脚本——因为TongWeb本身是兼容Tomcat规范的不少部署习惯也沿用了Tomcat的脚本结构。3.5 排查小结到这一步判断链条已经完整了集中管理启动进程时没有加载用户Shell环境启动脚本也没有显式设置LANGJVM的sun.jnu.encoding回退到ASCII最终创建文件名时中文变成了乱码。问题定位不是靠猜而是每一步都有命令输出做支撑。4. 修复方案给TongWeb集中管理启动脚本补上LANG修补方案就一句话在TongWeb集中管理相关的启动脚本里显式导出LANG。补上之后无论什么方式启动JVM拿到的locale都是确定的。4.1 方案一修改启动脚本头部推荐以startservernohup.sh为例用vim编辑脚本在#!/bin/sh之后、执行逻辑之前加入export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8完整示例#!/bin/sh # TongWeb startup script export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8 # 原有启动逻辑...这里我建议同时设置LC_ALL而不是只设置LANG。原因是LC_ALL优先级最高设置它可以屏蔽掉其他LC_CTYPE、LC_MESSAGES等分类环境变量可能带来的干扰。生产中求的就是一个确定性。有一个细节必须提醒不要用Windows记事本编辑这个脚本。Windows下保存的文件换行符是\r\nLinux下的Shell解析到\r会在变量后面附带一个不可见字符导致export LANGzh_CN.UTF-8实际变成export LANGzh_CN.UTF-8\r脚本执行起来依然拿不到正确的值。我建议在Linux上用vim或者用sed直接在服务器上改sed -i 2i export LANGzh_CN.UTF-8\nexport LC_ALLzh_CN.UTF-8 /opt/tongweb/bin/startservernohup.sh4.2 方案二通过JVM参数强制指定字符集如果不想改环境变量还可以在setenv.sh或启动脚本的JAVA_OPTS里追加参数JAVA_OPTS$JAVA_OPTS -Dfile.encodingUTF-8 -Dsun.jnu.encodingUTF-8-Dfile.encodingUTF-8管文件内容-Dsun.jnu.encodingUTF-8管文件名创建和读取。两个都要加缺一个都可能留坑。这两种方案怎么选我的建议是优先级这么排优先改脚本导出LANG它更接近Linux生态的标准做法Linux下很多非Java程序比如tar解压、zip解压、日志轮转也同样依赖locale导出LANG能一并解决。其次用JVM参数适合不方便改脚本、或者一台机器上同时跑多个对默认字符集有不同要求的Java应用的场景。4.3 修改后的验证步骤改完脚本不是万事大吉必须重新启动并验证。我的验证序列是这样的停掉集中管理的被管理节点进程。通过集中管理平台重新启动该节点。找到新进程PID检查环境变量cat /proc/PID/environ | tr \0 \n | grep -E LANG|LC_确认能看到LANGzh_CN.UTF-8。再跑一次CharsetCheck确认JVM层面的输出defaultCharsetUTF-8 file.encodingUTF-8 sun.jnu.encodingUTF-8重新上传一个包含中文文件名的部署包在服务器ls确认落盘文件名正常再到控制台页面确认显示正常。4.4 已产生乱码文件的处理这个点容易踩坑。修复只保证以后创建的文件名正常已经写坏的文件名不会自动恢复。现场那批乱码文件我当时的处理方式是在服务器上写一个小脚本批量修正find /opt/tongweb/console/uploads/ -name *????* -o -name *鏂囦欢*找到目标文件后确认对应关系再用mv重命名回正确文件名。这部分一定要先确认原始文件名是什么别拿乱码名直接替换不然会把别的文件覆盖掉。如果集中管理平台的数据库里记录了原始上传文件名以数据库的记录为准去重命名是最靠谱的方式。额外的坑有些情况下文件名乱码不是发生在创建时而是发生在解压时——如果你上传的是一个war包war包内部的文件名乱码那是构建war包时的JDK字符集或压缩工具编码问题跟本次讨论的LANG是两条线。排查时记得区分上传动作创建的文件和解压动作释放的文件。5. 同类问题延伸Java中间件在Linux下的字符集隐患TongWeb集中管理的这个问题修完之后我又顺便检查了同一批服务器上其他Java应用发现类似隐患其实相当普遍。这里展开讲几个常见的变体帮大家提前排雷。5.1 Tomcat/Spring Boot外置部署的相同问题TongWeb的bin目录结构本身就兼容Tomcat风格很多基于Tomcat的Spring Boot应用如果用/etc/init.d/或systemd service方式启动同样可能不加载用户Shell环境。如果service文件里没有设置EnvironmentLANGzh_CN.UTF-8JVM的默认字符集一样会回退。用systemd管理的服务正确写法是在service文件里加[Service] EnvironmentLANGzh_CN.UTF-8 EnvironmentLC_ALLzh_CN.UTF-8改完执行systemctl daemon-reload systemctl restart your-service5.2 容器化部署Docker镜像里没有locale现在不少TongWeb和Tomcat跑在Docker里而很多精简镜像为了控制体积压根没装完整的中文locale。就算是官方镜像如果没有在Dockerfile里显式设置ENV容器启动时环境变量同样是空的。常见做法ENV LANGzh_CN.UTF-8 \ LC_ALLzh_CN.UTF-8或者安装locale并生成对应编码。我遇到过最隐蔽的情况是镜像里虽然有 locale但Java进程是docker-entrypoint.sh启动的而entrypoint脚本内部重新exec了某个子脚本导致env被覆盖。这种只能在容器里手动检查/proc/PID/environ才能发现。5.3 文件内容乱码和文件名乱码要分治最后强调一个容易混的点。文件名乱码和文件内容乱码看着都是乱码但处理方式完全不同文件名乱码优先检查sun.jnu.encoding、LANG、locale和脚本启动方式强相关。文件内容乱码优先检查file.encoding、Java代码里读写的Stream是否显式指定编码、文件本身的真实编码。比如同一个Linux服务器上可能出现文件名正常但文件内容乱码的情况那多半是file.encoding不对或者代码里new String(bytes)没指定Charset。也可能反过来文件内容正常但文件名乱码那就是sun.jnu.encoding的锅。这次TongWeb集中管理属于后者但JVM层面两个属性同时受LANG缺失影响所以内容也可能跟着乱——排查时不能只盯一个。6. 实战总结这个坑的预防措施和个人体会借这个机会把后续的预防实践也一并整理出来。我在这台服务器上做完修复后又做了一套组合措施确保同类问题不再复发。6.1 建立启动脚本环境变量的自检清单不管是TongWeb、Tomcat还是Spring Boot凡是要后台启动的Java服务在交付前都过一遍这个清单启动脚本里是否显式设置了LANG和LC_ALL如果用systemd管理service文件里是否配置了Environment如果用Docker镜像的ENV里是否有UTF-8相关设置关键Java进程启动后是否抽查过/proc/PID/environ是否用CharsetCheck这类小工具验证过JVM实际默认字符集这个清单看起来简单但我在实际项目中见过太多脚本手动跑没问题、一上调度平台就乱码的案例基本都是没做第4和第5项检查。6.2 建议写进应用启动脚本的固定片段我现在的习惯是每个Java服务启动脚本都放这么一段当成模板用# 统一设置UTF-8环境避免locale缺失导致文件名/内容乱码 if [ -z $LANG ]; then export LANGzh_CN.UTF-8 fi if [ -z $LC_ALL ]; then export LC_ALLzh_CN.UTF-8 fi注意不是无条件覆盖而是判断为空才设置——这样既能兜底又不影响上层调度系统通过环境变量传入的其他语言偏好。在集中管理平台、任务调度平台这类后台启动场景下这个空则默认的思路能省掉很多沟通成本。6.3 最后的体会回头复盘这个TongWeb集中管理的乱码问题它本身的修复不算复杂真正有价值的反而是定位过程里那条环境变量-进程-JVM字符集的链路。很多人遇到乱码第一反应是改代码、调页面编码却忘了去确认Java进程到底是以什么字符集视角看待这个操作系统。/proc/PID/environ、sun.jnu.encoding、file.encoding这几个关键词如果在一开始排查时就能想到整个定位时间可以缩短一半以上。中间件产品本身的版本差异、部署形态差异都会变但JVM和Linux环境变量这套底层交互逻辑是稳定的把这条链路摸透无论换哪个Java应用服务器你都有一把通用的钥匙。