v-html无法渲染MHTML，因其本质是multipart/related MIME复合文档，非纯文本HTML；浏览器仅在原生加载时触发MIME解析，v-html仅执行DOM解析，跳过boundary分割与Base64解码，导致空白、乱码或资源失效。
v-html 不能渲染 MHTML 文件，因为浏览器根本不把它当 HTML 解析。 它是 MIME 复合文档，不是纯文本 HTML 字符串；直接塞进 v-html 只会触发解析失败或显示原始标签文本。
为什么 v-html 渲染 MHTML 总是空白或乱码？
MHTML 文件本质是 multipart/related 格式的二进制容器，含多个 Base64 编码的资源段（HTML 主体、CSS、JS、图片等），用 MIME boundary 分隔。浏览器原生只在 <iframe src="xxx.mhtml"></iframe> 场景下才调用 MIME 解析器；v-html 仅执行 DOM 解析，跳过 MIME 解析阶段，导致：
- 遇到
Content-Type: multipart/related开头直接放弃解析 - Base64 内容被当作文本原样插入，变成一堆
=和字母堆砌 - 即使手动截取 HTML 片段，缺失的 CSS/JS 路径和作用域隔离也会引发样式错乱或脚本污染
用 <iframe></iframe> 加载 MHTML 的真实限制
看似最直接的方案，但实际有硬性约束：
- 现代 Chrome / Edge 已默认禁用本地
file://协议下的 MHTML 加载（报net::ERR_UNKNOWN_URL_SCHEME） - Firefox 仍支持，但需确保服务端返回正确的
Content-Type: message/rfc822或multipart/related -
src必须是完整 URL，不能是 Blob URL（URL.createObjectURL(new Blob([...]))不生效） - 跨域 MHTML 文件受同源策略限制，无法读取其 document 内容，也无法注入样式或监听加载完成
mhtml2html 库怎么拆解并安全还原？
这个库核心是模拟浏览器 MIME 解析逻辑：先按 boundary 切分，再识别各 part 的 Content-Type 和 Content-Transfer-Encoding，最后将资源转为 data URL 或内联字符串。但要注意：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- 它不处理 JS 执行上下文隔离——还原后的 JS 仍运行在主页面全局作用域，可能覆盖已有变量或事件监听器
- CSS 未自动加 scope，若 MHTML 含
body { margin: 0 }这类重置规则，会污染主站样式 - 图片等二进制资源必须转成
data:image/png;base64,...，体积膨胀约 33%，大文件易触发内存警告 - 对含动态脚本（如
document.write）或依赖window.top的 MHTML，还原后行为不可预测
真正安全的落地建议
不要试图“完美还原”MHTML 的全部行为。生产环境应按风险等级分级处理：
- 只读展示场景（如审计快照）：用后端服务（如 Python 的
mhtml包）预解析为静态 HTML + 内联资源，再返回给前端；避免任何客户端 JS 解析 - 需交互的内部工具：强制要求 MHTML 来源可信，加载前用 Web Worker 拆包，CSS 加
scoped属性，JS 用eval在沙箱 iframe 中执行（注意 CSP 限制） - 绝对禁止把用户上传的 .mhtml 文件直接喂给
v-html或iframe——它比 HTML 注入更隐蔽，且绕过大部分 XSS 过滤器
最常被忽略的一点：MHTML 中的 javascript: 伪协议链接、onerror 内联事件、Base64 编码的恶意 payload，在解析阶段不会被任何前端 sanitizer 拦截，必须在服务端做 MIME 层面的内容白名单校验。
