必须先用file -i或PowerShell查文件真实编码，再通过VS Code“Reopen with Encoding”验证显示效果，确认无误后才可转存为UTF-8无BOM；meta charset声明无效时，根源在于文件实际字节编码与声明不符。
直接看文件真实编码，别信编辑器右下角显示的“UTF-8”——它只是 VS Code 的猜测，不是事实。乱码根源往往就藏在这一步误判里。
用 file -i 或 Get-Content -Encoding Byte 查真实字节
编辑器 UI 显示不可靠，必须查文件头原始字节：
- Linux/macOS 终端执行：
file -i yourfile.html，看输出中的charset=值。若为charset=gbk或charset=us-ascii（实为 GBK 检测失败），就说明不是 UTF-8 - Windows PowerShell 执行：
Get-Content yourfile.html -Encoding Byte | Select -First 3，检查前 3 字节是否为239 187 191（即十六进制ef bb bf）：有则是 UTF-8-BOM；无则继续比对 - 如果前 3 字节是
178 179 180类似值，大概率是 GBK 编码的汉字首字节（如“中”的 GBK 编码是d6 d0），此时file -i却可能报charset=unknown-8bit，需结合内容验证
在 VS Code 里用 “Reopen with Encoding” 验证显示效果
这是最贴近浏览器行为的验证方式：它不改文件，只尝试用指定编码打开并渲染中文。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 按
Ctrl+Shift+P→ 输入Reopen with Encoding→ 依次选GBK、GB2312、UTF-8 - 只要某次选完后中文突然清晰可读，就说明文件实际是那个编码——比如选
GBK后正常，那file -i就该显示charset=gbk或接近结果 - 注意：如果选
UTF-8正常，但file -i显示charset=us-ascii，大概率是文件含 BOM 且被误识别；此时再运行head -c 3 yourfile.html | xxd看是否真有ef bb bf
meta charset 写对了 ≠ 文件编码对了
很多人卡在这里：明明写了 <meta charset="UTF-8">，还是乱码。因为浏览器根本没机会读到它——文件本身不是 UTF-8，解析器从第一个字节就开始错位。
立即学习“前端免费学习笔记（深入）”；
- 典型现象：双击打开本地
index.html，显示 “涓枃” —— 这是 UTF-8 字节被当 GBK 解码的结果，说明文件实为 UTF-8，但浏览器 fallback 到了 Windows 默认编码 - 反向验证：把
<meta charset="UTF-8">改成<meta charset="GBK">，再双击打开。如果这时变正常了，基本锁定文件是 GBK 编码 - 关键点：
<meta charset>只在<head>开始后、无任何前置字符（包括 BOM、空格、注释）时才生效。哪怕前面多一个<!-- -->，都可能导致它被跳过
真正决定乱码走向的，从来不是你写了什么 meta，而是文件开头那几个字节是什么、浏览器怎么读它们。BOM 存不存在、file -i 输出是否可信、VS Code 重开后是否立刻显形——这三件事对得上，编码才算真正确认了。
