根本原因是文件实际编码未转换，仅修改meta标签无效；必须将文件另存为UTF-8（无BOM），并确保HTTP响应头未强制覆盖charset。
为什么 meta charset 批量替换后浏览器仍不认编码？
常见现象是：用 Sublime 的正则替换了所有 <meta charset="gb2312"> 为 <meta charset="utf-8">，但页面刷新后中文还是乱码。根本原因不是标签没改对，而是文件本身编码没变——HTML 标签只是“声明”，真正起作用的是文件磁盘上的字节编码。Sublime 默认保存时不会自动转码，改完标签后必须手动执行「File → Save with Encoding → UTF-8」，否则文件仍是 GBK/GB2312 字节流，charset="utf-8" 就成了谎言。
Sublime 正则匹配 meta charset 的安全写法
直接写 <meta charset=".*?"> 看似简单，但容易跨标签误匹配（比如注释里有类似字符串），也容易漏掉大小写或空格变体。稳妥做法是用更精确的模式：
-
<meta\s+charset\s*=\s*["']([^"']*)["']\s*\/?>—— 匹配带空格、自闭合、单双引号的任意组合 - 务必勾选
Match case和Regex，关闭Whole word - 替换为
<meta charset="utf-8">，不要多加空格或换行，避免破坏 HTML 结构 - 如果项目混用
http-equiv写法（如<meta http-equiv="Content-Type" content="text/html; charset=gb2312">），需另写一条正则：<meta\s+http-equiv\s*=\s*["']Content-Type["']\s+content\s*=\s*["'][^"']*charset=([^"']*)["']\s*\/?>，替换为<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
批量处理多个文件时，如何避免改错非 HTML 文件？
在 Sublime 的「Find in Files」里盲目勾选「Where」为 *.html,*.htm 仍可能误中 CSS/JS 里的字符串。更可靠的做法是：
- 先用侧边栏选中目标文件夹，右键 →
Find in Folder...，这样范围严格限定在你点中的目录内 - 在「Where」框里明确写路径，例如
./src/**/*.html（Sublime 支持 glob 语法） - 执行查找前，先点「Find」预览匹配结果，确认只有 HTML 文件被列出，再点「Replace All」
- 若项目有模板文件（如
.vue或.ejs），它们的<meta>也可能需要改，但需单独处理——因为这些文件通常用不同方式解析编码，不能和纯 HTML 一概而论
改完后必须验证的两个硬性检查点
仅靠肉眼确认 charset="utf-8" 出现了没用。真实生效要满足两个条件：
- 文件实际编码是 UTF-8 无 BOM：用 Sublime 右下角查看当前编码显示，如果不是
UTF-8，就点它 →Convert to UTF-8，再Save（注意是「Convert」不是「Reopen」） - HTTP 响应头未覆盖 HTML 声明：用浏览器 DevTools 的 Network 面板看响应头，确认没有
Content-Type: text/html; charset=gb2312这类服务端强设。如果有，改 HTML 标签毫无意义，得去服务器配置（如 Nginx 的charset utf-8;）
这两个点漏掉任何一个，都会让前面所有正则操作白费。尤其是第二点，开发时本地双击打开 HTML 文件没问题，一放到服务器就乱码，大概率是响应头在捣鬼。
