LC_ALL=C与Python UnicodeEncodeError的关联及编码原理咨询

咱们来把这事儿的逻辑理明白——很多人碰到这个问题都摸不着头脑，今天就拆解得明明白白。

先搞懂：LC_ALL=C到底干啥的？ #

LC_ALL=C说白了就是给Linux系统下了个强制命令：所有和区域设置（locale）相关的参数，全都改成最基础的C locale。这个C locale是Unix系统最原始的设置，只认ASCII字符集，连UTF-8都不支持，完全是为了兼容早期的极简系统设计的。

为啥会触发Python的UnicodeEncodeError？ #

看你给出的原始环境：

未设置LC_ALL时的系统locale：

$ unset LC_ALL
$ locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
...

你的系统默认用的是en_US.utf8，这个locale支持UTF-8编码，Python会自动继承系统的编码设置来处理标准输出（比如print语句）。但一旦设置LC_ALL=C，系统的默认编码就变成了ASCII——这时候如果你的Python代码要输出中文、emoji或者其他非ASCII的Unicode字符，ASCII编码器根本没法处理这些字符，直接就抛出UnicodeEncodeError了。

LC_ALL和Python编解码器的核心关联 #

• Python的标准I/O（print、sys.stdout等）不会直接用内部的UTF-8编码输出，它会调用locale.getpreferredencoding(False)来获取系统当前的编码，这个值完全由LC_ALL（或单个LC_*变量）决定
• 当LC_ALL=C时，这个返回值就是ASCII，而Python内部处理字符串用的是Unicode（默认UTF-8），把Unicode转成ASCII的时候，只要有非ASCII字符就会报错
• 你可以在Python里直接验证：执行import locale; print(locale.getpreferredencoding(False))，设置LC_ALL=C前后的输出完全不一样

LC_ALL=C和Unicode的本质矛盾 #

C locale是几十年前的产物，它的设计完全没考虑Unicode——它只支持ASCII字符集（0-127的字符），任何超出这个范围的Unicode字符，在C locale的环境下都会被视为“非法字符”。所以当你强制设置LC_ALL=C时，所有依赖locale的程序（包括Python）都会默认只能处理ASCII，碰到Unicode字符自然就没办法编码输出了。

内容的提问来源于stack exchange，提问作者caot