Python批量转码GBK转UTF-8脚本详解

本文深入解析了Python中批量处理GBK编码文件转UTF-8的实际痛点与可靠方案：当遇到UnicodeDecodeError报错时，本质是Windows环境下记事本、旧版Excel或国产软件生成的文本默认使用GBK系编码，而Python 3强制以UTF-8读取所致；文章摒弃依赖chardet误判、shutil字节拷贝、系统iconv命令等常见误区，强调“读用encoding='gbk'、写用encoding='utf-8'”这一核心原则，并通过pathlib实现安全批量转码——精准过滤文件类型、自动创建输出目录、跳过异常文件、避免覆盖原文件，全程仅用Python标准库，稳定、简洁、开箱即用，尤其适合处理中文环境下的日志、CSV和文本数据迁移任务。

遇到 UnicodeDecodeError 说明文件确实是 GBK 编码，但 Python 默认按 UTF-8 读取

Windows 上用记事本保存的文本、老版 Excel 导出的 CSV、某些国产软件日志，经常默认用 GBK（或 GB2312、GB18030）编码，而 Python 3 的 open() 默认走 utf-8。一读就报错：UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc4 in position 0: invalid continuation byte——这串乱码字节就是典型的 GBK 开头。

别急着改代码逻辑，先确认编码：用 chardet 或 file -i filename（Linux/macOS）粗略判断；更稳的是直接试 open(..., encoding='gbk') 能否成功读取。注意：gbk 在 Python 中兼容 GB2312 和大部分 GB18030 字符，够用。

• 不要依赖 chardet.detect() 对单个小文件的判断结果——它对短文本误判率高，尤其纯中文无标点时
• encoding='gb18030' 比 'gbk' 更宽泛，但部分旧系统生成的文件反而只认 'gbk'，建议优先试 'gbk'
• 如果文件里混了 UTF-8 BOM（如 \xef\xbb\xbf）又带 GBK 内容，会更麻烦——这种情况得先跳过 BOM 再按 GBK 解码，属于边缘场景，先不展开

用 pathlib + open() 批量转码最稳，不用第三方库

不用装 iconv 或 recode，Python 标准库完全够用。核心思路：读入时指定 encoding='gbk'，写入时指定 encoding='utf-8'，中间内容不做任何字符串处理（避免二次编码错误）。

关键点是路径遍历和文件过滤——别一股脑转所有文件，容易覆盖配置文件或二进制文件：

• 用 pathlib.Path('your_dir').rglob('*.txt') 比 os.walk 更简洁，支持通配符匹配
• 务必加后缀过滤，比如只转 *.txt、*.csv、*.log，避开 .py、.exe、.pdf 等
• 写入前用 try/except 包住读操作，跳过真正无法解码的文件（比如其实是图片），别让整个脚本中断
• 写入路径建议用新目录（如 output/），而不是覆盖原文件——调试阶段千万别 input == output

简短示例：

from pathlib import Path
for f in Path('data').rglob('*.txt'):
    try:
        content = f.read_text(encoding='gbk')
        (Path('output') / f.relative_to('data')).write_text(content, encoding='utf-8')
    except UnicodeDecodeError:
        print(f"跳过 {f}：无法按 GBK 解码")

shutil.copyfileobj() 不适用——它不处理文本编码转换

看到“批量”“文件”就想用 shutil？小心掉坑。shutil.copyfileobj() 是纯字节流拷贝，不碰编码。你传进去的是 GBK 字节，它原样写出去，还是 GBK，不是 UTF-8。

常见错误写法：

with open('in.txt', 'rb') as src:
    with open('out.txt', 'wb') as dst:
        shutil.copyfileobj(src, dst)  # ❌ 输出仍是 GBK 字节，不是 UTF-8 文本

必须经过字符串这一层：读成 str（解码），再写成 bytes（编码）。绕不开 encoding= 参数。

• 想提速？别用 shutil，改用 buffering=8192 控制 open() 的缓冲区大小，对大文件更有效
• 若文件超大（>500MB），考虑分块读取 read(65536) 再解码，但要注意 GBK 是变长编码，末尾可能截断一个双字节字符——得手动补全，复杂度陡增，一般情况不必要

Windows 下路径含中文时，subprocess 调 iconv 容易崩

有人想用系统命令偷懒：subprocess.run(['iconv', '-f', 'GBK', '-t', 'UTF-8', 'a.txt', '-o', 'b.txt'])。在 Linux/macOS 上可行，但在 Windows 上问题一堆：

• Windows 自带的 iconv 极少见，得额外装 GnuWin32 或 MSYS2，环境不统一
• PowerShell 或 cmd 对中文路径的参数解析不稳定，空格、括号、中文名都可能导致 FileNotFoundError
• iconv 错误输出是英文，但输入文件名是中文，报错信息里路径显示为乱码，排查困难
• 没法精细控制哪些文件跳过、哪些记录日志——全靠 shell 重定向，不灵活

真要用命令行，推荐 nkf（日本开发，Windows 支持好，对 GBK/UTF-8 转换稳定），但依然不如纯 Python 脚本可控。除非已有成熟 shell 流程，否则不值得引入额外依赖。

转码这事，核心就两步：读对、写对。其余都是围绕这两步防错和适配。最容易被忽略的是——没检查目标目录是否存在，Path('output').mkdir(parents=True, exist_ok=True) 这一行漏掉，脚本跑一半就停。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。