database disk image is malformed数据库损坏的地方貌似找到了，不知道原因和处理方法

[kuyunjian]

可能确定了是源文件的问题，或者解密方式的问题
我有3个 qqdb 数据库
一个100MB 左右，一个 1 GB 左右，一个5.9GB 左右

1. 100MB 的可以直接用 sqlcipher 解密db 文件为未加密的 db 文件
2. 1 GB 的和 5.9GB 的均要在 Windows sqlcipher 解密成导出成 sql 文件，再用 msys2指令导出 sql 文件为 db 文件。msys2的这个指令把错误的行忽略跳过了，所以才能导出
3. 上面说到的msys2的指令是qq-nt-db里面的

$ cat nt_msg.sql | sed -e 's|^ROLLBACK;\( -- due to errors\)*$|COMMIT;|g' | sqlite3 nt_msg.db

---

经查看，我的 1 GB db数据库 c2c_msg_table 这个表在58990行开始，数据无法读取，如图所示。
该表格使用唯一 id 也就是40001行正序排列，该列与时间戳列的排序方式不一致，在无法读取的前一行，我查看时间戳是1742467919，（2025-03-20 18:51:59）与我导出整个数据库的时间无异
（关于排列方式，也可能考虑是直接把无法读取的数据库放在了后面，具体这些内容是什么，以及怎么解密，我不了解方法）
（值得一提的是，该数据库的group_msg_table 表并没有损坏)
下图的左边是 db 文件，导出为 sql 文件，再导入回 db 文件的 db 文件
右边是原始的 db 文件

---

---

在5GB db 数据库同样也出现了类似的问题，不过这次出问题的是 group_msg_table
有效的数据累计有130万条左右，包括无效的总的有700万条左右，按照首列唯一消息 id 排序，最后一条群聊消息的时间戳是1709012044（2024-02-27 13:34:25）通过筛选，可以筛选出不到36条比这个大的时间戳，但是全部是170开头的，除了有两条173开头的1737685884（2025-01-24 10:31:24）但是我在二五年的消息记录应该很多才对
故考虑是本来导出的db数据库就损坏，或者没有选对解密方式，而不是故意以另外的方式加密
下图为原始的 db 文件

---

---

在无法加载行的页面持续停留， Windows sqlcipher 不会持续加载
数据库这里的窗口太多，每次我拿 pixpin 截屏的时候，滑动鼠标滚轮扩大选取窗口的时候，pixpin 也不响应了

---

至此，数据库损坏的原因可能是清楚了，我在考虑用二进制查看器或者其他的什么，来查看一下这些损坏的数据。或者有没有办法修复？

这些损坏的数据导出为 csv 文件时，依然不能导出

Originally posted by @kuyunjian in #57

[kuyunjian]

时隔两天我重新导出一次数据库，1GB的那个号，依然是c2c_msg_table出现了问题，依然是第58989行开始不可读，但是结尾扩大了十行到80655（可能是那个号最近没发什么私聊，私聊消息总共增加就十条）
可能是不可读的那一行被特殊处理了，有一些东西在那里，我不知道怎么定位它在二进制的地方

基于上一篇issue，我怀疑其用windows sqlcipher导出为sql文件时就已经缺少了报错部分（待验证，因为1Gb的是sql是2GB的，并且不用上一篇issue提到的cat指令导入回db文件，直接用windows sqlcipher导入回db文件会导入完成但是实际表为空）

[kuyunjian]

基于上一篇issue，我怀疑其用windows sqlcipher导出为sql文件时就已经缺少了报错部分（待验证，因为1Gb的是sql是2GB的，并且不用上一篇issue提到的cat指令导入回db文件，直接用windows sqlcipher导入回db文件会导入完成但是实际表为空）

发现一个有趣的现象，符合我的猜想

我有两个db文件出错 ，1GB的和5GB的
以下未注明的操作均用windows sqlcipher完成

时隔两天我重新导出一次数据库，1GB的那个号，依然是c2c_msg_table出现了问题，依然是第58989行开始不可读，但是结尾扩大了十行到80655（也有可能是那个号最近没发什么私聊）

我把1GB的db文件输入key解密之后，导出sql文件是2.2GB，再导入回db文件显示导出完成但是表为空，必须要用cat指令忽略错误导入
我把5GB的db文件输入key解密之后，导出sql文件是1.7GB，再导入回db文件可以正确导入！但是依然和那个msys2用cat指令导出出来的一样，缺失了group_msg后面的一大段

