浏览器把完整网页保存成单个文件时，经常会生成 .mhtml 或 .mht。这个文件不是截图，也不是普通 HTML，而是一份 multipart/related MIME 归档：HTML、样式表、图片和字体可能都作为独立分段放在同一个文件里。
直接双击通常会交给 Chrome 或 Edge 打开，但如果文件来自陌生邮件，或者你想先确认里面打包了哪些资源，直接渲染并不是唯一选择。MHTML 网页归档查看器会在浏览器本地解析归档，禁用脚本后预览页面，并列出可单独提取的图片、CSS 和其他 MIME 内容。
MHTML 怎样把一个网页装进单个文件#
归档根部通常声明一个 boundary。文件里的每一段都带有自己的 Content-Type、Content-Location、编码方式，有些还会使用 Content-ID。HTML 中原本指向网络地址的图片和样式，会通过这些位置重新关联到归档内资源。
解析时最重要的对应关系包括：
- 根 HTML 是哪一个 MIME 分段；
Content-Location对应原网页或资源的哪个 URL；cid:引用对应哪个Content-ID；- 内容使用 Base64、Quoted-Printable 还是普通文本编码；
- 相对路径应以哪个原始页面地址为基准。
所以，把 .mhtml 后缀直接改成 .html 通常没有用。浏览器只会看到 MIME 边界和编码文本，图片也不会自动恢复。
为什么预览时要拦截脚本和外部请求#
归档页面仍然是 HTML。它可能包含脚本、表单、iframe、事件属性、外部图片、追踪链接或远程样式。如果预览器原样执行，打开一份离线文件也可能向外部网站发送请求，甚至运行归档时保存下来的交互代码。
本地查看器会移除脚本、表单、iframe、对象和可执行嵌入，把能够确认来源的图片与样式转换成本地数据后再放进预览。找不到、体积过大或类型不安全的引用会被拦截，并在页面上给出数量提示。
这种处理适合阅读和检查，不等于病毒扫描。下载出来的脚本、Office 文件、可执行程序和未知二进制，仍然需要根据来源另行判断，不能因为预览页面没有弹窗就认定安全。
一套实际的打开和提取顺序#
先选择 MHT 或 MHTML 文件。解析完成后，先看归档标题、原始页面地址、MIME 分段数量和警告，再打开安全预览。
如果页面缺图，不要立即认为文件损坏。切换到资源列表，检查对应图片是否真的存在，以及它记录的 Content-Location 是否能与 HTML 引用匹配。需要交给别人时，可以：
- 单独下载原始 HTML；
- 选择需要的图片、CSS 或附件；
- 导出资源清单 JSON，保留类型、大小和原始位置；
- 将选择的资源打包成 ZIP。
提取后的 HTML 不一定能脱离原 MHTML 独立显示。它里面可能仍保留原始 URL 或 cid: 引用；如果要重建成普通离线网站，还需要重新组织目录并改写资源路径。
乱码和缺少样式通常从哪里来#
MHTML 可能同时涉及邮件头编码、MIME 分段编码和 HTML 自身字符集。旧版浏览器或办公软件保存的文件，还可能使用 GBK、Windows-1252 等编码。只用一种 UTF-8 解码方式读取整个文件，很容易让标题正常、正文却乱码，或者反过来。
缺少样式的常见原因则包括：
- 保存网页时资源还没有加载完成；
- 页面使用跨域字体、延迟图片或脚本动态生成内容；
- CSS 通过外部
@import再加载其他文件； - 归档记录的是重定向前后不同 URL；
- 浏览器没有把视频、Canvas 或受保护资源封装进去；
- 文件经过邮件系统二次编码或截断。
查看器会尽量匹配 Content-Location 和 cid:，但无法凭空恢复归档里根本不存在的资源。需要忠实保存复杂交互页面时，MHTML 本身就可能不是最佳格式。
MHTML 不等于网页真实性证明#
MHTML 适合留存一个“当时看见的页面副本”，但文件内容可以被修改，时间和来源头也不天然可信。它不能单独证明某个网站在某时确实发布过这些内容。
重要归档应保留原文件，并用 Hash 校验工具记录 SHA-256。需要可审计的网页证据时，还应配合可信时间戳、HTTP 响应记录、WARC 归档、屏幕录像或第三方存证服务。
如果只是想把页面发给同事阅读，PDF 或完整页面截图可能更稳定；如果要继续编辑页面，保存 HTML 与资源目录通常更方便；如果要研究网络请求，则应该保留 HAR，而不是只看 MHTML。
总结#
MHTML 的优势是把一页网页收进单个文件，问题也来自这里：HTML、编码、资源路径和安全边界全混在一个 MIME 容器中。
合理的处理方式是先解析结构，再禁脚本预览，随后按需提取资源，同时保留原归档。把它当作方便的离线副本，而不是天然可信、完整无缺的网页证据，判断会更准确。