打印预览中文乱码本质是浏览器严格按声明解码所致，须确保文件实际编码、（置于首行无BOM/空格）、HTTP响应头三者完全一致，且VS Code右下角显示编码与保存编码相同，禁用UTF-8 with BOM。
打印预览中文乱码，根本不是“打印设置”问题，而是浏览器在渲染打印视图时，**跳过了 HTML 文件实际编码，直接按系统默认编码（如 Windows 的 GBK）解码内容**。只要文件保存编码、<meta charset>、HTTP 响应头三者不一致，或存在 BOM 干扰，打印预览就会出错。
VS Code 里右下角显示 “GBK” 却写了 <meta charset="UTF-8">
这是最常见也最容易被忽略的矛盾点。VS Code 右下角显示的编码，是它当前**读取文件时所用的解码方式**，不是你保存时用的编码。如果文件实际是 GBK 保存的，但你硬写 <meta charset="UTF-8">，浏览器在普通浏览时可能靠启发式检测“蒙对”，但打印预览会严格按声明执行——用 UTF-8 解 GBK 字节，结果就是 æ 这类乱码。
- 先确认真实编码：在 VS Code 中点击右下角编码名 → 选 Reopen with Encoding → 依次试
UTF-8、GBK、GB2312，看中文是否正常显示 - 确认后立刻保存：选中正确编码 → 点击右下角 → Save with Encoding → 选同一编码（如
UTF-8，**不要选 “UTF-8 with BOM”**） -
<meta charset>必须与之完全匹配，且必须放在第一行，前面不能有任何空格、BOM 或注释
打印预览时 <meta charset> 完全失效
这种情况基本可断定：HTML 文件开头存在不可见字符（BOM 或空格），导致浏览器无法在前 1024 字节内识别到 <meta charset> 标签。打印预览比普通渲染更“较真”，一旦没扫到，就直接 fallback 到系统默认编码（Windows 是 GBK）。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 用命令行验证 BOM：
head -c 4 index.html | xxd（Linux/macOS）或Get-Content index.html -Encoding Byte | Select -First 3（PowerShell）。输出含ef bb bf就是 UTF-8 BOM，必须删掉 - 在 VS Code 中：打开文件 → Ctrl+Shift+P → 输入 “Remove BOM” → 选插件执行；或手动删除开头不可见字符（把光标移到最开头，按
←若有反应，说明有空格/BOM） - 删完后务必重新保存为纯
UTF-8（不是 “UTF-8 with BOM”），再检查右下角是否稳定显示UTF-8
本地双击打开（file://）时打印预览乱码，但用 Live Server 就正常
这是因为 file:// 协议下，浏览器**完全依赖 <meta charset> 和文件实际编码**，没有任何 HTTP 响应头干预；而 Live Server 启动的是 HTTP 服务，默认响应头是 Content-Type: text/html; charset=utf-8，它优先级高于 <meta>，掩盖了文件本身的问题。
立即学习“前端免费学习笔记（深入）”；
- 不要依赖 Live Server “看起来正常” 就认为没问题——它只是帮你兜底了
- 真正要修复的是文件本身：确保保存编码 =
<meta charset>声明 = 无 BOM =开头第一行 - 验证方法：把文件拖进 Chrome，按
Ctrl+P打开打印预览，同时按F12→ Network → 刷新 → 查看该 HTML 请求的Response Headers。如果是file://，这里没有Content-Type头，那就 100% 依赖文件自身
真正卡住人的，往往不是“怎么加 meta 标签”，而是编辑器右下角那个看似无关紧要的编码显示——它暴露的是文件底层字节和声明之间的裂痕。修不对这一处，其他所有配置都是障眼法。
