问号字符（）本质是UTF-8字节被错误当作ISO-8859-1或GBK解码所致，属解码失败信号而非字体或内容丢失；其根本原因是编码与解码规则不匹配，只要统一文件编码、HTML声明及HTTP响应头为UTF-8（无BOM），99%的即可消除。
问号字符（）本质是 UTF-8 字节被浏览器当 ISO-8859-1 或 GBK 解码的结果，不是字体问题，也不是内容丢失——只要三者统一为 UTF-8（无 BOM）+ <meta charset="UTF-8"> + HTTP 响应头 charset=utf-8，99% 的 就会消失。
为什么页面出现单独的 符号
浏览器在没看到有效 <meta charset> 时，会 fallback 到老旧默认编码（Windows 下常为 GBK，Linux/macOS 下常为 ISO-8859-1），而 UTF-8 中一个中文字符占 3 字节（如“爱”是 e7 88 b1），用 ISO-8859-1 拆成单字节读，每个字节都超出其范围，就显示为 。这不是乱码，是解码失败的明确信号。
常见触发场景：
-
<meta charset="UTF-8">写在<title>后面，或前面有空格、注释、BOM - 文件实际保存为
UTF-8 with BOM，开头三个字节ef bb bf被当成无效字符，导致<meta>失效 - PHP/Node.js 动态输出 HTML 前调用了
echo或console.log，提前输出了 BOM 或空格 - Nginx/Apache 配置了硬编码
charset gbk;，覆盖了 HTML 内声明
如何确认文件是否含 BOM
BOM 是隐形杀手，不打开十六进制视图根本看不见。别信编辑器右下角写的“UTF-8”，它可能在撒谎。
立即学习“前端免费学习笔记（深入）”；
验证方法：
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- VS Code：按
Ctrl+Shift+P→ 输入Change File Encoding→ 点Save with Encoding→ 选UTF-8（**不是**UTF-8 with BOM） - Linux/macOS 终端：
head -c 3 index.html | xxd，若输出00000000: efbb bf，说明有 BOM - PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，结果为239, 187, 191即含 BOM - Notepad++：菜单栏「编码」→ 看底部状态栏是否显示
UTF-8-BOM；若是，点「编码」→「转为 UTF-8 编码」→「另存为」
HTTP 响应头和 meta 标签谁说了算
HTTP 响应头里的 Content-Type: text/html; charset=utf-8 **永远优先于** <meta charset>。本地双击打开（file:// 协议）时响应头不存在，才轮到 <meta> 生效。
检查方式（Chrome DevTools）：
- F12 → Network → 刷新 → 点 HTML 文件 → Headers → Response Headers → 查
content-type - 如果值是
text/html; charset=gbk或压根没charset，那改<meta>没用 - Nginx 配置中搜
charset指令，删掉或改为charset utf-8; - Express 中不要只写
res.sendFile()，加一句res.set('Content-Type', 'text/html; charset=utf-8') - PHP 中确保
header()在任何输出（包括空格、BOM）之前调用，且传入charset=utf-8
动态模板里 meta 标签容易失效的坑
EJS、Jinja2、Thymeleaf 这类模板引擎拼接 HTML 时，<meta charset="UTF-8"> 很可能被插在 <head> 中间，甚至被条件逻辑包裹，导致它不再是前 1024 字节内的第一个 charset 声明。
安全做法：
- 把
<meta charset="UTF-8">放在<head>的**绝对开头**，前面不能有任何空格、换行、注释、<script>、<link> - 避免写成：
<head>\n <!-- 页面描述 -->\n <meta charset="UTF-8">（注释前的换行就算“前面有内容”） - 正确写法：
<head><meta charset="UTF-8">（紧贴，零空格、零换行、零注释） - Node.js 用
fs.readFileSync(path, 'utf8')读模板，Python 用open(path, encoding='utf-8')，否则读出来就是乱码字符串，再怎么写<meta>都救不回
真正难缠的不是 BOM 或响应头，而是那些藏在模板 include、CMS 输出、第三方 JS 注入里的隐性空格和提前输出——它们会让 <meta charset> 彻底失效，但你根本看不到源头。每次遇到 ，先查 BOM，再抓响应头，最后盯住模板第一行。
