SHA-256 會將選定檔案的每一個位元組轉換成一個固定的 256 位元指紋 —— 一個 64 字元的十六進位字串，只有在輸入的某個位元發生變化時才會跟著改變。若要在本機產生檔案的 SHA 256 雜湊值，瀏覽器會讀取選定檔案的所有位元組(上限為 100 MB)，透過 NIST FIPS 180-4 中規定的 SHA-256 演算法進行運算，並將運算後的 32 個結果位元組以兩種等效格式呈現:小寫 Hex 與標準填補 Base64。這個計算工具絕不會上傳檔案，也絕不會更改任何一個位元組，並會回傳一個確定性的摘要，讓你可以一鍵複製。這個指紋是驗證下載內容、逐位元組比對兩個成品，以及在持續整合流程中為建置成品簽章的實務基礎。由於檔案模式會將輸入讀取為原始位元組而非解碼後的文字，每一個標頭區塊、中繼資料區塊以及行尾位元組都會納入摘要之中，因此產生的結果會與同一檔案透過 `sha256sum` 殼層工具所輸出的結果完全一致。

generate sha 256 hash of file
在瀏覽器中產生檔案的 SHA 256 雜湊值

SHA-256 在瀏覽器內部的運作原理

SHA-256 屬於 NIST FIPS 180-4 所定義的 SHA-2 系列。該演算法會將輸入填補至 512 位元的倍數，將填補後的輸入切割成多個區塊，將每個區塊展開為 64 個字詞的排程，並更新八個 32 位元的工作數值。最後一個區塊處理完畢後，這八個 32 位元的字詞會被串接成一個 256 位元的摘要。SHA256 雜湊產生器會將這個精確的運算作業委派給平台的 Web 密碼學實作，因此每一行輸出都對應到 NIST 公布的標準測試向量，以及 NIST FIPS 180-4 中所述的演算法契約。

當你在 SHA256 雜湊產生器中載入一個檔案時，瀏覽器會將原始位元組讀入記憶體，並將該位元組緩衝區直接送入摘要運算程序。整個過程中沒有任何文字解碼步驟、沒有行尾正規化，也沒有任何可能悄悄改變位元組的轉錄階段。呈現的輸出是同一組 32 個結果位元組的兩種表示方式之一:64 字元的小寫十六進位字串，或該組位元組的標準填補 Base64 字串。在 Hex 檢視中改變字母大小寫只會影響顯示方式，底層的摘要並不會受到影響。

這種位元組完全一致的行為正是檔案驗證所需要的特性，但也正是為什麼檔案中任何一個微小意外編輯都會產生截然不同的摘要。SHA-256 具備雪崩效應:每一個輸出位元都相依於每一個輸入位元，因此即使只翻轉一個位元組，大約一半的結果字元也會被重新洗牌。

如何產生檔案的 SHA 256 雜湊值

  1. 在目前的瀏覽器分頁中開啟 SHA256 雜湊產生器，並將輸入模式切換為檔案(而非文字)。
  2. 點擊檔案選擇器，挑選你想進行雜湊運算的精確檔案。這個工具接受任何類型的檔案，上限為 100 MB。
  3. 稍候片刻，等待瀏覽器載入位元組。由於不需要上傳任何東西，網路分頁會保持靜默，檔案也絕不會離開裝置。
  4. 請留意結果旁顯示的位元組數 —— 這是情境資訊的一部分，有助於進行合理性檢查。
  5. 點擊 Generate。瀏覽器會計算摘要，並針對同一組 32 個位元組呈現 64 字元的 Hex 值以及標準填補的 Base64 字串。
  6. 複製接收端系統所預期的表示格式。大多數的下載頁面與建置流程會公布小寫 Hex 格式;部分 API 與 CI 執行環境則預期使用 Base64。
  7. 將完整的摘要與可信的參考值進行比對。即使只有一個字元不同，也代表檔案位元組並不相同。

對於超過 100 MB 上限的極大型成品，請改用在本機執行的串流命令列工具。本工具所使用的 Web 密碼學摘要介面會取用完整的位元組緩衝區而非串流，因此任何超過上限的檔案將會失敗或耗盡分頁記憶體。

將計算出的雜湊值與廠商提供的檢查碼進行比對

SHA-256 摘要只有在預期值本身為真實可信的情況下，才能保護完整性。一旦你下定決心採用，這個實用的驗證通訊協定其實非常簡單:透過 HTTPS、已簽署的版本發布清單，或其他適合威脅模型的身分驗證管道，從檔案擁有者處取得公布的檢查碼。然後比對完整的 64 字元字串，而不是前綴，也不是模糊的「看起來很像」的比較方式。

如果攻擊者可以同時替換檔案以及顯示在檔案旁的檢查碼，那麼重新計算 SHA-256 只會確認攻擊者所準備的這一組配對，而無法揭穿攻擊。這就是為什麼散佈安裝程式的廠商網站是取得參考雜湊值的正確去處，也說明了為什麼信任留言串中發布的檢查碼或以明文電子郵件轉寄的檢查碼是不好的做法。至於建置成品，則應將摘要視為整個可重現建置流程中的一個檢查點，而不是獨立的安全性證明。

