SHA-1 檔案雜湊是 NIST FIPS 180-4 所定義的 160 位元訊息摘要，顯示時會呈現為正好 40 個小寫十六進位字元，或 28 個經填補的 Base64 字元。當你搜尋「get sha1 hash of file cmd」這類做法時，目標幾乎都是以下兩件事之一：比對下載檔案旁邊公布的校驗碼，以確認位元組完整無缺地送達；或是產生一個值，連同檔案一起發布，讓接收端可以重複同樣的檢查。Windows 內建 certutil -hashfile 與 PowerShell 的 Get-FileHash 指令程式，而 Linux 與 macOS 則提供 sha1sum 與 shasum，在本機的命令列中任選其一都能產生相同的摘要。相同的 SHA-1 值也可以完全在瀏覽器分頁中產生，使用 Sha1 Hash Generator，既不需要安裝軟體，也不用把檔案上傳到遠端伺服器。本指南重點說明直接對應 CMD 工作的瀏覽器流程：選擇正確的輸入模式、產生摘要、並逐字元比對已公布的校驗碼。
為何瀏覽器工具可取代 CertUtil 與 Get-FileHash
命令列方式速度快，且內建於每個現代作業系統中，但仍有實際限制。目標檔案必須存放在可以開啟殼層的機器上，終端機必須接受長路徑，而且你必須記住確切的旗標（依工具而異，可能是 SHA1、SHA1sum 或 -Algorithm SHA1）。基於瀏覽器的工具跳過了安裝步驟，在任何能開啟網頁的裝置上都能運作——例如被鎖定的工作站、借來的筆電，甚至手機——只要你選擇同一個檔案，就會產生一模一樣的 40 字元十六進位字串。其內部機制相同：瀏覽器依據 FIPS 180-4 所定義的 SHA-1 摘要函式，依標準的填補方式、512 位元區塊與 80 回合排程處理檔案位元組，接著回傳同樣的 20 個摘要位元組。
如果你特別希望在 CMD 內操作，原生選項如下：
- Windows：在 PowerShell 中使用 certutil -hashfile "C:\path\to\file.zip" SHA1，或 Get-FileHash -Algorithm SHA1 "C:\path\to\file.zip"。
- Linux： sha1sum /path/to/file.zip。
- macOS： shasum -a 1 /path/to/file.zip。
這些指令都會印出單行 40 個十六進位字元。當無法使用殼層時——或單純希望結果更容易複製、貼上並目視比對——瀏覽器替代方案只需幾次點擊就能給你相同的字串。
在瀏覽器中取得檔案的 SHA-1 雜湊
對於想跳過終端機的讀者，以下是直接透過瀏覽器產生與 CMD 工具相同 40 字元字串的流程。
- 在桌上型或行動瀏覽器中開啟 Sha1 Hash Generator。不需要安裝、帳號或外掛。
- 將輸入模式切換為檔案。頁面提供文字欄位與檔案選擇器；請選擇檔案模式，讓工具對所選文件的原始位元組進行雜湊，而不是對你輸入的字元進行雜湊。
- 選擇你要雜湊的檔案。支援最高 100 MB 的檔案；所選位元組會在本機讀取，絕不會傳送到伺服器。
- 點擊產生摘要的按鈕。頁面會依照 FIPS 180-4 中定義的 SHA-1 演算法處理檔案位元組，並產生每個相容實作都會產生的相同 160 位元。
- 依目標系統要求選擇輸出表示方式。常見的 certutil / sha1sum 風格校驗碼請使用小寫十六進位；若舊式系統需要 28 字元的編碼形式，則使用標準填補式 Base64。
- 複製結果並貼在已公布的校驗碼旁邊。依序比對全部 40 個十六進位字元或 28 個 Base64 字元；只要有一個字元不符，就代表你手上的位元組與發布者簽署的位元組不同。
- 若檔案超過限制，請改用可信的本機作業系統工具，並在將其值視為權威結果前，先確認它接收到的是哪個演算法與位元組序列。
十六進位與 Base64：同一 20 位元組的兩種表示
摘要本身永遠是 20 個位元組。十六進位與 Base64 只是同一序列的兩種編碼方式，Sha1 Hash Generator 讓你可依接收端系統的期望選擇任一種表示。十六進位幾乎是所有命令列工具的預設：certutil、sha1sum 與 Get-FileHash 都會印出 40 個字元的小寫十六進位。Base64 則出現在某些較舊的資料庫匯出、憑證 blob 欄位，以及少數 Web API 中。
| 屬性 | 十六進位輸出 | Base64 輸出 |
|---|---|---|
| 長度 | 正好 40 個字元 | 含填補共 28 個字元 |
| 字元集 | 0–9 與 a–f | A–Z、a–z、0–9、+、/，並以 = 填補 |
| 使用工具 | certutil、sha1sum、Get-FileHash | 舊式憑證 blob、部分 REST API |
| 比對時是否區分大小寫 | 是 | 是 |
| 底層摘要是否相同 | 是——兩者編碼同一 20 位元組 | 是——兩者編碼同一 20 位元組 |
若你要餵入的系統要求 40 字元、無空白的小寫字串，請選十六進位。若它要求一行 A–Za–z0–9+/=，並以一個或兩個 = 結尾，請選 Base64。不要修剪空白、不要重新調整間距，也絕不要手動在兩者間轉換——工具的兩種模式都會輸出符合 RFC 4648 的標準形式，因此位元組本身會保持完全一致。
檔案模式涵蓋了哪些內容——以及略過了哪些
檔案流程會對作業系統交給瀏覽器的文件原始位元組進行雜湊。這代表只要每個工具看到相同的位元組序列，不論是 CMD、Linux 還是瀏覽器，同樣內容的 SHA-1 都能重現。以下三項刻意排除在摘要之外：
- 檔名。把 release.zip 改名為 release-final.zip，產生的雜湊相同。
- 修改時間。檔案複製到新位置後，仍帶有相同的摘要。
- 瀏覽器指派的 MIME 標籤。瀏覽器可能會公告 application/zip，但該字串並不包含在摘要所處理的位元組中。
文字模式的行為則不同。當你在文字欄位輸入字元時，工具會先把可見字串以 UTF-8 編碼再進行雜湊，這對含腔調字元、表情符號與非拉丁字母的腳本特別重要，因為單一字元可能佔用多個位元組。兩種模式不能互換：對 .txt 檔案的位元組進行雜湊，與對該檔案所含文字進行雜湊，兩者並不相同——若該檔案是以不同編碼儲存，結果更會有所差異。若你的 CMD 流程是針對位元組操作，請把瀏覽器工具保持在檔案模式。
有一項位元組層級的細節值得注意：空字串是合法的 SHA-1 輸入，擁有固定且眾所周知的摘要（da39a3ee5e6b4b0d3255bfef95601890afd80709）。空白的文字欄位與「完全沒輸入就點按鈕」並不相同——頁面必須在對某個內容執行過演算法後才會顯示摘要。
SHA-1 仍可派上用場之處，以及絕對不可使用之處
誠實的定位很重要。SHA-1 已被證實可產生碰撞：研究顯示攻擊者在現實條件下能構造出不同內容卻擁有相同摘要。這使得該演算法不再適用於任何新的安全設計，包括數位簽章、用於信任決策的憑證指紋、密碼儲存、對抗式檔案核准，以及防竄改保護。NIST 標準 FIPS 180-4 與 RFC 6194 明列了演算法內容與相關安全考量。
SHA-1 仍有其適用之處：
- 比對印在下載檔案、ISO 映像檔或韌體 blob 旁的舊式校驗碼。發布者只編碼了一次，你只需要偵測傳輸過程中是否發生意外損壞。
- 餵入尚未遷移至 SHA-256 或 SHA-512 的歷史資料系統。
- 基於相容性理由，與既有紀錄值進行逐位元組比對。
絕對不可使用的情境：
- 簽署新產出的成品。
- 驗證檔案的作者或來源，僅能用於偵測傳輸錯誤。
- 儲存密碼。SHA-1 是快速的通用演算法；攻擊者每秒可對其嘗試數十億次猜測。密碼儲存需要具備加鹽、刻意拉高成本的機制，例如 Argon2id、scrypt 或 bcrypt，並由帳號系統而非校驗碼頁面實作。
- 建構用於判斷上傳是否安全的核准流程。
一個實用的習慣是：對於每個 CMD 風格的校驗碼比對，都透過與檔案本身不同的管道取得參考值，並逐字元核對。若想將相同流程套用於更強的演算法，或需要完整的逐步比對說明，SHA-1 檔案雜湊比對完整步驟詳述了整個比對程序。若你能掌控接收端系統，請將儲存的參考雜湊遷移至 SHA-256 或更強的演算法，並透過經驗證的管道發布新的校驗碼。
瀏覽器檔案模式的限制
100 MB 的上限反映的是底層瀏覽器 API，而非演算法本身——在摘要函式能消化之前，整個選取的緩衝區都必須能讀入記憶體。對一般大小的下載、該容量以下的 ISO 映像、韌體 blob 與文件封存檔而言，這已相當充足。面對多 GB 的磁碟映像、作業系統安裝檔或壓縮備份時，請改回使用可信的本機命令列工具：
- Windows： certutil -hashfile bigfile.bin SHA1。
- Linux： sha1sum bigfile.bin。
- macOS： shasum -a 1 bigfile.bin。
在信任任何大型檔案的摘要之前，請先確認工具實際執行的是哪個演算法、讀取的是哪些位元組。SHA-1 與 SHA-256 雖然有相同的前置字母，但產生的輸出長度完全不同；在 SHA-1 流程中誤用 -Algorithm SHA256 參數，是常見的隱性不符原因。請務必在筆記中同時記錄演算法名稱與預期摘要，切勿僅憑前置字母就斷定相符。
想進一步了解，請參閱 產生 SHA256 雜湊並與參考值比對。