SHA-256 會產生固定的 256 位元摘要 —— 64 個小寫十六進位字元或 44 個標準 Base64 字元 —— 代表您所選擇任何檔案的精確位元組。當您為檔案產生 SHA256 雜湊值時，演算法會讀取該檔案的每一個位元組，包括不可見的標頭、嵌入的中繼資料，以及行尾位元組，並將其縮減為一個 32 位元組的指紋，在實務上沒有兩個不同的檔案會共用同一個指紋。這個結果小到可以貼到任何地方，但只要輸入的位元組有任何一個位元改變，它就會完全變動。SHA256 雜湊產生器會在您目前的瀏覽器分頁中執行此計算，使用 NIST FIPS 180-4 所指定的平台加密實作，因此您選擇的檔案絕不會離開您的機器。這讓此操作既可重現又具有隱私性:您複製的摘要就是演算法計算出來的摘要，沒有中介伺服器、沒有上傳步驟，也沒有對原始檔案做任何修改。了解該摘代表什麼 —— 以及不代表什麼 —— 是妥善運用它的第一步。
SHA-256 檔案雜湊實際代表的意義
SHA-256 檔案雜湊是將檔案位元組以確定性、單向的方式縮減為固定大小的識別碼。三項特性使其適用於檔案完整性工作。
首先，摘要是固定長度的。每個 SHA-256 輸出恰好都是 32 位元組，無論輸入檔案是 4 KB 還是 4 GB。這種一致性讓 64 個字元的十六進位字串能夠與數以百萬計的其他檔案一起，存放在資料庫欄位、發佈頁面或建置記錄中。
其次，摘要是確定性的。相同的輸入位元組序列永遠會產生相同的輸出位元組序列。若您在星期一為某個檔案計算雜湊，並在星期五對同一個未經修改的檔案再次計算，兩次操作必須產生相同的 64 字元十六進位字串。任何差異都代表位元組已經改變。
第三，摘要是單向的。沒有金鑰、沒有反運算，也沒有支援的方式可以從 SHA-256 摘要還原出原始檔案。SHA-256 不是加密;它是個指紋函式。SHA-256 屬於 NIST FIPS 180-4 所規範的 SHA-2 系列，該標準定義了實作必須遵循的精確填補、區塊與壓縮規則。
此工具會將該精確運算委派給瀏覽器:對輸入訊息進行填補、將其分割成 512 位元區塊、把每個區塊展開為 64 字排程，並更新八個 32 位元工作變數。最後八個字會組成 256 位元摘要。測試會將此精確摘要與 NIST 範例、RFC 範例，以及獨立交叉檢核過的文字、標點、UTF-8 與二進位案例進行比對，確保演算法本身已通過驗證，而不僅是自我一致。
如何為檔案產生 SHA-256 雜湊
- 開啟 SHA256 雜湊產生器，並切換到檔案輸入模式，而非文字輸入模式。
- 從本機磁碟選擇您要計算雜湊的檔案。該工具透過瀏覽器直接讀取最多 100 MB 的位元組，且不會上傳任何內容。
- 確認顯示的位元組數符合您的預期。位元組數屬於驗證情境的一部分，並非裝飾性細節，因為它能告訴您摘要涵蓋的確切位元組序列。
- 產生 SHA-256 摘要，並等待計算完成。非同步作業識別可防止較舊的檔案讀取或雜湊結果取代較新的選取。
- 複製 64 字元的小寫十六進位輸出，或標準填補的 Base64 輸出 —— 視參考系統所預期的格式而定。
- 逐字元比對完整輸出與信任的參考值。切勿僅比對前綴，若參考值本身區分大小寫，則比對時也必須嚴格區分大小寫。
若您同時使用命令列工具為檔案計算雜湊，請確認 shell 管線並未悄悄附加換行字元，並確認兩端從同一個檔案讀取到相同的位元組序列。這兩點中任何一點不一致，就會產生與您預期不同的摘要，即使來源檔案看似相同。
檔案檢查碼的 Hex 與 Base64 輸出
32 個結果位元組可以顯示為兩種等價的表示方式。Hex 是面向使用者的參考來源(如廠商下載頁面、建置清單與 Git 提交雜湊)的慣用選擇，因為每個字元都是數字或小寫字母，只要快速目視掃描就足以察覺打錯字。Base64 較為密集，這使其在 API、JSON 承載與精簡記錄(每個字元都耗用頻寬)等場景中具有吸引力。下表比較這兩種格式。
| 特性 | Hex 輸出 | Base64 輸出 |
|---|---|---|
| 輸出長度 | 64 字元 | 44 字元 |
| 字元集 | 0–9 與 a–f | A–Z、a–z、0–9、+、/，以 = 填補 |
| 大小寫敏感性 | 依慣例為小寫;兩種寫法的摘要相同 | 嚴格區分大小寫 |
| 常見用途 | 下載頁面、建置清單、Git 提交雜湊 | API、JSON 承載、精簡記錄 |
| 驗證方式 | 逐字元目視比對 | 更易於複製與解析 |
兩種格式都代表相同的 32 位元組，因此選擇哪一種並不會改變演算法的計算結果。請複製其他系統所預期的表示方式;改變 Hex 字母的大小寫只會改變呈現方式，並不會改變底層的摘要位元組。
將檔案雜湊與信任的參考值比對
檔案雜湊的價值，僅與您比對的參考值是否可信等強。只有在期望值本身可信時，相符的摘要才具有意義。若攻擊者能同時替換檔案與旁邊顯示的檢查碼，重新計算 SHA-256 只會確認攻擊者的組合，而不是揭穿它。
若要讓比對值得信賴，請透過 HTTPS 從檔案擁有者取得參考雜湊、透過加密簽署的發佈版本取得，或透過其他適合該風險等級的已驗證管道取得。對開放原始碼發行版本來說，通常意味著在專案官方下載鏡像站上，與二進位檔一同發佈的 checksums.txt 檔案，並由您能在離線管道驗證的維護者金鑰所簽署。對廠商提供的安裝程式而言，參考值通常會出現在已簽署的發佈說明中，或透過 TLS 取得的檢查碼清單中。
取得已驗證的參考值後，請貼上完整的摘要 —— 而非前綴 —— 並逐字元進行比對。一個字元不符就代表位元組不同，即使前綴看起來相同也一樣。如需此比對工作流程的更深入說明，請參閱比對參考值指南。
請在儲存任何摘要時一併記錄演算法名稱。一個沒有標示的 64 字元字串，可能是 SHA-256、截斷的 SHA-512，或某個未記載的自訂檢查碼，若沒有標籤，日後將無法分辨是哪個演算法所產生。
為何決定結果的是檔案位元組 —— 而非檔名
常見的誤解是，檔案的檔名、副檔名或位置會影響其雜湊值。事實不然。檔案模式會完全跳過文字解碼，並對所選的每個位元組進行雜湊，包括標頭、嵌入的中繼資料，以及行尾位元組。把 installer.exe 改名為 installer.bak 並不會改變摘要。把檔案從一個資料夾複製到另一個資料夾也不會改變摘要。唯一會改變摘要的，是底層位元組的變動。
這種位元組層級的保真度，同時也解釋了為何對看起來相同的內容，文字模式設定會產生不同的雜湊。在文字模式下，工具會先把字串編碼為 UTF-8，因此像 é 這樣的多位元組字元，會產生與 ASCII 字母 e 後接組合尖音符號不同的摘要。空格、Unicode 正規化形式、歸位字元與結尾換行字元全都是位元組，都可能改變結果。當您切換到檔案模式時，這些文字模式的細微差異便會消失，因為工具是直接對檔案已包含的位元組進行雜湊。
檔案上限為 100 MB，因為瀏覽器的摘要運算接收的是完整位元組緩衝區，而不是串流介面。對於更大的檔案，請改用本機上可信的串流工具，而不是耗盡瀏覽器的記憶體。此工具也刻意只執行原始的標準摘要;它不會把輸入包裝在 HMAC 結構中、不會用私密金鑰簽署，也不會套用密碼雜湊函式。這些都是具有不同保證的不同操作，選擇正確的操作與選擇正確的雜湊同樣重要。