最稳方式是用python脚本批量转html等文本文件编码为utf-8，需结合chardet检测+gb18030兜底、二进制字节筛查、保留目录结构，并避免误伤非文本文件。
直接上结论：用 Python 脚本批量转 HTML 文件编码为 UTF-8 是最稳、最可控的方式，比手动改或依赖 GUI 工具更可靠，尤其当文件夹里混着 .html、.css、.js、.txt 等多种文本类型时。
关键不是“能不能转”，而是检测准不准、失败是否静默、非文本文件会不会被误伤——这几个点踩错一个，就可能批量毁掉资源文件。
为什么不能只靠编辑器“另存为 UTF-8”
Notepad++ 或 VS Code 点几下确实快，但有硬伤：
• 它们不会自动识别原始编码，你选错源编码（比如把 GBK 当成 ISO-8859-1），结果就是“越转越乱”；
• 不支持递归遍历子目录，上百个文件得手动开几十次；
• 无法跳过图片、字体、PDF 等二进制文件，强行用文本方式打开会损坏；
• 没有日志反馈，某个文件转失败了，你根本不知道。
chardet 检测不总是靠谱，得加 fallback
很多旧网页是 GBK 或 GB2312 编码，但 chardet.detect() 对短文本（比如只有几行 HTML 的片段）经常返回 None 或误判为 ascii。这时候必须设兜底：
• 优先用 chardet；
• 检测失败时，默认 fallback 到 gb18030（它向下兼容 GBK/GB2312）；
• 解码时加 errors="ignore"，避免因个别非法字节中断整个流程；
• 不要用 errors="replace"，它会把错字替成 ，后续没法还原。
区分文本和二进制文件不能只看扩展名
光靠后缀判断风险很高：
• 有些 .js 文件其实是压缩过的二进制 blob（比如 webpack 打包产物带 \x00）；
• 有些 .txt 名义上是文本，实际是 base64 编码的图片数据；
• 有些 .html 文件开头有 BOM（\xef\xbb\xbf），有些没有，但都是合法 UTF-8。
稳妥做法是：
• 白名单扩展名（如 (".html", ".css", ".js", ".txt")）作为第一筛；
• 对白名单内文件，读前 1024 字节，检查是否含 \x00 或其他典型二进制字节；
• 有则跳过转换，直接二进制复制；
• 没有再走编码检测 + 转 UTF-8 流程。
路径和目录结构容易被忽略
脚本里如果写死 os.path.join("output", filename)，所有文件都会扁平化到同一层，丢失原始层级。正确做法是：
• 用 os.path.relpath(src_path, SRC_DIR) 获取相对路径；
• 再拼到 DST_DIR 下，例如 output_utf8/sub/page.html；
• 写入前调用 os.makedirs(os.path.dirname(dst_path), exist_ok=True)，否则遇到深层嵌套会报错 FileNotFoundError。
实际执行时，最常出问题的是那个 fallback 编码和二进制误判——它们不会报错，但会导致部分文件转出来仍是乱码，或者图片打不开。建议第一次跑之前，先挑 3–5 个典型文件手动验证解码结果。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
