若要取得 SHA-1 雜湊值，請將您的輸入透過 SHA-1 演算法執行，以產生其固定的 160 位元摘要，然後將產生的 20 位元組寫成 40 個小寫十六進位字元，或 28 個標準填補的 Base64 字元。無論輸入大小為何，輸出長度永遠相同，因為演算法的定義就是針對任何訊息輸出剛好 160 位元。當您從文字或檔案取得 SHA-1 雜湊值時，輸入的每一個位元組都會參與運算，包括不可見的字元，例如空格、換行符號，以及重音字母、表情符號和非拉丁字母文字背後的多位元組 UTF-8 序列。這就是為什麼兩個在畫面上看起來完全相同的字串，可能會產生不同的摘要。基於瀏覽器的 Sha1 雜湊產生器 使用 NIST FIPS 180-4 中指定的演算法在本機端計算摘要，因此您選擇的位元組永遠不會離開您的機器。在舊版下載頁面、檔案目錄或舊整合機制發佈 SHA-1 校驗和，且您需要比對確切的位元組時，這就是合適的工具。對於任何新的安全敏感工作，請改用 SHA-256 或 SHA-512。

get sha1 hash
取得 SHA-1 雜湊值：文字 vs 檔案、十六進位 vs Base64

SHA-1 雜湊值實際上看起來是什麼樣子

SHA-1 由 NIST 作為 Secure Hash Standard 的一部分發佈，並記錄於 FIPS 180-4 中。它的工作很簡單：接收任意長度的訊息，透過五個 32 位元狀態字執行 80 輪混合運算，然後輸出 160 位元的摘要。因為摘要寬度固定，輸入的大小並不會改變結果的長度。它只會改變演算法在讀取最終狀態前，內部處理的 512 位元區塊數量。

160 個位元會以 20 個原始位元組的形式輸出。這 20 個位元組可以用兩種標準方式來表示：

  • 小寫十六進位：每個位元組會變成兩個十六進位字元，總共剛好 40 個字元。這是多數舊版校驗和檔案使用的格式。
  • 標準填補 Base64：這 20 個位元組會使用 RFC 4648 字母重新編碼，產生 28 個字元。由於 20 位元組無法被 3 整除，結果會以一個 '=' 結尾。

這兩種表示法描述的是同一個摘要。它們不是不同的雜湊值，無法在沒有先將其解碼回原始 20 位元組的情況下互相轉換。選擇正確的格式純粹是為了符合使用端系統所期望的內容。

什麼時候 SHA-1 是正確的選擇（什麼時候不是）

SHA-1 已被破解出碰撞。研究人員已展示實際可行的選擇前綴碰撞，這代表攻擊者在現實條件下可以建構出兩個具有相同 SHA-1 摘要的不同檔案。因此，RFC 6194 明確警告不要將 SHA-1 用於任何新的數位簽章、憑證指紋，或可能被對手偽造的完整性承諾。

這並不代表 SHA-1 毫無用處。它在以下情境仍然是正確的選擇：

  • 比對舊版下載頁面或檔案目錄上發佈的舊版校驗和。
  • 將檔案與某個舊系統仍記錄的內部 SHA-1 參考值進行比對。
  • 重現其他腳本或程式庫已使用 SHA-1 產生的摘要，使兩個系統能夠達成一致。
  • 除錯已經依賴 SHA-1 輸出、需要快速交叉比對的工作流程。

在以下情境它則是錯誤的選擇：

  • 用於對抗性環境中的新數位簽章、憑證指紋或竄改偵測。
  • 密碼儲存。單純的 SHA-1 速度太快，攻擊者每秒可以對被竊的雜湊檔案測試數十億次猜測。請使用帶鹽、刻意放慢的機制，例如 Argon2id、scrypt 或 bcrypt，並由帳號系統實作。
  • 任何您可以自行選擇演算法、且希望具備現代安全邊際的設計。

對於新的安全敏感工作，SHA256 雜湊產生器 和 Sha512 雜湊產生器 是正確的起點。兩者都保持相同的瀏覽器內工作流程，但會輸出更長、目前安全的摘要。

三個步驟從文字或檔案取得 SHA-1 雜湊值

  1. 選擇 UTF-8 文字或檔案位元組，並提供未經正規化空白的確切輸入。如果您要雜湊輸入的字串，請直接貼上或輸入到文字欄位中。工具在雜湊前會將可見字串編碼為 UTF-8，因此重音字元、表情符號和非拉丁字母文字會使用其實際的多位元組形式。如果您要雜湊檔案，請從磁碟中選擇它。工具會讀取其原始位元組，直到文件記載的 100 MB 上限，且絕不會將其傳送至任何地方。請勿修剪開頭或結尾的空白、不要重新編碼檔案，也不要讓文字編輯器悄悄轉換換行符號。
  2. 產生 SHA-1 摘要，並選擇舊版系統所需的十六進位或 Base64 表示法。點擊計算按鈕。結果會以 40 個小寫十六進位字元顯示。當使用端系統預期使用 28 字元填補形式時，請切換到 Base64。無論使用哪一種方式，底層的 20 個摘要位元組都是相同的。
  3. 透過可信賴的管道逐一比對每個字元，並對新的安全敏感工作改用 SHA-256 或 SHA-512。相符的摘要只能證明位元組序列完全相符，無法證明作者身分。對於新的設計，請改用更強的演算法，並在可行時遷移已儲存的參考值。

