HTML页面必须在<head>最顶部声明<meta charset="UTF-8">，否则中文会因浏览器默认编码解析错误导致乱码、方块、问号甚至XSS拦截；该标签必须是第一个<meta>，不可用http-equiv替代，且需确保编辑器保存为UTF-8无BOM、构建工具未覆盖其位置。
HTML页面必须声明charset，否则中文会乱码
浏览器默认用ISO-8859-1或系统编码解析HTML，不显式指定就会把UTF-8的中文当成其他编码解，轻则显示方块、问号，重则触发跨站脚本过滤（比如某些CDN或代理会因编码异常拦截请求）。
唯一可靠写法是放在<head>最顶部的<meta charset="UTF-8">。它必须是<head>中**第一个**<meta>标签，且不能写成<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">——后者在HTTP头已存在时会被忽略，且HTML5标准已废弃该用法。
- 不要用
charset=gbk或charset=gb2312：Windows本地开发可能暂时不报错，但部署到Linux服务器或现代浏览器（尤其Chrome 120+）大概率崩溃 - 文本编辑器保存格式也得匹配：VS Code右下角确认是
UTF-8（不是UTF-8 with BOM），Sublime Text选File → Save with Encoding → UTF-8 - 如果用了构建工具（Vite/Webpack），检查
index.html模板里是否被插件覆盖了<meta>位置
为什么<meta charset>必须在<head>最前面
浏览器是流式解析HTML的，遇到第一个非空白字符就开始解析。一旦读到非ASCII字节（比如中文“你好”），而此时还没看到<meta charset>，就会按默认编码（通常是Latin-1）尝试解码，导致后续所有字符偏移错位——即使后面写了正确的<meta>也救不回来。
实测现象：<head><title>你好</title><meta charset="UTF-8"></head>中，“你好”在Chrome里会显示为，因为<title>内容已被错误解码过一次。
立即学习“前端免费学习笔记（深入）”；
- 正确顺序：
<head><meta charset="UTF-8"><title>你好</title></head></li> <li>如果用了<code><script>
前置加载JS，也要确保它在<meta charset>之后，否则JS里的字符串常量也可能乱码 - 某些老旧CMS生成的HTML会把统计代码塞进
<head>开头，务必手动挪开
服务端HTTP头和HTML meta冲突时听谁的
HTTP响应头里的Content-Type: text/html; charset=GBK优先级高于HTML中的<meta charset="UTF-8">。只要服务端发了带charset的头，浏览器就直接无视HTML里的meta。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
常见踩坑场景：
- 本地用Python
http.server启动时，默认头是charset=utf-8，但如果你改过源码或用了第三方模块，可能变成charset=iso-8859-1 - Nginx配置里写了
charset gbk;，但HTML里又写UTF-8，结果全站中文变方块 - GitHub Pages强制用UTF-8，但自定义域名绑了Cloudflare，而Cloudflare的“自动字符集”功能有时会误判，建议在Page Rules里强制设置
Content-Type头
验证方法：打开DevTools → Network → 点开HTML请求 → 查看Response Headers里的content-type字段。
特殊场景：HTML里嵌入非UTF-8资源怎么办
极少数遗留系统要求页面本身UTF-8，但加载的JS/CSS文件是GBK编码（比如某些政府老系统接口）。这时候不能改HTML的charset，否则整个页面乱码；也不能硬改资源文件编码（可能破坏签名或校验）。
可行方案只有两个：
- 对JS/CSS用
<script charset="GBK" src="xxx.js"></script>或<link charset="GBK" href="xxx.css">（注意：charset属性仅对外部资源有效，对内联<script>无效） - 更稳妥的做法：用Fetch API异步加载GBK资源，再用
TextDecoder('gbk')解码，最后eval()或注入<style>——但这要求你控制JS执行时机，且TextDecoder在IE中不可用
真正省事的办法，其实是让后端统一转成UTF-8输出。如果做不到，至少确认那个GBK资源文件没有BOM头，否则TextDecoder会多解出三个字节。