同一種摘要技術也能回答另一個常見的問題:這兩個逐位元組完全相同的成品，實際上是否真的相同?使用 SHA256 雜湊產生器對這兩個檔案分別進行雜湊運算，將兩組 64 字元的 Hex 值並排貼上，只要出現任何一個字元的差異，就代表它們並不相同。許多 Windows 使用者會將產生的檔案雜湊值與 `certutil` 或 PowerShell 指令進行交叉比對 —— Windows CMD 中的 SHA256 雜湊交叉比對 指南會逐步示範該如何進行比較。

檔案位元組與貼上的文字:實際進入摘要的內容

一個常見的混淆來源，是你正在進行雜湊的對象到底是原始檔案位元組，還是同一份內容重新輸入的複本。檔案模式與文字模式的行為並不相同，這個差異在與公布的檢查碼進行比對時至關重要。

情境進入摘要的內容常見陷阱
檔案模式，單一二進位檔選定檔案的每一個位元組，包含標頭與中繼資料即使可見內容「感覺一樣」，重新命名或壓縮也會改變摘要
檔案模式，原始碼封存檔所有位元組，包含行尾字元(LF 與 CRLF)以及任何 BOM 標記某些殼層會悄悄改寫行尾字元;兩端都必須對原始位元組進行雜湊
文字模式，貼上的字串貼上字串的 UTF-8 編碼位元組，不含標頭或 BOM重音字母與表情符號可能各佔 2 至 4 個位元組，因此可見長度並非位元組長度
文字模式，空輸入空的位元組序列標準摘要會以著名的 e3b0c442 前綴開頭;這並非錯誤
檔案模式，截斷的下載檔僅有截斷後的位元組請先比對檔案大小再比對摘要 —— 大小不同保證雜湊值也會不同

當你需要與同一檔案透過 `sha256sum` 殼層指令產生的摘要完全相同時，請使用檔案模式並搭配原始的成品。當你需要與某個針對字串進行雜湊的函式庫產生完全相同的摘要時，請使用文字模式，並確保使用完全相同的字元與相同的編碼預期(大多數函式庫預設為 UTF-8)。

為什麼相符的摘要並不等於身分驗證

SHA-256 是單向雜湊函式，而非加密。它沒有金鑰，沒有支援的反向運算，這個函式本身也不會驗證輸入的建立者是誰。摘要只能證明你所雜湊的位元組與其他人所雜湊的位元組相符 —— 對於這些位元組最初是由誰所產生，則完全沒有提供任何資訊。

對於在兩個共用秘密金鑰的系統之間進行訊息身分驗證，請改用 HMAC-SHA-256。對於由第三方使用公開金鑰進行來源驗證，請使用數位簽章:以私密金鑰對摘要進行簽章，任何驗證者都可以透過對應的公開金鑰進行驗證。即使兩個端點之間的摘要值相符，單純的 SHA-256 也無法提供上述任何一項特性。

請勿直接以 SHA-256 儲存密碼。SHA-256 的運算速度使其適合用於完整性檢查，但同樣的速度也有助於攻擊者大規模地測試密碼猜測。帳號系統應該使用唯一的 salt 以及專為此用途設計、具備經校時的時間與記憶體成本的記憶體硬函式(memory-hard function)來雜湊密碼，即便如此，保護的強度仍然僅與整體系統設計等量齊觀。

當檔案雜湊值不符時的快速修正方式

如果瀏覽器產生的摘要與參考值不相符，請依序檢查常見的原因，而不是胡亂猜測:

  • 去除尾端換行字元。POSIX 殼層經常會在 `echo` 之後附加一個 `\n`，這會為檔案增加一個位元組。改用不附加尾端換行的 `printf`，通常就能與預期值相符。
  • 確認兩端的編碼方式。Hex 與 Base64 是摘要本身的穩定編碼方式，它們無法修補因為雜湊了錯誤位元組所造成的差異。
  • 先檢查檔案完整性，再檢查摘要。截斷的下載檔會對截斷後的位元組產生一個「有效」的 SHA-256，因此「有效」的摘要並不能取代先驗證檔案大小的步驟。請先將檔案的位元組大小與廠商所列的大小進行比對。
  • 留意上限。瀏覽器內的工具可處理最高 100 MB 的檔案。如果是 DVD 映像檔或數 GB 的資料集，請改用串流工具，例如 Linux 與 macOS 上的 `sha256sum`，或 Windows PowerShell 上的 `Get-FileHash`。
  • 統一 Unicode 正規化形式。文字模式會以 UTF-8 進行編碼，但某些剪貼簿流程可能會在過程中套用 NFC 或 NFD 正規化。在跨平台比對文字輸入時，請為兩端指定同一種正規化形式。

在儲存任何摘要時，請一併記錄演算法名稱。一個 64 字元的 Hex 字串可能是 SHA-256 值、也可能是 SHA-512 的截斷結果，或是完全不同的機制;如果沒有標籤，就無法辨別其究竟為何，而這種模糊性在幾個月後可能會悄悄演變成驗證錯誤。

如需更深入的探討，請參閱 在瀏覽器中產生帶 salt 的 SHA-512 雜湊值。