求解这究竟是哪种编码后的hash编码值

版权声明:本文为博主原创文章遵循 版权协议,转载请附上原文出处链接和本声明

今天我来介绍三种在工程中比較实用的hash编码,它们分别是一致性哈希局部敏感哈希Geohash编码

首先,Simhash编码主要是用于文本去重的文本去重的第一步就是判断文本的相姒度,如果两个文本的相似度很

高那么我以认为它们是相同的文本。

对于文本相似度的计算传统的方法是使用向量空间模型(Vector Space Model),即VSMVSM计算文本相似

度的方法是这样的:先对文本进行分词,提取出特征词然后建立文本向量,把相似度的计算转化成某种特征向量

距離的计算比如余弦夹角,欧氏距离计算等等这样做结果就是,如果文本向量的维度很高那么计算的代价会

很大,所以必须另辟蹊径

可以看出,VSM计算文本的相似度是两两文本进行计算比较对于小数量文本处理是可以的。但对于百度Google这

样的搜索引擎,爬虫每天爬取嘚网页数目大得惊人对于新爬取的网页,为了防止重复收录网页需要对网页进行判

重处理,对于这样的海量数据VSM无能为力。所以针對这种海量文本的去重Google提出了Simhash编码算法,它把高

维度的文本向量映射成一个指纹进行降维,从而减少计算量

  (1)输入一个N维的文本特征向量V,每个特征具有一定权重

  (2)初始化一个C维的向量Q为0C位的二进制签名S为0

  (3)对于向量V的每一个特征,使用传统hash编码算法计算出┅个C位的散列值H对1<=i<=C,如果H的第i位

  (4)如果Q的第i个元素大于0则S的第i位为1,否则为0

  (5)返回这个C位的二进制签名S

下面以N = 3为例进行如图说明

對每篇文档根据Simhash编码算出签名S后再计算两个签名的海明距离,海明距离等于这两个二进制数异或后1的个数根据经验,对于64位的Simhash编码海明距离在3以内的都可以认为相似度比较高。

可以看出经过Simhash编码算法得到的是一个文档的指纹我们根据这个指纹来判断文档的相似度,湔面说过如果海明

距离在3以内,那么就认为这两个文档基本是相同的以64位的指纹来说,把它以每16位划分块如果两个指纹海明

距离小於等于3,那说明至少有一个16位块完全相同(组合数学里的鸽巢原理)但是我们不知道具体是哪两个块相

同,所以要进行枚举这里只需偠枚举4次。

以8位的数字指纹来说明

我们划分为4块每块两位,即01 10 00 11然后在所有的8位二进制签名中分别查找以01,1000,11开始的签

当然在这所有的8位二进制签名数据中,我们可以以前两位进行索引比如把和放在一个簇

中,如果找不到以0110,0011开始的二进制签名,说明海明距離肯定大于3这样就直接可以判断这两个文本不

相似,否则再比较后面的部分

以上是8位二进制签名的比较方法,64位的签名类似方法处理

假如现在有10亿个签名,约为2^34那么每个块最多可能有2^(34-16)=262144个结果,那么4个块最终比较次数为

4*262144大约为100万,这样原本需要比较10亿次现在只需偠比较100万次,可以看出计算量大大减少

问题:有10亿个不重复的64位01串,再另给一个64位的01串str如何快速从这10亿个串中找出与str的海明距离小


作者丨上海储迅信息技术有限公司联合创始人-冷波

IPFS的热门就不必说了太多的人关注基于它的Filecoin挖矿。

但是否能获得很大的收益谁也说不清楚,毕竟主网没有上线测试網也没有上线。但矿工们的交集等待并不会降低大家对IPFS相关技术的关注。

除了Filecoin越来越多的项目也会利用IPFS作为底层存储层或者网络数据傳输协议。

IPFS和传统文件系统的一个重要区别就是——内容寻址顾名思义,就是文件的内容定了其地址(访问路径)也就确定了。这和峩们平时存放文件不一样通常,我可以给一张图片随意更换文件名把它拷贝到不同的路径。

这样一模一样的文件,其访问方式却随時变化不可能根据文件的内容确定其访问路径。相比较而言内容寻址的IPFS就具有一个天然的优势——防篡改。数据只要修改了一个bit其哋址就彻底变化。想借助修改文件瞒天过海难度就陡增。

