跨机构交接实验数据时，传输清单应该记录什么

实验室把原始测量文件、处理脚本、环境说明和结果图交给另一机构。接收者能下载并打开文件，却不知道清单是否覆盖全部对象、每个校验值对应哪一版，也无法从结果图回到生成它的输入和运行。

传输清单不是文件名目录，而是一份双方可独立核验的交付契约：它必须区分对象与说明、完整与有效、字节一致与研究可解释，并记录版本、校验范围、来源关系、权限和接收结果。

文件名列表只能回答“看起来有什么”

常见交付清单只有文件名、大小和一句说明。它便于浏览，却不能证明目录已经覆盖全部交付对象，也不能说明校验值使用什么算法、针对哪个版本生成，更无法描述结果图由哪次运行产生。

真正的清单要回答六类问题：交付对象是什么；是否全部收齐；收到的字节是否与发送版本一致；对象怎样产生；谁可以使用；接收者实际检查了什么。

这六类问题不能压成一个“已完成”。上传进度到100%只表示传输工具结束当前任务。压缩包能解开，也不表示内部对象没有遗漏或版本混用。

把数据对象和说明文件分层

RFC 8493描述的BagIt格式把任意数字内容放在payload目录，把用于记录存储和传输的元数据放在tag文件。规格对payload内容视为不解释的字节，因此可以装原始测量、图像、脚本、环境文件和结果，却不会替团队理解它们的科学含义。

实验交付可以借用这项分层。对象层包含真正要保存或处理的文件；说明层包含对象清单、校验表、数据字典、版本关系、许可、联系人和接收回执。说明层不是装饰，它决定后来者能否解释对象。

BagIt以payload保存数字对象，并用tag文件记录传输与保存元数据。即使不采用BagIt目录名，也应保留同样的逻辑边界：数据文件不承担全部说明，说明文件也要成为可校验对象。

manifest必须逐一覆盖全部文件

BagIt要求至少存在一份payload manifest，而且每份manifest都要恰好列出每个payload文件一次。每行将相对路径与指定算法计算的十六进制校验值连接起来。

这比只给整个压缩包一个哈希更适合跨机构排错。压缩包总哈希验证单一容器，逐文件manifest定位具体遗漏或变化；两者的故障定位能力不同。总哈希失败时只能知道容器不同，逐文件表可以指出是哪一个对象缺失或变化。

清单固定使用相对路径，明确算法名称和字符编码。新交付可采用双方工具都支持的SHA-256或SHA-512。算法名称不能省略，同一串字符在没有算法时无法验证。

BagIt要求manifest逐一列出全部payload文件及其校验值。接收端不仅重算值，还要比较目录与manifest的差集：清单有而目录没有、目录有而清单没有、路径重复、大小写冲突都分别报告。

complete和valid是两道状态

RFC把complete和valid分开。完整包需要具备必需元素、列出的文件实际存在、全部payload都被manifest列出，且结构符合版本要求。有效包先要完整，再要求每个manifest校验值都与对应文件验证成功。

BagIt把对象收齐定义为complete，把所有校验值验证成功定义为valid。交付回执也应分两栏：对象覆盖检查和字节校验检查。只写“验证成功”会让人不知道它验证了数量、路径还是哈希。

说明文件自身也可能被改动。可建立tag manifest或等价的说明文件校验表，把payload manifest、数据字典、环境清单和交接说明纳入校验。否则攻击者或误操作可以改掉校验表，而对象值看起来仍有记录。

完整和有效都不解释payload内容。文件完整回答收到的字节是否一致，研究可解释回答这些字节代表什么以及如何产生。两项都需要，不能互相替代。

每个对象需要稳定ID和版本

FAIR原则要求数据与元数据具有持久唯一标识，并由丰富元数据描述。机构内部不一定要为每个文件申请公开标识，但应分配不会因移动目录或改文件名而改变的object ID。

对象表记录object ID、相对路径、角色、格式、版本、创建时间、大小、哈希和责任者。原始数据、清洁数据、脚本、环境、结果和展示图分别标识，不让“final2”承担版本关系。

版本更新不覆盖旧对象。修正版使用新version ID，记录修订原因、影响范围和替代关系。若只修改说明而数据字节不变，也明确标为metadata revision，避免接收者误以为结果重算。

稳定ID使目录迁移后仍能识别对象，哈希使同一版本的字节变化可被发现。ID不是哈希的别名：同一研究对象可以有多个版本，每版有自己的哈希。

从结果图反向连接输入与运行

W3C PROV-O用实体、活动和责任者描述来源。可以把原始文件、脚本、环境和结果视为实体，把一次数据处理视为活动，把执行人、审核人或自动系统记录为责任者。

每次运行分配run ID，列出实际使用的输入object ID与版本、脚本、参数、环境、开始和结束时间、退出状态，以及生成的输出object ID。结果图引用具体run ID，不只写“由analysis.py生成”。

FAIR和PROV-O分别提供稳定标识要求与输入—活动—输出关系。逐文件manifest发现遗漏或字节变化，稳定ID与来源关系再把文件连接回版本、运行和责任者。

交接前选择一张正式结果图，从output ID回到run ID，再找到输入数据、脚本、参数和环境。任何一步断开，都在清单中标为来源缺口，不用一句“方法见论文”掩盖。

