SHA-1 檔案雜湊是構成檔案之精確位元組的 160 位元訊息摘要，以 40 字元的小寫十六進位字串，或 28 字元採用標準填補的 Base64 字串顯示。若要取得檔案的 SHA-1 雜湊，透過瀏覽器式的摘要工具選取檔案，工具會在本機讀取位元組，結果會以兩種編碼方式呈現，以便與你已信任的校驗和進行比對。雜湊是確定性的:相同的位元組永遠會產生相同的 40 個十六進位字元，檔案內任何單一位元組的變更，都會產生完全不同的摘要。SHA-1 由 NIST 的安全雜湊標準 (FIPS 180-4) 所定義，會對輸入進行填補、切割成 512 位元的區塊，並在每個區塊的 80 輪運算中更新五個 32 位元的狀態字，最終產生 160 位元的狀態。檔案模式的雜湊會將位元組完全視為檔案系統所交付的形式 — 換行符號、空格以及結尾的換行都會計入 — 因此結果會對精確的位元組序列敏感，而不是內容的正規化檢視。
檔案的 SHA-1 雜湊實際代表的意義
SHA-1 摘要永遠是 160 位元長。以小寫十六進位表示時，正好是 40 個字元，因為每個十六進位數字編碼 4 個位元，40 × 4 = 160。以 RFC 4648 的標準 Base64 表示時，同樣的 20 位元組會佔 28 個字元，包括用來補完最後一組的單一 '=' 填補字元。沒有更短的合法形式，也沒有更長的合法形式 — 39 字元或 41 字元的字串不是被截斷，就是被無效位元組填補。雜湊函式會透過填補、區塊切割，以及 80 輪的狀態更新來處理輸入位元組，產生一個依賴輸入每個位元的固定長度輸出。
摘要是單向函式。你無法從雜湊還原原始檔案，過程中也沒有金鑰、鹽值或其他秘密。兩個不同的檔案可能會碰撞 — 產生相同的 SHA-1 摘要 — 而此特性已在受控條件下的實務中被證明，這也是為何該演算法不再適合用於新的安全性設計。若只是針對透過獨立受信任管道取得的單一校驗和進行完整性檢查，該函式仍能正常運作:它能可靠地偵測出檔案中任何位元組的變更。
檔案模式與文字模式:選擇正確的輸入
當你從同時接受文字與檔案輸入的工具取得 SHA-1 雜湊時，這兩種模式並不能互換。文字模式會在雜湊前將可見字串編碼為 UTF-8，這代表像 "é" 這類附加音符的字元會展開成兩個位元組 (0xC3 0xA9)，而單一表情符號可能會展開成四個位元組或更多。因此，貼入文字方塊的同一個詞，與從檔案讀取的同一個詞，如果檔案是以非 UTF-8 編碼儲存，或包含位元組順序標記，可能會產生不同的摘要。
檔案模式會對檔案系統所交付的原始位元組進行雜湊。檔名、修改時間戳記，以及瀏覽器提供的 MIME 標籤都不屬於摘要的一部分。對於任何隨附已發布 SHA-1 校驗和的下載檔案、封存檔、安裝程式或磁碟映像，檔案模式才是正確的選擇。文字模式則適用於你正在重現顯然是由 UTF-8 字串產生的校驗和時 — 例如，類似密碼的通行詞、標準化的授權聲明，或簡短的組態權杖。
五個步驟取得檔案的 SHA-1 雜湊
- 在現代瀏覽器中開啟 Sha1 雜湊產生器。該工具完全在分頁中執行，不會上傳任何資料。
- 選擇檔案輸入選項，而不是文字方塊。如果檔案大於 100 MB，請改用本機作業系統工具，因為瀏覽器式的路徑需要在摘要運算完成前，完整的位元組緩衝區都可使用。
- 從本機儲存裝置中選取檔案。瀏覽器會將其讀入記憶體，執行 FIPS 180-4 所定義的 SHA-1 摘要運算，並在雜湊計算完成後釋放該參考。
- 點擊按鈕以計算 SHA-1 摘要。結果會以兩種格式顯示:40 字元的小寫十六進位字串，以及 28 字元的已填補 Base64 字串。
- 複製舊版系統所預期的格式 — 幾乎所有校驗和頁面與 README 檔案使用十六進位，部分較舊的 API 使用 Base64 — 並將其貼到所提供值的旁邊，透過受信任的管道逐一比對每個字元。
空檔案是合法的輸入，其眾所周知的 SHA-1 值為 da39a3ee5e6b4b0d3255bfef95601890afd80709。這與指向零位元組檔案時所看到的 40 字元十六進位摘要相同，也是確認工具是否正確連線的有用健全性檢查。文字模式中的空欄位會回傳相同的值;只有在你完全沒有點擊按鈕時，才會出現「無結果」。
讀取十六進位與 Base64 而不修剪或重新編碼
40 字元的十六進位輸出僅使用字元 0–9 與 a–f 的小寫形式。某些系統以大寫形式發布校驗和;兩者都是相同摘要位元組的合法表示方式，在正規化後，字元層級的比對應不區分大小寫。28 字元的 Base64 輸出使用 RFC 4648 的標準字母表 (A–Z、a–z、0–9、+、/)，並在結尾使用單一 '=' 填補字元。十六進位與 Base64 是相同 20 位元組的編碼形式 — 它們並非兩種不同的雜湊演算法，你絕不應同時發布兩者，並期望它們能作為獨立的校驗和運作。
當你將摘要複製到另一個工具時，請抗拒修剪空白、轉換換行符號，或套用任何文字轉換的衝動。字串開頭缺少一個零，或字串內不小心多了一個空格，都會產生與底層檔案無關的比對失敗。如果發布的值在群組之間包含空格、冒號或換行 — 這在 README 檔案中很常見 — 請在比對前移除這些呈現用的字元，但實際的十六進位或 Base64 內容應保持不變。
為何你的雜湊與發布的校驗和不符
大多數「錯誤雜湊」的結果來自三個根本原因之一，仔細檢查通常能釐清是哪一個在作用。
- 輸入模式錯誤。將檔案內容貼入文字方塊，並與檔案模式摘要進行比對，若文字模式套用了 UTF-8 正規化、刪除了結尾的換行，或以不同於 LF 的方式處理 CRLF 換行符號，則會失敗。
- 下載不完整或損毀。你雜湊的檔案並非發布者計算校驗和的檔案。請重新下載並再次比對 — 在數 GB 的檔案中，單一位元組的差異就足以讓整個摘要失效。
- 來源被重新編碼。HTML 頁面的「檢視原始碼」副本、透過會轉換編碼的系統所進行的剪貼簿貼上，或從會移除位元組順序標記的檢視器複製，都會改變位元組序列與產生的雜湊。
除了上述三者之外，非常大的檔案偶爾會觸發記憶體或瀏覽器 API 的限制。本機緩衝區 100 MB 的上限是實際的限制，並非任意設定，超過此大小的檔案需要使用以串流方式分塊讀取與計算摘要的命令列工具。對於小於此限制的檔案，以同一檔案再次計算通常能確認是發布的值有誤，還是你的環境有問題。
SHA-1 適用與不適用的情境
SHA-1 適用於範圍明確且理解透徹的工作流程:透過獨立已驗證管道取得的校驗和來驗證下載檔案、將封存檔項目與目錄項目進行比對，或重現仍要求舊版演算法的舊版整合。在這些情況下，用途僅限於比對，管道值得信任，且不存在產生碰撞檔案的對抗壓力。
當用途涉及對抗性或安全性關鍵時，SHA-1 並不適用。根據 RFC 6194 中的安全性考量，針對 SHA-1 的碰撞攻擊在實務上是可行的，且已經被證明。請勿將 SHA-1 用於數位簽章、未同時經由外部驗證之憑證授權單位的憑證指紋比對、程式碼簽署決策、密碼儲存，或任何攻擊者可能替換碰撞酬載的工作流程。純粹的 SHA-1 摘要也不是密碼雜湊 — 快速的通用演算法讓攻擊者每秒可測試數十億次猜測。密碼儲存需要加鹽且刻意放慢的機制，例如 Argon2id、scrypt 或 bcrypt，由帳號系統本身實作。
對於任何可以自行選擇摘要的新系統，優先採用 SHA-256 或 SHA-512。256 位元的變體會產生 64 個十六進位字元，或 44 個含填補的 Base64 字元;512 位元的變體會產生 128 個十六進位字元，或 88 個含填補的 Base64 字元。兩者對當前的公開密碼分析仍維持碰撞抗性，並且獲得廣泛支援。如果你正在遷移既有的驗證流程，SHA-512 驗證指南 會以更高的安全性等級，逐步說明相同的逐字元比對方式。每當消費端系統可以變更時，請將儲存的參考值更新為更強的演算法，並透過已驗證的管道發布新的校驗和。
SHA-1、SHA-256 與 SHA-512 用於檔案摘要的比較
這三種演算法共享相同的介面 — 任意輸入、固定長度輸出 — 但在輸出大小、十六進位與 Base64 長度，以及安全性態勢上有所不同。下表概述了各 NIST 標準所定義的確切數值。
| 屬性 | SHA-1 | SHA-256 | SHA-512 |
|---|---|---|---|
| 輸出大小 (位元) | 160 | 256 | 512 |
| 十六進位字元長度 | 40 | 64 | 128 |
| Base64 字元長度 (含填補) | 28 | 44 | 88 |
| 區塊大小 (位元) | 512 | 512 | 1024 |
| 碰撞狀態 | 實務上已被破解 | 具抗性 | 具抗性 |
| 建議用途 | 舊版校驗和比對 | 新檔案完整性、簽章 | 高保證完整性、簽章 |
對於無法更改的校驗和頁面，你只能接受使用 SHA-1。對於任何你能掌控的系統，請改用 SHA-256 或 SHA-512，並同時更新發布的參考值，然後再次比對新摘要與檔案，以重新驗證遷移是否正確。
若你正在權衡選項，以正確方式產生字串的 SHA-256 雜湊 對此有詳細說明。