摘要

  • 10 月 28 日的第 03 版草案为个人数据归档选定 POSIX pax 容器。一次导出可以拆成多个各自可读的归档，大文件夹也可以跨卷；导入方须依靠相同的文件夹 uid 和一致的元数据把内容并回去。
  • 导入方必须拒绝绝对路径、向上穿越路径和特殊归档条目，也不得把归档里的文件权限位、所有者、扩展属性或 ACL 直接套到本地文件。原服务记录的共享角色同样不能被自动当作新服务的授权。

最容易丢的不是文件，是同一性

设想一个邮箱过大，服务商把导出拆成两卷。第一卷放旧邮件，第二卷放新邮件；两卷都出现“收件箱”。若接收软件按文件名建目录，用户得到两个收件箱；若只把第一卷当成完整数据，最近的邮件便消失。界面上的“导入成功”无法证明它把一个逻辑对象恢复成了一个对象。

新草案要求每卷都有自己的 archive.json，以递增的 part 和 final 标识卷次。一个文件夹跨卷时，每卷的 folder.json 只列本卷项目，但其他身份字段必须一致，删除列表也要重复。文件夹 uid 是合并的依据，导入方必须合并而非复制。这里的身份不是漂亮的名称，而是需要跨文件边界维持的操作约束。只要接收方忽略它，用户拿到全部字节仍会失去原有结构。

修订版还明确使用 POSIX pax。它扩展传统 tar，能容纳国际化路径和附加大小信息。导出方只能放普通文件与目录，不能塞符号链接、硬链接、设备文件。条目名称必须是 UTF-8 相对路径，不能有 . 或 .. 路径段，并须在单卷内唯一。然而两个在归档中不同的名字，落到不区分大小写或会规范化 Unicode 的文件系统时可能重合。草案要求导出方尽量避开这种碰撞，导入方应拒绝重名项目，而不是让后一个文件悄悄覆盖前一个。

这不是细枝末节。邮箱里可能有名字只差大小写的文件夹，也可能有视觉相同、编码不同的字符。一次迁移若把它们压成同一个目录，账面上下载了全部资料，实际却改变了用户的分类、检索和保留状态。格式的价值必须在接收端检验。

归档不能任命新机器的主人

权限问题比命名更直接。草案第 8.3 节要求导入方在写磁盘前检查条目路径，拒绝绝对路径、父目录穿越和非普通文件、非目录的条目。它还要求导入方不得应用归档内的权限位、所有者、扩展属性和访问控制列表，而要使用本机默认设置。归档可以交付内容，却不能替新机器指定谁拥有文件、谁有权打开它。

应用层也有相同的边界。导出的日历可能写着参与者和角色，其他对象可能含 shareWith 字段。旧服务让某人看过一份日程，不代表新服务已经验证过这个人的账户，也不代表上传者没有改动过角色字段。草案明确提醒：来源处的访问控制可能无法可靠迁移，导入的权限信息也可能不可信。接收方必须用自己的账户与授权规则决定共享范围。所谓“原样恢复”，不能把旧系统的信任判断偷偷塞进新系统。

文件同一性同样要防止人为噪声。对 JSContact、JSTask 和 JSCalendar 对象，导出方必须保留 uid 与 updated。导入方要寻找相同 uid 的既有对象；若内容足够相似，不应为了重新导入而改写对象并刷新时间戳。否则每次搬家都会制造“新修改”，联系人重复、日历冲突随之而来。草案允许接收方判断何谓“足够相似”，因此两套实现的合并结果仍需要实测。

它允许未压缩、gzip 或 Zstandard；导入方必须接受前两种，应接受后一种。压缩带来效率，也能把巨大的解析负担藏在小下载文件里。草案提醒导入方控制解压后的总大小、条目数量及单项大小。整包还聚合了通信对象、受邀者和联系人等第三人的私密资料。给用户一把方便的打包工具，同时给导出授权与导入解析增加了成本。

上一版尚未敲定这组 pax 容器和跨卷文件夹规则；IETF 状态页仍把它列为工作组 Internet-Draft。如何请求和传送导出文件并不由本文档规定。没人能凭这份草案断言某家服务已提供完整迁移，也不能把文件格式误称为已经验证的用户退出权。

来源