為什麼我們不能使用沒有衝突的雜湊來可靠地壓縮數據？
根據維基百科，散列將任意大小的數字數據映射到固定大小的數字數據。
對於所有實際措施，散列是一大塊數據的唯一簽名。但是我聽說有一個無衝突雜湊之類的東西。
除了能夠解壓縮之外，可以說壓縮和散列之間的主要區別正是衝突因素——但是如果散列沒有衝突怎麼辦？
為什麼我們不能“只是”得到那個“完美”的散列並將其用作壓縮方法呢？它不能生成更小的文件嗎？
我知道我一定是錯過了一些東西，所以這只是我試圖理解散列和壓縮之間潛在區別的方式！:)
從數學上講，不存在無衝突雜湊這樣的東西。實際上，有。
信譽良好的加密雜湊函式沒有已知的衝突。這是他們的定義屬性之一。它們確實有碰撞，但考慮到目前的數學知識，地球上（如果不是在整個宇宙中）沒有足夠的計算能力來找到一個。SHA-256 值是 256 位，因此我們知道存在一對具有相同雜湊值的 257 位字元串，但最知名的查找技術超出了目前計算能力的範圍。
直覺地說，如果很難找到雜湊的衝突，那麼雜湊就很難逆向。如果有一個已知的算法來反轉散列，那麼在某些時候該算法將不得不決定去哪一個可能的原像，我們可以執行它來找到一個衝突。
可以使用散列作為壓縮函式。但是由於沒有辦法從雜湊中計算出原文，所以這種壓縮方式只能在原文有的情況下使用。聽起來沒用？不完全的。事實上，這是使用雜湊的基本原因之一！當有兩種儲存或通信機制時使用加密雜湊，一種是安全的但僅支持少量數據，另一種不安全但支持大量數據。將散列儲存在小型安全儲存中，將實際數據儲存在大型不安全儲存中。然後，當您需要該文件時，檢索數據、檢索散列並檢查散列。這樣，安全儲存機制使用雜湊作為壓縮函式；解壓功能利用了不安全的儲存，但保證結果的安全。（但是，您不會失去某些東西：如果不安全的儲存已損壞，這將被檢測到，但無法糾正。“解壓縮”機制保證了完整性（如果您取回數據，它就是正確的數據）但是不可用（您可能無法取回數據）。）
換個角度看，加密雜湊可以用作壓縮機制，但這要求每次儲存新文件時，都要對解壓函式進行某種修改以記住原始文件內容。這顯然是不切實際的，但它具有理論上的意義——這基本上描述了一個隨機預言機，它是一種理想化的加密雜湊版本。
完美雜湊是另一種野獸：它在數學上是無衝突的，但它通過將可能的輸入限制為所有可能輸入的有限（通常很小）子集來實現這一點。完美散列的解壓縮函式通常儲存為從散列值到相應原始數據的表（例如，如果散列值是小整數，則使用數組）。
完美的散列函式為預定義的有限可能輸入集計算唯一索引。通常，此類函式用於實現雜湊表。這樣就不必擔心碰撞。通常，可能輸入的集合很小且已知，因此也可以反轉函式（即，給定索引可以找到輸入）。
範例：如果您有一組字元串
("Hello World", "A quick brown fox", "A lazy dog")那麼例如計算字元串中字元
l出現的函式將是這些字元串的完美雜湊函式，因為它將字元串映射到索引，如下所示："Hello World" -> 3 "A quick brown fox" -> 0 "A lazy dog" -> 1因此，您可以以某種方式使用此功能進行壓縮。但是有很多問題：
- 第一個潛在問題是，為了解壓縮，您必須知道完美的散列函式和可能的字元串集。因此，如果您將“3”儲存在文件中，您還必須在某處儲存“3”對應於“Hello World”的事實。但是，如果您有一組用於許多文件的固定輸入，則此方法可能有意義。
2）只有當你有一小部分大輸入時，你才會有壓縮。例如，如果可能的輸入集是 {“a”,“b”,…,“z”}，則結果索引（雜湊）將類似於 {1,…,26} 不進行壓縮地方。所以這種散列不適合通用壓縮。
- 將每個輸入映射到相同的固定大小索引可能不是壓縮的最佳主意。像霍夫曼編碼這樣的通用壓縮函式也會考慮不同字元串出現的機率，然後將出現頻率更高的字元串映射到比非常罕見的字元串更短的序列，從而提供更好的壓縮比。
PS：您的問題並不是真正的密碼學問題，因為雜湊表的完美雜湊函式不是密碼雜湊函式。