Linux locale 配置为什么让脚本输出乱码：LANG、LC_ALL 与服务环境核验

不少运维和开发都碰到过这类场景：同一段脚本在SSH终端里跑输出完全正常，换成systemd服务托管后跑出来就乱码了，最常见的原因根本不是脚本源码突然出问题，而是两次启动进程拿到的locale环境不一样。交互式Shell往往会继承登录环节加载的用户自定义配置，systemd服务则只会读取unit文件和管理器明确提供的环境变量，大部分本地化配置不会自动同步到服务进程里。

先比较终端与服务实际看到的 LANG、LC_ALL、LC_CTYPE 和 locale charmap，再决定是修 unit 环境、补生成 locale，还是处理应用自己的输入输出编码。

先确认乱码发生在哪一层

“中文变成问号”并不等于 Linux locale 配置有问题。终端渲染字体、脚本输出的原始字节、日志查看器的解码规则和数据库连接的字符集设置，整条链路任意一环异常都可能触发乱码。排查时先把同一条命令分别放到两个环境里执行，别刚看到现象就直接动手改全局配置。

printf 'LANG=%s\nLC_ALL=%s\nLC_CTYPE=%s\n' "$LANG" "$LC_ALL" "$LC_CTYPE"
locale
locale charmap

如果终端输出的是 UTF-8，而服务日志显示 ANSI_X3.4-1968、POSIX 或空值，问题已经缩小到服务启动环境。若两边都是 UTF-8，再去看脚本是否把 UTF-8 字节按其他编码解码，或者日志查看端是否替换了字体。

为什么登录 Shell 正常，systemd 却不正常

登录 Shell 通常会读取用户级或系统级 profile 文件，里面可能设置了 LANG。systemd 启动服务时不会把某个用户登录会话里的变量完整搬过来；服务进程看到的环境要以 unit 配置和管理器环境为准。

你可以先查看unit的最终合并配置，再核对systemd确认会传给当前服务的环境变量列表：

systemctl cat report-worker.service
systemctl show report-worker.service --property=Environment
systemctl show-environment

这三条命令回答的是不同问题：systemctl cat 展示配置来源，systemctl show ... Environment 展示服务属性，systemctl show-environment 展示管理器环境。不要只看当前终端里的 echo $LANG，那只能证明当前 Shell 的状态。

用一组最小证据判断修复方向

把诊断命令写入一次性临时unit或者服务自带的调试入口，完整记录变量名和对应取值，不要只笼统留下“输出乱码”这类无效描述。举个例子，可以先在目标服务旁边准备一个完全不会修改业务数据的检查脚本：

#!/bin/sh
set -eu
printf 'LANG=%s\n' "${LANG-}"
printf 'LC_ALL=%s\n' "${LC_ALL-}"
printf 'LC_CTYPE=%s\n' "${LC_CTYPE-}"
locale charmap

若 locale charmap 报“Cannot set LC_CTYPE”或类似错误，说明变量指向的 locale 在机器上未生成，单纯在 unit 里填写变量并不能解决问题。若 charmap 已经是 UTF-8，且服务日志仍乱码，就应检查应用读取文件、写日志或连接数据库时的编码约定。

在 unit 中做可回滚的修复

确认系统里已经存在可用的UTF-8 locale之后，可以直接在服务的drop-in配置里明确声明字符集相关环境变量，尽可能减少对全局系统配置的影响：

sudo systemctl edit report-worker.service

在编辑器中写入对应配置内容：

[Service]
Environment="LANG=C.UTF-8"
Environment="LC_CTYPE=C.UTF-8"

不同发行版可用的名称可能是 C.UTF-8、en_US.UTF-8 或其他已生成的 locale。先用 locale -a 查实际名称，不要照抄一个系统不存在的值。这里没有直接设置 LC_ALL，是为了避免把数字、时间、排序等其他 locale 分类一起强制覆盖。

sudo systemctl daemon-reload
sudo systemctl restart report-worker.service
systemctl show report-worker.service --property=Environment
journalctl -u report-worker.service -n 80 --no-pager

如果你的服务是通过模板unit、容器入口或者自动化部署脚本生成的，手动加的drop-in配置很可能会在下一次发布流程里被覆盖。问题修复完成之后，记得把相关变更同步回真实的配置生成源，同时保留原drop-in的内容作为后续回滚的依据。

几个容易把问题带偏的判断

只改终端 profile

修改 ~/.bashrc 只会影响从该 Shell 启动的进程。服务由 systemd 拉起时，它可能完全不会读取这个文件。

把所有问题都归因于字体

字体通常影响终端“看起来像什么”，不会改变服务写入日志的字节。先看 locale charmap 和原始日志，再判断是否是显示端问题。

直接设置 LC_ALL

LC_ALL 的优先级最高，适合短时诊断，不适合作为没有边界的长期兜底。它可能让时间格式、排序规则或消息语言一起变化，业务脚本因此出现新的差异。

修改后的验收与回滚

验收环节至少要覆盖三个状态：服务进程实际拿到的环境变量值、日志里新生成的中文内容展示、服务重启之后配置的持久化效果。不要只验证一次手工执行成功就直接上线。

systemctl show report-worker.service --property=Environment
systemctl is-active report-worker.service
journalctl -u report-worker.service --since "5 minutes ago" --no-pager
locale -a | grep -i 'utf\|c\.utf'

如果服务启动失败或日志内容仍不对，先移除 drop-in 中新增的两行，重新执行 daemon-reload 和重启，再回到应用编码链路排查。保留修改前后的 systemctl cat、服务状态和日志片段，之后才能区分“locale 修好了但应用仍按错误编码处理”和“locale 根本没有进入服务”。

相关问题

LANG 和 LC_ALL 同时存在时看谁？

优先看 LC_ALL，它会覆盖其他 locale 分类变量；没有设置时，再按具体的 LC_* 变量和 LANG 判断。

为什么脚本输出问号，日志文件却能看到中文？

这类情况大概率是终端字体或者日志查看工具的显示问题，也有可能是脚本对标准输出和本地文件输出用了完全不同的处理路径。分别导出原始字节内容和查看端的展示结果再下判断就好。

修改 unit 后为什么没有效果？

常见原因是忘记 daemon-reload、改的是错误的模板实例，或服务实际由容器、定时器和另一份 unit 启动。用 systemctl cat 和 systemctl status 先确认真实服务名与配置来源。

把交互式终端和systemd服务当成两台完全独立的运行环境，按变量取值、字符集规则、应用层处理逻辑和日志查看渲染四层逐一核对，通常比反复调整shell全局配置更快定位根因。