Linux locale 与字符集统一实战：中文乱码七层链路排查，从 cron 到 MySQL 到 CSV 导出全流程

  1.  Home
  2. Text  
    3. Share to：

为什么中文站总会撞上编码问题

如果你的站点有中文内容，那么「乱码」几乎是一定会遇到的敌人。它出现的地方极其分散：上传的中文文件名变成问号、数据库里存进去的中文变成 ????、导出的 CSV 用 Excel 打开满屏乱码、crontab 定时任务生成的中文日志变成不可读的符号。这些问题往往各自为战，修好一个又在别处冒出来——根本原因是它们背后的 locale 和 字符集 没有被统一。

这篇文章把 Linux 服务器上中文编码问题的整条链路讲清楚：从 locale 是什么、UTF-8 和 GBK 的本质区别，到 shell、文件名、MySQL、定时任务、日志、导出文件的逐层排查与统一方案。目标不是修一个具体报错，而是让整台服务器的「编码基线」一次性对齐，从根上消灭乱码。

Locale 到底是什么

Locale 是一组环境变量，告诉程序「该用哪种语言、哪套字符编码、哪种日期/数字格式」。它不是一个变量，而是一族：用 locale 命令能看到全部。最关键的是以下三个：

  • LANG：默认语言环境，其他 LC_* 未设置时都用它兜底
  • LC_ALL：最高优先级，一旦设置就覆盖所有其他 LC_* 和 LANG，通常只用于临时调试
  • LC_CTYPE：决定「字符分类和编码」，也就是程序怎么理解多字节字符。中文乱码十有八九和它有关

其余如 LC_TIME（日期格式）、LC_NUMERIC（小数点/千分位）、LC_COLLATE（排序规则）各管一摊。查看当前设置：

locale
# 典型输出：
# LANG=C
# LC_CTYPE="C"
# ...
# 或
# LANG=en_US.UTF-8
# LC_ALL=

这里要特别注意 LANG=C（或 POSIX）：C locale 是纯 ASCII 的，它认为「一个字节就是一个字符」。当程序在 C locale 下处理 UTF-8 中文（一个汉字占 3 字节），就会把每个字节当成独立字符，于是出现「一个汉字变三个乱码符号」「按字符截断把汉字切成两半」这类经典问题。很多 Docker 容器默认就是 LANG=C，这是容器里中文乱码的头号原因。

UTF-8 与 GBK：不是「好不好」，是「用哪套」

中文世界两套编码并存：GBK（国标，一个汉字通常 2 字节）和 UTF-8（国际标准，一个汉字 3 字节）。

它们的核心差异在于：GBK 只覆盖中文及相关字符，是地区性编码；UTF-8 能表示全世界所有字符，是当今唯一正确的选择。一个纯 UTF-8 的站点，从 HTML 到数据库到文件系统都用 UTF-8，中文、emoji、日韩字符都能正常处理。而混用 GBK 和 UTF-8 的系统，必然在某个转换环节出错。

现实中的坑在于「历史遗留」：老项目的数据库可能是 GBK（或 MySQL 的 utf8——它其实是「最多 3 字节的残缺 UTF-8」，存不了 emoji，必须用 utf8mb4）；从 Windows 导出的文件可能是 GBK；某些老软件默认 GBK 输出。判断一个文件是什么编码，用 file 命令：

file -i 中文文件.txt
# text/plain; charset=utf-8
# 或 charset=iso-8859-1（往往意味着其实是 GBK 但没被识别）

# 更准确：用 iconv 试着转换，能转通则说明源编码对
iconv -f GBK -t UTF-8 老文件.txt -o 新文件.txt

iconv 是编码转换的主力工具。-f 指定源编码、-t 指定目标编码。当转换报 illegal input sequence，说明 -f 猜错了。加 //IGNORE 可以跳过无法转换的字符（会丢数据，慎用）。

检查系统是否装了 UTF-8 locale

