SHA-1 檔案雜湊是檔案精確位元組序列的 160 位元訊息摘要，以 40 個小寫十六進位字元或 28 個帶有填補字元的標準 Base64 字元表示。要為檔案產生 SHA-1 雜湊，意即將那些原始位元組餾入 NIST FIPS 180-4 所定義的演算法，再讀回產生的指紋，過程中不會混入任何中繼資料。檔名、最後修改時間以及瀏覽器的 MIME 標籤都不參與運算——只有磁碟上的位元組才會參與。在瀏覽器分頁中本機執行摘要運算時，無論檔案是數 KB 或接近用來讀取它的 File API 所設定的 100 MB 上限，都會產生相同的 20 個位元組。正是這種本機處理方式，讓基於瀏覽器的 SHA-1 產生器在實務上可用於透過可信賴的管道所提供的校驗和來驗證下載的成品:您可以重新計算摘要並逐字元比對，而不必將位元組傳送到任何地方。
「為檔案產生 SHA-1 雜湊」真正的含義
SHA-1 雜湊將輸入視為位元組串流，並產生固定 160 位元的指紋。當輸入是檔案時，該檔案的每個位元組都會貢獻到摘要中——演算法會對輸入進行填補、將其切分為 512 位元的區塊，並依 NIST 安全雜湊標準的規範，在每個區塊上以五個 32 位元狀態字進行 80 輪的混合運算。最後的 160 位元狀態就是您在螢幕上看到的值。
因為摘要是 160 位元，它剛好對應到 20 個位元組。這 20 個位元組可以以下列兩種等價形式顯示:
- 小寫十六進位:20 個位元組 × 每個位元組 2 個十六進位字元 = 40 個字元。
- 標準帶填補 Base64:ceil(20 ÷ 3) × 4 = 28 個字元，含任何結尾的「=」填補字元。
這兩種形式是同一組 20 個位元組的不同編碼方式;兩者都不是第二種雜湊演算法，在它們之間切換並不會改變底層的摘要。對於文字輸入，顯示的字串在雜湊前會以 UTF-8 編碼，這對於含腔調字母、表情符號以及非拉丁文字很重要，因為單一字元可能佔用數個位元組。對於檔案輸入，則會以從磁碟讀取的原始位元組精確地進行雜湊——不進行字元集轉換、不進行標準化、也不進行修剪。行尾結尾、結尾空白以及最後的換行全都是會改變結果的位元組，這就是為什麼外觀相似的檔案確實可能產生不同的摘要。
空白的文字欄位是有效的訊息，其眾所周知的 SHA-1 值為 da39a3ee5e6b4b0d3255bfef95601890afd80709。如果您在空白輸入上點擊「產生」時，工具回傳的正是這個字串，代表實作連線正確。任何其他值都意味著位元組串流並非空字串——例如，因為欄位中含有殘留的空白字元。
為何檔案校驗和仍使用 SHA-1
儘管 SHA-1 已被宣告不適合用於新的安全性設計，它仍在三個實務檔案工作流程中常見:
- 舊版下載頁面和鏡像網站會在早於遷移至 SHA-256 的安裝程式與 ISO 映像旁邊公布 SHA-1 總和。
- 舊的封存目錄與軟體博物館會將 SHA-1 清單保留為歷史紀錄。
- Git 以及某些套件管理器仍會發出 SHA-1 物件識別碼，以維持與現有儲存庫的相容性。
在上述每個案例中，SHA-1 值都是作為校驗和——也就是偵測意外傳輸損毀的方式，例如下載被截斷，或在連線不穩時位元被翻轉。它不是簽章、不是真實性證明、也不是對能夠替換內容的攻擊者的防禦。認清這條界線，正是正確校驗和工作流程與不安全工作流程的差別。對於新的安全相關工作——程式碼簽署、憑證指紋、密碼儲存、防竄改記錄——正確的選擇是 SHA-256 或 SHA-512。
在瀏覽器中對檔案進行雜湊的步驟
Sha1 雜湊產生器會將所選檔案讀取為一塊連續的位元組緩衝區，並在瀏覽器分頁中完整執行 FIPS 180-4 所定義的 SHA-1 摘要運算。具體步驟如下:
- 在瀏覽器分頁中開啟 Sha1 雜湊產生器。
- 若來源是本機檔案，請將輸入模式切換為檔案模式;若您只是要對短字串進行雜湊，則可保留在文字模式。
- 點擊檔案選擇器並選取目標檔案，大小上限為 100 MB。
- 點擊「產生」。瀏覽器會讀取檔案，本機執行 SHA-1 演算法，並呈現 160 位元的摘要。
- 視舊版系統所預期的格式，複製 40 字元的小寫十六進位字串，或 28 字元的 Base64 字串。
- 將該值貼到已公布的校驗和旁，並透過可信賴的管道逐字元進行比對。
步驟 4 期間不會進行任何上傳。檔案會就地由 RFC 6234 所描述的同一套演算法進行雜湊，因此您複製的值會與 OpenSSL 或任何其他遵循規範的實作在相同位元組上所產生的結果完全一致。
文字模式 vs 檔案模式
此工具提供兩種輸入模式，因為它們雜湊的是不同的位元組序列。選錯模式會在無聲無息中改變摘要，因此值得了解自己需要的是哪一種。
| 面向 | 文字模式 | 檔案模式 |
|---|---|---|
| 輸入來源 | 在欄位中鍵入的可見字串 | 從磁碟選擇的本機檔案 |
| 編碼方式 | 字串在雜湊前先轉為 UTF-8 | 從檔案讀取的原始位元組 |
| 空白字元處理 | 每個空格、Tab 和換行都是一個位元組 | 二進位內容可能包含 0–255 的任何位元組值 |
| 是否納入檔名 | 否 | 否 |
| 大小上限 | 僅受限於實際字串長度 | 100 MB，由瀏覽器 File API 設定 |
| 典型用途 | 對短識別碼或校驗和字串進行雜湊 | 對安裝程式、ISO、封存檔或任何二進位區塊進行雜湊 |
如果已公布的校驗和是來自對下載檔案的雜湊，那麼檔案模式幾乎總是正確的選擇。文字模式適用於需要比對的值本身是從 UTF-8 字串計算出來的情況。
100 MB 的限制與較大的檔案
100 MB 的上限是由工具所使用的瀏覽器 File API 所設定:在摘要運算完成之前，所選輸入必須能以一塊連續的位元組緩衝區形式取得。這對典型的安裝程式、韌體區塊以及 100 MB 以下的 ISO 映像來說都能順利運作，但會排除任何更大的東西，包括數 GB 的磁碟映像、未壓縮的影片檔以及完整的虛擬機器匯出檔。
對於超過 100 MB 的檔案，請改用可信賴的本機作業系統工具，並在信任其輸出之前檢查兩件事:
- 它執行的是哪一套演算法。該工具可能預設為 SHA-256;只有在已公布的校驗和明確為 SHA-1 時，才強制使用 SHA-1。
- 它讀取的是哪個位元組序列。請確認它處理的是原始檔案內容，而不是標準化後的副本、經 CR/LF 轉譯的副本，或經轉碼的外層包裝。
對於非常大的成品，串流式的命令列工具才是正確的選擇。對於任何能放進 100 MB 的檔案，基於瀏覽器的 Sha1 雜湊產生器會以完全相同的演算法對完全相同的位元組進行雜湊。
將雜湊與已公布的校驗和進行比對
雜湊相符僅代表您雜湊的位元組與用來產生已公布值的位元組逐位元相同。這並不能證明檔案名副其實——只能確認內容在傳輸過程中沒有改變。若要正確比對，請遵循 檔案校驗和比對指南 中的工作流程:
- 從工具複製 40 字元的十六進位字串。不要修剪空白、不要重新編碼，也不要中途在十六進位與 Base64 之間切換。
- 透過與檔案本身分開的可信賴管道傳遞該字串與已公布的校驗和——例如經簽署的發布頁面或 PGP 簽署的公告。
- 逐字元進行比對。在 40 個十六進位字元中只要有任何一個不相符，就代表位元組不同，該檔案不應被視為同一個成品。
- 若使用端系統預期的是 Base64 而非十六進位，請從同一個工具複製 28 字元的 Base64 形式，並與來源所公布的 Base64 形式進行比對。
不要將相符視為作者身分證明，也不要視為對決心堅定的攻擊者的保護。SHA-1 已被破解碰撞:攻擊者在實際可行的條件下可以建構出不同內容卻具有相同摘要的檔案，如 RFC 6194 所記載。校驗和工作流程僅在這個限制範圍內捕捉意外的傳輸損毀，僅此而已。
SHA-1 不適用的情境
請將 SHA-1 保留給舊版的校驗和比對。請勿將其用於:
- 數位簽章或程式碼簽署憑證。
- 防竄改或對抗式的檔案核准。
- 新信任儲存區中的憑證指紋比對。
- 密碼儲存或密碼驗證。
單純的 SHA-1 摘要並非密碼雜湊。快速的通用型演算法讓攻擊者能在商用硬體上每秒嘗試數十億組猜測。密碼儲存需要由帳號系統實作的有加鹽、刻意耗資源的密碼雜湊機制，例如 Argon2id、scrypt 或 bcrypt。Sha1 雜湊產生器從不加入鹽值，也從不衍生金鑰——它會對相同的輸入位元組每次都計算出相同的 160 位元摘要，這正好與密碼儲存的需求相反。
遷移至 SHA-256 或 SHA-512
若您掌控使用端系統，請使用 SHA-256 雜湊產生器 或 SHA-512 雜湊產生器 重新產生儲存的參考值，並將新的校驗和連同舊的一起(或取代舊的)發布。從操作者角度來看，這三種演算法的行為完全相同——相同的文字或檔案輸入、相同的瀏覽器本機處理、相同的十六進位或 Base64 選擇——但安全性態勢差異極大:
| 演算法 | 輸出位元數 | 十六進位長度 | Base64 長度 | 是否適合新的安全工作? |
|---|---|---|---|---|
| SHA-1 | 160 | 40 | 28 | 否——碰撞已被破解 |
| SHA-256 | 256 | 64 | 44 | 是 |
| SHA-512 | 512 | 128 | 88 | 是(高吞吐量時優先採用) |
在過渡期間，請對同一個成品同時驗證兩種摘要，以便仍預期 SHA-1 的現有用戶端在完成遷移前仍可正常運作。一旦所有使用端都已切換，即可完全移除舊有的 SHA-1 欄位，並透過已驗證的管道發布更強的校驗和。
若您正在權衡選項，如何使用 OpenSSL 或瀏覽器產生 SHA256 雜湊 對此有詳細說明。