在使用Ubuntu的过程中，无论是服务器还是桌面环境，你都可能遇到过类似 perl: warning: Setting locale failed 或者 locale not supported by C library 这样的报错。这类问题看似复杂，其实根源都在于系统的语言环境配置不完整。语言环境决定了程序如何显示文字、如何格式化日期数字、如何进行字符编码转换，一旦配置缺失，很多依赖它的软件就会出现警告甚至拒绝运行。
先弄清楚locale到底是什么
locale翻译过来叫语言环境或区域设置，它不仅仅是指界面显示什么语言，而是一整套规则的集合，包括字符编码、货币符号、日期格式、数字分隔符、排序规则等。在Linux系统中，locale由一组环境变量共同控制，比如LANG表示默认语言，LC_ALL表示强制覆盖所有分类设置，LC_CTYPE控制字符处理，LC_TIME控制时间格式等。
当程序启动时，C库会根据这些环境变量去查找系统中已经生成的locale数据。如果环境变量指向了一个系统中并不存在的locale，比如变量设置成了zh_CN.UTF-8，但系统从未生成过这个语言包，程序就会抛出locale not supported的警告。所以这个错误的本质是环境变量的声明与系统实际安装的语言包不匹配。
可以用下面的命令查看当前环境的locale设置以及系统中已生成的locale列表：
# 查看当前生效的locale配置 locale # 列出系统中所有已经生成的locale locale -a
如果locale命令的输出中出现无法用UTF-8编码显示的字符，或者locale -a的结果里找不到你需要的语言，比如zh_CN.utf8，就说明问题出在语言包未生成这一步，接下来就是补齐它。
生成并配置缺失的语言环境
Ubuntu提供了locale-gen工具来生成需要的语言包。以中文简体为例，执行以下命令即可：
# 生成中文简体和英文的语言包 sudo locale-gen zh_CN.UTF-8 sudo locale-gen en_US.UTF-8 # 刷新语言包列表 sudo update-locale
生成完成后，还需要把这些locale写入系统配置。Debian系的系统可以通过编辑/etc/default/locale文件来设置全局默认值，也可以使用update-locale命令一步完成：
# 设置系统默认语言为中文 sudo update-locale LANG=zh_CN.UTF-8 LC_ALL=zh_CN.UTF-8
如果你希望配置更细粒度的控制，也可以手动编辑配置文件。文件内容大致如下：
# /etc/default/locale 文件内容示例 LANG=zh_CN.UTF-8 LANGUAGE=zh_CN:zh LC_CTYPE=zh_CN.UTF-8 LC_NUMERIC=zh_CN.UTF-8 LC_TIME=zh_CN.UTF-8
修改完成后，重新登录或者执行source /etc/default/locale让配置生效。需要注意的是，LC_ALL是一个优先级非常高的变量，它会覆盖所有其他LC开头的设置，一般不建议长期在配置文件中固定它，临时排障时在命令行指定即可。
SSH远程登录场景的特殊处理
locale问题最常出现在SSH远程连接的场景中。本机是中文环境的Linux或macOS，通过SSH连接到一台刚装好的Ubuntu服务器时，客户端会把本机的LANG变量传递过去。如果服务器上没有生成对应的语言包，登录后执行任何命令都可能伴随一串警告信息。
排查思路是先确认警告是出现在登录时还是执行命令时。如果是登录时就报错，基本可以断定是SSH的 AcceptEnv 和 SendEnv 机制把客户端的locale变量传到了服务器。有两种解决方式：一是在服务器上直接生成客户端传过来的那个locale，二是禁止变量传递。
# 方式一：在服务器上生成客户端传来的locale，比如zh_CN.UTF-8 sudo locale-gen zh_CN.UTF-8 # 方式二：编辑服务器上的 /etc/ssh/sshd_config # 注释掉或删除 AcceptEnv LANG LC_* 这一行，然后重启sshd sudo vi /etc/ssh/sshd_config sudo systemctl restart sshd
对于Windows用户使用PuTTY等工具连接服务器的情况，还要注意终端本身的字符编码设置要与服务器locale一致。比如服务器设置为zh_CN.UTF-8，PuTTY的Translation选项中就应该选择UTF-8，否则即使locale配置正确，终端显示的中文依然会是乱码。乱码和locale报错是两个不同的问题，前者是编码显示不一致，后者是语言包缺失，排查时不要混淆。
程序运行时仍报错的进阶排查
如果按照上面的方法配置之后，个别程序仍然提示locale not supported，可以从几个方向继续排查。首先检查环境变量的实际生效值，有些程序会在自己的启动脚本中覆盖LANG变量，比如某些通过crontab定时执行的任务，其环境变量非常精简，可能根本没有LANG设置，导致程序回退到一个不存在的默认值。
# 在crontab任务中显式声明locale LANG=zh_CN.UTF-8 0 2 * * * /home/user/scripts/backup.sh
其次，容器环境也是重灾区。Docker镜像为了减小体积，通常只保留最基础的语言数据，进入容器后执行perl或某些Python程序时经常报locale警告。解决办法是在Dockerfile构建阶段就完成语言包的生成：
FROM ubuntu:22.04
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y locales \\
&& locale-gen zh_CN.UTF-8 en_US.UTF-8 \\
&& update-locale LANG=zh_CN.UTF-8
ENV LANG=zh_CN.UTF-8 \\
LC_ALL=zh_CN.UTF-8
还有一种情况是系统升级后locale数据损坏，比如中断了语言包的安装过程。这时可以重新配置locales软件包，交互式界面中勾选需要的locale即可：
sudo dpkg-reconfigure locales
执行过程中会列出所有支持的语言，用空格键选中需要的项，确定后系统会重新生成所有选中的locale数据。这个方法几乎能解决所有语言包层面的问题，属于终极修复手段。
总的来说，locale not supported并不算疑难杂症，核心就是保持环境变量声明与系统已生成的语言包一致。遇到问题时按照查看locale -a、生成缺失语言包、更新默认配置、检查SSH传递和容器环境这个顺序逐一排查，基本都能在几分钟内定位并解决。配置好之后建议重启终端会话验证locale命令输出无报错，再继续后续的工作。
Ubuntu localelocale not supported系统语言配置修改时间：2026-09-16 18:49:29