测量上下文不能只放在聊天里

实验文件的语义常依赖仪器、校准、采集参数、时间基准、样本状态和环境条件。清单至少记录仪器或数据源ID、采集开始与结束时间、配置版本、单位、坐标或通道定义、缺失值规则和已知异常。

处理结果还要记录过滤、转换、校正、随机种子、参考库和软件环境。只交脚本而不交环境和参数，接收者无法判断脚本是否就是生成当前结果的状态。

对大文件可以把数据分块，但分块ID、顺序、大小、逐块校验和整体对象关系要明确。恢复传输前先确认源对象未变化；若源文件变化，旧分块不能继续拼成新版本。

来源和许可也随对象记录。FAIR把详细属性、清楚许可、详细来源和领域标准列为可再利用条件。能下载的文件不一定允许再次分发，能打开的数据也不一定适合新的研究问题。

权限、来源认证和恶意内容是另一层

RFC明确说明，manifest主要针对传输或保存中的数据损坏，不设计为抵御主动攻击。校验通过只能说明收到的字节与manifest声称的值一致；若manifest和文件同时来自不可信渠道，它不会证明发送者身份。

需要来源认证时，机构还要使用经过约定的数字签名、受控传输渠道、身份和权限记录。签名验证谁发布某个对象，哈希比较对象是否变化，两者作用不同。

接收端也要按安全政策扫描和隔离未知脚本、宏、可执行文件及外部下载链接。文件签名不替代恶意内容检查，反过来，安全扫描通过也不证明实验内容正确。

校验通过不能证明来源认证、文件安全、测量正确或研究结论有效。清单应把“字节完整”“来源已认证”“安全检查”“科学复核”列成独立状态。

跨设备文件名可能造成假缺失

RFC还提醒大小写、Unicode规范化、路径分隔符和保留文件名的差异。macOS、Windows和Linux可能对视觉相同的文件名采用不同字符序列，或对大小写有不同处理。

交付前避免只在大小写上不同的两个名称，统一Unicode规范化策略，并测试最长路径和特殊字符。manifest内部使用明确的相对路径形式，接收工具在比较前按约定进行同一规范化，同时保留原始路径供审计。

如果文件看起来存在却验证器报缺失，不要立即重命名或删除。先导出文件系统实际名称的编码与manifest条目比较，记录修复动作，并重新生成相应版本的manifest。

接收回执由接收方生成

发送方可以声明交付完成，最终回执应由接收方独立产生。回执记录收到时间、接收者、工具版本、manifest算法、对象总数、总字节数、差集、校验结果、异常和处理决定。

接收者先比较对象差集，再独立重算校验。通过后，从一张结果图反向找到输入、脚本和运行记录，并打开一个代表性数据对象确认格式、字段和单位与说明一致。

若某个低影响说明文件暂缺，可以把包状态写成“字节有效、研究语境待补”，并限制用途。不要为了尽快关闭任务，把有例外的交付写成无条件通过。

回执也分版本。补交文件、修订说明或重新打包后，产生新的receipt ID并关联原回执，保留差异。双方以后讨论的是同一个交付版本，而不是各自电脑里的“最新文件夹”。

交付前先做一次失败演练

清单第一次启用时，不要直接拿真实项目判断它是否可靠。复制一个小型测试包，分别删除一个payload文件、修改一个字节、增加一个未登记文件，再把一个路径中的大小写或Unicode形式改掉。接收工具应把四类问题分开报告，而不是只返回笼统的“失败”。

然后测试说明层：修改数据字典或环境清单，确认tag manifest或等价校验表能够发现变化；更换一个run ID，确认结果图到输入的反向链路会中断。这样的演练验证的是清单与工具的配合，不是研究结论本身。

测试记录要保存工具版本、操作系统、算法和预期结果。若发送端与接收端使用不同工具，也要对同一测试包得到一致的对象集合与校验判断。只有发送端能通过的清单，不足以作为跨机构交付契约。

正式交付时可以按数据规模抽查语义，但对象差集和校验不能抽样。逐文件验证的成本可以自动化，若只抽查若干文件，就无法声称整个包已经valid。大对象可以分批验证并保存进度，但每批必须绑定同一个manifest版本。

一份可执行的最小清单

第一张表是对象表：object ID、路径、角色、版本、格式、大小、哈希、创建时间和责任者。第二张表是来源表：数据源、采集条件、许可、限制和领域字段。

第三张表是运行表：run ID、输入、脚本、环境、参数、时间和输出。第四张表是权限表：谁可读、谁可修改、有效期和再分发限制。第五张表是接收表：差集、校验、代表性复核、异常和签发人。

这套清单不要求每个项目采用同一软件。关键是发送与接收两端对字段、算法、状态和例外有相同理解，并能独立重做关键核验。

清单完整不等于实验能够科学复现。它的价值是把问题定位到对象、版本、传输、来源、环境或方法中的具体一层，使后续复核从同一个事实起点开始。

资料来源

• RFC Editor / BagIt authors：《The BagIt File Packaging Format (V1.0)》，发布或更新于 2018-10-01
• Scientific Data / FAIR原则作者组：《The FAIR Guiding Principles for scientific data management and stewardship》，发布或更新于 2016-03-15
• World Wide Web Consortium：《PROV-O: The PROV Ontology》，发布或更新于 2013-04-30