十六進位還是 Base64：您需要哪種輸出格式

舊版系統通常會選定一種格式並持續沿用。讀錯格式會讓完全正確的摘要看起來不符，這也是這些頁面上出現「雜湊值不符」最常見的原因。下表摘要說明了 SHA-1 在實務上的差異。

特性 小寫十六進位 標準 Base64
字元集 0 到 9 以及 a 到 f A 到 Z、a 到 z、0 到 9、+、/
SHA-1 的輸出長度 40 個字元 28 個字元（一個 '=' 填補）
典型用途 校驗和檔案、.sha1 sidecar、README 列表 API token、嵌入式參考值、精簡欄位
區分大小寫？ 是 — 小寫形式為標準 是 — 大小寫是編碼的一部分
編碼標準 RFC 4648 第 8 節（base16） RFC 4648 第 4 節

如果下載頁面上的參考值是由數字和小寫字母組成的 40 字元字串，請複製十六進位的結果。如果它是 28 字元、以 '=' 結尾且可能包含大寫字母或 '+' 或 '/' 字元的字串，請複製 Base64 的結果。有疑慮時，發佈者使用的格式幾乎永遠就是您應該比對的格式。

為什麼確切的位元組和 UTF-8 編碼很重要

SHA-1 雜湊的是位元組，而不是字元。換行符號、單個空格以及缺少的結尾換行，都是位元組層級的差異，而這些差異會各自產生完全不同的摘要。這是設計上的特性，也是此演算法最有用的特性之一：檔案任何意外的更動都能被偵測出來。

同樣的原則也適用於文字。當您在文字欄位中輸入 "café" 時，工具會將其編碼為 UTF-8 位元組 63 61 66 C3 A9。即使渲染出來的文字看起來類似，對等價的 Latin-1 序列 63 61 66 E9 進行雜湊會產生不同的摘要。對於非 ASCII 的內容，請務必確認工具雜湊的是您實際想要處理的位元組，而不是重新編碼後的複本。

幾個值得了解的實際影響：

  • 空白的文字欄位是有效的訊息。其眾所周知的 SHA-1 值為 da39a3ee5e6b4b0d3255bfef95601890afd80709。
  • 在結尾加上換行符號會改變摘要，即使畫面上看起來一樣。
  • 使用不同的換行符號（CRLF 與 LF）重新儲存檔案會改變摘要。
  • 檔名、修改時間以及瀏覽器的 MIME 標籤永遠不會納入摘要的一部分 — 只有檔案的原始位元組會被雜湊。

安全地針對可信賴來源驗證摘要

相符的 SHA-1 摘要是一個強烈的訊號，代表您雜湊的確切位元組與產生參考值的位元組完全相同。它無法防範已經同時置換了檔案和發佈校驗和的攻擊者，也無法說明檔案是誰建立的。由於這兩個原因，參考值本身必須透過攻擊者無法重寫的管道送達。

安全的驗證習慣如下：

  • 從專案網站取得發佈的校驗和，最好透過 HTTPS，或從您可以獨立驗證的已簽署清單取得。
  • 使用 Sha1 雜湊產生器在瀏覽器本機端產生摘要。位元組永遠不會離開您的分頁，且摘要運算會針對您選擇的確切緩衝區執行。
  • 逐一比對每個字元。請留意大小寫、前導零、發佈字串中結尾的空白，以及不小心貼上的多餘字元。
  • 如果您掌控使用端系統，請將儲存的參考值遷移至 SHA-256 或更強的演算法，並透過已驗證的管道發佈新的校驗和。

這個工具能解決問題的真實情境

人們搜尋「取得 SHA-1 雜湊值」最常見的原因，是某個舊版產物仍然需要它。以下是幾個瀏覽器工作流程確實合適的具體例子：

  • 舊版下載入口網站在每個檔案旁邊列出 SHA-1。您已經下載了該檔案，並且想在不安裝額外軟體的情況下確認它是否為原始檔案。
  • 檔案目錄多年前儲存了 SHA-1 值，而您需要確認哪一份本機複本符合目錄中的哪一筆紀錄。
  • 某個腳本或程式庫會產生或取用 SHA-1，您想在不啟動本機工具鏈的情況下重現其輸出以進行除錯。
  • 較舊程式碼中的測試固定資料寫死了 SHA-1，您想確認產生的檔案仍然與其相符。

這些情境都不需要上傳檔案。基於瀏覽器的 SHA-1 摘要運算完全在您的分頁中執行，受限於文件記載的 100 MB 上限，因此您雜湊的位元組永遠不會到達外部伺服器。100 MB 的上限反映了此處使用的瀏覽器 API：在摘要運算完成前，所選的輸入必須以單一位元組緩衝區的形式存在。對於超過此大小的產物，請改用可信賴的本機作業系統工具，例如 Linux 或 macOS 上的 sha1sum，或 Windows PowerShell 中的 Get-FileHash -Algorithm SHA1，並在信任結果前同時確認演算法和位元組來源。

如果您正在權衡選項，在瀏覽器中產生檔案的 SHA-256 雜湊值對此有詳細說明。

如果您正在權衡選項，在瀏覽器中產生帶鹽的 SHA-512 雜湊值對此有詳細說明。