GBK文件需显式指定encoding='gbk'读取，否则因Python默认UTF-8解码而报UnicodeDecodeError；不确定时用'gb18030'更鲁棒，禁用errors='ignore'；批量处理应先用charset-normalizer检测编码，再流式转存为UTF-8。
GBK文件用open()直接读会报UnicodeDecodeError
Windows上老项目存的文本文件，十有八九是GBK编码，但Python默认按UTF-8解码。一读就崩，典型错误是'utf-8' codec can't decode byte 0xc1 in position 0。这不是文件坏了，是解码器没对上。
关键不是“怎么读”，而是“必须显式指定encoding='gbk'”。别信IDE自动检测——它常误判，尤其文件开头没BOM时。
-
open(path, 'r', encoding='gbk')是安全起点；UTF-8文件用这个会报错，所以得先确认编码（见下一条） - 如果不确定是GBK还是GB2312/GBK18030，用
encoding='gb18030'更鲁棒（它向下兼容GBK和GB2312） - 千万别用
errors='ignore'硬吞乱码——覆写后内容就永久损坏了
批量识别编码再转存，别硬猜
一个目录里混着GBK、UTF-8、甚至带BOM的文件？靠扩展名或文件名判断编码纯属碰运气。真实场景里，得用chardet或charset-normalizer实测前10KB字节。
推荐charset-normalizer（比chardet快且准）：
pip install charset-normalizer
立即学习“Python免费学习笔记（深入）”；
- 只检测不读全文件：
from charset_normalizer import from_path; r = from_path(file_path)[0]; r.confidence > 0.7 and r.charset == 'GBK' - 置信度低于0.7的文件，跳过或人工检查——强行转换风险远大于漏处理
- 检测完立刻用对应编码读取，再用
encoding='utf-8'写入，避免中间环节二次编码
pathlib遍历+open()覆写，注意换行符和BOM
用pathlib.Path找文件比os.walk清爽，但覆写时有两个隐形坑：Windows换行符\r\n会被open(..., 'w', encoding='utf-8')自动转成\n，以及UTF-8 BOM问题。
- 保持原换行风格：读取时用
newline=''，写入时用newline=orig_newline（需先用readline()探一次） - 不想加BOM？写入时用
encoding='utf-8-sig'会自动加，要纯UTF-8就坚持用encoding='utf-8' - 务必先写到临时文件，再
os.replace()原子替换——断电或崩溃时不会丢原文件
大文件别一次性read()，用iter()分块转
几百MB的日志文件，用read()直接加载进内存，Python进程可能被系统OOM Kill。得流式处理。
核心思路：按行或按固定大小块读取，解码→重新编码→写入。注意块边界不能切在GBK双字节中间。
- 安全块大小：用
4096或8192字节（避开单个GBK字符跨块） - 读块后，末尾字节若为
0x81–0xFE范围（GBK首字节特征），说明可能截断，多读1–2字节再回退 - 实际更省事：用
io.TextIOWrapper包装二进制流，让它自动处理编码边界——但得确保buffer参数传对
最麻烦的永远不是转换本身，而是确认哪些文件真需要转。比如配置文件里硬编码的GBK路径，转完UTF-8后程序反而打不开——这种依赖编码的逻辑，得同步改代码，光转文件没用。
