linux日志中文乱码的核心原因是字符编码不一致，需统一“写入、传输、显示”三环节为utf-8；应先用file或enca确认日志真实编码，再统一终端、locale及java应用（如tomcat）的编码设置。
Linux日志出现中文乱码，核心原因是字符编码不一致：日志文件本身用一种编码（如UTF-8），而查看工具、终端或系统环境用另一种编码（如GBK、GB18030或ISO-8859-1）去解析，结果就显示为方块、问号或乱码符号。解决的关键是让“写入”“传输”“显示”三个环节的编码统一为UTF-8（推荐）或至少匹配。
检查并确认日志文件真实编码
别急着改配置，先看清日志本来是什么编码：
- 用 Notepad++（Windows）打开日志文件，右下角直接显示当前编码，比如 ANSI（常对应 GBK）、UTF-8-BOM 或 UTF-8 无 BOM
- 在 Linux 终端中运行：
file -i 日志文件名或enca -L zh 日志文件名（需安装 enca），查看输出中的 charset= 字段 - 如果确认是 GBK/GB18030 编码，又希望长期用 UTF-8，可用
iconv -f GBK -t UTF-8 原文件 > 新文件转换（操作前务必备份）
统一终端与远程连接工具的编码设置
即使日志是 UTF-8，终端解码错了照样乱码：
- Xshell：【文件】→【属性】→【终端】→【编码】选 UTF-8；再进【外观】→【字体】确保用了支持中文的字体（如 NSimSun 或 DejaVu Sans Mono）
- SecureCRT：【Options】→【Session Options】→【Terminal】→【Appearance】→【Character Encoding】选 UTF-8
- Linux 本地终端（如 GNOME Terminal）：编辑 → 首选项 → 当前配置文件 → 字体/编码 → 设为 Unicode (UTF-8)
修正系统级 locale 和语言环境
避免全局乱码隐患，尤其影响日志生成程序（如 Tomcat、Log4j、rsyslog）：
- 执行
locale查看当前环境，重点看 LANG 和 LC_ALL 是否为zh_CN.UTF-8或en_US.UTF-8 - 若不是，临时生效：运行
export LANG=zh_CN.UTF-8；永久生效则追加到/etc/profile或用户~/.bashrc - 确保该 locale 已生成：运行
locale -a | grep "zh_CN.utf8"，没有就执行sudo locale-gen zh_CN.UTF-8（Ubuntu/Debian）或sudo localectl set-locale LANG=zh_CN.UTF-8（RHEL/CentOS）
针对 Java 应用（如 Tomcat）的日志编码专项处理
Tomcat 控制台日志乱码最常见，本质是 JVM 启动时未指定编码，导致依赖系统默认（Windows 常是 GBK，Linux 常是 UTF-8）：
- 修改
$CATALINA_HOME/bin/catalina.sh（Linux）或catalina.bat（Windows），在exec "$PRGDIR"/"$EXECUTABLE" start "$@"前添加：export JAVA_OPTS="$JAVA_OPTS -Dfile.encoding=UTF-8" - Tomcat 自身日志框架（java.util.logging）也需同步：编辑
$CATALINA_HOME/conf/logging.properties，将所有java.util.logging.ConsoleHandler.encoding = UTF-8（原可能是空或 UTF-8，但显式声明更稳妥） - 若用 Log4j2，检查
log4j2.xml中PatternLayout的charset属性是否设为UTF-8
