弹窗乱码根源是HTML编码链断裂，需确保HTML文件为UTF-8无BOM、位于head最前，且AJAX/模板/ DOM取值等环节统一UTF-8编码。
弹窗内容乱码不是单独的“弹窗问题”，而是整个 HTML 页面或动态加载内容的编码链断裂导致的。核心判断：只要 alert()、confirm()、prompt() 里中文显示为 或方块，说明浏览器在解析 JS 字符串时已按错误编码解码——根源一定在 HTML 文件本身或外链资源的编码不一致。
确认 HTML 文件实际编码是否为 UTF-8（无 BOM）
VS Code 默认保存为 UTF-8 with BOM，而 BOM（EF BB BF）会干扰 JS 引擎对字符串字面量的解析，尤其在旧版 IE 或某些嵌入式环境里，直接导致 alert("你好") 显示乱码。
- 在 VS Code 中按
Ctrl+Shift+P→ 输入 “Save with Encoding” → 选UTF-8（**不带 BOM**） - 验证：Linux/macOS 执行
head -c 3 index.html | xxd，输出应为3c 68 74（即<ht>），而非 <code>ef bb bf - Windows PowerShell 验证：
Get-Content index.html -Encoding Byte | Select -First 3，前三字节不能是239, 187, 191
检查 alert() 字符串来源是否被二次转码
如果弹窗内容来自 DOM 文本、AJAX 响应或模板引擎，乱码往往发生在数据流转环节，而非 HTML 本身。
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- DOM 取值：用
document.getElementById("xxx").textContent而非.innerHTML，避免 HTML 实体未解码（如你） - AJAX 响应：fetch 返回
response.text()前，确认服务端 HTTP 头含Content-Type: text/plain; charset=utf-8；若后端返回 GBK 编码，需手动用new TextDecoder('gbk').decode(arrayBuffer) - 模板变量（如 EJS/Thymeleaf）：确保模板文件本身是 UTF-8 无 BOM，且服务端渲染时未额外 encode —— 比如 EJS 的
应直接输出原始字符串，而非（后者会 HTML 转义）
避免 document.write() 或内联脚本触发编码 fallback
当 HTML 文件没声明 <meta charset="UTF-8">，或该标签不在 最开头，浏览器可能用系统默认编码（Windows 是 GBK）解析整个文档，包括 <script></script> 内的字符串字面量。
立即学习“前端免费学习笔记（深入）”；
-
<meta charset="UTF-8">必须是的第一个子节点，前面不能有任何空白、注释或 BOM - 不要写成
<meta charset="utf8">或<meta charset="UTF8">—— 只有"UTF-8"是标准值 - 禁用
document.write()动态插入含中文的 script 标签，它会绕过 HTML 解析器的 charset 判断，直接按当前文档编码解释
BOM 和 <meta charset> 位置是两个最常被忽略的硬性条件；一旦它们出错，哪怕 JS 字符串写得再规范，浏览器也早在解析阶段就把它当成了乱码。
