直接补必须置于开头第一行，前面不得有空格、换行、BOM或HTML注释；若文件开头为EF BB BF（UTF-8 BOM），须先删除BOM再补；若实际编码为GBK，则应先确认编码（如file -i或PowerShell查字节），再转码为UTF-8并统一设置meta，而非仅修改charset值。
老旧HTML源码里被注释或删了怎么办
直接补上 <meta charset="UTF-8">，但必须放在 开头第一行，前面不能有任何空格、换行、BOM 或 HTML 注释。老系统常把这行注释掉（如 <!-- <meta charset="UTF-8"> -->）或删掉，导致浏览器 fallback 到 ISO-8859-1 或 GBK。补之前先用 xxd index.html | head -n 1 看开头三字节：如果是 ef bb bf，说明有 UTF-8 BOM，得先删 BOM 再补 <meta charset="UTF-8">；否则补完可能仍失效。
文件实际编码是GBK却硬写UTF-8 meta怎么救
这种情况会直接显示方块或问号，不是“乱码”而是解码错位。别改 <meta>，先确认真实编码：file -i index.html（Linux/macOS）或 PowerShell 里 Get-Content index.html -Encoding Byte | Select -First 3。若确认是 GBK，就做两件事：
• 把 <meta charset="UTF-8"> 改成 <meta charset="GBK">（仅限临时兼容，不推荐长期用）
• 更稳妥的是用 iconv -f gbk -t utf-8 index.html > index_fixed.html 转码，再统一补 <meta charset="UTF-8">
• 注意：转码前确保原文件没混入 UTF-8 字节，否则 iconv 会报错或截断
HTML被压缩成一行且无缩进，如何安全美化而不破坏逻辑
老系统常把 HTML 压成单行（比如 <title>...</title>），直接用格式化工具可能出错。优先手动或脚本处理：
• 先用正则把关键闭合标签后加换行：sed 's/>/>\n/g' old.html > temp.html（适用于简单结构）
• 对含 JS/CSS 的复杂页，用 prettier --parser html，但必须加 --tab-width 2 和 --print-width 100 防止自动折行破坏内联脚本
• 绝对避开在 <script></script> 或 <style></style> 标签内加缩进——老 IE 会因换行误判 JS 字符串结束
• 检查是否含条件注释（如 <!--[if IE]>...<![endif]-->），这类结构不能拆行，否则 IE 解析失败
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
服务端返回 Content-Type 缺 charset，前端补 meta 有用吗
只在本地双击打开（file:// 协议）时有效；一旦走 HTTP（http:// 或 https://），浏览器优先信任响应头里的 Content-Type，哪怕它写的是 text/html; charset=gbk，<meta charset="UTF-8"> 也会被无视。验证方法：F12 → Network → 刷页面 → 点 HTML 请求 → Headers → 看 Response Headers 里的 Content-Type。修复必须从服务端入手：
• Apache：加 AddDefaultCharset UTF-8 到 .htaccess
• Nginx：在 server 或 location 块加 charset utf-8;
• Express：在 res.sendFile() 前调用 res.set('Content-Type', 'text/html; charset=utf-8')
• PHP：在任何输出前加 header('Content-Type: text/html; charset=utf-8');，且确保文件本身没 BOM（BOM 会导致 header 失效）
立即学习“前端免费学习笔记（深入）”；
