這是一個謎題！使用奇偶校驗數據修復損壞的位
讓我們說我們有64個字節，每個字節爲8位加一個奇偶校驗位
讓我們說有一個進一步的LRC校驗字節（通過逐位異或荷蘭國際集團所有的64個字節組成）
因此，我們可以將其視爲一個8 + 1乘64 * 1的網格
如果一位被損壞，奇偶校驗會標記它：一行奇偶校驗檢查失敗，另一列也失敗。
因此，查找有問題的位並將其反轉是很重要的。
然而，正方形排列中的四個損壞位將欺騙奇偶校驗：因爲每個違規的行和列將包含2個錯誤，因此給出正確的奇偶校驗讀數。
但這是一個不太可能發生的情況。
我的問題是：我會如何去修復這種數據集？可以修復多少？
我的直覺是必須有修復輕微受損數據集中的一些明智的方式...
我假設你用64 + 1格意味着8 + 1。
假設其中一個非奇偶校驗位已損壞。數據字節上的奇偶校驗位將標記該字節。所有字節上的奇偶校驗將標記已損壞的列（位）。都好。
假設「普通」數據字節的一個奇偶校驗位被損壞。額外奇偶校驗字節的最後一位會標記它，不是嗎？
假設奇偶校驗字節的一個奇偶校驗位被損壞。額外奇偶校驗字節的最後一位會標記它，不是嗎？
那麼該位的值是如何定義的？
2維奇偶修復每行或每行一位不可修復只是可檢測的。
至於如何在一個數據集的2個維度上建立可修復的共情以達到一定的損害程度......我曾經計算出每個方向上的單個位損壞可以恢復，如果每6個字節有1個字節在陣列的每個方向上。
看看，也許維基raid 5和raid 6架構。他們採用類似的方法來分攤驅動器之間的部門
64個字節，每個字節是8個比特加一個奇偶校驗位 LRC校驗字節（通過逐位XOR形成荷蘭國際集團的所有64個字節） 64 + 8個字節將被用於每字節字1奇偶校驗位作爲。 所以每個塊將有64個數據+9個奇偶校驗字節
如果該位不是塊上的奇偶校驗位（大假設），LRC會告訴你該塊是壞的。） 你可以計算移情，因爲你知道什麼字節是壞的，你可以強制幾個不同的位來糾正lrc和字節，直到兩個匹配，但作爲一個單一的lrc只告訴你，你有1/256的機會獲得與您匹配的組合將獲得一組符合「固定」標準的數學數據。
如果您知道它是什麼類型的文件，這將提高您的數據恢復機會。 例如，如果您知道文件類型是文本，字節5是大寫或小寫，並且任何數字不在字母數字範圍&中，常見的字符可能會被刪除。
所以是從技術上講，可以用這樣的模式強制數據恢復成形。
如果您決定這樣做，我建議您先將其封鎖爲每64個塊50個字節的數據。這會給你14個字節的奇偶校驗來實現一個數學模型。接近16/64，或者塊中涉及的1/4字節僅用於救援目的。
您的數據集的1/4將會丟失，但會增加一些穩定性。在你的例子9/71中的 約佔數據的13％。
我曾經在數據恢復之前強迫過這樣的強制數據集，但在大多數情況下，不可能確定你已經成功。
例如，如果您有1兆字節的文件，並且說您對奇偶校驗的同理心在4個區域中受損。這是一個MP4文件或壓縮文件嚴重受損。
如果損壞限於每塊1位，並且很可能可以修復該文件。 如果你說每個塊有2個比特，你就會知道每個塊有2個區域被損壞，產生一個8個可能文件平方的序列。你可以生成64個文件，並嘗試解壓每個文件，但是說每個塊的損壞是3位，現在你可能會看8個立方體。
這是可能的蠻力修復這樣的事情，我已經在緊急情況下成功地取得了成功。
您似乎對您的答案進行了很多思考，並努力做到徹底。我（和許多SO用戶）非常感謝！但是，請注意，大多數提出問題的人都在尋找特定問題的具體答案，而不僅僅是對該主題的一般性討論（不論是徹底的）。你似乎沒有真正解決這個問題。 –
我在這裏解決了特定的問題。他詢問這個特定的矩陣是否受到行和列上的奇偶校驗保護。從表面上看，這可能適用於涉及高達1位的錯誤（因爲奇偶校驗會將發生錯誤的行和列都標記爲錯誤）。我指出錯誤也會影響奇偶校驗數據本身，奇偶校驗數據本身沒有足夠的保護，因此無法定位奇偶校驗數據中的單個位錯誤。 – chrono
我認爲投票是錯誤的......雖然沒有回答這個問題，但這清楚地闡明瞭一個相關的問題。應該珍視這樣的「答案」，因爲它們提高了作爲資源的問題的價值。我猜它可能已被作爲評論... –