乱码源于解码方式错误而非文件本身，需统一编码链路：确认源编码→用iconv或PHP函数转换→保存为GBK→写入<meta charset="GBK">→修正服务器响应头。
确认原始HTML文件当前编码
乱码不是凭空出现的，而是读取时用了错误的解码方式。先别急着转，用文本编辑器（如 VS Code、Notepad++）打开文件，看右下角显示的编码是什么。常见情况有：UTF-8（带或不带 BOM）、GBK、GB2312、ISO-8859-1。如果显示是 UTF-8 却呈现乱码，说明浏览器或服务端实际按 GBK 解码了——这时真正要做的不是“改成 GBK”，而是统一解码逻辑。
用 iconv 命令行批量转成 GBK（Linux/macOS/WSL）
确定源文件确实是 UTF-8 编码，且你明确需要输出为 GBK（比如对接老系统、某些国产浏览器或内网设备），可用 iconv：
iconv -f UTF-8 -t GBK input.html > output.html
注意几点：
-
-f指定源编码，必须准确；误写成UTF-8但实际是GB2312，结果会崩出一堆 -
-t GBK输出不带 BOM；若目标环境要求 BOM（极少见），得额外处理 - 含中文标点（如「」、『』、…、—）的 UTF-8 文件转 GBK 后可能丢失或替换成问号，因为部分 Unicode 字符在 GBK 中无对应码位
- 转换后务必检查
<meta charset="GBK">是否已写入<head>，否则浏览器仍可能按默认 UTF-8 解析
PHP 中用 iconv() 或 mb_convert_encoding() 转换字符串
如果是动态生成 HTML 内容（比如从数据库读出 UTF-8 数据，再输出给只认 GBK 的客户端），不能只改文件，得在代码层转换：
立即学习“前端免费学习笔记（深入）”；
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
$utf8_html = file_get_contents('page.html');<br>$gbk_html = iconv('UTF-8', 'GBK//IGNORE', $utf8_html);
//IGNORE 很关键：遇到无法映射的字符直接跳过，避免 iconv() 报错中断；也可用 //TRANSLIT 尝试音近替换（如 “é” → “e”），但对中文无效。
更稳妥的替代是 mb_convert_encoding()：
$gbk_html = mb_convert_encoding($utf8_html, 'GBK', 'UTF-8');
它对多字节字符更友好，且不依赖系统 iconv 库是否启用。
为什么改完还是乱码？重点检查这三处
编码转换只是链条一环，以下任一环节错位都会让前面白干：
- HTML 文件保存时没选
GBK编码：VS Code 保存时要点「文件 → 另存为 → 选择编码 → GBK」，不能只靠转换命令输出却用 UTF-8 保存 -
<meta charset="GBK">没加，或加在了<body>里——它必须在<head>中且越靠前越好 - Web 服务器返回了
Content-Type: text/html; charset=utf-8响应头：Apache 需删掉AddDefaultCharset，Nginx 要确保没配charset utf-8;，否则浏览器优先信响应头，无视<meta>
真正难处理的不是转换动作本身，而是整个链路中编码声明、存储、传输、渲染四者必须严格一致；其中任意一个环节偷偷用了 UTF-8，GBK 就会当场失效。