比如我创建了一个很简单的文本文件demo.txt,然后把它上传到IPFS网络中:

于是我就嘚到一个hash编码值

下面我们简单探索一下,这个hash编码值是如何得来的

玩区块链的人,不管对技术多熟悉或多或少都知道这个概念。每个攵件存入IPFS网络都会有一个唯一的哈希(hash编码)值,通过该值便可以确定文件进而访问数据。只要文件内容稍微修改hash编码就会变化。IPFS采用了SHA2-256这个安全级别还算高的算法对任意长度的内容,生成的hash编码值长度固定都是32个字节。

得到的结果有64字节其原因是因为用了十陸进制的表示方式,每个字符表示4个bit加在一起就是256bit,也就是32字节但在IPFS中,并不能利用上面得到的SHA2-256结果去确定文件地址,因为IPFS还有一些额外的因素需要考虑

前面我们把demo.txt加入到IPFS中,除了正文里面的StorSwift几个字符之外IPFS还会添加一些元数据。比如通过如下命令我们可以看到IPFSF裏面到底存放了什么内容:

返回的是一个JSON格式的字符串,Data显示了具体的内容可见在文件的原始内容之外,添加了一些其他的数据IPFS会把攵件数据以unixfs这种格式保存,可以认为它是IPFS的核心数据结构MerkleDAG的一个表现方式。

具体内容以后再做解释。我们可以通过获取IPFS的原始格式的數据来计算正确的hash编码值。IPFS保存的内容会被分成许多块(block)本例的文件因为比较小,一个块就可以保存

所以,我们可以用如下的命囹直接获取IPFS block的内容:

该block的hash编码值用十六进制数表示为:

是否用该hash编码值就能得到我们通常看到的IPFS文件的hash编码值好像不是那么回事,因为峩们看到的文件hash编码值都是以Qm开头的显然在这里对不上号。这就涉及到另外一个话题——动态选择hash编码算法的设计

虽然现在SHA2-256还比较安铨,但随着科技的发展说不定哪天就突然有人宣布,可以破解它呢那自然需要采用更先进的算法。但IPFS的协议制定好了也不能随便改。怎么办呢虽然现在用的是SHA2-256,但可以宣称我支持多种hash编码算法到时候升级算法即可,但不会有大的架构改动

于是,IPFS采用了multihash编码这种簡单的hash编码表示方式支持多种hash编码算法。如果未来修改算法用的仍然是multihash编码,保证了表达方式的持续性

multihash编码的格式简单,具体文档參见:它其实就是一个字符串,由三部分组成:hash编码算法编码、hash编码值的长度(字节数)、hash编码 值

SHA2-256的编码为0x12,其hash编码摘要长度为32字节(十六进制数为0x20)把1220加到前面所得hash编码值的开头,我们得到本例文件的multihash编码编码(十六机制):

但这个hash编码值显然也不是我们看到的内嫆那是怎么回事呢?它太长了一堆数字读起来也不容易,所以需要再进行编码压缩其长度,且容易被传播为此,IPFS采用了Base58这种编码

Base58最早被比特币采用,如今在区块链项目中非常流行经常用于表示钱包地址。做过开发的朋友可能比较了解Base64这种编码能把任意二进制內容转换成方便软件查看的可读字符。

但Base64有一些缺点就是某些字符不和谐,比如O和0容易混淆,+和/等符号很容易让人把一个完整的字苻串认为是两个不同的字符串,形成阅读上的障碍有时候我们用鼠标一点,想自动选中整个字符串却因为这些符号的干扰,导致选择操作没有那么高效因此,就诞生了Base58这种编码

很简单,就是和Base64类似能转换二进制内容为可读字符,只是把前面讲的那些有干扰的字符铨部剔除

Base58的代码非常简单,可以从这里获取:

我引用了里面的Python源文件基于前面生成的multihash编码编码进行计算:

 

补充一点,IPFS现在的multihash编码值嘟是以1220开头的,按照Base58的算法算出来的结果就都是以Qm开头。

大功告成!现在对IPFS文件的hash编码值有了比较清楚的认识知道其来龙去脉了。总結一下就是:

当然,如果上传的是目录或者分成多块的文件,其过程就要复杂一些

我要回帖

更多关于 hash编码 的文章

 

随机推荐