篇一：超大机群上的简单数据处理
A单词频率统计
本节包含了一个完整的程序,用于统计在一组命令行指定的输入文件中,每一个不同的单词出现频率.
#include "mapreduce/mapreduce.h"
//用户map函数
class WordCounter : public Mapper {
public:
virtual void Map(const MapInput& input) {
const string& text = input.value();
const int n = text.size();
for (int i = 0; i < n; ) {
//跳过前导空格
while ((i < n) && isspace(text[i]))
i++;
// 查找单词的结束位置
int start = i;
while ((i < n) && !isspace(text[i]))
i++;
if (start < i)
Emit(text.substr(start,i-start),"1");
}
}
};
REGISTER_MAPPER(WordCounter);
//用户的reduce函数
class Adder : public Reducer {
virtual void Reduce(ReduceInput* input) {
//迭代具有相同key的所有条目,并且累加它们的value
int64 value = 0;
while (!input->done()) {
value += StringToInt(input->value());
input->NextValue();
}
//提交这个输入key的综合
Emit(IntToString(value));
}
};
REGISTER_REDUCER(Adder);
int main(int argc, char** argv) {
ParseCommandLineFlags(argc, argv);
MapReduceSpecification spec;
// 把输入文件列表存入"spec"
for (int i = 1; i < argc; i++) {
MapReduceInput* input = spec.add_input();
input->set_format("text");
input->set_filepattern(argv[i]);
input->set_mapper_class("WordCounter");
}
//指定输出文件:
// /gfs/test/freq-00000-of-00100
// /gfs/test/freq-00001-of-00100
// ...
MapReduceOutput* out = spec.output();
out->set_filebase("/gfs/test/freq");
out->set_num_tasks(100);
out->set_format("text");
out->set_reducer_class("Adder");
// 可选操作:在map任务中做部分累加工作,以便节省带宽
out->set_combiner_class("Adder");
// 调整参数: 使用2000台机器,每个任务100MB内存
spec.set_machines(2000);
spec.set_map_megabytes(100);
spec.set_reduce_megabytes(100);
// 运行它
MapReduceResult result;
if (!MapReduce(spec, &result)) abort();
// 完成: ’result’结构包含计数,花费时间,和使用机器的信息
return 0;
}
Google三大核心技术之二：GFS
GFS是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，但可以提供容错功能。它可以给大量的用户提供总体性能较高的服务。
1、设计概览
（1）设计想定
GFS与过去的分布式文件系统有很多相同的目标，但GFS的设计受到了当前及预期的应用方面的工作量及技术环境的驱动，这反映了它与早期的文件系统明显不同的设想。这就需要对传统的选择进行重新检验并进行完全不同的设计观点的探索。
GFS与以往的文件系统的不同的观点如下：
1、 部件错误不再被当作异常，而是将其作为常见的情况加以处理。因为文件系统由成百上千个用于存储的机器构成，而这些机器是由廉价的普通部件组成并被大量的客 户机访问。部件的数量和质量使得一些机器随时都有可能无法工作并且有一部分还可能无法恢复。所以实时地监控、错误检测、容错、自动恢复对系统来说必不可 少。
2、按照传统的标准，文件都非常大。长度达几个GB的文件是很平常的。每个文件通常包含很多应用对象。当经常要处理快速增长的、包含数以 万计的对象、长度达TB的数据集时，我们很难管理成千上万的KB规模的文件块，即使底层文件系统提供支持。因此，设计中操作的参数、块的大小必须要重新考 虑。对大型的文件的管理一定要能做到高效，对小型的文件也必须支持，但不必优化。
3、大部分文件的更新是通过添加新数据完成的，而不是改变已 存在的数据。在一个文件中随机的操作在实践中几乎不存在。一旦写完，文件就只可读，很多数据都有这些特性。一些数据可能组成一个大仓库以供数据分析程序扫 描。有些是运行中的程序连续产生的数据流。有些是档案性质的数据，有些是在某个机器上产生、在另外一个机器上处理的中间数据。由于这些对大型文件的访问方 式，添加操作成为性能优化和原子性保证的焦点。而在客户机中缓存数据块则失去了吸引力。
4、工作量主要由两种读操作构成：对大量数据的流方式 的读操作和对少量数据的随机方式的读操作。在前一种读操作中，可能要读几百KB，通常达 1MB和更多。来自同一个客户的连续操作通常会读文件的一个连续的区域。随机的读操作通常在一个随机的偏移处读几个KB。性能敏感的应用程序通常将对少量 数据的读操作进行分类并进行批处理以使得读操作稳定地向前推进，而不要让它来来回回的读。
5、工作量还包含许多对大量数据进行的、连续的、向文件添加数据的写操作。所写的数据的规模和读相似。一旦写完，文件很少改动。在随机位置对少量数据的写操作也支持，但不必非常高效。
6、系统必须高效地实现定义完好的大量客户同时向同一个文件的添加操作的语义。
（2）系统接口
GFS提供了一个相似地文件系统界面，虽然它没有向POSIX那样实现标准的API。文件在目录中按层次组织起来并由路径名标识。
（3）体系结构：
一 个GFS集群由一个master和大量的chunkserver构成，并被许多客户（Client）访问。如图1所示。Master和 chunkserver通常是运行用户层服务进程的Linux机器。只要资源和可靠性允许，chunkserver和client可以运行在同一个机器 上。
文件被分成固定大小的块。每个块由一个不变的、全局唯一的64位的chunk－handle标识，chunk－handle是在块创建时 由 master分配的。ChunkServer将块当作Linux文件存储在本地磁盘并可以读和写由chunk－handle和位区间指定的数据。出于可靠 性考虑，每一个块被复制到多个chunkserver上。默认情况下，保存3个副本，但这可以由用户指定。
Master维护文件系统所以的元 数据（metadata），包括名字空间、访问控制信息、从文件到块的映射以及块的当前位置。它也控制系统范围的活动，如块租约（lease）管理，孤儿 块的垃圾收集，chunkserver间的块迁移。Master定期通过HeartBeat消息与每一个 chunkserver通信，给chunkserver传递指令并收集它的状态。
与每个应用相联的GFS客户代码实现了文件系统的API并与master和chunkserver通信以代表应用程序读和写数据。客户与master的交换只限于对元数据（metadata）的操作，所有数据方面的通信都直接和chunkserver联系。 客 户和chunkserver都不缓存文件数据。因为用户缓存的益处微乎其微，这是由于数据太多或工作集太大而无法缓存。不缓存数据简化了客户程序和整个系 统，因为不必考虑缓存的一致性问题。但用户缓存元数据（metadata）。Chunkserver也不必缓存文件，因为块时作为本地文件存储的。
（4）单master。
只 有一个master也极大的简化了设计并使得master可以根据全局情况作出先进的块放置和复制决定。但是我们必须要将master对读和写的参与减至 最少，这样它才不会成为系统的瓶颈。Client从来不会从master读和写文件数据。Client只是询问master它应该和哪个 chunkserver联系。Client在一段限定的时间内将这些信息缓存，在后续的操作中Client直接和chunkserver交互。
以图1解释一下一个简单的读操作的交互。
1、client使用固定的块大小将应用程序指定的文件名和字节偏移转换成文件的一个块索引（chunk index）。
2、给master发送一个包含文件名和块索引的请求。
3、master回应对应的chunk handle和副本的位置（多个副本）。
4、client以文件名和块索引为键缓存这些信息。（handle和副本的位置）。
5、Client 向其中一个副本发送一个请求，很可能是最近的一个副本。请求指定了chunk handle（chunkserver以chunk handle标识chunk）和块内的一个字节区间。
6、除非缓存的信息不再有效（cache for a limited time）或文件被重新打开，否则以后对同一个块的读操作不再需要client和master间的交互。
通常Client可以在一个请求中询问多个chunk的地址，而master也可以很快回应这些请求。
（5）块规模：
块规模是设计中的一个关键参数。我们选择的是64MB，这比一般的文件系统的块规模要大的多。每个块的副本作为一个普通的Linux文件存储，在需要的时候可以扩展。
块规模较大的好处有：
1、减少client和master之间的交互。因为读写同一个块只是要在开始时向master请求块位置信息。对于读写大型文件这种减少尤为重要。即使对于访问少量数据的随机读操作也可以很方便的为一个规模达几个TB的工作集缓缓存块位置信息。
2、Client在一个给定的块上很可能执行多个操作，和一个chunkserver保持较长时间的TCP连接可以减少网络负载。
3、这减少了master上保存的元数据（metadata）的规模，从而使得可以将metadata放在内存中。这又会带来一
些别的好处。
不利的一面：
一个小文件可能只包含一个块，如果很多Client访问改文件的话，存储这些块的chunkserver将成为访问的热点。但在实际应用中，应用程序通常顺序地读包含多个块的文件，所以这不是一个主要问题。
（6）元数据（metadata）：
master 存储了三中类型的metadata：文件的名字空间和块的名字空间，从文件到块的映射，块的副本的位置。所有的metadata都放在内存中。前两种类型 的metadata通过向操作日志登记修改而保持不变，操作日志存储在master的本地磁盘并在几个远程机器上留有副本。使用日志使得我们可以很简单 地、可靠地更新master的状态，即使在master崩溃的情况下也不会有不一致的问题。相反，mater在每次启动以及当有 chuankserver加入的时候询问每个chunkserver的所拥有的块的情况。
A、内存数据结构：
因为metadata存储在内存中，所以master的操作很快。进一步，master可以轻易而且高效地定期在后台扫描它的整个状态。这种定期地扫描被用于实现块垃圾收集、chunkserver出现故障时的副本复制、为平衡负载和磁盘空间而进行的块迁移。
这 种方法的一个潜在的问题就是块的数量也即整个系统的容量是否受限与master的内存。实际上，这并不是一个严重的问题。Master为每个 64MB的块维护的metadata不足64个字节。除了最后一块，文件所有的块都是满的。类似的，每个文件的名字空间数据也不足64个字节，因为文件名 是以一种事先确定的压缩方式存储的.如果要支持更大的文件系统，那么增加一些内存的方法对于我们将元数据（metadata）保存在内存种所获得的简单 性、可靠性、高性能和灵活性来说，这只是一个很小的代价。
B、块位置：
master并不为chunkserver所拥有的块的副本的保存一个不变的记录。它在启动时通过简单的查询来获得这些信息。Master可以保持这些信息的更新，因为它控制所有块的放置并通过HeartBeat消息来监控chunkserver的状态。 这样做的好处：因为chunkserver可能加入或离开集群、改变路径名、崩溃、重启等，一个集群重有成百个server，这些事件经常发生，这种方法就排除了master与chunkserver之间的同步问题。
另一个原因是：只有chunkserver才能确定它自己到底有哪些块，由于错误，chunkserver中的一些块可能会很自然的消失，这样在master中就没有必要为此保存一个不变的记录。
C、操作日志：
操作日志包含了对metadata所作的修改的历史记录。它作为逻辑时间线定义了并发操作的执行顺序。文件、块以及它们的版本号都由它们被创建时的逻辑时间而唯一地、永久地被标识。
操作日志是如此的重要，我们必须要将它可靠地保存起来，并且只有在metadata的改变固定下来之后才将变化呈现给用户。所以我们将操作日志复制到数个远程的机器上，并且只有在将相应的日志记录写到本地和远程的磁盘上之后才回答用户的请求。
Master可以用操作日志来恢复它的文件系统的状态。为了将启动时间减至最小，日志就必须要比较小。每当日志的长度增长到超过一定的规模后，master就要检查它的状态，它可以从本地磁盘装入最近的检查点来恢复状态。
创 建一个检查点比较费时，master的内部状态是以一种在创建一个检查点时并不耽误即将到来的修改操作的方式来组织的。Master切换到一个新的日子文 件并在一个单独的线程中创建检查点。这个新的检查点记录了切换前所有的修改。
篇二：数据库集群部署
1.1 ORACLE GI
1.1.1 创建安装 OCR，VOTEDISK和ORADATA磁盘
注意：一下磁盘划分是根据某局某处安装编写的文档，其中磁盘组和逻辑卷的命名都统一，只有磁盘设备的选择需要根据各点的具体情况来划分。
在sfrac1节点执行
创建磁盘组
[root@sfrac1 ~]# vxdg -s init ocrvotedg aluadisk0_4
[root@sfrac1 ~]# vxdg -s init oradatadg aluadisk0_1
[root@sfrac1 ~]# vxdg -s init ftpdg aluadisk0_5
[root@sfrac1 ~]# vxdg -s init dbbakdg aluadisk0_10
[root@sfrac1 ~]# vxdg -s init ftpbakdg aluadisk0_11
[root@sfrac1 ~]# vxdg -s init oradatadgud aluadisk0_13
[root@sfrac1 ~]# vxdg -s init ftpdgud aluadisk0_14
[root@sfrac1 ~]# vxdg -s init ocrvotedgud aluadisk0_1
分别创建逻辑卷
[root@sfrac1 ~]# vxassist -g ocrvotedg make ocrvotevol maxsize
[root@sfrac1 ~]# vxassist -g oradatadg make oradatavol maxsize
[root@sfrac1 ~]# vxassist -g ftpdg make ftpvol maxsize
[root@sfrac1 ~]# vxassist -g dbbakdg make dbbakvol maxsize
[root@sfrac1 ~]# vxassist -g ftpbakdg make ftpbakvol maxsize
[root@sfrac1 ~]# vxassist -g oradatadgud make oradatavoludmaxsize
[root@sfrac1 ~]# vxassist -g ftpdgud make ftpvoludmaxsize
[root@sfrac1 ~]# vxassist -g ocrvotedgud make ocrvotevoludmaxsize 启动卷
[root@rac1 ~]# vxvol -g ocrvotedg startall
[root@rac1 ~]# vxvol -g oradatadg startall
[root@sfrac1 ~]# vxvol -g ftpdg startall
[root@sfrac1 ~]# vxvol -g dbbakdg startall
[root@sfrac1 ~]# vxvol -g ftpbakdg startall
[root@sfrac1 ~]# vxvol -g oradatadgud startall
[root@sfrac1 ~]# vxvol -g ftpdgud startall
[root@sfrac1 ~]# vxvol -g ocrvotedgud startall
1.1.2 创建文件系统并挂载
创建文件系统并挂载在同一挂载点
在一个节点上执行
mkfs -t vxfs /dev/vx/rdsk/ocrvotedg/ocrvotevol
mkfs -t vxfs /dev/vx/rdsk/oradatadg/oradatavol
mkfs -t vxfs /dev/vx/rdsk/ftpdg/ftpvol
mkfs -t vxfs /dev/vx/rdsk/ftpbakdg/ftpbakvol
mkfs -t vxfs /dev/vx/rdsk/dbbakdg/dbbakvol
mkfs -t vxfs /dev/vx/rdsk/oradatadgud/oradatavolud
mkfs -t vxfs /dev/vx/rdsk/ftpdgud/ftpvolud
mkfs -t vxfs /dev/vx/rdsk/ocrvotedgud/ocrvotevolud
在所有节点上执行
mkdir /ocr
mkdir /oradata
mkdir /ftp
mkdir /ftpbak
mkdir /dbbak
mount -t vxfs -o cluster /dev/vx/dsk/ocrvotedg/ocrvotevol /ocr mount -t vxfs -o cluster /dev/vx/dsk/oradatadg/oradatavol /oradata mount -t vxfs -o cluster /dev/vx/dsk/ftpdg/ftpvol /ftp
mount -t vxfs -o cluster /dev/vx/dsk/ftpbakdg/ftpbakvol /ftpbak/ mount -t vxfs -o cluster /dev/vx/dsk/dbbakdg/dbbakvol /dbbak/ 确认配置成功
df -k
1.1.3 将ocr和vote添加到VCS资源组
修改VCS配置为读写权限
haconf -makerw
配置加入CVM资源组
hares -add ocrvote_voldg_ocrvotedg CVMVolDg cvm
hares -modify ocrvote_voldg_ocrvotedg Critical 0
hares -modify ocrvote_voldg_ocrvotedg CVMDiskGroup ocrvotedg hares -modify ocrvote_voldg_ocrvotedg CVMVolume -add ocrvotevol hares -modify ocrvote_voldg_ocrvotedg CVMActivation sw VCS下配置文件系统
hares -add ocrvote_mnt_ocrvotedg CFSMount cvm
hares -modify ocrvote_mnt_ocrvotedg Critical 0
hares -modify ocrvote_mnt_ocrvotedg MountPoint "/ocr" hares -modify ocrvote_mnt_ocrvotedg BlockDevice \
"/dev/vx/dsk/ocrvotedg/ocrvotevol"
链接资源关系
hares -link ocrvote_voldg_ocrvotedg cvm_clus
hares -link ocrvote_mnt_ocrvotedg ocrvote_voldg_ocrvotedg hares -link ocrvote_mnt_ocrvotedg vxfsckd
开启资源
hares -modify ocrvote_voldg_ocrvotedg Enabled 1 hares -modify ocrvote_mnt_ocrvotedg Enabled 1 修改VCS配置为只读
haconf -dump -makero
将资源启动
hares -online ocrvote_voldg_ocrvotedg -sys sfrac1 hares -online ocrvote_voldg_ocrvotedg -sys sfrac2 hares -online ocrvote_mnt_ocrvotedg -sys sfrac1
hares -online ocrvote_mnt_ocrvotedg -sys sfrac2
确认资源已经在每个节点启动
hares -state ocrvote_voldg_ocrvotedg
hares -state ocrvote_mnt_ocrvotedg
每个节点修改权限
[root@rac1 opt]# chown -R grid:oinstall /ocr
[root@rac1 opt]# chown -R oracle:oinstall /oradata/ 正确配置截图
所有组合资源online
1.1.4 使用oracle OUI安装GI
上传安装包
p13390677_112040_Linux-x86-64_3of7.zip
至rac1下面的/opt目录
解压
unzip p13390677_112040_Linux-x86-64_3of7.zip 生成grid目录
通过本地图形界面安装或者使用Xmanger4远程安装。 使用grid用户运行命令
/opt/grid/runInstaller
跳过更新
篇三：微信聊天记录查看器(程序+源码)
微信聊天记录查看器（程序+源码）
摘要
iPhone中的微信是不是占用了越来越多的空间呢？不想删图片？不舍得删视频？那就转移到电脑硬盘上来吧，在Windows中使用本软件进行查看、搜索，手机上的空间就可以腾出来了！本文详细介绍了软件的使用说明，以及介绍了微信聊天记录数据存储格式，并给出了本软件与源代码的下载地址，最后是iPhone聊天记录中图片与视频数据的清理方法。
1. 前言
随着使用微信的日子变长，手机中微信所占用的空间也越来越大，iPhone的存储空间也日益紧缺，其中图片、视频所占的空间最大，像我这样什么都要追求完整性的人，是坚持不会删除任何一张照片或视频的，喜欢用手机拍照片视频的我，每过一段时间就把照片视频移到电脑存储，腾空手机。可是到了每一两天都要腾空间的时候，我发现这样不是长久之道，看了看微信已经占用了2个多G的空间，这样下去不是办法，现在腾讯官方没有iOS版本微信的聊天记录转储硬盘工具（Android的好像有）；即便有，在Windows上要求能够像在手机上查阅；微信内置的聊天记录备份恢复功能是为转储到其它设备设计的，聊天记录在服务器只能存放７天，而且2G这么大的数据要上传到候年马月？
因此，干脆自己写一个聊天记录查看器吧，把数据挪到电脑大硬盘，这样就可以放心地在手机上删图片、视频啦 。以下先给出本人开发的微信聊天记录查看器的使用说明，以及本人分析猜测的聊天记录数据存储格式，可是不全，只能显示最主要的数据内容，感兴趣的朋友可以一块分析完善。
2. 使用说明
首先说明，该软件目前仅支持iPhone上的微信聊天记录。以下分别对软件的使用方法进行详细说明。
2.1 数据转储
使用 iTools 等第三方工具将微信（WeChat）应用中 Documents 目录导出到电脑硬盘保存，该目录中包含所有在此 iPhone 上登录过的微信帐号的聊天记录，也可以只导出某一个帐号的聊天记录。每一个微信帐号的数据都存储在以该微信ID的MD5值为名称的文件夹中，例如，图2-1中 Documents 目录下32位数字名称的文件夹分别是不同的微信帐号。
图 2-1 Documents目录示例
2.2 选择数据库
聊天记录数据库文件存放在微信帐号文件夹内的 DB 文件中，文件名为 MM.sqlite。本文最后将提供一个聊天记录例子，程序运行时会提示选择数据库文件，选择以下文件即可：06af9525a11ebb4f49ec72be6d165d10\DB\MM.sqlite。
2.3 主界面
启动软件，选择数据库加载完成后，程序的主界面如图2-2所示，左侧是该微信帐号的好友列表，按拼音首字母排序，右侧是具体的聊天记录内容。好友列表分为3个标签页，分别是“好友”、“群”、“其它”，顾名思义，单独好友在“好友”标签页，群聊天在“群”标签页，剩下的订阅号、服务号等等在“其它”标签页。好友列表上方可以搜索好友，聊天内容上方可以搜索文字。点击好友列表中的好友，右侧的聊天内容窗口将加载与该好友聊天的具体内容。
由于本程序采用的是EO.WebBrowser控件试用版（博主穷~
会影响后续阅读。 ），每次程序启动后，聊天内容窗口下侧会出现购买许可的提示，关闭它即可，不
图 2-2 微信聊天记录查看器主界面
2.4 数据类型
2.4.1 文字
就像手机中显示的那样，采用气泡风格显示，如图2-3所示。
图 2-3 数据类型示例：文字
2.4.2 表情
可以显示微信自带的小型emoji表情，如图2-4所示。可以显示的所有emoji表情请参见图2-5。
图 2-4 数据类型示例：emoji表情
图 2-5 所有能显示的 emoji
除了 emoji 以外，还可以显示微信官方的动画表情，如图2-6所示。
图 2-6 数据类型示例：动画表情
除了这两种表情以外，微信用户还经常看到许多非官方表情，如果想在这软件里显示的话，需要进行额外的数据导出工作，也不复杂：照样使用 iTools 打开微信App的这个目录：/Library/WechatPrivate/emoticon1，将此文件夹复制到本软件的安装目录，覆盖原有的 emoticon1 文件夹即可。
2.4.3 图片
聊天记录中的图片如图2-7所示，点击图片将会调用本机默认的 *.jpg 文件关联程序来查看大图，默认的程序是 Windows Photo Viewer。
图 2-7 数据类型示例：图片
2.4.4 视频 & 小视频
聊天记录中的视频与小视频如图2-8所示，点击视频将会调用本机默认的 *.mp4 文件关联程序来观看视频。
图 2-8 数据类型示例：视频 & 小视频
2.4.5 语音
聊天记录中的语音如图2-9所示，点击将会播放语音内容。
图 2-9 数据类型示例：语音
2.4.6 分享链接
聊天记录中的分享链接如图2-10所示，点击链接将会调用浏览器查看原网页。
图 2-10 数据类型示例：分享链接
2.4.7 位置信息
聊天记录中的位置如图2-11所示，点击链接将会调用浏览器查看具体的地图信息，如图2-12所示。
图 2-11 数据类型示例：位置信息
图 2-12 浏览器查看具体的位置信息
2.4.8 名片
聊天记录中的名片消息如图2-13所示。
图 2-13 数据类型示例：名片
2.4.9 语音、视频电话
聊天记录中的语音、视频电话只能给出当时的通话时长等信息（微信是不可能录制你的通话内容D），如图2-14所示。
图 2-14 数据类型示例：语音、视频电话
2.5 搜索好友
当好友数据众多时，从左侧的好友列表上方搜索栏内输入好友的关键字，可以是中文，也可以是拼音，但目前版本不能是拼音首字母，例如：搜“张三”，可以输入“张”、“三”、“zhangsan”或“zhangs”等等，但不能输入“zs”
。当输入内容时，搜索结果窗口将即时出现，并列入符合关键字的好友，
如图2-15所示。点击搜索结果的好友，将自动加载与他聊天的内容。
图 2-15 搜索好友示例
2.6 搜索聊天内容
聊天内容的搜索分为“搜索当前好友”与“搜索所有好友”，在聊天内容窗口上方的下拉框选择即可。在搜索栏内输入关键字，回车后将进行搜索，搜索结束后将显示搜索结果列表，点击某条记录后，聊天内容窗口将显示并高亮关键字，如图2-16所示。这里提示：搜索所有好友耗时将比较长。
图 2-16 搜索聊天内容示例
2.7 页面跳转
聊天内容窗口右上角是导航按钮，可进行翻页。若页数过多时，可以直接单击页数，将弹出跳转页面的输入窗口，输入想要查看的页码后将跳转至该页面，如图2-17所示。
图 2-17 页面跳转示例
3. 微信聊天记录格式
聊天记录的根目录是以用户微信ID用户名（不一定是微信ID，见下文）的MD5哈希值为名的文件夹。下文假设root为根目录。聊天记录最主要的内容是一个SQLite类型的数据库文件MM.sqlite，路径是root\DB\MM.sqlite。以下是本人对此数据库内容格式的分析结果。
3.1 数据表
这里先讲两个本软件用到的数据表，分别是Friend表与Chat_XXX表，XXX表示好友微信ID的MD5值。
3.1.1 Friend表
这个表存储了所有的联系人，除了好友以外，还包括非好友、订阅号、服务号等等。
(1) 字段：type
该字段可以将好友的类型进行分类，由于本软件只分成了好友、群、其它等3类，所以下面这个表大家就参考着看吧，在本软件的代码中没有用上。
表 1-1 Friend 数据表 type
可见，第0位表示该联系人是否已添加好友；第6位表示该好友是否加星标；第8位表示该好友是否被屏蔽朋友圈；第11位表示该好友是否在手机的好友列表中置顶。等等等等，本人愚昧，只悟出这么多，剩下的大家感兴趣的可以去分析。
(2) 字段：UsrName
UsrName字段中，以“gh_”开头的都是订阅号、服务号，以“@chatroom”结尾的都是群。
3.1.2 Chat_XXX表
XXX表示好友微信ID的MD5值，每一个好友的记录都存放在单独一个表当中。
(1) 字段：Message
代表该消息记录的具体内容。
(2) 字段：Type
代表该消息的类型，在第3.2节有具体说明。
(3) 字段：Des
0表示本人发的信息，1表示对方发的信息。
(4) 字段：CreateTime
日期转换：CreateTime字段存储的是Unix时间戳，在sql语句中通过以下方式可以转换：
select datetime(createtime, 'unixepoch', 'localtime') from chat_XXX
3.2 信息类型
3.2.1 文本
聊天记录的数据库文件为：root\DB\MM.sqlite。
Friend表存储所有好友的信息，字段UsrName是唯一标识好友的ID，但不一定是微信ID，若用户是用QQ号申请的微信，则UsrName是qq12345678形式，若使用微信ID申请的话，则UsrName就是微信ID，若使用手机号申请的话，则UsrName就是wxid_XXXXX形式。不管怎样，将此UsrName进行MD5运算，得到的哈希值，前面加上“Chat_”得到的字符串，就是存放与此好友所有聊天记录的表名，如：Chat_a500325c723649ddb75eda10635edf82。群组也是一样。
Friend表的ShortPY字段存储了有好友的备注信息，但是编码不一样。
聊天记录表中，Message字段就是与该好友的聊天记录的所有信息，若是文本，则直接存储，其它格式，请见下面章节。其中CreateTime字段是信息产生的时间；Des字段若为0则是用户向好友发送的信息，若为1则是好友发送过来的信息；其中Type字段若为1，则该信息是文本信息。
3.2.2 图片
在好友的聊天记录表中，假设为 Chat_ a500325c723649ddb75eda10635edf82 表，若字段Type为3，则该信息是图片。MesLocalID字段是数字，假设为“407”，图片存储在root\Img\a500325c723649ddb75eda10635edf82\下的“407.pic”，其中“407.pic_thum”是该图片的缩略图。
3.2.3 视频
在好友的聊天记录表中，假设为 Chat_ a500325c723649ddb75eda10635edf82 表，若字段Type为43，则该信息是视频。MesLocalID字段是数字，假设为“8011”，视频存储在 root\Video\a500325c723649ddb75eda10635edf82 下的“8011.mp4”，其中“8011.video_thum”是该视频的缩略图。
3.2.4 小视频
在好友的聊天记录表中，假设为 Chat_ a500325c723649ddb75eda10635edf82 表，若字段Type为62，则该信息是小视频。MesLocalID字段是数字，假设为“8011”，视频存储在 root\Video\a500325c723649ddb75eda10635edf82 下的“8011.mp4”，其中“8011.video_thum”是该小视频的缩略图。
建材加盟网友情提示：多打电话、多咨询、实地考察，可降低投资风险！
Copyright © www.yuan0.cn Corporation, All Rights Reserved 共享时代 共享你我他 版权所有