JavaScript 中的 SHA-256 雜湊是將精確位元組通過 NIST FIPS 180-4 中定義的 SHA-2 壓縮函式所產生的 256 位元摘要,通常以 64 個小寫十六進位字元或標準填補 Base64 的形式呈現。瀏覽器內建的 Web Crypto API 可以透過 crypto.subtle.digest('SHA-256', bytes) 來計算它,這也是 SHA256 雜湊產生器所委派執行的相同操作,因此您無需自行撰寫樣板程式碼即可產生該值。產生器完全在您目前的瀏覽器分頁中執行,絕不會上傳您選擇的內容,並接受 UTF-8 文字或最多 100 MB 的檔案位元組。由於相同的位元組序列永遠會產生相同的摘要,您可以複製任一種表示法,並逐字元地與供應商、建置系統或已簽署發行版本所提供的參考值進行比對。

SHA-256 會產生什麼
SHA-256 屬於 NIST FIPS 180-4 所規範的 SHA-2 系列。在內部,該演算法會對訊息進行填補、將其分割成 512 位元的區塊、將每個區塊展開成 64 字排程,並更新八個 32 位元的工作數值。最後這八個字會組成 256 位元的摘要,且該輸出具備確定性:相同的輸入位元組永遠會產生相同的 32 位元組,且過程中不涉及任何隨機鹽值、金鑰或初始化向量。一旦計算出摘要後,工具會以兩種標準格式呈現,以便您將其交給任何您正在整合的系統。小寫十六進位形式是從 0-9 與 a-f 中取出的 64 個字元,而標準填補 Base64 形式則是從 A-Z、a-z、0-9、+、/ 中取出的 44 個字元,結尾再加上一個 =。兩種表示法編碼的是相同的 32 位元組;在十六進位形式中改變字母大小寫只會改變呈現方式,而不會改變底層的摘要。
在瀏覽器中執行 SHA256 雜湊產生器
如果您需要在不撰寫程式碼的情況下快速取得摘要,SHA256 雜湊產生器會在本機執行完整的 Web Crypto 操作,並並排回傳兩種表示法。您貼上一段字串或選擇一個檔案,頁面會將文字編碼為 UTF-8 或直接讀取檔案位元組,然後結果會以小寫 Hex 與填補 Base64 呈現,並顯示位元組計數作為參考依據。由於計算使用的是平台加密實作,因此該值會與正確撰寫的 JavaScript 程式碼片段所產生的結果、與命令列工具(例如相同位元組序列的 sha256sum)所產生的結果,以及與廠商所發佈的檢查碼(若該檔案未遭到竄改)相符。實作背後由八組 NIST 與 RFC 參考測試案例,加上獨立交叉驗證的文字、標點符號、UTF-8 與二進位案例所支援,並透過測試斷言其精確的摘要、固定的 32 位元組大小,以及標準的 Base64 編碼。
逐步建立 SHA256 雜湊
- 開啟 SHA256 雜湊產生器,並選擇您要雜湊文字還是檔案。請刻意切換模式,因為文字模式會將字串編碼為 UTF-8 位元組,而檔案模式會跳過解碼程序,直接雜湊您選擇的每一個位元組。
- 輸入您要驗證的精確內容。若是文字,請按照您要比對的來源中呈現的方式貼上字元;若是檔案,請使用檔案選擇器挑選最多 100 MB 的成品。顯示的位元組計數是結果脈絡的一部分,因此請務必留意。
- 產生 SHA-256 摘要。頁面會將位元組傳遞給瀏覽器的加密實作,回傳 32 位元組的摘要,並將其呈現為 64 個小寫十六進位字元以及標準的填補 Base64。
- 複製其他系統所預期的表示法。若廠商發佈的是 64 字元的檢查碼,請使用 Hex;若目標欄位預期的是 44 字元的填補形式,請使用 Base64。兩者編碼的是相同的位元組。
- 請比對完整的輸出,而非僅比對前綴。只有當預期值本身是真實的時候,相符的摘要才有意義,因此請透過 HTTPS、向擁有者索取,透過已簽署的發行版本,或透過其他適合該風險層級的已驗證管道來取得參考雜湊。
JavaScript 中的 Web Crypto API 途徑
當您希望直接從 JavaScript 呼叫 SHA-256 時,現代瀏覽器的方式是使用非同步的 SubtleCrypto.digest 介面。輸入必須是 BufferSource,這就是為什麼字串會先使用 TextEncoder 進行編碼,而檔案則會使用 FileReader 或 Blob.arrayBuffer 進行讀取。回傳的 ArrayBuffer 是原始的 32 位元組摘要,而將其轉換為十六進位則是對每個位元組進行的小型迴圈。一個簡潔、完整的範例如下所示:
async function sha256Hex(text) { const bytes = new TextEncoder().encode(text); const digest = await crypto.subtle.digest('SHA-256', bytes); return [...new Uint8Array(digest)] .map(b => b.toString(16).padStart(2, '0')) .join(''); }
相同的模式也適用於 File 物件,只要將 new TextEncoder().encode(text) 替換為 await file.arrayBuffer() 即可。若要取得填補 Base64 而非十六進位,請將產生的 Uint8Array 通過 btoa(String.fromCharCode(...bytes)) 處理,並且只有在位元組長度不是 3 的倍數時才附加 = — 對於 32 位元組的 SHA-256 摘要而言,填補永遠是一個 =。如果您想深入了解邊界情況以及 Web Crypto 與現成工具之間的關係,請參閱JavaScript 中產生 SHA-256 雜湊:Web Crypto 與工具指南。這兩種路徑背後的規範都是NIST FIPS 180-4,因此當 JavaScript 實作與 SHA256 雜湊產生器雜湊相同的位元組時,兩者不可能產生不同的結果。
為什麼您的雜湊可能與其他工具不同
摘要不符最常見的原因是隱藏的位元組差異,而非演算法差異。文字模式會在雜湊之前將您的字串編碼為 UTF-8,這一點很重要,因為像 é 這樣的字元是兩個位元組,而一個表情符號通常是四個位元組。如果參考工具將您的輸入視為 Latin-1 或字碼點,則位元組序列將會分歧,摘要也會跟著不同。空格、 carriage returns、結尾的換行字元以及 Unicode 正規化形式也都是位元組,並會改變結果,因此附加結尾換行的 shell 命令所產生的雜湊,會與不附加結尾換行直接貼上內容所產生的雜湊不同。與命令列工具進行比對時,請確保兩端讀取的是相同的檔案,且沒有夾帶額外的換行字元。檔案模式可避免這個問題,因為它會雜湊所選成品的每一個位元組,包括檔頭、內嵌的中繼資料以及行尾位元組,因此 SHA256 雜湊產生器與在相同檔案上正確呼叫的 sha256sum 結果將會一致。
什麼時候 SHA-256 不是合適的工具
SHA-256 是單向且無金鑰的,這使得它非常適合用於完整性檢查,但不適合用於若干相關任務。請將摘要用於驗證下載、確認兩個成品是否逐位元組相同,或產生建置與部署工作流程所需的數值。請勿直接透過套用 SHA-256 來儲存密碼:它的速度有助於完整性檢查,但也同樣有助於攻擊者測試密碼猜測,因此帳號系統應使用唯一的鹽值以及具備校準過的記憶體與時間成本、專為密碼雜湊設計的函式,例如 Argon2id、scrypt 或 bcrypt。SHA-256 也無法驗證輸入的建立者身分,因此當兩個系統共用秘密並需要訊息驗證時,請使用 HMAC-SHA-256,或在驗證者必須使用公開金鑰確認來源時,使用數位簽章。下表摘要整理了原始 SHA-256 何時是合適的基礎原語,以及何時應改用具驗證機制的替代方案。
| 使用情境 | 僅使用 SHA-256? | 更好的替代方案 |
|---|---|---|
| 根據廠商檢查碼驗證下載的檔案 | 是 | — |
| 確認兩個成品逐位元組相同 | 是 | — |
| 儲存使用者帳號密碼 | 否 | Argon2id、scrypt 或 bcrypt 並搭配唯一的鹽值 |
| 在共用秘密的兩方之間驗證訊息 | 否 | HMAC-SHA-256 |
| 證明訊息是由特定金鑰持有者所建立 | 否 | 數位簽章,例如 Ed25519 或 ECDSA |
請將演算法名稱與任何儲存的摘要一起記錄下來,如此一來,64 字元的 SHA-256 值日後便不會與其他格式或未記載的檢查碼混淆。產生器刻意接受空文字,因為空位元組字串具有合法的標準摘要,其開頭為 e3b0c442,而非同步作業識別可防止頁面運作時,較舊的檔案讀取或雜湊取代較新的選擇。
如果您正在權衡各種選項,在 Linux 上無需終端機產生 SHA-512 雜湊對此有詳細說明。