~~

解决方案 »

  1.   

    看了一下MSDN,没有用于文件比较的api,只有自己写代码来完成它了,先分别读出文件到不同的缓冲区,然后逐一对比各个字节是否相同,如果想加快进度的话,可以考虑使用文件映射
      

  2.   

    谢谢楼上这么快回复,我也是先找API,没有找到~~
    因为我要二三秒就对比一下,文件虽不是很大,二三十K,但经常读和比较会不会对系统有影响
      

  3.   

    哈希码……文件1=文件2 => Hash(文件1)==Hash(文件2)但是反过来不一定,选一个好一点的摘要算法。例如md5,sha1
      

  4.   

    kiko2008
    你做的效果好,效率高吗?
      

  5.   

    最简单的办法,将两个文件分别作MD5运算以后比较其散列值。随便搜索以下一大把MD5的算法,各种语言的源代码、现成的动态库、现成的比较文件软件……一摞一摞的
      

  6.   

    因为总共就十来个JPG文件作比较,用MD5好像有些大材小用了,有什么效率高点的算法呢?
      

  7.   

    可以调用COMMAND。COM的FC命令,然后通过管道来读取数据或是直接读它生成的文本文件。这好象是最快速的方法了。
      

  8.   

    DemonLoveLizzy
    一开始我也是想用FC来弄的,可就是不会得到FC的返回值,可否给些管道的例子
      

  9.   

    FC也是逐字节比较的逐字节比较的速度瓶颈在于硬盘传输率
    想做到实时比较得想办法减低数据量
    对于JPEG,不同图片转换软件的量化表、Huffman表不同(而且还可调整压缩率),所以对文件的逐字节比较是无法判断图片是否相同的
    而且由于它是有损压缩,就算解出图像后再比较图像,也是不可能完全相同的
      

  10.   

    zyl910(910:分儿,我又来了!) 谢谢你的指点
    我是想为公司一个软件做个小外挂,从而减少大量重复操作,半年前已经做过个了,就是不够完善,所以想改良一下,通过识别JPG文件,得到程序运行情况,从而由我自己的程序来监控那程序。我已看过了,那程序产生的JPG文件是相同的,所以不会出现像你那样的情况
    我用MD5来运算好像有些延时,可否给些好见议
      

  11.   

    为什么20多K的文件,MD5运算这么慢,要一两秒多?
      

  12.   

    //为什么20多K的文件,MD5运算这么慢,要一两秒多?网上VB写的MD5都是用字符串来模拟位运算的,自然速度慢这样做速度快得多:
    用Byte数组来存放数据,再用乘除来实现移位(VB编译器会自动将乘除“2^x”优化成移位)
      

  13.   

    //VB编译器会自动将乘除“2^x”优化成移位谢谢楼上的.一语点醒梦中人.我一直都用数组模拟机器码进行运算,看来完全没有必要了.
      

  14.   

    能不能调用命令行的工具啊,如果可以的话,试试
    fc 文件1 文件2 /b