@ryd994 你说的对，是有点问题。

于是这问题又变成了如何对 float 进行 hash 处理，如何把 2.99 和 3.00 计算成同一个 hash 值。

hmm.. 算了，我表示放弃追贴了。越飘越远。

@clf 好的，好的 ^_^

@binux 我 google 查了一下，那么多图片相似度算法，最后一步都是计算汉明距离，

楼主的主楼诉求，貌似就是为了省略掉这最后一步。N x N (n=十万), 数量不大，也不算很小了。

理论上可以通过一些 floor 技巧实现。

比如图片 1 的 hash 是 3.5 ，1.2 ...
图片 2 的 hash 是 3.45, 1.02...

都 floor 后，都变成了 3, 1, ...整型，那么当数字变成字符串文件名后，两者就是匹配的。

@clf 可以转给我吗？感谢感谢。

VX: bGl2aWRsaXZpZDQ=

@binux 好像是没有这种算法，楼主的意思，是想把 hash 作为文件名。

如果多个图片是相似的，那么文件名就会冲突，最终磁盘只能保存一个图片。

目前开源的算法，都是给两个图片，求他们的相似值。但这个相似值又不能作为文件名，给保存下来。

要全屋净水干嘛，生活用水你又不喝。

RO 是过滤水分子，加了后水压和流量肯定小，完全不适合家庭普通用水。

靠谱点，就走普通装修路线，给饮用水 RO 过滤就可以了。

by the way, JPEG 压缩算法，也是把高频信息作为次要信息扔掉后，达到压缩图片数据的目的。

把图片压缩到极致后，也能变相达到图片模糊 hash 的目的。

@shylockhg “不是南辕北辙么”有这种算法的，英文里叫 fuzzy hashing ，最初是比较两个文件的相似性。

比如两个源代码文件，内容能达到 99%的相似度，fuzzy hashing 的结果就是高度一致的。

hash 的本质，就是把多余的数据给扔掉，剩下的均匀分布到输出空间里。至于把数据哪一部分给怎么扔掉，就是这个技术的核心，需要对源数据进行分析处理。比如源代码预处理，就可以把注释全部扔掉，这是次要的信息。

按信息的重要程度排序，反复对数据处理，重复扔掉几次次要信息后，最终计算的 hash ，这就是模糊 hash 算法了。

@Hconk 我自己写了一个 exe ，扔到 sendto 文件夹里，来替代 copy path 。

@yfugibr 应该还是有这种算法，做字符串大量的模糊匹配。比如 word 里，英文单词拼写纠错，就是模糊查找英文字典的一个典型应用。

就是还没想明白，具体算法应该怎么写。

我怎么看现在的洪蒙系统教学，全部都是前端套皮呢。

根本不是 native 开发，和 iOS 没法比。

洪蒙 native 系统也有，不过是嵌入式，受众极少。

@zxCoder "怎么定义相似的 hash"

6 楼就是相似的 hash 案例。两个字符串错一个或者两个英文，hash 结果是一样的，但错三个以上，hash 就不一样了。

@illusionist 你应该单独发个拍卖贴的，价高者得，绝对能卖到 600+

举个例子，怎么对

hello world
healo world
heelo world

这三个字符串做模糊 hash ，并且让 hash 值的结果完全一致？

这问题有点复杂，因为已经生成 hash 了，问题的本质是如何对 hash 值组成的字符串，做模糊匹配。

我个人想法是，先遍历十万数组，把 100 位做 bit 出现概率分析，去掉最低频率的 36 位。最后形成十万数量级的 64 位完美 hash ，直接丢掉 hashtable 进行一一匹配，处理速度会非常快。

匹配成功后，再进行二次 hamming distance 的严格配对。

这个简单，我以前写过。但不是用 base64 ，而是 36 （ http://en.wikipedia.org/wiki/Base_36 ）

用来在 apk 文件里，存中文文件名的。（不知道为什么，官方 apk 打包工具不支持中文名，百思不得其解。）

因为是文件名，我只希望用 A-Z, 0-9 ，不希望有别的杂乱字符影响。

再说一下原理，DCT 末尾截断，本质上就是把图片里的高频信号给去掉。

就好比你直接去比较两张壁纸，是不相同的，但是你放到 photoshop 里，高斯模糊一下后，把细节都去掉，壁纸看起来就很相似了。

这个简单，学 jpeg 压缩原理，DCT 后是可以末尾截断的，多截断一些位数，就变成了图片的模糊 hash 值。

我也遇到过类似的问题，ide 为了对齐，每个 span 占了一整行，换行符最终变成了页面中的空隙。
这就是我不喜欢 html 的地方，还是 C++好。