HTML文件中文乱码的根本原因是读取端用GBK等错误编码解码UTF-8字节流；修复需同时满足：文件为UTF-8编码（有无BOM均可）且内首行添加正确位置的。
导出的 HTML 文件中文乱码，**根本原因不是文件“坏了”，而是读取端用了错误编码去解码 UTF-8 字节流**。火狐、Chrome 导出的 bookmarks.html 本质都是 UTF-8（无 BOM），但记事本、Excel、旧版浏览器默认用 GBK 解析，结果把 `中` 的 UTF-8 字节 `E4 B8 AD` 当成三个 GBK 字符读，就变成 `ä¸` 或问号。
确认文件实际编码是不是 UTF-8
别猜，直接验证：用 VS Code 打开该 bookmarks.html → 看右下角状态栏显示的编码。如果是 UTF-8 或 UTF-8 with BOM，说明文件本身没问题；如果显示 GBK 或 Windows 1252，说明它已被错误转码过一次，得先找回原始文件或从源头重导出。
- 火狐导出的书签 HTML 永远是 UTF-8（无 BOM），不会自动切 GBK
- 用记事本打开后点“另存为”再选“UTF-8”，新版记事本实际保存的是 UTF-8 with BOM —— 这反而能骗过很多老软件
- 用
xxd -l 4 bookmarks.html（Linux/macOS）或Get-Content bookmarks.html -Encoding Byte | Select -First 4（PowerShell）检查头三字节：出现ef bb bf就是 BOM，否则就是无 BOM
修复方式：加 <meta charset="UTF-8"> 到
这是最通用、最可靠的修复动作。HTML 规范规定浏览器只扫描前 1024 字节找 charset 声明，所以这行必须紧贴 起始标签，前面不能有空格、注释或 BOM。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 用 VS Code 或 Notepad++ 打开文件，在
后直接换行插入：<meta charset="UTF-8"> - 不要写成
<meta charset="utf8">或<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">—— 前者不标准，后者在 HTML5 中已不推荐 - 确保这行在
<title></title>、<script></script>、任何注释之前；如果已有其他<meta>，把它挪到最顶上 - 保存后，用 Chrome/Firefox 直接双击打开，按
Ctrl+Shift+R强制刷新，再右键“查看页面信息”确认字符编码是否显示为 UTF-8
导入火狐前必须确保两个条件同时满足
火狐导入书签时既看文件字节流，也看 HTML 内部声明。只改编码或只加 meta 都可能失败。
立即学习“前端免费学习笔记（深入）”；
- 文件必须是 UTF-8 编码（带或不带 BOM 都可）
-
内必须存在且位置正确的<meta charset="UTF-8"> - 不要用记事本“另存为 UTF-8”后再手动删掉 BOM —— 容易误删关键字节，直接用 VS Code 保存为 UTF-8（无 BOM）更稳
- 导入路径：火狐中按
Ctrl+Shift+B→ 左侧“导入与备份” → “从 HTML 文件导入…” → 选修复后的文件
真正容易被忽略的是：**BOM 和 <meta charset> 在某些编辑器里会互相干扰**。比如 VS Code 默认给 Windows 用户加 BOM，而 BOM 出现在 <meta> 前面，会导致部分解析器跳过 meta 声明。所以优先保证 meta 位置绝对正确，BOM 可有可无，但绝不能让它挡在 meta 前面。
