按：本文是少数派会员内容的试读文章。如果对本文感兴趣，欢迎考虑订阅少数派会员，获得专属内容、独家周边、会员社区和定期优惠等多项福利。
引言
苹果是一家做什么的公司？不同代际的用户可能有不同印象。七零后可能会想到农业公司，八零后可能会想到电脑公司，九零后可能会想到手机公司，零零后可能会想到服务公司。
的确，这些年来，服务在苹果营收中的占比持续提高，到 2022 财年已占五分之一强，是 iPhone 以外最高的比例。具体举措上，苹果这两年一直在扩充 iCloud、支付等服务的功能，加强在自制剧和独家流播内容方面的投入，拓展 App Store 的变现能力。即使你并不关心这些，大概也能从 iPhone 上日益增多的「植入广告」，感受到苹果向你推销自家服务的急迫心情。
但苹果的「到群众中去」也伴随着「从群众中来」；与服务范围扩大相同步的，是收集个人信息的需求。尽管苹果一直试图维护尊重和保护隐私的形象，总体而言确实也做的不错；但它也绝非「两袖清风」，收集和保留的数据范围比大多数人以为的都要多。
那么，作为普通用户，如何更好地了解苹果到底对自己知根知底到什么程度呢？
一个相对利好的背景是，随着世界各地不断加强对科技公司收集和使用个人数据的监管，「数据迁移权」（the right to data portability）也成为一项普遍要求。根据这项权利，个人用户有权向个人数据的控制者要求查询、复制、转移数据。例如：
- 2018 年 5 月生效的欧盟《通用数据保护条例》（GDPR）最早规定了数据迁移权（Article 20(1)-(2)）；
- 科技公司扎堆的加州在 2020 年初正式推行了《消费者隐私法案》（CCPA），其中包含数据迁移权的规定（Cal. Civ. Code §§ 1798.110(a)(5), (b); 1798.130(a)(3)(A) ）；
- 在国内，分别于 2021 年初和年底生效的《民法典》（第 1037 条）和《个人信息保护法》（第 45 条）也规定了查阅、复制个人信息的权利。国家推荐标准 GB/T 35273—2020《信息安全技术 个人信息安全规范》对于范围和响应流程做了进一步规范（第 8.6—8.7 条）。
作为一家跨国公司，苹果对此必然有所响应。2018 年，它几乎踩着 GDPR 生效的时间点上线了「请求获取数据拷贝」功能，随后在当年 11 月扩展到了美国等其他多个服务区。因此，目前网上能找到的体验和介绍，大多也是当时撰写的。
但一晃五年过去，苹果的服务疆域相比当年已经大大拓宽，当时的评论可能已经不适用了。那么，这五年中，苹果它有没有对数据导出功能做及时更新，反映新的服务类型和功能？导出流程和数据格式有没有发生变化？导出数据的实用性如何，提供了哪些平时不易获得的信息？这就是本文要观察的主题。
[ 注： 本次测试使用笔者自己的常用账号作为导出对象，为美区账号。但根据写作时使用其他账号的额外确认，中国区账号也支持数据导出；事实上，导出数据中还专门有一项是与苹果官方微信客服的沟通记录。]
导出方法和初步观察
提交请求、等待和下载
针对数据导出功能，苹果在官网提供了一份比较完整的指南，大致步骤如下：
首先，前往苹果的隐私专页 privacy.apple.com，登录后选择「请求获取数据拷贝」，然后选择要导出的数据类型。
目前，苹果提供了 17 种可供导出的数据类别，这与 2018 年功能刚上线时基本相同，只是增加了一项后续推出的 NFC 收款（Tap to Pay）功能相关数据。
[ 注： 本次测试有意未选择 iCloud 照片，原因是：iCloud 照片导出有更简单快捷的官方方案（例如使用 Mac 或 PC 下载，或要求转移到 Google Photos）和第三方方案（如基于 Python 的脚本 icloud_photos_downloader），无需等待就能发起下载；此外，照片已经将关键数据存储在其自身的元信息中，苹果额外存储的主要是相册分类、分享记录和评论等软件功能层面的信息，意义有限。出于类似原因，本次也没有要求导出易于直接复制备份的 iCloud Drive 文件。]
接下来的界面中，可以选择是否要把导出数据拆成特定大小的分块。如果你的数据比较多，特别是如果在前一步选择了导出 iCloud Drive、iCloud Photos 等较占空间的数据，用这个选项有助于避免因文件过大而中途下载失败、或者超出某些文件系统的单文件体积限制。
之后要做的就是等待了。页面提示称，最多需要七天来完成导出，我这次等了四天整，算是提前完成。但考虑到最近使用谷歌的 Takeout 服务导出账号数据时，前后总共只花了六个小时，苹果的效率着实不算高。当然，这比起简直相当于地老天荒的法定期限（国标和 GDPR 为 30 天，CCPA 为 45 天）还是快多了。
此外，从收到导出完成的通知邮件起，数据会在云端保留 14 天，与常见做法一致。
下载页面的布局与之前的请求界面基本相同，仍然根据数据类别分类，每个类别对应一个 ZIP 压缩文件。由于没有索要比较占地方的云盘和照片数据，我的下载体积并不大，12 种类别加起来还不到 900MB。
文件指南
页面右侧还可以下载解释导出数据含义的文件指南。但仿佛是故意要捉弄你，苹果给每种文件单独准备了一个 PDF 格式的指南，总数多达……273 份。更变态的是，这些指南的下载链接都是冒充成链接的按钮，既不能批量下载、也没有固定地址，必须逐个点击，通过临时生成的带令牌地址下载。（如果你跟我一样无聊的话……不客气。）
要这么隆重的仪式才能下载，让我本以为这些指南里一定有什么金玉良言；我太天真了。事实上，这些 PDF 文件只是用 Pages 生成、远低于苹果正常审美水准的简陋文档，每个文件的主体部分就是数据字段和解释说明的对照表；换句话说，本可以通过一个简明的文档页面统一列举，而不是采用笨重和不便检索的 PDF 格式。
不过，来都来了，我们还是尽量从里面多打捞些信息。注意到每个 PDF 的封面都标注了文件的更新时间，不妨看看哪些导出数据是新近提供或修订的。运行：
for i in {19..22}; echo "20$i:" && rga --stats "[A-Z][a-z]+\s+20$i" | rg matches[ 注： rga (ripgrep-all) 是一个可以对 PDF、EPUB 和 Office 文档进行纯文本搜索的鸡血版 ripgrep。如果你生活中经常和这些格式打交道，请相信我它可以改变你的生活。]
结果为：
2019:
133 matches
133 files contained matches
2020:
37 matches
37 files contained matches
2021:
30 matches
30 files contained matches
2022:
65 matches
65 files contained matches可见，超过半数的数据格式都在 2020 年及以后更新过，还是挺努力的。如果再以 2022 为关键词搜索，可以发现去年的更新主要集中在 Apple Music 和 AppleCare 相关数据；下文也将表明这正是最为实用的两类数据。
目录结构和文件数量
下面看看拿到的文件本身。12 个压缩文件解开后，我得到了 29 个目录和子目录，其中又包含 180 个文件。但这其中很多本身又是压缩文件，有的打包的内容还相当多（例如 Apple_Media_Services.zip 中含有近百个目录和文件），因此实际的文件数量还要多出不少。
将内嵌的压缩文件也充分解压后，就得到了下图所示的「果园全景图」：
（如果你想看大码的。）
文件格式
在审阅实际内容之前，不妨先看看苹果交来的都是什么格式的文件。根据官方文档：
Apple 会以原始格式或易于打开和阅读的行业标准格式提供你的数据。照片、视频和文稿会以原始格式提供。通讯录、日历、书签和邮件会以
.vcf、.ics、.html和.eml等格式提供。App 使用信息会以电子表格或文件（采用.json、.csv或
实际情况如何呢？运行：
sort << EOF | uniq -c | sort -r
$(for i in **/*; echo "${i##*.}")
EOF（我知道这有点歪门邪道，但省事啊。）
结果为：
111 vcf
110 csv
22 json
15 ics
7 xml
5 pdf
. . .除掉 .vcf（联系人名片）、.ics（日历）和 PDF 这三种交付原始附件的格式，可以看出占据绝对多数的是 CSV 格式，只有少数是 JSON 和 XML 格式。这显著区别于 ZDNET 在 2018 年时的报道，当时，苹果主要是通过 Excel 表格格式（.xlsx）交付数据的。
苹果为什么要改用 CSV 格式呢？这可能有一部分合规的考虑。GDPR 和 CCPA 对于导出数据的形式都有一定要求：前者规定数据必须采用「常用」且「机器可读」的格式（Recital 68, GDPR）；后者规定电子数据必须采用「直接可用」（readily usable）的格式，以便用户无阻碍地进行转移（Cal. Civ. Code § 1798.130(2)(A)）。
虽然这都没有对格式做具体限定，但 CSV 作为一种更简单、不受制于任何专属权的格式，肯定比 Excel 格式更贴近法规要求。例如，英国数据保护机构 ICO 的网站就指出，如果一种格式需要用户额外下载软件才能打开，无论这种软件本身有多么普及，都不能算是「常用」格式。（中国法规暂时没有类似规定，只有还在征求意见阶段的《网络数据安全管理条例》提出了「便捷」和支持「结构化查询」的要求。）
当然，如果说苹果还有点「小心思」，不想在自家功能中给对头微软打广告，那也是可以理解的。
那为什么不选择同样是开放格式的 JSON 和 XML 呢？可能是考虑到存储的经济性：它们都是以「啰嗦」著称的格式。如果说 CSV 就像是把表格逐行抄一遍，用逗号表示纵向分割线；那么它俩是在抄到每一格的时候都把那一列的标题也抄一遍，轻轻松松就可能花到两倍以上的篇幅。苹果导出的数据中，恰恰有很多动辄几十列的超宽表格，如果都用 JSON 和 XML，场面可能就过于「壮观」了。（.xlsx 格式本质上是由多个 XML 文件和元信息、资源文件组成的压缩包，只会更占用空间。）
当然，选择 CSV 也是有代价的。它的语法实在过于简单，几乎到了无法无天的程度。如 RFC 4180 所述，CSV 根本没有统一的规范，以至于诸如换行符的类型、引号是否视为区分字段类型的依据、以何种形式存储编码信息等关键细节，实践中都是自说自话。因此，在处理 CSV 文件格式时遇到数据错位、字符乱码等问题都不是什么稀罕事。（对 CSV 有兴趣的朋友请千万不要错过日本邮政的 KEN_ALL.csv，一个凭实力被开发者称为「地狱」的畸形怪胎。）
而苹果交过来的 CSV 格式，质量也确实可谓堪忧：有的不能通过标准语法校验，有的字段内部还嵌套着 JSON 格式数据，还有的在一个文件中放着三个完全不同的表格。毫无疑问，苹果自己的服务器上是不可能用这种数据结构存储的；它违反了哪怕最低阶的数据库规范化形式（1NF，要求包括属性不可再分），只能说明是将查询到的数据草率缝合后提供给用户的。如果硬抠法条，这大概也不是完全合规的：法规要求数据「机器可读」，但机器看到这种文件大概就已经死机下线了。
值得关注的文件和数据
了解完导出数据的规模和类型，剩下的就是一头扎进文件了。虽然上面批评了苹果在提供解释文档时的低效做法，但好在它给大多数文件起的名字都一目了然，不需要对照解释也能看出用途。显然，大多数文件也是枯燥乏味的，这里也没有必要一一列举。
不过，连篇累牍之中总归有一些相对更重要的文件，其中有的反映出日常不易察觉的数据收集规模，有的则提供了其他方法难以获得的有价值信息。下文中，我们就以下载得到的压缩文件为序，分别挑选其中值得一提的文件做具体分析。
Apple ID 账号和设备信息（Apple ID account and device information）
Apple ID Account Information.csv 保存了 Apple ID 基本信息历次更新的记录。如果不看这个文件，你可能不知道苹果眼中，自己 Apple ID 的「基本信息」就多达 77 种；除了基本的名称、联系方式、付款方式等，还包括一些非常细节的设置，例如推广内容偏好、高级数据保护功能的开启状态等。因此，这份文件很适合用来了解自己账户的犄角旮旯，以及备份留档。
[ 注：本文配图中的信息已经过处理和修改，其中 * 字符是苹果交付的原始文件中就已经隐去的部分，其他遮挡的内容为不影响理解的个人信息。]
Apps Using Sign In with Apple.csv 和 Hide My Email Information.csv 是两个与登录有关的列表，分别记录了「使用 Apple 登录」和「隐藏邮件地址」的使用历史、绑定的应用程序或网站等；很多条目或许早就被你遗忘了。这两项记录虽然在设置中也能查到，但步骤繁琐、响应缓慢，手头留一个这样的 CSV 表格会方便很多。
Apple 媒体服务信息，第 1 部分（Apple Media Services information Part 1 of 2）
这部分的重点资料存在其中嵌套的 Apple_Media_Services.zip 压缩文件，顾名思义是与苹果的音乐、图书、视频等媒体服务有关的用户数据。
其中，大多数人最关心的可能就是 Apple Music Activity 目录下的音乐数据。诚然，Apple Music 本身的互通性还可以，曲库信息、播放列表等信息都可以通过桌面端的 Music 应用导出，也可以由第三方软件通过 API 或者设备端的 MusicKit 访问；但即使这样，Apple Music Activity 目录收录信息的范围也是更全面、查阅起来更容易的。
例如，Apple Music Play Activity.csv 是一个事无巨细的播放历史，除了一般理解的曲目信息、播放时间之外，还包括客户端的各类诊断信息，例如设备类型、软件版本、IP 地址；以及与播放事件相关的用户行为分析，例如是从哪个界面点击播放、停止播放的原因等等。
一个比较有趣的发现是，苹果就 Apple Music 收集的数据有一定冗余：除了 Apple Music Play Activity.csv 这个「大合集」，还有很多其他文件也包含播放历史，只是时间和信息收录范围各有差异；苹果给出的解释是服务于不同用途。例如，Apple Music - Track Play History.csv 只记录了歌手和曲名、播放时间和是否用户发起，其用途是提供「为你推荐」页面的关联推荐；另有一个 Playback Activity.csv 文件，把音乐、视频、播客的播放记录整合在一起，其目的则是提供跨设备同步。
除了播放记录外，同样有留档价值的包括：
Apple Music - Top Content.csv（根据播放频次排列的歌手和流派列表）；Apple Music Likes and Dislikes.csv（收藏和点踩的记录）；以及Apple Music Library Activity.json（对音乐库的所有操作记录）等。
显然，这些数据都是算法推荐的重要依据，但苹果平时并未提供方便的查询入口，第三方工具也无法通过 API 拿到相同完整度的信息；数据导出是用户唯一能面见它们的机会。
Apple Music 之外的媒体服务信息则存储在 Stores Activity 下以相关服务为名的子目录。其中最有用的可能是：
Apple Books Information下的Apple Books Global Annotations.json（所有 Books 应用中的高亮和批注信息）；
Apple TV and Podcast Information下的Podcasts Playstate.csv（播客播放信息）和TV App Favorites and Activity.json（Apple TV 观看和收藏记录）；以及Other Activity子目录下的Arcade App Usage.csv（Arcade 游戏游玩记录）、Fitness Plus Activity.csv（Fitness+ 健身课程记录）。
此外，最不能错过的是各个文件名含有 Click Activity 字样的文件。如果问你：是否还记得多年前某次兑换礼品卡的时候，有没有输错过兑换码、中途有没有点击过取消、网络有没有卡顿？或者你是在哪个百无聊赖的午后、通过怎样的一通乱点找到了新的「宝藏歌手」？大多数人可能只会摇摇头。
但苹果帮你记得一清二楚。例如，下面的片段来自 App Store Click Activity.csv（简明起见已略去大量不重要字段），其中完整记录了我某次使用 App Store 的全过程，从启动、搜索、购买到退出的细节无一遗漏：
最后，如果你有任何类似于「钱都去哪了」的疑问，Stores Activity/Account and Transaction History 目录有你要的答案：
Store Transaction History.csv记录着所有付费应用和内容的购买或退款记录（免费内容单独记录在Store Free Transaction History.csv中）；Subscription History.csv则是订阅制产品年年月月从你钱包暗渡陈仓的血泪史；
- 对于贵人多忘事的朋友，第三方应用授权记录（
App Authorization History.csv）和手动隐藏的购买项目（iTunes and App Store Hidden Purchases.csv）也有存档备查价值。
值得注意的是，这部分数据中，IP 地址的出现频率明显更高，而且是未经任何遮挡或去特征化处理的原始 IP 地址；而其他导出数据大多只记录到 IP 地址的大致位置，或者隐去靠后的子网数字。或许苹果认为，在涉及钱的问题上，风控的优先级比隐私更高吧。
Apple.com 和 Apple Store
既然提到了钱，除了数字内容外，实体产品才是真正的大头；这就是下一个压缩文件 Apple.com and Apple Store.zip 的主题。
这里，Transaction History 目录存放了你通过苹果官网下过所有订单的记录（Online Purchase History.csv，包括配送和到店提货，基本就是官网商城「订单」页面的文字版），以及还在进行中的分期付款（Apple Retail Financing Information.csv）。
至于那些未经预约直接到店发生的消费，则可以在 Transaction History/Retail Store Receipts.zip 中找到 PDF 格式的收据副本。
接下来重点看 AppleCare.zip，这里保存着保修和售后相关的所有记录。其中，最重要的又属 AppleCare Support/Applecare Device Details.csv 中的设备保修信息。
不幸的是，这就是前面在介绍数据格式时提到的、「品相」最差的一批数据（从文件名里的大小写就开始乱来了），本质上是把多达四个不同的表格混在了一个文件中，完全无视了 CSV 格式的基本语法。
但让我们暂时不纠缠细节，先看看内容。文件中杂糅的四个表格分别是：
- 账号绑定过所有设备的购买和发货日期；
- 法定保修起止日期；
- AppleCare 服务期限（没有单买过 AppleCare 服务的新设备也会列上自带的支持期限，例如 iPhone 自带的 90 天电话支持）；以及
- AppleCare 协议编号和账单地址。
显然，这些信息在寻求售后时非常重要，但平时散落在邮件和收据中，急用时往往只能在操作缓慢的官网渠道手动查询；相比之下，这个文件可以说是把做好的功课送到了面前，不点赞收藏都对不起它的好意。
至于你与苹果售后斗智斗勇的历史，则存放在同目录下的 AppleCare Cases.csv 中。无论通过网页聊天、电话还是邮件联系售后，都会在这里留下一个案例记录，以及相关的设备序列号和订单号。
相比于只能查到最近 90 天案例的网页版，这里可以一直追溯到你帐号的创世纪；不过，最大的看（笑）点还是客服填写案例名称的风格是多么因人而异，而胡诌程度却又多么一以贯之。（如果在咨询之后发生了到店维修事件，则会在 AppleCare Repairs and Service.csv 中单独记录相关信息。）
其他数据
剩下的文件相对而言就没有那么重要，主要是一些 iCloud 服务的零散信息，存储格式还五花八门，可见苹果也只是随便一把抓起来扔给用户。这些文件的保存价值不是很高，因为诸如书签、通讯录、日历等备份性质的信息，反倒是直接从对应应用中导出来得更方便。
其中，相对值得一看的是 Other Data Part 2 of 3.zip，其中列举了很多平时不太容易意识到苹果也会上传服务器的信息，例如：
- 邮件和日历中的近期联系人（
Recents.xml，用于提供地址自动补全、骚扰拦截等功能）； - 地图中的收藏和标记（
Maps/Maps_Location_Attributes.json，例如「家」和「公司」等）； - 已登录的 WiFi 名称（
Wi-Fi/KnownNetworks.xml）； - 甚至于你有没有看 macOS 升级后的新功能弹窗介绍，苹果都会用小纸条偷偷记下来（
QuickTour.xml）。
最后，如果你关心 iCloud Drive 的使用情况，iCloudUsageData Set1.zip 中有一个解压后体积数十兆的同名 CSV 文件，记录了近一个月 iCloud Drive 的操作记录，包括发起操作的设备信息、应用信息和具体的操作内容，还包括具体到城市和 ASN 的 IP 地址信息（但没有记录实际地址）。这个文件也存在「杂糅」的毛病，最下方还混进了 iCloud 照片图库的操作记录和 iCloud 设备定期同步记录。
结语
总的来说，苹果的数据导出给我的印象是合格的。从导出过程看，功能入口明显、操作简单，认证、下载等环节也没有设置人为障碍，除了等待时间偏长就没有明显缺点。从导出结果看，虽然前面关于数据格式的规范性多有批评，但从另一个角度看也算一种「实诚」：索要的数据类型都如数提供，而且没有做明显的删减或保留。与 2018 年这项功能刚推出时媒体报道的情况相比，也能看出苹果的持续改进，例如扩展和修订数据内容，换用更通用的格式等。
可以认为，苹果数据导出功能的水准已经追平了谷歌、Meta 等更早推行该功能的平台，并与之互有胜负；比起国内那些靠几行无关痛痒的账户信息敷衍了事的平台（见澎湃新闻在 2021 年底对 50 个应用所做调研），优势就更不用说了。
但我们不妨把标准再定得高一点；除了看在形式上是否符合法规和行业标准，也要关注实质上能否达到目的。法律之所以要规定数据查阅和迁移权，其目的除了满足用户知情权这一个人信息保护的基本目标，也是要强化用户对自己数据的控制权，降低在平台之间的迁移成本，防止那种因顾虑数据丢失被迫锁定在特定服务商（vendor lock-in）的问题。
从这个目标出发，假设你正准备逃出苹果的「围墙花园」，是否觉得凭借导出功能获得的数据足以完成顺利迁移呢？答案恐怕是否定的，哪怕数据表面上已经相当完整。
正如任何使用过「歌单搬家」服务的人都会有的体会：仅仅将曲库从一个平台搬到另一个平台，远不足以在新平台获得与之前相同准确的个性化推荐，因为这往往是需要通过长期使用而「磨合」「训练」出来的，其影响因素远多于用户有感知、可导出的范围。特别是随着 AI 技术在今后的普遍使用，这种从输入数据到使用体验之间的跃迁只会越来越明显、迅速和不可预测。
从这个角度说，现有法律规定的数据迁移权只是一个最低门槛，帮助用户实现数据自由的第一步。问题的解决不可能只靠数据迁移权的规定、以及机械遵循这些规定提供的数据本身，而要依靠更偏效果导向而不是过程导向的改进标准，以及与针对数据透明度、互操作性等规定的合力。例如，根据欧盟去年底生效的《数字市场法》（Digital Markets Act），到 2024 年 3 月，包括苹果在内的「守门人」平台必须进一步保障数据迁移权，提供「持续和实时」的个人数据访问功能（Article 6(10)）。按照这个标准，苹果（以及目前大部分平台）的数据导出功能就不合格了，且看它们这次会如何早做打算。
不过，即使不能指望数据导出功能帮助我们自由切换平台，本文也鼓励读者积极尝试用它来导出自己的数据。如上文分析表明，这些数据是一种很好的辅助存档和自我教育的方式：一方面，通过数据导出功能，可以获得不少平时无法查询或者完整查询很麻烦的账户信息，例如详细保修信息、订阅服务详单、歌单操作历史等。这些信息本身就颇有存档价值，或者能用来自我分析使用习惯和偏好。另一方面，数据导出也是我们为数不多能对数据收集活动产生直观印象的机会。包括我自己在内，大多数人可能都会把同意隐私政策当作一个过场，即使偶尔有闲多看两眼，也未必能把那些（故意为之的）抽象描述和实际数据建立起联系。但当这些数据以更为原始的形态直接呈现在眼前时，就很难不感触于其颗粒度之细、信息量之大。
也正因如此，我认为苹果数据导出功能的最需要改进的地方，在于没有很好地帮用户理解数据。在最基本的层面上，文件指南不应该藏在层层点击之后，也不应该做成几百个难用的 PDF 格式，而是应该主动提供。这方面，谷歌在导出文件中附带一个网页版目录和说明书的做法可资参照。
进一步说，对于收集数据的详细解释和演示本就不应是用户前来索要时才做的工作，而最好提前到注册、使用阶段，例如作为隐私政策中的示例，与隐私政策披露的收集类型一一对应。
回到标题提出的问题：啃了一口的苹果可以打包带走吗？答案是可以，但目前而言还是保量不保质、保鲜不保味。对此，苹果的义务是持续改进打包技术，让用户带走的东西分量充足、风味不改；而用户的义务则是别嫌麻烦，多多尝试——别忘了，这些苹果的发芽生长，本就有你出的一份力，也本该追随你的脚步。
