Python批量转换GBK到UTF-8教程

本文详解了如何用纯Python标准库（无需额外安装工具）安全高效地批量将GBK编码的文本文件（如Windows记事本、老版Excel导出CSV、国产软件日志等）转为UTF-8，直击开发中高频报错“UnicodeDecodeError”的根源——并非代码逻辑问题，而是编码不匹配；强调优先尝试`encoding='gbk'`而非依赖不可靠的`chardet`，通过`pathlib`精准过滤文件类型、隔离输出目录、捕获异常避免中断，并彻底厘清常见误区（如误用`shutil.copyfileobj`做字节拷贝、滥用系统`iconv`在Windows下的兼容性陷阱），手把手给出简洁稳健的实战方案，让转码真正“读对、写对、防错、可控”。

遇到 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学习网公众号。