Python 文件读写中的编码陷阱

Windows下open()读中文文件报UnicodeDecodeError的根源是默认编码为cp1252而非UTF-8，解决方法是显式指定encoding='utf-8'或更稳妥的'utf-8-sig'以处理BOM。

Windows 上用 open() 读中文文件报 UnicodeDecodeError

默认编码不匹配是 Windows 下最常踩的坑：open() 在 Windows 中默认用 cp1252（而非 utf-8）解码，而绝大多数中文文本文件是 UTF-8 编码。一旦文件含中文，就会抛出 UnicodeDecodeError: 'charmap' codec can't decode byte 0xXX。

解决方法很简单：显式指定 encoding='utf-8'。但要注意——不是所有“UTF-8 文件”都真正 BOM-free；若文件带 BOM（如记事本另存为“UTF-8”时默认加的），utf-8 能正常读，但 utf-8-sig 更稳妥（自动剥离 BOM）。

• 用 utf-8-sig 读取记事本保存的“UTF-8”文件，避免开头出现 \ufeff
• 写入时若需兼容旧系统（如某些 Windows 工具），可选 utf-8-sig，否则统一用 utf-8
• 不要依赖 locale.getpreferredencoding() 判断读取编码——它返回的是控制台编码，和文件无关

用 pandas.read_csv() 读 CSV 中文列名乱码

根本原因和 open() 一样：pandas 默认用系统 locale 编码（Windows 是 cp1252）解析文件，而非 UTF-8。即使文件本身是 UTF-8，列名、数据也会变乱码。

read_csv() 的 encoding 参数必须显式传入，且不能省略。常见错误是只设了 encoding='utf8' 却没处理 BOM，导致第一列名多出 。

• 优先试 encoding='utf-8-sig'，尤其当 CSV 来自 Excel 或记事本
• 若仍报错，用 chardet 库粗略探测：chardet.detect(open('x.csv', 'rb').read(10000))，但别全信结果
• 避免用 encoding=None 或留空——pandas 不会自动猜编码

跨平台脚本中 encoding 参数写死成 'utf-8' 安全吗？

安全，而且推荐。Python 3.6+ 中 open() 默认编码已是 utf-8，但仅限于 CPython 实现且未被环境变量覆盖时；实际工程中，显式写死 encoding='utf-8' 反而是最可控的做法。

真正危险的是“不写 encoding”，让 Python 去猜——它会查 locale.getpreferredencoding()，在 Linux/macOS 可能是 UTF-8，但在 Windows 很可能是 cp1252，导致同一份代码在不同机器上行为不一致。

• 所有文本文件读写操作，只要内容含非 ASCII 字符，就必须带 encoding 参数
• 写入时也需指定，否则 open('out.txt', 'w').write('中文') 在 Windows 可能静默失败或写乱码
• pathlib.Path.read_text() 和 .write_text() 同样需要 encoding，默认值不可靠

二进制模式读写时还用管 encoding 吗？

不用——但你要清楚自己在做什么。用 'rb' / 'wb' 打开文件，返回的是 bytes，绕过了所有编码解码环节。此时 encoding 参数无效，也不该传。

常见误用：先用 open(..., 'rb') 读出 bytes，再用 .decode() 手动转字符串，却忘了指定解码器，或用了错误编码（比如用 gbk 解 UTF-8 字

• 如果确定要手动 decode，务必明确原始字节来源的编码，例如 data.decode('utf-8')
• 用 codecs.open() 已过时，统一用内置 open() + encoding
• 日志、配置、用户输入等涉及文本 IO 的地方，最容易漏掉 encoding —— 这些恰恰是最该加的地方

编码问题从不报错到突然崩溃，往往只差一个特殊字符。最保险的做法不是“看情况加”，而是“凡文本 IO，必写 encoding”。