必须让文件保存编码、HTTP响应头、HTML声明三者完全一致；任一错位，浏览器均显示乱码或方框，90%源于文件本身非UTF-8 without BOM，BOM或GBK保存会使<meta charset="UTF-8">失效。
HTML编码设置出问题，不是“改个就行”，而是必须让文件保存编码、HTTP响应头、HTML声明三者完全一致；任一环节错位，Chrome/Firefox/IE都可能显示乱码或方框。
确认当前文件实际保存编码是否为UTF-8 without BOM
浏览器看到的乱码，90%源于文件本身不是UTF-8。即使写了<meta charset="UTF-8">，若文件用GBK保存，所有中文都会变成问号或乱码字节。
- 在VS Code右下角状态栏点击编码名称（如“GBK”），选“Save with Encoding” →
UTF-8（注意：不选UTF-8 with BOM） - 用Notepad++打开，菜单栏“编码”→“转为UTF-8无BOM格式”→保存
- 用十六进制编辑器（如HxD）检查文件开头：应为
EF BB BF（有BOM）或纯文本起始（无BOM）；IE/Edge对BOM敏感，旧版会忽略<!DOCTYPE>导致怪异模式 - 改完后务必重新打开HTML文件——不要仅刷新页面，缓存可能仍读旧字节
验证HTTP响应头中Content-Type是否声明charset=utf-8
服务器返回的HTTP头优先级高于<meta charset>。本地双击打开HTML时无HTTP头，依赖<meta>；但部署到Nginx/Apache后，若响应头是Content-Type: text/html; charset=GBK，<meta>直接被无视。
- Chrome DevTools → Network → 刷新页面 → 点击HTML请求 → 查看Response Headers里的
Content-Type - Apache：在站点根目录
.htaccess中添加AddDefaultCharset UTF-8（不要写GBK） - Nginx：在
server或location块中加charset utf-8;（注意是utf-8，非UTF-8） - PHP动态页：在输出HTML前调用
header('Content-Type: text/html; charset=utf-8');，且必须在任何echo或空白输出之前
检查位置与语法是否合法
<meta charset>必须出现在<head>最前面，且不能有任何前置内容（包括注释、空格、BOM）。位置错或语法错，Firefox和IE会降级使用响应头或默认编码。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 必须写成
<meta charset="UTF-8">（自闭合写法<meta charset="UTF-8"/>在HTML5中无效） - 必须位于
<head>内，且是<head>子节点中的第一个标签（<title>前） - 禁止在
<meta charset>前插入任何字符：比如<!-- 注释 --><meta charset="UTF-8">会导致IE11及以下完全忽略该声明 - 若用构建工具（如Webpack/Vite）生成HTML，确认模板中
<meta>未被插件误删或挪位
本地双击打开HTML时乱码的临时绕过方法
本地文件（file://协议）无HTTP头，全靠<meta charset>和浏览器猜测。Chrome/Firefox对此支持较弱，尤其Windows系统默认用系统编码（GBK）解析，极易失败。
- Chrome：F12 → ⋮ → More tools → Rendering → 勾选
Emulate document charset→ 选UTF-8 - Firefox：地址栏输入
about:config→ 搜索intl.charset.fallback.override→ 双击修改为UTF-8 - 终极方案：用
python3 -m http.server 8000起本地服务，用http://localhost:8000/xxx.html访问——此时有HTTP头，行为与线上一致 - 切勿依赖“浏览器手动切换编码”修复：这只是掩盖问题，上线后用户不会自己调
最容易被忽略的是：文件保存编码与<meta charset>声明不一致，且开发者只盯着HTML源码看，没查十六进制字节流。一旦BOM存在或文件实为GBK，所有后续调试（改响应头、换字体、清缓存）都是徒劳。
