1樓：范德成
Reed-Solomon糾錯碼https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction
貌似很有用。
還有Erasure coding和RAID5/6的模式也可以用於糾錯。
2樓：夏雨婷
壓縮檔案損壞後是如何修復的？如果沒猜錯，題主指的是類似WinRAR的恢復記錄的功能，通過增加一些冗餘資料實現整個壓縮文件少部分連續資料損壞得以修復。
CRC確實只是校驗演算法，只能判斷解壓縮後的資料和元資料是否匹配，沒有修復功能，那麼讓你來實現類似WinRAR恢復記錄功能該如何做？
在沒有任何資料和知識的情況下，我的想象力也就達到了在壓縮包尾部疊加一樣的資料，這樣壓縮包的體積就增加了一倍，其中一部分損壞就取另一部分即可。但是WinRAR的文件明確寫著：「If damaged area is continuous, every sector helps to recover 512 bytes of damaged information.
」這已經超出我的知識範圍了。
WinRAR文件還寫著：「RAR 4.x recovery record is based on XOR algorithm.
」 這句我看的有點莫名其妙，XOR怎麼還會是演算法？我想到的乙個點子是，把壓縮文件對半分，然後按位儲存前半和後半的xor值，這樣「只」需要增加50%的冗餘資料就可以修復整個文件了。
在計算機網路課程，提到了「家喻戶曉」的CRC校驗演算法後，還順帶提了一句所謂「海明碼」：
海明碼通過在2的整數次冪插入校驗位可以糾正一位錯誤，但是一位顯然沒有多大的作用，WinRAR的文件也明確指出它有能力解決遠超過一位的錯誤。我曾經以為海明碼就是正確答案，還打算將其擴充套件為支援N位的演算法，直到發現了下面這個「所羅們糾錯演算法」：
我認為該演算法就是最終答案。
3樓：ReVanTis
不管是校驗演算法，還是糾錯演算法，本質上或者說思路上都是利用冗餘資訊對檔案原本的樣子進行推算。
根據用途的不同，校驗演算法的目的是利用更小的冗餘資訊進行錯誤是否存在的驗證，而糾錯演算法是在保證一定冗餘資訊量的前提下，對已經發生錯誤的檔案進行修復。
CRC可以保證檢測出100%的奇數個錯誤和小於其階數個的突發錯誤。
這一演算法僅僅是用於檢測錯誤，而不是糾正錯誤，單純憑藉這一資訊很難修復出錯。
對rar檔案進行成功修復往往是建立在配置了一定比例的冗餘資料的基礎上的。
而且當錯誤足夠多時，往往這些冗餘資料也不能起到太大的幫助。
題外話：
事實上夏農在通訊的數學理論一書中提出過：
存在一糾錯演算法，使得訊號傳輸過程中的誤位元速率得以任意小。
如果原話理解起來費勁的話，可以理解成：
存在乙個糾錯演算法，可以使得錯誤率不為100%的任意情況下通訊得以絕對保真。
唯一的問題在於：為了保真，我們需要付出的額外的冗餘代價是否現實，或者值得。
這一論斷可以認為是通訊領域中最有用也最沒用的乙個。
因為這一論斷從事實上可以證明不論通訊多麼差，我們總可能設計出演算法來對通訊進行可靠性保證。
但是這個論斷對於我們實際設計出這些演算法簡直是一點幫助也沒有，充其量也不過是為我們鼓起信心而已。
學會哈夫曼樹怎麼實現壓縮檔案？
望山 你可以去Github看看cyan4973的FiniteStateEntropy的原始碼，它裡面除了FSE演算法，還有乙個HUFF0，是優秀的huffman編碼實現。這位作者是當今世界上最頂級的無失真壓縮大牛之一，LZ4的作者。 悽臨雨 壓縮時不在是文字，甚至不是以位元組為單位，而是以位為單位來...
壓縮檔案為什麼不能一層層壓縮自身？
1866886 你最後會不會發現壓縮檔案體積不降反增，因為壓縮這東西是找規律的事，把重複檔案已經做成了乙個字典，第二次壓縮已經沒有重複檔案了，但依然要字典 kuzhushu 檔案壓縮，多數檔案在壓縮之前，其內容很有規律，這是能壓縮的基礎。被壓縮後，就變得不規律了，就沒法再壓縮了。你舉的abc.rmv...
關於壓縮檔案破解的一些問題。以及怎麼解包壓縮檔案？
zsd 我大致描述下加密是什麼 abcd 是我的原始資訊我們約定乙個加密方法比如所有字母向後推n位我再設n為1221 所得到的資訊就是 bdee 其中 所有字母向後推n位 是演算法 另外提一句 windows的密碼預設情況下是不完整加密資料的所以有PE工具可以很方便的破解windows密碼進入系統讀...