開元最近學(xué)習(xí)了一下Blizzard的MPQ文件格式，頗有一些心得，其中一條就是對(duì)HastTable的理解，很想寫出來給大家共享，感謝Justin Olbrantz的文章《Inside MoPaQ》，大多認(rèn)識(shí)來源于此。
先提一個(gè)簡(jiǎn)單的問題，如果有一個(gè)龐大的字符串?dāng)?shù)組，然后給你一個(gè)單獨(dú)的字符串，讓你從這個(gè)數(shù)組中查找是否有這個(gè)字符串并找到它，你會(huì)怎么做？
有一個(gè)方法最簡(jiǎn)單，老老實(shí)實(shí)從頭查到尾，一個(gè)一個(gè)比較，直到找到為止，我想只要學(xué)過程序設(shè)計(jì)的人都能把這樣一個(gè)程序作出來，但要是有程序員把這樣的程序交給用戶，我只能用無語(yǔ)來評(píng)價(jià)，或許它真的能工作，但...也只能如此了。
最合適的算法自然是使用HashTable（哈希表），先介紹介紹其中的基本知識(shí)，所謂Hash，一般是一個(gè)整數(shù)，通過某種算法，可以把一個(gè)字符串"壓縮" 成一個(gè)整數(shù)，這個(gè)數(shù)稱為Hash，當(dāng)然，無論如何，一個(gè)32位整數(shù)是無法對(duì)應(yīng)回一個(gè)字符串的，但在程序中，兩個(gè)字符串計(jì)算出的Hash值相等的可能非常小，下面看看在MPQ中的Hash算法
unsigned long HashString(char *lpszFileName, unsigned long dwHashType)
{
unsigned char *key = (unsigned char *)lpszFileName;
unsigned long seed1 = 0x7FED7FED, seed2 = 0xEEEEEEEE;
int ch;
while(*key != 0)
{
ch = toupper(*key++);
seed1 = cryptTable[(dwHashType << 8) + ch] ^ (seed1 + seed2);
seed2 = ch + seed1 + seed2 + (seed2 << 5) + 3;
}
return seed1;
}
Blizzard的這個(gè)算法是非常高效的，被稱為"One-Way Hash"，舉個(gè)例子，字符串"unitneutralacritter.grp"通過這個(gè)算法得到的結(jié)果是0xA26067F3。
是不是把第一個(gè)算法改進(jìn)一下，改成逐個(gè)比較字符串的Hash值就可以了呢，答案是，遠(yuǎn)遠(yuǎn)不夠，要想得到最快的算法，就不能進(jìn)行逐個(gè)的比較，通常是構(gòu)造一個(gè)哈希表(Hash Table)來解決問題，哈希表是一個(gè)大數(shù)組，這個(gè)數(shù)組的容量根據(jù)程序的要求來定義，例如1024，每一個(gè)Hash值通過取模運(yùn)算 (mod)對(duì)應(yīng)到數(shù)組中的一個(gè)位置，這樣，只要比較這個(gè)字符串的哈希值對(duì)應(yīng)的位置又沒有被占用，就可以得到最后的結(jié)果了，想想這是什么速度？是的，是最快的O(1)，現(xiàn)在仔細(xì)看看這個(gè)算法吧
int GetHashTablePos(char *lpszString, SOMESTRUCTURE *lpTable, int nTableSize)
{
int nHash = HashString(lpszString), nHashPos = nHash % nTableSize;
if (lpTable[nHashPos].bExists && !strcmp(lpTable[nHashPos].pString, lpszString))
return nHashPos;
else
return -1; //Error value
}
看到此，我想大家都在想一個(gè)很嚴(yán)重的問題："如果兩個(gè)字符串在哈希表中對(duì)應(yīng)的位置相同怎么辦？",畢竟一個(gè)數(shù)組容量是有限的，這種可能性很大。解決該問題的方法很多，我首先想到的就是用"鏈表",感謝大學(xué)里學(xué)的數(shù)據(jù)結(jié)構(gòu)教會(huì)了這個(gè)百試百靈的法寶，我遇到的很多算法都可以轉(zhuǎn)化成鏈表來解決，只要在哈希表的每個(gè)入口掛一個(gè)鏈表，保存所有對(duì)應(yīng)的字符串就OK了。
事情到此似乎有了完美的結(jié)局，如果是把問題獨(dú)自交給我解決，此時(shí)我可能就要開始定義數(shù)據(jù)結(jié)構(gòu)然后寫代碼了。然而Blizzard的程序員使用的方法則是更精妙的方法。基本原理就是：他們?cè)诠１碇胁皇怯靡粋€(gè)哈希值而是用三個(gè)哈希值來校驗(yàn)字符串。
中國(guó)有句古話"再一再二不能再三再四"，看來Blizzard也深得此話的精髓，如果說兩個(gè)不同的字符串經(jīng)過一個(gè)哈希算法得到的入口點(diǎn)一致有可能，但用三個(gè)不同的哈希算法算出的入口點(diǎn)都一致，那幾乎可以肯定是不可能的事了，這個(gè)幾率是1:18889465931478580854784，大概是10的 22.3次方分之一，對(duì)一個(gè)游戲程序來說足夠安全了。
現(xiàn)在再回到數(shù)據(jù)結(jié)構(gòu)上，Blizzard使用的哈希表沒有使用鏈表，而采用"順延"的方式來解決問題，看看這個(gè)算法：
int GetHashTablePos(char *lpszString, MPQHASHTABLE *lpTable, int nTableSize)
{
const int HASH_OFFSET = 0, HASH_A = 1, HASH_B = 2;
int nHash = HashString(lpszString, HASH_OFFSET);
int nHashA = HashString(lpszString, HASH_A);
int nHashB = HashString(lpszString, HASH_B);
int nHashStart = nHash % nTableSize, nHashPos = nHashStart;
while (lpTable[nHashPos].bExists)
{
if (lpTable[nHashPos].nHashA == nHashA && lpTable[nHashPos].nHashB == nHashB)
return nHashPos;
else
nHashPos = (nHashPos + 1) % nTableSize;
if (nHashPos == nHashStart)
break;
}
return -1; //Error value
}
1. 計(jì)算出字符串的三個(gè)哈希值（一個(gè)用來確定位置，另外兩個(gè)用來校驗(yàn))
2. 察看哈希表中的這個(gè)位置
3. 哈希表中這個(gè)位置為空嗎？如果為空，則肯定該字符串不存在，返回
4. 如果存在，則檢查其他兩個(gè)哈希值是否也匹配，如果匹配，則表示找到了該字符串，返回
5. 移到下一個(gè)位置，如果已經(jīng)越界，則表示沒有找到，返回
6. 看看是不是又回到了原來的位置，如果是，則返回沒找到
7. 回到3
怎么樣，很簡(jiǎn)單的算法吧，但確實(shí)是天才的idea, 其實(shí)最優(yōu)秀的算法往往是簡(jiǎn)單有效的算法，
Blizzard被稱為最卓越的游戲制作公司，不愧于此。