备选标题（按我自己觉得的点击欲排序）：
- App本地SQLite数据导出实操：先摸清陌生表结构，再动手写Python
- 导出别人App的SQLite数据，我第一版脚本全删了——问题出在没看懂表
- 面对一个陌生的SQLite文件，我是怎么一步步把它读明白的
起因：一条“Apple图书笔记能导出了”的分享
前几天在论坛翻到一条分享，作者说自己一直用苹果自带的图书App看书，但这玩意儿没有开放接口，笔记导不出来。他搜了一圈，发现可以直接去读iCloud里那个SQLite数据库，然后基于AI做了个笔记导出的小工具，还放了GitHub仓库。
我当时的第一反应不是“哦又一个导出脚本”，而是——这条路子太通用了。你手机、电脑上装的一堆App，本地存数据十有八九用的就是SQLite。
只要文件能拿到、没加密，理论上你自己的数据你就能自己导。
说真的，我过去写的东西基本都是“自己建库、自己往里塞数据”，表长什么样心里门儿清。而这次是反过来的：一个别人建的、你压根没参与设计的库，扔在你面前，让你把里面的东西捞出来。
这个反向场景，坑和之前完全不是一回事。
我第一版脚本，写完就删了
先说个丢人的。我拿到一个App的本地db文件（就是我自己那台设备上的数据，先声明一下），想都没想就开干：连上、`SELECT * FROM` 一把梭，导成CSV。
结果导出来的东西根本没法看。笔记的正文在一张表里，书名在另一张表里，两张表靠一个我看不懂的ID字段关联；时间戳是一串诡异的数字，不是常见的Unix秒；还有一堆字段全是空的，或者存的是二进制。
我对着CSV看了半天，愣是拼不出“哪条笔记属于哪本书”。
第一版就这么废了。回头复盘，问题特别清楚：我跳过了最关键的一步——先看懂这张库长什么样，就急着写导出。
真正该先做的：把表结构摸清楚
后来我老老实实换了顺序。别急着写代码，先当个考古的，把这个陌生库里里外外看一遍。
我的做法是把db文件丢进SQLite编辑器里，先不查数据，先看结构。具体看这么几样：
一是有哪些表。很多App的库里表不止一张，有主数据表、有索引表、有一堆自动生成的辅助表（名字里带 `sqlite_` 或者一串下划线前缀的，通常不用管）。
先把跟你要的数据明显相关的那几张挑出来。
二是每张表的字段。挨个看列名和类型，猜每一列大概存的是什么。
列名有时候会骗人，比如叫 `ZANNOTATIONTEXT` 这种带前缀的（Core Data生成的库常见这德行），你得靠取几行真实数据来印证猜测。
三是表和表之间怎么连的。这一步最重要。
你要找出哪个字段是主键，哪个字段是外键——也就是“这张表的这一列，对应另一张表的哪一列”。摸清这个关系，你才能把散在几张表里的数据重新拼成一条完整记录。
看结构的时候我习惯边看边记，把“书名在A表的X列、笔记在B表的Y列、两者靠Z列关联”这种关系用大白话写下来。等真正动手写导出时，照着这张自己画的地图走就行，不用再回去猜。
关于那些“看不懂”的字段
摸结构的过程里，你一定会撞上几个看不懂的坑，提前打个预防针：
时间戳可能不是你熟悉的格式。有的库存的是从某个特殊起点算起的秒数，直接当Unix时间转会得到一个几十年前或者几十年后的离谱日期。
碰到日期不对劲，先别怀疑自己代码，去查一下这个字段的基准时间。
有些字段存的是引用而不是内容。比如笔记表里可能只存了一个书籍ID，书名得去另一张表查。
这也是为什么第一步“看懂表关系”省不得。
还有空字段和软删除。有些行看着在表里，其实是被标记删除的（某个字段是1或者0来区分）。
导出时得把这些过滤掉，不然你会导出一堆已经被用户删掉的脏数据。
这些东西，你光看列名是看不出来的，必须真的取几行数据出来对着看。所以“先看懂表”不是让你读一遍schema就完事，而是结构和真实数据一起看，互相印证。
结构摸清了，再写导出逻辑
把地图画明白之后，写导出反而是最轻松的一步。逻辑无非就是：连库、按你理清的表关系做关联查询、把时间戳这类字段转成人能看的格式、过滤掉软删除的行、最后输出成你要的格式（CSV、Markdown随你）。
我一般不在本地折腾环境，直接把处理脚本扔进Python在线运行里跑，改一版看一眼结果，不对就调，反馈很快。SQLite本来就是Python标准库自带的，不用额外装驱动，连上文件就能查，特别适合这种“边试边改”的活。
这里有个小心得：别想着一步到位写完美。先只导两三条出来，人眼核对一下——书名对不对、笔记内容全不全、时间对不对。
核对没问题了，再放开跑全量。我第一版就是栽在“没核对就全量导”上。
最后收拢成一个能反复跑的小工具
如果这事你只干一次，脚本跑完就完事了。但通常你会想隔段时间再导一次（比如又看了几本书、记了新笔记）。
这时候值得把脚本收拢成一个固定的东西：上传db文件、点一下、拿到导出结果，不用每次重新翻代码。
我的做法是把它发布成一个站内的在线工具，下次要用直接打开跑，省得每次都从头配。逻辑一旦跑通并且验证过，固化下来的收益比你想象的大——你不用再记“当时那个时间戳基准是多少”“哪张表是主表”，这些都已经写死在工具里了。
反常识的那一点
整件事最反直觉的地方在于：面对一个陌生数据库，写代码的时间可能只占两成，剩下八成全花在“看懂它”上。而大多数人（包括第一版的我）会本能地跳过看懂这一步，直接开写，然后在导出结果里发现全是乱账，再回头返工。
返工的时间远比老老实实先读一遍库要多。
所以如果你也想把某个App里自己的数据捞出来，记住顺序别搞反：先摸表结构和字段关系，取真实数据印证，画一张自己看得懂的地图，最后才动手写导出。
给你一个今天就能做的小动作：找一个你自己设备上、你有权访问的App本地db文件，别写任何代码，先把它打开，只做一件事——数一数里面有几张表，挑出跟你想要的数据最相关的那一张，把它的字段挨个看一遍，猜每一列存的是什么。就这一步，你会立刻明白为什么“先看懂表”这么关键。