设计文件差异同步程序

[笨笨的小菜]

设计文件差异同步程序，要求如下：
a)假设在时间t1时，文件内容为file1；时间t2时，文件内容为file2.。
b)要求设计程序A,生成file1与file2的差量文件file3。
c)要求设计程序B,通过file3和file1得到文件file2。
d)file1, file2为任意格式的二进制数据文件。
e)file3的文件大小要尽量小，至少要小于file2的文件大小。
f)用C#、Java或C++语言实现

遇到的一个面试题，谁做过类似的呢，给点提示？

[gomoku]

假设file1为空文件，假设file2不可压缩。 那么差异文件file3一定不比file2小。

[devmiao]

google 最长公共子串

[笨笨的小菜]

引用 2 楼 devmiao 的回复:

google 最长公共子串

二进制格式也可以这样比较？

[devmiao]

引用 3 楼 lyh1234 的回复:

[quote=引用 2 楼 devmiao 的回复:] google 最长公共子串

二进制格式也可以这样比较？[/quote] 当然

[devmiao]

引用 6 楼 wlhkane110 的回复:

[quote=引用 2 楼 devmiao 的回复:] google 最长公共子串

很感兴趣 不过又没做过 想问下我这样的想法不知可不可行： 设File1数据表示为：byte[] File1；File2表示为：byte[] File2; 1：File1和File2生成File3: ①首先File2进行压缩，得到尽量少的压缩后的byte[] nFile2;nFile2.Length<File2.Length.（现在应该有现成的方法进行压缩和还原的吧？） ②这里提到了公共子串，假定File1[x]到File1[y]的数据与nFile2[a]-nFile[b]((y-x)==(b-a))。File3表示为byte[] File3。 那么我File3[a]设定标识字节 File3[a+1]=x File3[a+2]=y File[a+3]也为标志字节 也就是说用4字节来表示nFile2中与File1长度大于4的公共子串。（File3[a]==File3[a+3] File3[a+2]-File3[a+1]>4); 也就是说在还原nFile2[]时，将File3[a]-File[a+3]替换成：File1[File3[a+1]]-File1[File3[a+2]]; 目前我能想到的就是这样的做法了 求批评指点[/quote] 压缩还原请google 哈夫曼编码。

[以专业开发人员为伍]

引用 10 楼 wlhkane110 的回复:

仔细想想 如果用字节来比对差异的话 实际实现的话性能上来说会有很大的问题的样子

如果不比较，如何记录差异的位置呢？这里的关键不是“比较字节”，而是如何组织“分块”的算法。 “压缩”对于这个问题没有任何意义。压缩了之后再比较源码的所有差异，根本说不通。

[Rumia]

引用 14 楼 sp1234 的回复:

[quote=引用 10 楼 wlhkane110 的回复:] 仔细想想 如果用字节来比对差异的话 实际实现的话性能上来说会有很大的问题的样子

如果不比较，如何记录差异的位置呢？这里的关键不是“比较字节”，而是如何组织“分块”的算法。 “压缩”对于这个问题没有任何意义。压缩了之后再比较源码的所有差异，根本说不通。[/quote] 一开始没考虑到File1与File2的可能关联 也就是File1和File2是完全随机不同的文件 而且一味求File3最短 偏离应用场景的影响 如果结合实际应用的话确实不合时宜了 感谢指正

[wanghui0380]

其实为了简化描述我使用文本做特例引入，你能看到这里面的实现 换到二进制文件，其实实现过程和文本并无太多不同，只是你不能readline，只能像sp说滴去分块。 其实这个问题本身与检索，比较关系不太紧密（更和LCS，Huffman没多大关系），按position读取固定字节，然后比较这件事情基本毫无难度，至于状态机引入貌似就3态，有限滴可以了 这问题滴实际难度在与你怎么去构建file3的文件格式。如果不考虑双向，只是按题目做单向记录你甚至完全可以像下面那样描述 1. 块1-块50 写入“0101010101010“ 2. 块51-块80 从文件1 读取50块写入 3 块81-块90 写入”9块滴字符a“ 也就是记录所有file2里有file1里没有滴，忽略file1有file2没有滴(因为题目只是单向操作，所以没必要只在file2里有滴)，保留file1和file2都有滴 ，当然我这里只是简单描述一下，具体怎么更合理组织文件格式你要自己想 ps：无需压缩，也无需LCS，两文件逐字节比较即可，老p说的分块也可以，不过实际运算上多少有些麻烦，因为删入，删除滴数据未必就满1个“块”，所以需要做很多对齐操作

