解释一
python的字符串hash算法并不是直接遍历字符串每个字符去计算hash,而是会有一个secret prefix和一个secret suffix,可以认为相当于是给字符串加盐后做hash,可以规避一些规律输入的情况
显然这个secret前后缀的值会直接影响计算结果,而且它有一个启动时随机生成的机制,只不过,在2.x版本中,这个机制默认是关闭的,前后缀每次启动都设置为0,除非你改了相关环境变量来要求随机,而在3.x中修改了默认行为,如果你不配置环境变量,则默认是随机一个前后缀值,这样每次启动都会不同
这个环境变量是PYTHONHASHSEED,无论在2.x还是3.x中,配置为一个正整数,将作为随机种子;配置为0,则secret前后缀默认清零(和2.x默认行为就一样了),配置为空串或“random”,则表示让进程随机生成(和3.x默认行为一样)
具体为啥要这么做,猜测一个是为了安全性(防字符串hash表的攻击,比如php曾经碰到的攻击),另一个可能也是强调不要依赖一些内建结果,因为这种算法可能随着版本而更新,避免有些用户不看文档,误以为是永远不变的
作者:冒泡
链接:https://www.zhihu.com/question/57526436/answer/153241020
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
解释二
set/dict的hash还真就是这个玩意实现的,因为它保证了在同一个解释器进程里相同字符串hash一致。
因为CPython 3.x里的str,它的实体是unicode对象,实体是个utf-8 bytes或者是wstr(嗯这里真特么有个『或者』),并且通过一个叫做unicodedata_db的玩意来实现缓存(不然就没法儿保证str对象的不可变与地址一致性了)。
于是乎当你调内部hash的时候,反正不同进程中的解释器不会共用一个unicodedata_db,这个解释器进程里的字符串的hash到另一个进程里指不定连个字符串都不是,所以在计算这个内部hash的时候加入了一个code_magic的玩意,同时也均摊了一把复杂度,省得这个db以及set/dict对特定数据表现出极差性能。再说了,谁也不会傻到拿个解释器内部hash去做跨进程交换。
所以真需要做可重现可跨进程保持一致性的hash,请用hashlib。
作者:Coldwings
链接:https://www.zhihu.com/question/57526436/answer/153238652
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。