散列一个字节串答案

【问题标题】：Hash a byte string散列一个字节串
【发布时间】：2023-03-15 23:47:01
【问题描述】：

我正在开发一个个人项目，一个文件压缩程序，但我的符号字典有问题。我需要将以前遇到的字节字符串存储到一个结构中，以便我可以快速检查它们的存在并检索它们。我一直在假设哈希表最适合此目的的情况下进行操作，因此我的问题将与哈希函数有关。但是，如果有人可以建议一个更好的哈希表替代方案，我会全力以赴。好的。所以问题是我无法为这些字节字符串想出一个好的散列键。我想到的所有东西要么分布非常不均匀，要么耗时太长。以下是我正在处理的情况列表：

所有字节串至少长度为两个字节。
哈希表的最大大小为 3839，它很可能会被填满。
测试表明，对于任何给定字节，与低七位相比，最高位被设置的可能性要小得多。
否则，字符串中的字节可以是 0 到 255 之间的任何值（我正在处理任何格式的原始字节数据）。
我在 UNIX 环境中使用 C 语言。我更喜欢使用标准库，但它不需要移植到其他操作系统。（即 unistd.h 很好）。
安全性无关紧要。
速度是一个高度关注的问题。
大小并不重要，因为它不会被写入文件。但是，考虑到要存储的字节字符串的潜在大小，内存空间可能会成为压缩过程中的一个问题。

【问题讨论】：

“我想到的一切”——你可以考虑用谷歌搜索“散列函数”，而不是这样做；网上有大量参考资料。
@Jim，而不是思考？您是否认真地建议 Google 作为思考的替代方案？
@Blindy 我建议利用人类丰富的知识，而不是试图从个人努力的限制中重新发明轮子。软件工程（以及人类文化）的整个历史都是关于利用现有技术的。思考会让你明白这一点，而不是讽刺我写的东西。具有讽刺意味的是，你自己的回答反映了这一点——你肯定没有发明尝试，而且保罗不会仅仅通过经历他能想到的一切来想到它们。
P.S. burtleburtle.net/bob/hash/doobs.html 是一个很好的例子，说明谷歌搜索可以为您提供单纯思维无法获得的东西。当然，考虑到之前的工作，人们可以对其进行大量思考，但回避研究而仅仅满足于自己能想到的东西是不称职、不专业且没有生产力的。

标签： c hash byte hashtable

【解决方案1】：

trie 更适合这种事情，因为它允许您将符号存储为树并快速解析它以匹配值（或拒绝它们）。

作为奖励，您根本不需要哈希。您一次存储/检索/比较整个序列，同时仍然只保留最少量的内存。

编辑：作为额外的奖励，只需第二次解析，您就可以查找与当前序列“接近”的序列，因此您可以摆脱一个序列并使用前一个序列，用一些内部符号来保存差异。这将帮助您更好地压缩文件，因为：

较小的字典意味着较小的文件，您必须将字典写入文件
如果您添加人口上限并使用大文件命中它，较少数量的项目可以腾出空间来容纳其他更稀有的序列。

【讨论】：

不错的答案！不需要哈希的好点。也许如果 Paul 可以将数据存储为数字而不是字符串，他可能会有一个有序列表并对其进行二进制搜索。
我其实不用把字典写到文件里；我正在使用 LZW 压缩方案。但是，尝试听起来确实很吸引人。我要试一试。