SHA-256 是一種 256 位元的加密摘要，由 NIST FIPS 180-4 所定義，可以使用 OpenSSL 的 dgst -sha256 子指令在一行內產生，也可以在瀏覽器中從完全相同的 UTF-8 或檔案位元組在本機計算。OpenSSL 路線適合腳本、CI 流程，以及希望使用已知、可重現工具且輸出格式可預測的遠端伺服器;瀏覽器路線適合快速的抽樣檢查、在不想開啟終端機時驗證下載檔案，以及貼上字串比透過 shell 回顯更快的情境。對於相同的輸入位元組，兩種路徑都會產生相同的固定 32 位元組摘要，可以呈現為 64 個小寫十六進位字元，或是標準的填充 Base64。要注意的重點是確保兩端看到的輸入在位元組層級完全相同 —— 這意味著換行字元要一致、UTF-8 編碼要相同，而且不能有 shell 額外附加的尾端換行 —— 並且你用來比對的參考雜湊是透過已驗證的管道發布的，而不是從無關的鏡像網站抓取而來。
OpenSSL 產生 SHA-256 摘要背後的指令
對檔案計算 SHA-256 雜湊的標準 OpenSSL 呼叫是一行指令。在存放該檔案的目錄中開啟終端機，然後執行 openssl dgst -sha256 filename.zip。輸出會以類似 (stdin)= 摘要 或 filename.zip= 摘要 的形式印出演算法名稱和 64 字元的十六進位摘要。若想在腳本中去掉檔名前綴，加上 -r 即可輸出單一以空格分隔的一行:openssl dgst -sha256 -r filename.zip。OpenSSL 也接受簡寫別名 openssl sha256 filename，在 FIPS 模式下建置的版本中兩者等價，而且更便於記憶。
若要對字串常值(而非檔案)計算雜湊，可將 echo 透過管線傳入同一個命令。關鍵的旗標是 -n，它告訴 echo 不要附加尾端換行 —— 那單一個位元組會徹底改變摘要。指令 echo -n "hello world" | openssl dgst -sha256 會回傳廣為人知的測試向量 b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9。若移除 -n，附加的換行會讓輸出整個偏移為完全不同的 64 字元值，這正是命令列摘要經常讓新手感到意外的原因 —— 他們往往是與從網頁複製的校驗碼進行比對。若必須完全避免任何換行，請使用 printf '%s' "your string" | openssl dgst -sha256，這會在不同的 shell 之間產生位元組完全相同的輸出。
對於二進位檔或下載下來的產物，同一個 openssl dgst -sha256 呼叫會精確地對所有儲存的位元組計算雜湊，包括檔頭、中繼資料，以及檔案若以 CRLF 換行儲存時的 CRLF。CLI 端沒有所謂的串流限制;OpenSSL 會很樂意以分段方式處理數 GB 大的檔案。若你要驗證的是已發布的簽章，而非僅僅是校驗碼，可將摘要指令與 openssl dgst -sha256 -verify publickey.pem -signature file.sig file 搭配使用，或使用對應的演算法來比對另外下載的簽章檔案。對於日常針對已發布十六進位字串的完整性檢查，單純的摘要指令就已足夠。
在瀏覽器中產生 SHA-256 雜湊
當無法使用終端機時 —— 例如在鎖定的工作站上、在共用電腦上，或是單純貼上文字比輸入 shell 指令更快時 —— SHA256 雜湊產生器 可直接在瀏覽器分頁中重現相同的 NIST 定義摘要，使用的是平台內建的密碼學實作。所有運算都在本機進行，不會上傳任何資料，結果面板會同時顯示位元組數量以及十六進位與 Base64 輸出，讓你能精確地檢查到底雜湊了哪些內容。
- 開啟 SHA256 雜湊產生器，選擇文字模式或檔案模式。
- 輸入或貼上精確的 UTF-8 字串，或選擇你要雜湊其位元組的本機檔案。
- 產生摘要，並閱讀結果旁顯示的位元組數量 —— 它應該與你預期要雜湊的位元組相符。
- 複製 64 字元的小寫十六進位值，或是標準填充的 Base64 字串，端看接收端系統需要哪種格式。
- 將完整輸出與你從可信來源取得的參考雜湊，逐字元進行比對。
此工具將檔案輸入上限設為 100 MB，因為底層的 Web Cryptography 摘要介面是在單一呼叫中接收整個位元組緩衝區，而不是以串流分段方式處理。對於更大的產物，請改用本機機器上的串流式 CLI 工具。文字模式並非以字元為基礎:頁面會先將字串編碼為 UTF-8，因此帶腔調字母、表情符號，以及 ASCII 以外的文字，各自都會貢獻正確數量的位元組到你所看到的數字。檔案模式則完全跳過文字解碼，直接對所選的每個位元組進行雜湊 —— 包括隱藏的中繼資料、嵌入的檔頭，以及換行位元組 —— 這也是為什麼它的輸出與對同一個檔案執行 openssl dgst -sha256 的結果一致。
為什麼瀏覽器與 CLI 的結果有時會不同
兩種路徑都實作了相同的 FIPS 180-4 壓縮函式，因此只有當輸入位元組改變時，摘要才會改變。當瀏覽器工具與 OpenSSL 指令產生不同的結果時，原因幾乎總是輸入中存在隱藏的位元組層級差異，而不是演算法不相符。下表依據常見程度依序列出常見的原因。
| 常見原因 | 實際發生情況 | 修正方式 |
|---|---|---|
| Shell 附加了尾端換行 | Echo 加上 0x0A，使壓縮函式中的每個區塊邊界都產生偏移 | 使用 echo -n 或 printf '%s' "your string" |
| 文字編碼不相符 | 一端將字串視為 Latin-1，另一端視為 UTF-8 | 確認兩個工具都讀取 UTF-8，並檢查顯示的位元組數量 |
| Unicode 正規化形式 | 視覺上相同的字串，但字碼點位元組不同(NFC 對 NFD) | 在雜湊前將兩端正規化為 NFC |
| 檔案與文字混淆 | 檔案模式忽略文字解碼，保留原始位元組 | 二進位檔使用原始位元組，文字則使用編碼後的 UTF-8 |
| 不可見的空白字元或 BOM | 多餘的空格、Tab，或是 UTF-8 BOM(EF BB BF)悄悄混入 | 移除 BOM、修剪空白，然後重新雜湊 |
每當摘要與參考值不一致時，先修正輸入，再重新執行兩個工具。不一致反映的是位元組的問題，而不是演算法的問題 —— 一旦輸入一致，OpenSSL 與瀏覽器產生器也會一致。
十六進位與 Base64:同一 32 位元組的兩種呈現
SHA-256 摘要永遠剛好是 32 位元組，也就是 256 位元。Hex 與 Base64 之間的選擇純粹是由產生校驗碼的軟體所決定的呈現方式;底層的位元組完全相同，兩種編碼都可以無損地互相轉換。
| 特性 | 十六進位 | Base64 |
|---|---|---|
| 輸出長度 | 64 個字元 | 44 個字元，包含等號填充 |
| 字元集 | 數字 0–9 與小寫字母 a–f | A–Z、a–z、0–9、加號、斜線，以及等號填充 |
| 比對時是否區分大小寫 | 是 | 是 |
| 所代表的底層位元組 | 32 位元組 | 32 位元組 |
| 常見使用情境 | Git commit 雜湊、ISO 校驗碼、套件管理器的摘要 | JWT 段落、API 請求主體、精簡的權杖格式 |
當你從 SHA256 雜湊產生器複製摘要時，選擇接收端預期的表示方式。十六進位字母的大小寫只影響呈現，絕不會改變底層位元組值，因此大多數工具無論接受大寫或小寫，都會產生相同的相符結果。以固定時間進行比對的接收系統通常會先把兩端都轉為小寫;如果你的系統不會這樣做，就請精確地按照你所複製的大小寫貼上，避免產生隱形的輸入錯誤。
相符的摘要僅能證明位元組相符
SHA-256 比對只能精確回答一個問題:這個 32 位元組摘要是否來自經過 SHA-2 壓縮後產生這 32 位元組的輸入位元組?它無法證明是誰建立了檔案、何時建立的，或為何建立。NIST CAVP 安全雜湊 套件會以已知向量驗證演算法;但它無法驗證你所比對的摘要其出處是否可信。
若攻擊者能同時替換下載檔以及檔案旁顯示的校驗碼，那麼重新計算 SHA-256 仍然會相符 —— 只是因為兩者被一起換掉了。要讓摘要比對具有意義，參考雜湊必須來自攻擊者無法竄改的管道:透過 HTTPS 提供的廠商網站、經簽署的 release 公告、套件管理器的清單檔，或是與 PGP 簽章一同發布的校驗碼檔案。對於高度重要的發布，請先驗證簽章檔，然後才信任其所列的摘要。
對於需要確認訊息來源的應用，SHA-256 是不適合的工具。當兩方共用秘密，需要驗證每一則訊息時，請使用 HMAC-SHA-256;當驗證者必須確認來源時，請使用搭配公鑰的數位簽章。密碼儲存也屬於不同的類別:密碼的原始 SHA-256 對攻擊者而言非常容易暴力猜測，因此生產環境應使用每位使用者唯一的 salt 與專為此用途設計的記憶體困難函式，而不是使用此原始摘要。
選擇正確的工具取決於使用情境。OpenSSL 仍是腳本與伺服器端自動化的標準，適合在命令列已受信任、且希望無大小限制地雜湊大型檔案的場合。SHA256 雜湊產生器則適用於不想特地開啟終端機的情境 —— 貼上一段複製的字串、在公用電腦上驗證下載檔案，或是向同事展示一段文字的精確摘要。當輸入位元組相符時，兩者會產生相同的 32 位元組答案，而這個特性是唯一值得比較的。