UTF-8是唯一可行方案，因GB18030/GBK在HTML5中不被规范支持（如<meta charset="GB18030">非法），浏览器会降级至系统locale导致乱码；且JS/CSS等外部资源易因编码不一致报错，搜索引擎、屏幕阅读器等仅可靠识别UTF-8。
UTF-8 是唯一可行方案，其他编码（如 GBK、GB18030）在现代 HTML 中无法可靠支持生僻字，且会引发跨平台/跨浏览器兼容问题。
为什么不能用 GB18030 或 GBK 声明生僻字？
虽然 GB18030 理论上覆盖了大量汉字（含古籍生僻字），但它在 HTML 中不被规范支持：
-
<meta charset="GB18030">不是 HTML5 合法值，浏览器会 fallback 到系统 locale（如 Windows-1252），直接导致乱码 - HTTP 响应头若设为
Content-Type: text/html; charset=GB18030，Chrome/Firefox 会拒绝解析或静默降级 - 外部资源（JS/CSS）若也用 GB18030 编码，
<script src="a.js">会因编码不一致抛出Uncaught SyntaxError: Invalid or unexpected token - 搜索引擎、屏幕阅读器、翻译工具普遍只识别
UTF-8，lang属性配合 GB18030 无实际语义增强
生僻字必须用 UTF-8，但需额外三步验证
仅写 <meta charset="UTF-8"> 不够。生僻字（如「?」「?」「?」）依赖完整的 UTF-8 实现链：
- HTML 文件本身必须保存为 UTF-8 without BOM —— VS Code 默认带 BOM，Sublime/Notepad++ 默认带 BOM，BOM 会卡在
<!DOCTYPE html>前，使meta失效 - 服务器响应头必须明确声明
Content-Type: text/html; charset=utf-8（注意小写utf-8）；Nginx 配置用charset utf-8;，Apache 用AddDefaultCharset UTF-8 - 所有关联文件（
.js、.css、.json）也必须是 UTF-8 without BOM，否则document.getElementById("?")会因 JS 解析失败而报错
字体层面：CSS 必须兜底 fallback 字体链
即使编码正确，生僻字仍可能显示为方框（），这是字体缺失，不是编码问题：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 避免只写
font-family: "SimSun"—— 宋体不包含 Unicode 扩展区（如 CJK Ext-B/C/D）的字 - 必须叠加多层 fallback：
font-family: "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", "Noto Sans CJK SC", sans-serif; - 关键点：
Noto Sans CJK SC是 Google 开源字体，完整覆盖 CJK Unified Ideographs Extension A–G，对「?」类字支持最稳定 - 若需更高覆盖率（如甲骨文、金文字形），需用
@font-face加载专业字体，且确保该字体文件本身是 UTF-8 引用、WOFF2 格式
验证生僻字是否真能走通：三处必查
改完后不要只看页面渲染，要检查底层链路：
- 用十六进制编辑器（如 HxD）打开 HTML 文件，确认开头三字节不是
EF BB BF（即无 BOM） - DevTools → Network → 刷页面 → 点 HTML 请求 → Response Headers → 确认
Content-Type值含charset=utf-8，且无空格或大小写错误 - 在 Console 执行
document.characterSet，返回必须是"UTF-8"（注意大小写和连字符）；若返回"ISO-8859-1"，说明 meta 或响应头彻底失效
生僻字支持的真正瓶颈从来不在“选什么编码”，而在于 UTF-8 全链路（存储→传输→解析→渲染）中任意一环的微小偏差——比如 Notepad++ 里一个勾选、Nginx 配置里一个分号位置、CSS 字体名里一个空格，都足以让「?」变成 。
