杂谈 again

距离上一篇已经过了大半个月，这段时间发生了蛮多事。

2017年最后一晚喝的应该是阿贝乌干达加大冰，2018年第一杯是Hendricks的干马天尼，庆幸那晚连续喝了两杯烈酒后没有宿醉。

10号晚上微信数据库突然损坏，官方修复程序修复失败，直接清空了数据库，把我气得要死，于是先用备用机登着微信，以保护主机的本地文件，看看有没有机会抢救回来。

11号考完试，大约又是学校最后考完的一两批人。

13号斯米诺红到手，晚上糟蹋之。

15号的火车，发车晚点3小时，路上晚点1小时，无官方理由。

16号第一卷胶卷冲扫完，拿到手。

18号认真分析微信仅存的本地文件，最后以失败收场。

今天先说说微信数据库的东西吧，可能比较枯燥。不想附图，太懒了。

微信数据库出问题应该也称不上是个小概率事件了，据不知道可不可靠的资料显示，损坏比例约为0.02%，万里挑二。出问题的原因大约包括设备空间不足、电量不足、文件同步失败。

我出问题当天微信占用1.2G，手机容量剩余800+M，电量30%左右，所以说实话我是不太明白。

更重要的问题是微信官方修复程序的修复成功率比较低，又据不知道可不可靠的资料显示修复率大约为30%，而我就这么幸运的成为了0.02%里的70%了。

数据库清空后，发现微信所占的空间减少了200+M，所以想尝试是否有机会修复。

官方途径失败了，去找第三方，网上有比较多的国产流氓软件，xx恢复大师之流，下了一个试用，发现可以扫描出来所有文本信息，不过想要恢复就要付128。想让我付钱？不太可能。知道了本地文件还留存着信息，于是自己折腾试试。

很绝望的发现，我的MM.sqlite只有1.03M，WCDB_Contact.sqlite 5.98M正常。

装上DB Browser for SQLite来看一下数据库里的内容。

MM.sqlite有若干个表组成，其中聊天记录存放在Chat_***的表里，***是对方username的MD5码，有多少个聊天就有多少个这样的表，后面详细讲。

而WCDB_Contact.sqlite里主要信息存放在friend的表里，里面的字段有username, type, rtificationFl, imgstatus等。

username跟前面提到的一样，type是二进制的12位数，对应的是好友的星标、置顶、屏蔽、是否好友等信息，rtificationFl大约是判断类型的，一般好友是0，公众号是8，服务号是24，微信官方是56，自己找规律摸索的，可能有误。

imgstatus有0-3共4个值，大概是头像吧。

前面数据库的chat_***里每一条数据对应着一条信息，有一些关键字段，MeslocalID, MesSvrID, CreatTime, Message, Status, ImgStatus, Type, Des，一个个来讲。第一个是信息的本地ID，从1开始按顺序编号，是表中的码。第二个按名字来看应该是服务器的ID，这个让我比较头大，每条信息的这个值都是一个比较庞大的数值。第三个是信息对应的时间，采用的是unix时间戳。message顾名思义是信息内容，status有2和4两个值，对应发与收，最后一个Des有0和1两个值，一样的意思。ImgStatus应该是信息是否包含图片吧，1是纯文字，另外还有2 5 6几个值或者更多，对应分享推送、表情等等。Type是信息的类型，据自己摸索，发现了这些，10000代表撤回，62是短视频，50是语音或视频通话，49是链接，48是地理位置，47是表情，43是视频，42是名片，34是语音，3是图片，1是文字。

通过偶然的发现，在fts目录下找到了另外的数据库fts_message.db，有足足132M，打开查看发现新大陆，文字信息都在里面，以上提到的xx大师大约就是靠这个数据库吧。

仔细分析，里面有几个表，主要内容是fts_message_table_0/1/2/...9为首的几个表，还有个fts_username_id的表。前者一个table共有4个表，其中一个无后缀无内容，还有三个**_content, **_segdir, **_segments的表，其中内容存放在content表里，无后缀的是虚表，对应三个真实表格来保存信息，其余两个应该是起结构作用，先不管他们。思路在于能否将fts数据库内容修改成主数据库的格式，如果可以的话就相当于手工恢复了。问题就在于主数据库所需要的字段是否都能拿到。先看一下content表里的内容。

和主数据库不同，没有把每个人单独分在一个表里，而是所有人分成10个表进行存放，里面的字段主要有c0UsernameID，c1MesLocalID，c2CreateTime，c3Message，第一个的id不是md5值，而是普通的数字，而其余三个都与前面说的一样，似乎有希望。usernameID到底是什么呢，注意到数据库里还有一个表fts_username_id，打开看一看。

主要字段有usernameID，username，tableid。username和主数据库一样，usernameID对应table表，tableid是该用户数据存放在哪个table里。

非文字内容是分开储存的，Audio, Draft, Img, Video里有若干个以MD5为名的文件夹，里面就存放了语音、草稿、图片、视频这些内容，语音是aud文件，好像就是缺少文件头的amr，手动加上之后就可以播放了。

分析完了开始比对，比对完之后就开始感到绝望了。信息缺少最重要的收发分辨值，以及不知道是否必需的服务器id，缺了这些内容，连尝试都没办法尝试。

后来仔细看了一下流氓xx大师的试用界面，也是不能分辨信息的收发，而且只能恢复成网页的形式查看，我就知道他们用的手段跟我的大致相同，没希望了。

fts其实不是别的，是SQLite的全文检索，在搜索聊天记录时，为了提高搜索速度，另外做了个简易的表出来使用，仔细想想在微信界面搜索的情况就明白fts到底删了些什么不必要的字段了。

无奈，认命了，手动导出csv储存在电脑里吧。

导出整理之后一共有48万+条内容，也是蛮唬人的，存成时间-用户-信息的excel表，批量做vlookup的时候把CPU跑满了，最后存下来29M。稍微分类汇总，排了下序，千条以上都认了人备注了。

不得不说数据真是蛮唬人的，统计数据从2015年9月到2018年1月10号。

第一个9w多的，内容其实只从2017年7月开始，算了。

处理好之后把手机的数据清空了，重新再来吧 :-)

毕竟，一无所有是最适合重新开始的时机，不是吗？

不是。

已经太晚了。

不过，错过了最佳时机，次佳的时机应该就是现在了吧。重新来吧。

另外，有人反映这个黑背景只有上吊的灯泡看着压抑。我只是单纯看中这个准确三分构图。

完美啊，再滑稽一下。

好吧，有什么头像推荐可以发给我过目，采纳无奖。

下一次写东西不知道什么时候，看心情吧。