有什么简单的方法可以将一个32位整数（例如IP地址，例如Unix time_t等）哈希成一个16位整数？
例如，hash_32b_to_16b(0x12345678) 可能会返回 0xABCD。
让我们从这个可怕但实用的例子解决方案开始：
function hash_32b_to_16b(val32b) {
return val32b % 0xffff;
}
这个问题特别涉及到JavaScript，但是欢迎添加任何与语言无关的解决方案，最好不要使用库函数。
此问题的背景是生成唯一的ID（例如，64位ID可能由各种32位值的几个16位哈希组成）。避免碰撞很重要。
简单=好。疯狂+混淆=有趣。
幸运的是，有一种只需要两个操作的好技巧，可以在这种情况下得到相同的最优结果。与xor一样，它不仅确保对于任何给定的32位值，扭曲任何输入位都将导致2位输出的更改，而且还确保在给定输入值的均匀分布的情况下，2位输出值的分布也将完全均匀。在当前示例中，该方法将4,294,967,296个可能的输入值分成恰好1,073,741,824个四个可能的2位哈希结果{ 0, 1, 2, 3 }。
{16、8、4、2}，我下面展示的魔法值是唯一的值，当按照我在这里展示的方式使用时，满足上述完美哈希条件。
不再拖延，将32位哈希为n = {16、8、4、2}的唯一且数学上最优过程是乘以与n相对应的魔法值（无符号，舍弃溢出），然后取结果的n高位。要将这些结果位隔离为[0 ... (2ⁿ - 1)]范围内的哈希值，只需将乘法结果向右移动32 - n位（无符号！）。
将32位减少到最大熵保留哈希. . .
目标位数 乘数 右移位数 表达式 [1, 2]
----------- ------------ ----------- -----------------------
16 0x80008001 16 (i * 0x80008001) >> 16
8 0x80808081 24 (i * 0x80808081) >> 24
4 0x88888889 28 (i * 0x88888889) >> 28
2 0xAAAAAAAB 30 (i * 0xAAAAAAAB) >> 30
将64位减少到最大熵保留哈希. . .
目标位数 乘数 右移位数 表达式 [1, 2]
----------- ------------------ ----------- -------------------------------
32 0x8000000080000001 32 (i * 0x8000000080000001) >> 32
16 0x8000800080008001 48 (i * 0x8000800080008001) >> 48
8 0x8080808080808081 56 (i * 0x8080808080808081) >> 56
4 0x8888888888888889 60 (i * 0x8888888888888889) >> 60
2 0xAAAAAAAAAAAAAAAB 62 (i * 0xAAAAAAAAAAAAAAAB) >> 62
注释:
我觉得这很酷。在实际应用中，关键的信息理论要求是保证对于任何m位输入值及其对应的n位哈希值结果，翻转任何一个m源位总是会导致n位结果值发生变化。尽管总共有2ⁿ种可能的结果值，但其中一种已经“被使用”（由结果本身），因为从任何其他结果“切换”到该结果将不会有任何变化。这留下了2ⁿ - 1个结果值，可供整个由单个位翻转的m输入值组成的集合使用。
让我们来考虑一个例子；事实上，为了展示这种技术可能看起来有点神秘或者非常神奇，我们将考虑更极端的情况，其中m = 64和n = 2。使用2个输出比特位，有四种可能的结果值，分别是{0, 1, 2, 3}。假设一个任意的64位输入值0x7521d9318fbdf523，我们会得到它的2位哈希值1：
(0x7521d9318fbdf523 * 0xAAAAAAAAAAAAAAAB) >> 62 // result --> '1'
1，而声明是在单个位0x7521d9318fbdf523被切换的64个值集合中，没有任何一个值可能具有相同的结果值。也就是说，这64个其他结果中没有一个可以使用值1，而必须使用0、2或3。因此，在这个例子中，似乎每一个2⁶⁴个输入值——除了另外64个输入值——都会自私地独占输出空间的四分之一。考虑到这些交互约束的巨大数量，是否存在一个同时满足的解决方案？0x7521d9318fbdf523的单个位的输入。3 2 0 3 3 3 3 3 3 0 0 0 3 0 3 3 0 3 3 3 0 0 3 3 3 0 0 3 3 0 3 3 // continued…
0 0 3 0 0 3 0 3 0 0 0 3 0 3 3 3 0 3 0 3 3 3 3 3 3 0 0 0 3 0 0 3 // notice: no '1' values
1 值，这意味着源代码中的每一位都必须作出贡献才能影响结果（或者，如果你喜欢，0x7521d9318fbdf523 中每一位的实际状态对于防止整个结果变为“非 1”是至关重要的）。因为无论您对 64 位输入进行何种单比特更改，2 比特结果值都将不再是 1。0x7521d9318fbdf523 中转储；每个其他可能的输入值都有自己的类似表格，每个表格都神秘地缺少其所有者的实际结果值，但在其集合成员中却以某种方式保持全局一致。这种属性基本上对应于在（固有的有损）位宽缩减任务期间最大程度地保留可用熵。换句话说，xor 的特殊'信息保留'特性（也就是它的高度可靠的保证，与and、or等不同，它总是可以并且将会改变一位）自然会有一定的代价，即强烈的非协商要求一定的操作空间——至少2个比特。
我认为这是你能得到的最好结果。你可以将代码压缩成一行，但现在变量还在那里作为文档:
function hash_32b_to_16b(val32b) {
var rightBits = val32b & 0xffff; // Left-most 16 bits
var leftBits = val32b & 0xffff0000; // Right-most 16 bits
leftBits = leftBits >>> 16; // Shift the left-most 16 bits to a 16-bit value
return rightBits ^ leftBits; // XOR the left-most and right-most bits
}
考虑到问题的参数，最佳解决方案应该让每个16位哈希值对应恰好2^16个32位数字。我认为它还应该以不同的方式哈希连续的32位数字。除非我遗漏了什么，否则我相信这个解决方案做到了这两点。
我认为在这个问题中安全性不能成为考虑因素，因为哈希值只有太少的位数。我相信我提供的解决方案可以将32位数字均匀地分配给16位哈希值。
(i>>16) ^ ((i&0xffff) * p)，其中p是一个质数。((i>>16) ^ ((i&0xffff) * p) & 0xffff)（但我不是专家）。 - clankill3r像这样简单的东西...
function hash_32b_to_16b(val32b) {
var h = hmac(secretKey, sha512);
var v = val32b;
for(var i = 0; i < 4096; ++i)
v = h(v);
return v % 0xffff;
}