假設我有一個URL。URL的最佳可逆散列算法是什麼? (接近零碰撞!)
http://google.com ...我想把它變成一個散列。 S3jvZLSDK。 然後拿這個散列並反轉它!到http://google.com。
對於你來說呢 - 對於接近零的碰撞,最好的方法是什麼?
假設我有一個URL。URL的最佳可逆散列算法是什麼? (接近零碰撞!)
http://google.com ...我想把它變成一個散列。 S3jvZLSDK。 然後拿這個散列並反轉它!到http://google.com。
對於你來說呢 - 對於接近零的碰撞,最好的方法是什麼?
如果你可以反轉它,那麼根據定義它不是一個散列。這是一種編碼。任何編碼都將有零衝突(否則它將無法準確地將其反轉)。
爲此目的的常見編碼是base64。
散列的整個觀點是它不可逆(缺少蠻力,嘗試每個可能的輸入,直到輸出匹配)。
這是否是一個網址縮短服務?這樣做的通常方法是將http://google.com
存儲在一個唯一密鑰下的數據庫中,當有人使用該密鑰進行查詢時(如果您真的喜歡隨機字符串,可能是'S3jvZLSDK',但可能很容易就是'1')把你記得的價值再吐出來。
沒有辦法獲得接近零的衝突,但是如果您使用大輸出大小的加密哈希,您可以使衝突任意地不可能發生。 SHA-2系列包含具有512位密鑰的版本;那應該是你的。
你想寫點類似URL shortener?如果是這樣,只需生成一個隨機字符串,然後使用大型哈希表,關係數據庫(帶索引)等將鍵(S3jvZLSDK)與URL(google.com)相關聯,反之亦然。
這將爲您提供處理衝突(密鑰已存在,URL已存在)和快速查找的簡單解決方案。
即使蠻力的方法也行不通。你幾乎可以保證找到一個錯誤的答案,因爲有更多的可能的輸入比哈希碼。 – 2009-09-30 22:48:01
在大多數情況下,您不需要查找原始值,只需要一個會生成相同散列值的值。但是,是的,在這種情況下,蠻力強制哈希將是無用的。 – 2009-09-30 22:50:15
對於URL,你會比任何舊字符串更有可能挑選正確的輸入... http://google.com會比較容易找到,但對於路徑或參數較長的任何內容,沒有機會。 – bobince 2009-09-30 23:41:39