即使你设了 LANG=zh_CN.UTF-8，如果系统根本没生成这个 locale，程序照样会回退到 C。先查有没有：

# 列出系统已生成的 locale
locale -a | grep -iE 'utf|zh'

# 如果没有 zh_CN.UTF-8 或 en_US.UTF-8，需要生成它
# Debian/Ubuntu：
locale-gen en_US.UTF-8
locale-gen zh_CN.UTF-8
update-locale LANG=en_US.UTF-8

# CentOS/RHEL：
localedef -i zh_CN -f UTF-8 zh_CN.UTF-8

实践建议：服务器的系统 locale 用 en_US.UTF-8 而不是 zh_CN.UTF-8。原因是 en_US.UTF-8 的编码部分（CTYPE）就是 UTF-8，中文能正常处理，但日期、报错信息保持英文，日志和命令行输出更通用、更好搜索、更没有时区歧义。中文显示交给具体应用（网站、数据库）去管，系统层保持英文 UTF-8 是最稳妥的基线。

永久设置 locale 的几个位置

改了 locale 却发现「重登又变回去了」，多半是没写对地方。常见的生效位置，按优先级从高到低：

  • /etc/default/locale（Ubuntu/Debian）：系统级默认，登录时由 PAM 读取
  • /etc/locale.conf（systemd 系）：systemd 服务读取
  • ~/.bashrc / ~/.profile：只对交互式 shell 生效，对 cron 和 systemd 服务无效
  • 服务单元里的 Environment=LANG=...：针对单个 systemd 服务

最容易被忽略的是：~/.bashrc 里设的 locale，crontab 任务根本看不到。因为 cron 不加载登录 shell 的配置文件。所以「手动跑正常、cron 跑乱码」的原因就在这里——cron 用的是极简环境，locale 往往是 C。修复方式在下一节。

场景一：中文文件名变问号或无法识别

上传一个 产品介绍.pdf，结果文件名变成 ???.pdf，通常是 FTP/SFTP 客户端和服务器的编码不一致，或者文件系统的文件名编码有问题。排查步骤：

# 看文件名的实际字节（-b 显示转义）
ls | cat -v
# 或
find . -name '*.pdf' -print0 | xargs -0 -n1 echo

# 用 stat 看名字，用 python 看真实字节
python3 -c "import os; print(os.listdir('.')[0].encode('utf-8'))"

如果是上传工具造成的，改用支持 UTF-8 的客户端，或直接 scp/rsync（它们保留原始字节）。如果文件名已经是错的字节，可以批量重命名：用一个临时脚本把「猜测为 GBK 的字节」重新按 UTF-8 解释。注意这种修复有风险，务必先备份文件名列表。

场景二：cron 定时任务里的中文乱码

cron 的环境极其干净，locale 常为 C，PATH 也只有 /usr/bin:/bin。如果定时脚本会处理或输出中文，必须在 crontab 顶部显式声明：

# crontab -e 顶部加这两行
LANG=en_US.UTF-8
LC_ALL=en_US.UTF-8
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# 然后才是任务
0 3 * * * /usr/local/bin/gen_report.sh >> /var/log/report.log 2>&1

或者在脚本内部第一行就 export LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8——推荐后者，因为脚本自包含、不依赖部署环境的 crontab 写法。另外脚本里如果调用 PHP/Python，它们会继承 shell 的 locale，所以 export 在脚本开头即可覆盖。

场景三：MySQL 存中文变问号

数据库是乱码的重灾区。三层都要对齐：连接层、表/列层、服务器层。先看现状：

SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';

关键要保证 character_set_client、character_set_connection、character_set_results 三者与表实际编码一致，理想情况全是 utf8mb4。建表和建库时显式指定：

CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE TABLE posts (
  id INT PRIMARY KEY,
  title VARCHAR(200)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

# 修改已存在的库/表（注意：不改已存数据的字节，只改解释方式）
ALTER DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE posts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

务必用 utf8mb4 而不是 MySQL 那个假的 utf8——MySQL 的 utf8 最多只支持 3 字节，存不了 emoji，也存不了部分生僻汉字，会直接报错或截断。PHP 连接时要在 DSN 里指定 charset=utf8mb4：

// PDO
$pdo = new PDO('mysql:host=localhost;dbname=mydb;charset=utf8mb4', $user, $pass);

// mysqli
$mysqli->set_charset('utf8mb4');

如果出现「存进去是问号」，往往是连接层 charset 没设，客户端把 UTF-8 字节按 latin1 发给服务器，服务器又存入 utf8mb4 列——字节已经损坏，无法通过改配置找回，只能重新导入。

场景四：导出 CSV 用 Excel 打开乱码

网站后台导出的 UTF-8 CSV，用 Excel 双击打开常是乱码——因为 Excel（尤其 Windows 版）默认按本地 ANSI/GBK 解释，不认 UTF-8。解决方案是输出 UTF-8 BOM：在文件开头写 3 个字节 EF BB BF，Excel 见到 BOM 就知道这是 UTF-8：

# PHP：先输出 BOM
echo "\xEF\xBB\xBF";
// 然后再输出 CSV 内容

# 命令行给已有文件加 BOM
printf '\xEF\xBB\xBF' | cat - data.csv > data_bom.csv

# 用 iconv 顺便加 BOM
iconv -f UTF-8 -t UTF-8 data.csv | sed '1s/^/\xEF\xBB\xBF/' > data_bom.csv

注意 BOM 只该出现在给 Excel 用的导出文件里，不该出现在网页、JSON API、或要再被程序读取的 CSV 里——BOM 会污染数据的第一个字段。网页层面则用 HTML meta 声明编码，且 HTTP 头的 Content-Type 优先级更高：

<meta charset="utf-8">

（真实 HTML 里写 <meta charset="utf-8">，注意别把尖括号也转义了。）

场景五：命令行工具处理中文的截断与排序

在 C locale 下用 cut、substr、awk 处理中文，会把汉字按字节切开，产生半个字符的乱码。确保 LANG 是 UTF-8 后，gawk 才能正确处理多字节。同样，sort 中文的排序结果也依赖 locale：C locale 按字节码排（非拼音顺序），zh_CN.UTF-8 才可能按拼音。做中文排序时要意识到这个差异。用 wc -m（字符数）而不是 wc -c（字节数）来统计中文字数，两者在中文上差异巨大。

统一编码基线的检查清单

把下面几条一次性对齐，中文乱码问题就能从根上大幅减少：

  • 系统 locale：/etc/default/locale 设 LANG=en_US.UTF-8，并确认 locale -a 里存在
  • cron/systemd 任务：脚本开头 export LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8，不依赖交互 shell
  • MySQL：库、表、连接全程 utf8mb4，绝不用假的 utf8
  • PHP：DSN/set_charset 显式 utf8mb4；导出 CSV 加 UTF-8 BOM
  • Web：HTML meta charset + 服务器 Content-Type: text/html; charset=utf-8
  • 文件传输：用 scp/rsync 保留原始字节，避免 FTP 客户端的隐式转换
  • 命令工具：确认用 gawk 而非 mawk，wc -m 统计字符数
  • 容器：Dockerfile 里 ENV LANG=C.UTF-8，别让容器停在 LANG=C

编码问题之所以难缠，是因为它是「链路问题」而非「点问题」——任何一环用了不同的编码，整条链就断。所以正确的做法不是见到乱码就救火，而是一开始就定好「全程 UTF-8、系统 en_US.UTF-8、数据库 utf8mb4、导出加 BOM」这条基线，然后每次新增组件时都问一句「它用的是不是 UTF-8」。基线统一了，乱码自然就少了。

Last modification：October 16th, 2026 at 09:27 pm
© 允许规范转载

相关文章

Leave a Comment