这说明1GB那个sql文件是完整的（二编：并不完整，不包括了c2c_msg.table 错误的那部分）
(1GB的db文件查看时group_msg.table 没发生错误）
（5GB的db文件查看时c2c_msg.table 没发生错误）

留下问题

1. sql文件好像是可读的，希望借1GB的那个文件定位到错误的地方（二编：找不到，sql文件已经不包含错误部分）
2. 明明操作一样但是为什么导出的sql文件不同，我刚刚试了一下，单独把1gb的那个db文件错误的c2c_msg_table导出成sql文件同导出5GB的整体导出一样，并不能导出错误的部分（同1）
3. 5gb的那个错误发生在group_msg.table的130w行左右，但是1GB那个group_msg.table到了200w行都没错误，是内存的问题还是解压方式的问题，但是内存占用少的表格和那个100mb的qqdb 文件都没有发生错误
4. 可能值得一提的是，windows sqlcipher翻到这些正在加载中的行的时候，只是闪了一下正在加载中的标志，并没有像其它要加载的行，正在加载中完成之后加载出来，但是我通过时间戳查看，这段数据应该是要存在的，它们是24年2月之后的数据
   
   
   
   
   
   
   
   

5. 我最近还会尝试用qq自带的备份软件备份聊天记录到新小米手机上（和这部手机同是小米的，同样未升级hyperos）再导出看看会不会出现这种情况
6. 另外，听说安卓本身就是linux。小米备份出来的删掉头文件之后又可以用tar点gz解压。我打算用linux指令解压一下小米的压缩包。看看是不是解压的过程出了问题

[kuyunjian]

1. sql文件好像是可读的，希望借1GB的那个文件定位到错误的地方
2. 明明操作一样但是为什么导出的sql文件不同，我刚刚试了一下，单独把1gb的那个db文件错误的c2c_msg_table导出成sql文件同导出5GB的整体导出一样，并不能导出错误的部分

通过搜索唯一消息id，c2c_msg_table可读的最后一条，好像1GB的这个db文件导出成的sql文件已经不包含错误的部分，但是直接用windows sqlcipher导入回db文件会导入完成但是实际表为空
并且c2c_msg_table的条数和db数据库中可读条数相同
这个sql文件有2GB全是group文件的大小

留下问题
1.想找一个方法，用代码方式解密，输入迭代次数4000和sha1，sha512
并且不使用.output sql
而是直接查看错误的表的原始数据的方法吗

我怀疑这一部分像头文件一样在中间加了一些00或者什么东西

2. 最后一条可读数据，1G的是24年11月，5G的是24年2月，但也有三条25年1月的
3. 有人遇到一样的情况吗

[kuyunjian]

我看到这里还有一个相对较大的文件group_msg_fts.db，用5GB的这个qq举例
这里面有个表有481.1960w行，加上之前可读的130.9116w，是612.1076w行，应该要是736.1073w行才对
我搜了一下唯一消息id，发现group_msg_fts.db里面的群聊消息和nt_msg.db确实还有重复的部分

值得一提的是group_msg_fts.db里面的第一列是没有加密的文本，是不是群聊的文本消息都在这里？

[kuyunjian]

5. 我最近还会尝试用qq自带的备份软件备份聊天记录到新小米手机上（和这部手机同是小米的，同样未升级hyperos）再导出看看会不会出现这种情况

我把1GB的那个号备份聊天记录，用qq内置的手机聊天记录转移，转移到了另一个小米手机

1. 用同样的方法导出之后c2c_msg_table全部可读了（没有转移全部的聊天记录）

• 之前能读取5.8w/8.06w行，现在能读取所有的6w行（我没有备份所有的私聊到另一个手机上）

• 尤其是有最近的时间戳了，之前最新也就是24年一月的
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

2. 但是群聊的后半部分又加载不出来了，之前是加载的出来的（也考虑是我备份数据的时候中断，断在群聊的地方了）
   如果这样可行的话，我的方法是，要备份哪个群聊就备份那个群聊的消息到另一个手机
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   待测试:
   不去备份聊天记录到另一个手机，只重新登陆，刷新rand，再解密能不能刷新这部分可读的部分（猜测大概不能，因为24年11月之后我重新登陆过许多次1GB这个号，但也有可能，可能本来能读又刷新回去了这样）

[kuyunjian]

刚刚用 QQ 官方的聊天记录迁移，把手机的一 GB 的聊天记录完整迁移到了另一个手机。
这是我第一次迁移之后，把新手机的 QQ 数据全部清除，重新来了一次。所以这是第二次

这一次，我在 QQ 官方的迁移界面选择了仅文本迁移，数据包也小了许多
从原来的1GB多变成了890MB
值得一提的是，好像有部分图片id也是保存了的，但是既然db文件少了，不知道是少了哪些地方

---

---

---

---

---

---

这一次，1GB的数据库可以直接用 Windows sqlcipher完整解密了，并没有出现报错

后续还会尝试连带图片一起迁移，然后看一下数据库损坏的规律

。。。。。。

目前猜测是 QQ 产生聊天记录的过程中，因为内存过大，在某一些断点上卡掉了，但是他们自己的代码里面有修复这些断点的方法

但是对于用户来说，解密之后的数据经过这个断点就不能被 windows sqlcipher读取后续的数据
目前我看到唯一能通过代码解密出数据库的是qqnt_backup不过也不能处理错误数据

现在想有

1. 有大佬能做出用代码进行解密，但是不进行导出和另存为未解密的 db 文件（因为错误的数据并不能因为包含错误的数据并不能解密，只能用 commit 代替 rollback（上面多次提到和下面临时提到的cat命令）。但是这样会损失那一大部分错误的数据），但是仍然可以查看那部分不可读代码，中间有什么数据错误，片段错误

$ cat nt_msg.sql | sed -e 's|^ROLLBACK;\( -- due to errors\)*$|COMMIT;|g' | sqlite3 nt_msg.db

如何用命令行操作sqlcipher

2. 重复导出两次到小米手机，一次是有文本无图片的（数据库不会损坏）（5GB的群聊记录仍然损坏，而且损坏的行数不同，分批导出试试，也不是内存占用大的就一定损坏。之前我1GB 这个数据库 group msg table 表有200万行，没有发生错误，但是对应的 c2cmsg table 仅有几10万行就不可读了）一次是有文本有图片的，即使数据库损坏，也能有图片的索引以及图片。把两次综合起来就能得到完整。有文字、有图片的聊天记录

[kuyunjian]

经确认，所有群聊的文本聊天记录都被存在了group_msg_fts.db里面
而且第一列没有被加密，是直接可读的文本，不知道是不是群聊消息太多，需要适配解密功能
如果用这个文件的唯一消息id配上nt_msg.db会不会快很多
（不含图片索引）

等数据处理大佬（话说是不是可以直接分类导出excel了（）都不用数据处理了）

bytheway
我5GB的那个qqdb文件这个db文件同样报错了。。。
而且我把5Gb那个qq只备份最大的那个群聊尝试用官方的备份工具，一直卡在导入界面。。。

[kuyunjian]

group_msg_fts.db里面41704列
1是文本
3是文本带图
129是链接
4097是转发消息
2049疑似qq官方链接，比如WheatCloudSleep 官方文档 https://docs.qq.com/doc/DTHlKbHROTWNMYUd1，在聊天记录里查看时只有链接部分
4099是文本带图，上面有俩图片，下面有一图
17是带emjoy的（有一个是纯emjoy，有一条是文本，后面跟了一个 emjoy，但是后者没有显示emjoy）
577是bot
131是有图，有文本，有链接（三张图，然后一段文本，然后一段链接

[kuyunjian]

这一次，我在 QQ 官方的迁移界面选择了仅文本迁移，数据包也小了许多 从原来的1GB多变成了890MB 值得一提的是，好像有部分图片id也是保存了的，但是既然db文件少了，不知道是少了哪些地方

实测qq官方备份界面选择仅备份文字仍然会导出一定量的图片（不只是id），目前没去看什么逻辑，并且在备份后的手机，qq应用内删除这些图片并不会改变导出nt_msg.db文件的大小

目前增加一个逻辑：通过qq官方迁移软件备份的图片，再通过小米手机导出，会随图片一起导出（上一个issue说的53缩水到20，这个应该不会，只是应该）

[shenapex]

经确认，所有群聊的文本聊天记录都被存在了group_msg_fts.db里面

fts指的是full-text searches，这个后缀的数据库文件都是用来本地搜索的，这个在网站也有所提及

其他的恕我目前没有精力来解答🙃

[kuyunjian]

经确认，所有群聊的文本聊天记录都被存在了group_msg_fts.db里面

fts指的是full-text searches，这个后缀的数据库文件都是用来本地搜索的，这个在网站也有所提及

其他的恕我目前没有精力来解答🙃

哦哦是我没有仔细看完这些文档，我的我的

我还是卡在了我的5GB大db文件没办法无损导出（哭）

[artiga033]

我怀疑这一部分像头文件一样在中间加了一些00或者什么东西

至少从sqlite的实现上来讲，这几乎是不可能的，因为实际上没法判断某一列数据对应在文件的哪个字节偏移位置。应该还是你的导出过程产生的错误更有可能。比如导出的时候是否确定已经正常杀死QQ进程

一个建议是搞个root机或者模拟器然后直接去查/data看看(

以及这些“损坏的”数据在QQ客户端中是否能正常显示？如果是的话极大可能是你的导出过程有问题

---

把两次综合起来就能得到完整。有文字、有图片的聊天记录

这个直接用SQL就能实现，假设你已经打开了一个数据库，然后有另一个数据库文件为 2nd.db

ATTACH DATABASE '2nd.db' AS db2;
INSERT OR IGNORE INTO c2c_msg_table SELECT * FROM db2.c2c_msg_table;

不过如果按你的说法这个子查询可能直接报错就是了，但是如果你知道损坏数据的具体范围的话可以改一下后面的子查询直接跳过那部分数据