MKV附带说明文件怎样确认完整，读取附件后如何核对原始字节

Matroska可以把相关说明文件作为附件存进容器，附件不同于可播放音视频流，也不同于封面attached_pic。确认完整性时，应读取filename和mimetype，再提取原始字节比较摘要；不应运行附件来判断它是否有效。

这组文件怎样比较

本题将一份原创UTF-8说明文本嵌入一秒MKV，再提取为extracted.txt。文本没有代码或外部引用，只用于演示字节保持。Matroska官方要求读取器不得执行附件，本例全过程只是封装、提取和读取，不触发任何附件程序。

按原始结构逐项检查

1. 先保存原始note.txt的SHA-256与字节长度，明确它是待比较基准。mimetype采用text/plain，filename写明note.txt；这些标签帮助使用方识别，但标签可以被写错，因此也不能只凭MIME便宣布附件内容可信或语言正确。

2. 封装后用附件类型说明符列出流，确认附件数量及元数据。附件不参与普通视频帧数或音频时长统计，完整解码音视频不会自动证明附件字节完整；所以本题把附件提取验证作为独立步骤，避免被通用解码通过掩盖。

3. 通过dump_attachment提取到新的文件名，比较SHA-256与原始文本一致，必要时再按UTF-8读回检查句子。提取名称不必等于源filename，身份应依据记录与摘要确认；若已有同名文件，应保留原件并使用明确的新输出路径。

容易误读的地方

反例是只看到容器里有附件就认为字体或说明资源已被播放器采用。附件存在与使用方加载是不同条件，目标软件可能忽略某类资源；另一反例是给附件改成字体扩展名后宣称已获得字体支持，本题不做这种内容伪装。

下载与本地读回

attached.mkv、extracted.txt、generation.json、note.txt、observed.csv、observed.json、source.mkv。

下载全部附件到同一个独立目录，用 python verify.py 运行本题独立核验脚本。依赖为Python 3.12.4、PATH中的FFmpeg及ffprobe 8.0.1；程序不联网、不连接设备，读取本题文件并在终端输出检查结果。本地实际执行回执保存实际命令、退出码和完整输出。

程序实际验证一个附件、正确filename与MIME，并证明原始与提取文本SHA完全一致，源片及带附件片可完整解码。没有测试播放器是否展示附件列表，也没有验证任意第三方附件的安全性、许可或内容质量。

命令已在原创短片上实际执行并读回文件。官方文档为滚动版本，本文所列选项已用本地8.0.1确认；未测试目标硬解、网络起播或现场实时性能。

把结果带回交付

交付时列出附件名称、类型、大小、摘要和用途，接收方可以先只读检查再按受支持流程使用。若说明文更新，应重新封装并比较提取结果，不能只替换容器旁边的外部文本却继续声称内部附件已经同步；文件内外版本要分别追踪。

相关背景见视频文件能打开却播到一半卡住，怎样做完整解码预检，还可从多媒体播放专题继续查找文件处理方法。需要核对实际工程的接收条件时，可携带本题文件与读回结果进行工程对接咨询。

一级依据

• Matroska Attachments存储相关文件数据，读取器不得执行附件。

来源核对日期：2026-10-24。引用支持文件机制；原创输入的本地结果不代表客户素材或现场系统已经通过验收。