[tanta]

压缩是肯定不对的，文件差异查找，我们要假设这两个文件有一定关联，文件的部分内容是相同的。这样还是查找最长公共子串的问题。

[笨笨的小菜]

看来没人会这个啊？来个高手吧！

[wanghui0380]

http://www.codeproject.com/Articles/509425/BinDiff-A-tool-to-compare-binary-files 这里就有一篇按16byte分块比较滴文章，但是作者本身也没考虑过“对齐”的事情，只是分块分滴足够小基本是BCD比较，所以对齐误差也小（其实可以想想，如果前面不是FF真好插进了16byte，如果前面只插了5byte滴数据，哪怕后面完全一样，那如果不考虑对齐操作，那结果其实就成file2滴全部数据了）

[Rumia]

引用 2 楼 devmiao 的回复:

google 最长公共子串

很感兴趣 不过又没做过 想问下我这样的想法不知可不可行： 设File1数据表示为：byte[] File1；File2表示为：byte[] File2; 1：File1和File2生成File3: ①首先File2进行压缩，得到尽量少的压缩后的byte[] nFile2;nFile2.Length<File2.Length.（现在应该有现成的方法进行压缩和还原的吧？） ②这里提到了公共子串，假定File1[x]到File1[y]的数据与nFile2[a]-nFile[b]((y-x)==(b-a))。File3表示为byte[] File3。 那么我File3[a]设定标识字节 File3[a+1]=x File3[a+2]=y File[a+3]也为标志字节 也就是说用4字节来表示nFile2中与File1长度大于4的公共子串。（File3[a]==File3[a+3] File3[a+2]-File3[a+1]>4); 也就是说在还原nFile2[]时，将File3[a]-File[a+3]替换成：File1[File3[a+1]]-File1[File3[a+2]]; 目前我能想到的就是这样的做法了 求批评指点

[MoonAndWolf]

这么复杂？我觉得是否需要应用上压缩的算法呢？ 还有个问题？如果 File1和 File2 没有任何的关系，那么File3 一定不会比File2 小。 只有在File1和File2 具有很大的相似性的情况，下才能File3 比File2 小。

[以专业开发人员为伍]

这在工程上是不太可行的。 不过如果我们只是拿出静态的两个文件（也就是说，当前时刻文件并没有一部分在windows磁盘系统缓冲区中）来比较和记录“差异”，这可以这样做： 假设你把文件按照每1024k长度部分分成多块，然后依次比较，你就能够更容易地发现哪些文件块不同。对于不同的块，你还可以再划分为32个32k的块，依次比较，你就能发现哪些小块不同。你还可以划分为更小的块，直到达到你设置的足够细的尺度。 最后把多个小块数据顺序写在一个文件里（有一个字节表示块号）即可。

[以专业开发人员为伍]

有一个字节表示块号 --> 有一个整数表示块号

[Rumia]

引用 9 楼 sp1234 的回复:

有一个字节表示块号 --> 有一个整数表示块号

这个的实际应用场景是用来数据还原 断点续传应该也能用得上 仔细想想 如果用字节来比对差异的话 实际实现的话性能上来说会有很大的问题的样子 学习了呢

[wanghui0380]

当作文本一行一行读入 这样会有一个list<rowContext> 直接对比list<rowcontext>做集合交集，差集，补集其实你就是你要的东西 至于你要地其实观察一下svn产生地版本冲突文件，你大概就明白了 <<<<<<my<<<<< 我地修改 <<<<<<myend<<<< <<<别人地修改<<< 别人地修改 <<<别的人修改end<<< 当然svn是同时在一个文件中表示，而你则可以简化表示 基本上就是 行号30-50 差集 行号 80-90 补集 行号 100-150 补集 其他未表示行号为交集

[wanghui0380]

至于如何判定是交集，补集，还是差集（并且能的到连续的行数），我们简单推论地模型其实就是状态机，而且不是怎么太复杂的状态机