摘要

  • 1994 年 12 月的 RFC 1740 规定了 Macintosh 文件如何装入 MIME 邮件。AppleSingle 把内容与属性合成一条字节流；AppleDouble 则把 Mac 专属信息和数据叉分开。
  • 对多数需要特别封装的文件，RFC 推荐 multipart/appledouble：一个 application/applefile 部分保存资源和桌面信息，另一个部分用合适的 MIME 类型呈现数据。

同一份文件，两个抽屉

许多电脑把文件当作一串连续字节。经典 Macintosh 的文件却有“数据叉”和“资源叉”。前者放其他电脑通常也能使用的数据；后者可能放程序片段、图标位图和其他属性。Finder 还另存一些信息。把这样的文件交给只认一串字节的文件系统，或者塞进电子邮件，发送方必须决定：哪些东西捆在一起，哪些东西要让不同收件人直接拿到？

RFC 1740 的三位作者 Patrik Faltstrom、Dave Crocker 和 Erik E. Fair 沿着 RFC 1521 的 MIME 机制找答案。MIME 允许同一封信装多个正文部分，每个部分标出自己的内容类型。它已经替图片、应用程序数据和其他内容准备了座位。Mac 文件的难题，是让独特的资源信息同行，同时把普通数据放在别人够得着的位置。

AppleSingle 选择整箱打包。文件内容与属性连成一条字节流，以 application/applefile 发送。箱子里东西齐全；只想看图片的非 Mac 收件人，得先学会开这个箱子。外面的类型标签写的是 Apple 的封装方式，里头的数据到底是图片还是别的文件，需要再拆一层。寄出的人省了分类，收件的人多了一门手艺。

AppleDouble 把这门手艺分给该用它的人。文件头保存资源叉和桌面信息，数据叉单独放。外层 multipart/appledouble 恰好有两个子部分：第一个是 application/applefile，第二个按数据本身标注类型。RFC 给出的例子是 image/gif；找不到合适的已注册类型时，使用 application/octet-stream。非 Mac 软件可以直接处理第二部分。Mac 软件则把两部分拼回完整的文件经验。

这不是“所有 Mac 文件都装双层盒”的死规矩。已有明确 MIME 类型、资源叉又不存在或微不足道的文档，可以像普通 MIME 正文一样寄出。没有数据叉的文档则必须用 AppleSingle：根本没有独立数据值得分到第二格。其余尤其是资源叉内容重要、或数据没有合适标准类型的文件，才是 AppleDouble 的主场。RFC 按文件实际携带的东西选择包法，而不是让每个附件参加同一套仪式。

邮件的老脾气仍在。AppleSingle 的二进制流和 AppleDouble 的二进制文件头，经过限制较严的邮件链路时可能需要传输编码；RFC 把 Base64 列为最稳妥的选择。作者还建议写 name 参数，让收件人知道附件叫什么。这个名称受 MIME 继承的语法约束，只能用七位 US-ASCII。文件内部两副行李可以安全同行，行李牌上的字母却还是老规格。这是九十年代邮件系统的一处滑稽接缝。

AppleDouble 的关键不是把 Mac 文件改造成别的电脑的文件，而是安排谁负责拆箱。普通数据以标准 MIME 类型露面；Mac 特有的资源与桌面信息守住自己的隔层。不同机器可以从同一封信里取走自己理解的部分，完整性和可读性不再抢同一个座位。

RFC 1740 读起来像一份附件格式说明，落到人的动作上却很简单：把一张图片寄给使用别种电脑的同事，他能打开图片；把同一个附件送回 Mac，资源和 Finder 信息也还在。信封只有一个，里面终于有了两个抽屉。