根本原因是HTML文件保存编码与浏览器解码方式不一致：文件中“你好”为UTF-8字节，但浏览器按GBK或ISO-8859-1解析，导致方块、问号或乱码；需统一文件编码（UTF-8无BOM）、置于最前、HTTP响应头Content-Type含charset=utf-8，并可辅以Unicode转义规避。
HTML 中 alert() 弹出的中文显示为方块、问号或乱码，根本原因不是 JavaScript 本身的问题，而是 HTML 文件保存编码与浏览器解码方式不一致 —— 你写的“你好”在文件里是 UTF-8 字节，但浏览器按 GBK 或 ISO-8859-1 解读，就必然出错。
确认当前 HTML 文件真实编码格式
很多编辑器界面显示“UTF-8”，实际保存可能是 UTF-8 with BOM、GBK 或 ANSI（Windows 下常等价于 GBK）。BOM 头会影响某些旧环境解析，而 GBK 编码的文件即使写了 <meta charset="UTF-8">，浏览器加载时仍会先按系统默认或响应头解码，再处理 meta，此时已晚。
- 用 VS Code 打开文件 → 右下角查看当前编码标识（如 “UTF-8”、“GBK”、“UTF-8 with BOM”）
- 点击该标识 → 选择 “Save with Encoding” → 明确选
UTF-8（不含 BOM）→ 保存 - 若右下角显示
UTF-8 with BOM，务必转成纯UTF-8；若显示GBK或GB2312，直接转存为UTF-8 - 命令行验证（Windows PowerShell）：
Get-Content -Encoding UTF8 -Raw yourfile.html | Select-String "alert"，能正常输出中文说明文件编码正确
检查 <meta charset> 是否位置正确且唯一
<meta charset="UTF-8"> 必须是 内第一个可解析的标签，不能被注释、空行、BOM 或其他 meta 干扰。它必须在任何脚本、样式或内容之前出现，否则浏览器可能已用错误编码开始解析。
- 打开 HTML 源码，确保
<meta charset="UTF-8">紧跟开始，前面无空格、换行、注释或 BOM 字节 - 删除所有重复的 charset 声明，比如同时存在
<meta charset="UTF-8">和<meta http-equiv="Content-Type" content="text/html; charset=GBK"> - 不要写成
<meta charset="utf8">（缺横杠）或<meta charset="utf-8">（单引号在极少数解析器中可能失效），统一用双引号和标准写法<meta charset="UTF-8">
排除服务器响应头覆盖 meta 的可能性
HTTP 响应头中的 Content-Type 优先级高于 <meta charset>。如果 Web 服务器（如 Nginx、Apache）或后端框架（如 Express、Flask）返回了 Content-Type: text/html; charset=gbk 或根本不带 charset，浏览器会忽略 HTML 里的 meta。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- F12 打开开发者工具 → Network 标签 → 刷新页面 → 点击 HTML 请求 → 查看 Response Headers 下的
Content-Type - 确认其值为
text/html; charset=utf-8（注意大小写不敏感，但utf8非标准，应写utf-8） - Nginx 配置需加：
charset utf-8;；Apache 加：AddDefaultCharset UTF-8；Express 中用res.set('Content-Type', 'text/html; charset=utf-8') - 本地直接双击打开
file://协议时，无响应头，完全依赖 meta 和文件编码，此时更要确保前两项 100% 正确
绕过编码依赖：用 Unicode 转义写死中文内容
当无法控制文件编码或服务器配置（比如离线 MHTML、第三方 CMS 导出页），最稳妥的方式是避开原始字节，直接用 Unicode 码点写 alert 内容。JS 引擎执行时会原样还原，不经过文件编码解析环节。
- 把
alert("你好");改成alert("u4f60u597d");（“你好”的 UTF-16 码点） - 可用在线工具快速转换，或在浏览器控制台运行：
"你好".split('').map(c => '\u' + c.charCodeAt(0).toString(16).padStart(4, '0')).join('') - 注意：仅适用于静态提示文本；动态拼接或用户输入内容不适用此法
真正棘手的不是 alert 本身，而是它暴露了整个链路的编码断点 —— 从编辑器保存、服务器响应、到浏览器解码，任一环节掉链都会让中文变成乱码。多数人只改 meta，却忽略了文件实际编码和响应头这两个更底层的开关。
