绝大多数情况不是“转换”问题，而是原始字节仍完整、但被错误解码；只要未出现问号或菱形替换符，就大概率能无损恢复——关键在不覆盖、不重编码、只重解释，即用编辑器强制以UTF-8重新打开、删BOM、确保<meta charset="UTF-8">位于<head>最开头且无前置字符，并核对服务端Content-Type响应头是否为utf-8。
老旧 HTML 页面中文乱码，**绝大多数情况不是“转换”问题，而是原始字节仍完整、但被错误解码了一次或多次**。只要没出现问号（?）或菱形替换符（），就大概率能无损恢复——关键在“不覆盖、不重编码、只重解释”。
确认乱码类型：先看是不是 UTF-8 被当 GBK 读了
打开文件，如果看到类似 ä¸æ–‡、é½¢ 这种拉丁字母组合，基本可断定：原始是 UTF-8 编码，但被编辑器/浏览器按 GBK、ISO-8859-1 或 Windows-1252 等单字节编码打开了。
- 这是最常见、最容易无损修复的情形
- 不要用“转码工具”反复点击“UTF-8 → GBK → UTF-8”，那只会让字节进一步错乱
- 正确做法是：用支持手动指定编码的编辑器（如 VS Code、Sublime Text），强制以 UTF-8 重新打开该文件
- VS Code 中：右下角状态栏点击当前编码（如
GBK），选Reopen with Encoding→UTF-8
检查文件是否带 BOM 且位置错误
UTF-8 with BOM 文件开头有 3 字节 EF BB BF，它会干扰 <meta charset="UTF-8"> 的识别——因为浏览器只扫描前 1024 字节找 charset，而 BOM 后若紧跟着空格、注释或换行，<meta> 就可能被跳过，最终 fallback 到系统默认编码（如 Windows 上的 GBK）。
- 用命令验证：Linux/macOS 执行
head -c 4 index.html | xxd，输出含ef bb bf即带 BOM - Windows PowerShell 执行
Get-Content index.html -Encoding Byte | Select -First 3，结果为239 187 191即带 BOM - 若带 BOM，且
<meta charset="UTF-8">不在<head>最开头（前面有空行、注释或 BOM 后多余字符），就删掉 BOM 并确保<meta>是<head>内第一个非空白标签 - VS Code 中保存时选
Save with Encoding→UTF-8（不带 BOM），而非UTF-8 with BOM
修复 <meta charset> 位置与写法
<meta charset="UTF-8"> 必须出现在 <head> 内前 1024 字节，且不能被任何内容（包括空格、注释、BOM）阻隔，否则无效。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 错误写法：
<meta charset="utf8">（缺连字符）、<meta charset="UTF8">（大小写不标准）、<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">（HTML5 已不推荐） - 正确写法（且必须顶格、无前置空格）：
<meta charset="UTF-8">，紧跟<head>开始 - 检查顺序：DOCTYPE 第一行 →
<html lang="zh-CN">→<head>→<meta charset="UTF-8">→ 其他 - 如果页面里已有
<meta http-equiv="Content-Type">，建议删掉，避免和<meta charset>冲突
服务端响应头优先于 <meta>
通过 HTTP 访问时（http:// 或 https://），服务器返回的 Content-Type 响应头（如 text/html; charset=gbk）权重高于 HTML 内的 <meta> 标签。老旧页面常部署在未配置 charset 的 Nginx/Apache 上，默认发 iso-8859-1，直接覆盖所有 meta 设置。
- F12 打开 Network 面板，刷新页面，点 HTML 请求 → Headers → Response Headers → 查
Content-Type - Nginx 配置需加：
charset utf-8;（注意不是add_header，那是给已有头加字段） - Apache 需在
.htaccess或虚拟主机中加：AddDefaultCharset UTF-8 - Node.js/Express：在
res.send()前调用res.set("Content-Type", "text/html; charset=utf-8") - PHP：在任何输出前调用
header("Content-Type: text/html; charset=utf-8");，且确保 PHP 文件自身也存为 UTF-8（无 BOM）
真正难修复的，是那些已经保存过多次、中间被 GBK 编辑器覆盖写入、把原始 UTF-8 字节替换成问号的文件——此时字节已丢失，再怎么“转换”都只是在错误数据上徒劳拟合。所以第一步永远是：别动原文件，先用十六进制查看器确认开头几个字节是否还保留着可识别的中文 UTF-8 模式（如 e4 b8 ad 对应“中”）。
