解析 FB-Purity 的 Firefox idb（索引数据库 API）object_data 来自 Linux bash 的 blob
Parsing FB-Purity's Firefox idb (Indexed Database API) object_data blob from Linux bash
从 Linux bash 脚本中，我想读取由名为 FB-Purity 的特定 Firefox 附加组件存储的结构化数据。
我找到了一个名为 .mozilla/firefox/b8eab5j0.default/storage/default/moz-extension+++37a9788c-671d-4cae-ba5c-fbdb8788499a^userContextId=4294967295/ 的文件夹，其中包含一个 .metadata 文件，其中包含字符串 moz-extension://37a9788c-671d-4cae-ba5c-fbdb8788499a，一个 URL 在 Firefox 中打开时显示添加- on的详细信息，所以我很确定这个文件夹属于插件。
该文件夹包含一个 idb 目录，听起来像 Indexed Database API, a W3C standard apparently used since last year by Firefox 它用于存储附加组件数据。
idb 文件夹只包含一个空文件夹和一个 SQLite 文件。
不幸的是，SQLite 文件不包含太多应用程序结构化数据，但是 object_data table 包含一个 95KB 的 blob，它可能包含真正的结构化数据：
INSERT INTO `object_data` VALUES (1,'0pmegsjfoetupsf.742612367',NULL,NULL,
X'e08b0d0403000101c0f1ffe5a201000400ffff7b00220032003100380035003000320022003a002
2005300610074006f0072007500200055007205105861006e00690022002c00220036003100350036
[... 95KB ...]
00780022007d00000000000000');
问题：知道这个 blob 的格式是什么吗？如何将其提取（使用命令行或任何库或 Linux 工具）为 JSON 或任何其他可读格式？
好吧，我今天度过了愉快的一天，解决了这个问题，并结束了创建一个 Python 工具的过程，该工具可以从这些 indexedDB 数据库文件中读取数据并打印它们（有时可能更多）：https://gitlab.com/ntninja/moz-idb-edit
先回答问题的技术部分：
- 名称
key（名称）和 data（值）都使用 Mozilla 专有格式，目前唯一的文档似乎是其源代码。
- 密钥使用特殊的专用编码，其粗略描述可在 mozilla-central/dom/indexedDB/Key.cpp – the file also contains the only known implementation. Its unique selling point appears to be the fact that it is relatively compact while being compatible with all the possible index types websites may throw at you 中找到，并且默认采用正确的二进制排序顺序。
- 这些值是使用 SpiderMonkey 的内部 StructuredClone 表示存储的，在浏览器中的进程之间移动值时也会使用该表示。同样，no docs to speak of but one can read the source code which fortunately is quite easy to understand. Before being added to the database however the generated binary is compressed on-the-fly using Google's Snappy compression“不以最大压缩为目标 [而是……] 以非常高的速度和合理的压缩为目标”——考虑到我们在这里处理浪费的网络内容，这可能不是一个坏主意。
- 要为扩展的本地存储数据找到正确的 indexedDB 文件，需要将扩展的静态 ID 解析为所谓的“内部 UUID”，其值在每个浏览器配置文件实例中都不同（以基于安装插件要困难得多）。此映射 table 在 prefs.js 中存储为 pref（“extensions.webextensions.uuids”）。那么 IDB 路径是 ${MOZ_PROFILE}/storage/default/moz-extension+++${EXT_UUID}^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite
出于所有实用意图和目的，您可以通过下载上述项目来读取任何扩展的单个存储密钥的值。基本用法是：
$ ./moz-idb-edit --extension "${EXT_ID}" --profile "${MOZ_PROFILE}" "${STORAGE_KEY}"
其中 ${EXT_ID} 是扩展的静态 ID（检查它的 manifest.json 文件，如果您不确定，请查看 about:support#extensions-tbody），${MOZ_PROFILE} 是 Firefox 配置文件目录（也在 about:support) 中，${STORAGE_KEY} 是您要查询的键的名称（不幸的是，尚不支持查询所有键）。
目前也不支持写入数据。
我会在实现更多功能时更新此答案（或在项目页面上给我发个问题！）。
从 Linux bash 脚本中，我想读取由名为 FB-Purity 的特定 Firefox 附加组件存储的结构化数据。
我找到了一个名为 .mozilla/firefox/b8eab5j0.default/storage/default/moz-extension+++37a9788c-671d-4cae-ba5c-fbdb8788499a^userContextId=4294967295/ 的文件夹，其中包含一个 .metadata 文件，其中包含字符串 moz-extension://37a9788c-671d-4cae-ba5c-fbdb8788499a，一个 URL 在 Firefox 中打开时显示添加- on的详细信息，所以我很确定这个文件夹属于插件。
该文件夹包含一个 idb 目录，听起来像 Indexed Database API, a W3C standard apparently used since last year by Firefox 它用于存储附加组件数据。
idb 文件夹只包含一个空文件夹和一个 SQLite 文件。
不幸的是，SQLite 文件不包含太多应用程序结构化数据，但是 object_data table 包含一个 95KB 的 blob，它可能包含真正的结构化数据：
INSERT INTO `object_data` VALUES (1,'0pmegsjfoetupsf.742612367',NULL,NULL,
X'e08b0d0403000101c0f1ffe5a201000400ffff7b00220032003100380035003000320022003a002
2005300610074006f0072007500200055007205105861006e00690022002c00220036003100350036
[... 95KB ...]
00780022007d00000000000000');
问题：知道这个 blob 的格式是什么吗？如何将其提取（使用命令行或任何库或 Linux 工具）为 JSON 或任何其他可读格式？
好吧，我今天度过了愉快的一天，解决了这个问题，并结束了创建一个 Python 工具的过程，该工具可以从这些 indexedDB 数据库文件中读取数据并打印它们（有时可能更多）：https://gitlab.com/ntninja/moz-idb-edit
先回答问题的技术部分：
- 名称
key（名称）和data（值）都使用 Mozilla 专有格式，目前唯一的文档似乎是其源代码。 - 密钥使用特殊的专用编码，其粗略描述可在 mozilla-central/dom/indexedDB/Key.cpp – the file also contains the only known implementation. Its unique selling point appears to be the fact that it is relatively compact while being compatible with all the possible index types websites may throw at you 中找到，并且默认采用正确的二进制排序顺序。
- 这些值是使用 SpiderMonkey 的内部 StructuredClone 表示存储的，在浏览器中的进程之间移动值时也会使用该表示。同样，no docs to speak of but one can read the source code which fortunately is quite easy to understand. Before being added to the database however the generated binary is compressed on-the-fly using Google's Snappy compression“不以最大压缩为目标 [而是……] 以非常高的速度和合理的压缩为目标”——考虑到我们在这里处理浪费的网络内容，这可能不是一个坏主意。
- 要为扩展的本地存储数据找到正确的 indexedDB 文件，需要将扩展的静态 ID 解析为所谓的“内部 UUID”，其值在每个浏览器配置文件实例中都不同（以基于安装插件要困难得多）。此映射 table 在 prefs.js 中存储为 pref（“extensions.webextensions.uuids”）。那么 IDB 路径是 ${MOZ_PROFILE}/storage/default/moz-extension+++${EXT_UUID}^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite
出于所有实用意图和目的，您可以通过下载上述项目来读取任何扩展的单个存储密钥的值。基本用法是：
$ ./moz-idb-edit --extension "${EXT_ID}" --profile "${MOZ_PROFILE}" "${STORAGE_KEY}"
其中 ${EXT_ID} 是扩展的静态 ID（检查它的 manifest.json 文件，如果您不确定，请查看 about:support#extensions-tbody），${MOZ_PROFILE} 是 Firefox 配置文件目录（也在 about:support) 中，${STORAGE_KEY} 是您要查询的键的名称（不幸的是，尚不支持查询所有键）。
目前也不支持写入数据。
我会在实现更多功能时更新此答案（或在项目页面上给我发个问题！）。