1. 檔名相同與內容相同是兩回事
下載的安裝檔若在名稱與大小上都符合說明頁面，很容易讓人以為已正確取得檔案。然而，名稱可以更改，大小相同的檔案也可能有不同內容。反過來說，把照片檔複製成另一個名稱，並不表示檔案內的位元組一定會改變。此時，把檔案內容送入固定計算程序並以短數值表示的雜湊，就能協助比較。我們要確認的問題不是檔名看起來是否可信，而是收到的位元組是否與可信的基準一致。將備份檔案移到另一個儲存裝置時，也可以提出同樣的問題。
SHA-256 是一種從輸入產生 256 位元雜湊值的演算法。通常以 64 位十六進位數表示，因為一位十六進位數代表 4 位元。即使檔案變大，結果長度也不會隨檔案大小等比例增加。對相同位元組套用相同演算法，就會得到相同結果。不過，由於必須把所有輸入對應到長度有限的數值，原理上仍存在不同輸入得到相同數值的碰撞。應區分「可用於實務比較」與「在數學上替所有檔案賦予獨一無二名稱」這兩種說法。RFC 6234 提供了包含 SHA-256 在內的雜湊計算與測試資料。
2. 雜湊不是加密，也不是檔案的縮小副本
知道雜湊值，不代表就有了解碼按鈕，可以還原原本的文件或照片。加密的設計是讓人能以適當的金鑰取回原文，但密碼學雜湊並不是用來還原原文的儲存格式。這也不表示只公開雜湊，就能保護所有輸入的秘密。若可能的輸入只有幾個，便可以逐一計算雜湊後比較。因此，不能把用於檔案驗證的 SHA-256 說明，延伸成「直接把密碼做雜湊後儲存就已足夠」的建議。確認完整性、保密與儲存密碼，是條件要求各不相同的工作。
若計算整個檔案，所比較的也不只是螢幕上看得見的文字。即使看來是同一句話，換行方式、字元編碼或文件內部中繼資料不同，都可能使位元組不同。解壓縮後得到的檔案，與原本的壓縮檔是不同的比較對象。若先將文字正規化或改變換行再計算，得到的就是轉換後資料的雜湊。若發佈者提供的是原始壓縮檔的數值，應先拿收到的壓縮檔本身來比較。這項區分，是把既有 Unicode 與 UTF-8 文章中「顯示內容與位元組不同」的觀念，應用於實際檔案驗證的例子。
3. 下載檔案應以相同演算法與基準值比較
驗證前，先在製作者的官方發佈說明中，一併確認目標版本、作業系統、檔名與雜湊演算法。其他作業系統的安裝檔或不同版本的數值，不能當作比較基準。在 PowerShell 中，可用 Get-FileHash -LiteralPath '.\download.zip' -Algorithm SHA256 讀取本機檔案並計算。這個命令不會執行該路徑的檔案內容。Microsoft 官方文件說明，數值是根據檔案內容計算，僅更改名稱不會改變數值。請把檔名與路徑改成實際取得的檔案，計算期間也不要修改檔案。
在輸出中，將 Hash 欄位的完整 64 位數，與發佈者公開的 SHA-256 值逐一核對。不能只因開頭或結尾幾位相同，就認定整個數值一致。十六進位英文字母的大小寫代表同一個數，但若混入其他字元或位數不足，應先檢查複製的值。結果相符，可支持收到的位元組與所信任基準值的一致性；這並不是已檢查文件事實、程式品質或惡意行為的結果。若基準檔案本身有問題，與它完全相同的副本也會具有相同雜湊。計算成功與檔案是否適合使用，必須分開判斷。
4. 不符是調查原因的訊號，並非攻擊的確證
例如，假設將昨天取得的發佈檔案，與今天說明中的數值比較，發現兩者不同。這是說明用案例，並非真實事故紀錄。首先要確認說明是否指向同一版本、是否取得其他裝置的檔案，以及是否在下載完成前就開始計算。也可能是計算了解壓縮後的檔案，而不是壓縮檔，或編輯器重新儲存了文件。因此，必須區分比較對象改變，與傳輸或儲存過程中內容改變的情況。僅憑數值不同，無法得知是誰、何時、改了什麼。
不要為了確認而立刻執行雜湊不符的安裝檔；應重新確認官方發佈說明與基準值，再比較重新下載的檔案。若仍不同，宜查閱發佈者的更正公告或支援管道，並留下結果。紀錄中應一併寫下確認時間、來源網址、檔案版本、演算法與計算值。重複計算結果相同，可作為以相同方式讀取目前本機檔案的線索，但這並不會解決發佈者所刊數值有誤或發佈途徑有問題的情況。若用預期值覆寫基準紀錄，就會失去判斷日後是否發生變更的依據。
5. 信任基準值的依據與數位簽章的作用
若攻擊者能同時更改檔案與說明中的雜湊值，就能計算被修改檔案的雜湊，並把它列成新的基準。NIST SP 800-175B 說明了不使用金鑰或簽章、僅使用雜湊時的這項限制。從官方網址的 HTTPS 頁面取得數值，有助於確認來源與傳輸途徑，但並不能保證連發佈伺服器本身遭入侵的情況也已排除。重點不是雜湊字串看起來很長，而是基準值從何處、透過什麼信任程序取得。同一畫面複製的兩個數值相符，並不足以確認製作者的身分。
數位簽章讓人利用以可信方式取得的公開金鑰等，驗證簽章與資料之間的關係。若發佈者提供簽章驗證程序，應依官方說明操作，包括如何確認金鑰持有人與指紋。若直接信任來路不明檔案旁第一次看到的公開金鑰，信任起點的問題仍未解決。使用共享秘密金鑰的 HMAC 也是不同於一般雜湊的驗證工具，但不是任意附加到所有下載項目，就能解決問題的功能。即使簽章有效，也不能推論程式沒有缺陷，或文件內容一定屬實。位元組一致、來源確認與內容評估彼此相關，但各自仍需要可驗證的依據。
6. 備份與協作也應記錄比較範圍
備份個人照片時，保存原始檔案的 SHA-256 並與副本比較，有助於確認搬移過程是否發生變更。此時，也要妥善保管基準清單，避免與原始檔案一起遺失或被覆寫。若照片管理軟體重新寫入旋轉資訊或拍攝中繼資料，即使看到的照片相似，檔案雜湊仍可能不同。因此，應先區分目的是逐位元組保存，還是確認編輯後照片的意義是否相同。若要確認整個資料夾，不能只算一個檔案的雜湊就結束，而應一起管理納入的檔案清單、相對路徑與各檔案的數值。
在協作文件審閱中，雜湊也可以作為固定已審閱版本的標記。然而，檢查雜湊相符，不能取代某人確實讀過全文或對照過翻譯的證據。先記錄審閱了什麼、何時審閱、採取什麼方法，再把紀錄連結到相應檔案的數值，才有意義。本文的圖片是自行製作的說明示意圖，整理位元組比較、基準值來源與驗證範圍，並非實際量測結果或憑證。確認檔案時，請依序記錄對象與演算法、基準來源，以及結果能支持的說法範圍。如此便能避免誇大相符或不符的意義，也讓下一個人重現相同步驟。