SHA-256 對於它接收的任何位元組序列，都會產生一個 64 字元的十六進位摘要，長度恰好是 32 位元組 (256 位元)，所以要產生某字串的 SHA-256 雜湊值，你必須先明確決定該字串代表的是哪些位元組。SHA256 雜湊產生器會在你目前的瀏覽器分頁中執行 NIST FIPS 180-4 標準演算法，無論輸入是單一字元、多行段落，或是空字串，都會回傳相同的摘要，並以兩種輸出格式呈現相同的 32 位元組。文字輸入會在雜湊前以 UTF-8 編碼，這代表含音標的字元、表情符號，或非 ASCII 文字的字元，會以 2、3 或 4 個位元組計算，而不是 1 個位元組，所顯示的位元組總數也是因此才會一併提供。檔案則是逐位元組進行雜湊，不做任何文字解碼的步驟。你所輸入或挑選的資料都不會離開瀏覽器，因此你可以放心地為憑證、API 酬載或機密字串計算校驗碼。
SHA-256 實際上對字串做了什麼
許多人將雜湊想像成對「字元」的轉換，但演算法只看得見位元組。SHA-2 系列中、由 FIPS 180-4 規範的 SHA-256 函式會對位元組輸入進行填充，將其切割為 512 位元的區塊，再將每個區塊展開成 64 字的排程，並更新 8 個 32 位元的工作變數，直到最後 8 個字被串接為 256 位元的摘要。這整個過程都不是在字元層級發生。對字串而言，字元必須先透過編碼轉成位元組，而唯一標準的選擇就是 UTF-8。
其含意非常具體。以預組合 (precomposed) 的「é」字元寫成的字串 café，在 UTF-8 中佔 5 個位元組 (c、a、f，加上 é 的 2 個位元組)。同樣的邏輯字若以組合式尖音符 (e + ́) 書寫，則佔 6 個位元組 (c、a、f、e，加上組合記號的 2 個位元組)，但這兩組位元組序列並不相同，因此兩個 SHA-256 雜湊值也會不同，即使兩者在螢幕上看起來都是「café」。這就是為什麼這個工具會在摘要旁邊顯示位元組計數的原因——位元組計數是說明兩個結果為何一致或不一致的脈絡之一。
產生字串的 SHA-256 雜湊值
- 在瀏覽器中開啟 SHA256 雜湊產生器，並選擇文字輸入模式。
- 貼上或輸入你想要雜湊的確切字串，留意空白、換行，以及來源可能附加的結尾換行字元。
- 查看輸入框下方顯示的位元組計數，確認 UTF-8 大小符合預期——若不一致，通常代表有不可見字元或使用了不同的編碼。
- 產生 SHA-256 摘要，並依據比對對象系統所要求的格式，複製 64 字元的小寫 Hex 表示法，或填充過的 Base64 表示法。
- 將完整輸出與經驗證的參考值逐字元比對;若比對通過，代表位元組一致，若比對失敗，則代表輸入位元組連一個空白都不一致。
為何看起來相同的兩個字串，雜湊結果卻不同
字串的雜湊值不符，幾乎都是來自人眼看不見的單一位元組差異。以下依實際支援單據中出現的常見次序，列出最常見的原因。
- 結尾的換行字元。許多命令列工具與編輯器在儲存文字時會附加一個結尾的 \n。在典型的 shell 中執行 echo "test" 會附加換行，而瀏覽器的文字框不會，因此會產生 5 位元組而非 4 位元組的摘要。
- 換行位元組。Windows 檔案使用 CRLF (\r\n)，而 Unix 檔案只使用 LF (\n)。這兩種位元組序列並不相同，因此雜湊值也不會相同。在系統之間複製貼上時，可能會在無聲無息中將其中一種轉換成另一種。
- Unicode 正規化形式。NFC 與 NFD 對相同的可見字元使用不同的位元組序列。來自 Mac 的字串與來自 Windows 工具的字串，可能會以不同的方式正規化。
- 零寬度字元。由右至左標記、位元組順序標記 (BOM) 以及零寬度連接子 (zero-width joiner)，在螢幕上看起來什麼都沒有，卻會增加位元組並改變摘要。
- 編碼不符。將 Latin-1 的位元組序列當成 UTF-8 解譯，所產生的雜湊值，會與直接以 UTF-8 輸入相同字元所產生的雜湊值不同。
最安全的單一診斷方式，就是查看 SHA256 雜湊產生器在輸入框旁邊顯示的位元組總數。如果位元組計數與預期大小一致，代表你雜湊的就是正確的位元組;若不一致，表示問題出在編碼流程，而非演算法本身。
Hex 與 Base64 輸出一覽
32 個結果位元組可以用兩種同樣有效的方式表示。兩者編碼的是同一份摘要;只有呈現方式不同，也不存在其中一種帶有另一種所沒有的隱藏資訊。
| 特性 | 小寫 Hex | 標準 Base64 |
|---|---|---|
| 可列印字串的長度 | 64 字元 | 44 字元 (含填充) |
| 編碼的位元組數 | 32 位元組 | 32 位元組 |
| 字元集 | 0–9 與 a–f | A–Z、a–z、0–9、+、/ |
| 區分大小寫 | 是——大小寫僅影響呈現方式 | 不適用 |
| 常見出現場合 | 軟體發布頁面、套件管理工具、Git 提交記錄 | JWT 與 JWS 簽章、精簡的 API 權杖 |
改變 hex 輸出的大小寫並不會改變摘要;底層的 32 位元組完全相同。請永遠複製接收端系統所要求的格式，並在儲存任何摘要時一併記錄演算法名稱 ("SHA-256")，讓未來的讀者不會將一個 64 字元的值誤認為其他不相關的校驗碼格式。
字串 SHA-256 的實際用途
當你需要為長度不固定的文字產生簡短、固定大小的指紋，並希望在不洩露原始內容的前提下驗證身分時，字串雜湊就非常有用。以下提供幾個例子:
- 快取鍵值。許多內容系統會將正規化後的 URL 或查詢字串以 SHA-256 雜湊，以產生一個確定性的快取識別碼，在來源格式出現小幅變動時仍能保持一致。
- 內容指紋。提交訊息的摘要、議題追蹤系統的 ID，以及合併請求的標題，都能透過雜湊在建置日誌中建立穩定的參考。
- ETag 式的驗證機制。伺服器可以發布設定 blob 的 SHA-256，讓用戶端在不需要重新下載的情況下，偵測該 blob 是否已經變更。
- 快速的完整性檢查。在送出前對 API 請求主體或小型 JSON 酬載進行雜湊，可以讓你在記錄中附加一段精簡的校驗碼，以便日後稽核。
如需這些系統所使用的 SHA-256 訊息排程規格，請參閱 RFC 6234，該文件為網際網路社群重新整理了 FIPS 180-4，並確認了 64 個十六進位字元的輸出長度。
超越單純的雜湊
相符的摘要只能證明位元組相同;無法證明是誰產生的。若你的目標是訊息鑑別——確保它來自與你共享密鑰的合作對象——SHA-256 並非正確的工具。請改用 HMAC-SHA-256，它會將共享密鑰混入雜湊中，是 API 請求驗證的合適選擇。
若你的目標是儲存使用者密碼，SHA-256 單獨使用同樣不是正確的工具。它的設計刻意求快，這對於完整性檢查很方便，卻也讓攻擊者能以極高速率猜測密碼。真正的帳號系統會為每位使用者儲存一個獨特的隨機鹽，並搭配緩慢且記憶體密集的函式，例如 Argon2id、scrypt 或 bcrypt;緩慢的成本正是重點所在。SHA256 雜湊產生器刻意只提供原始的標準摘要，使其結果能毫無歧義地對照 FIPS 180-4 規格與命令列工具進行驗證。
以空字串進行快速健全性檢查
空輸入有一個眾所周知的標準摘要，因此非常適合作為冒煙測試。將空字串編碼會產生 0 個 UTF-8 位元組，而 0 位元組的 SHA-256 摘要，根據定義，就是常數 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855。如果你在 SHA256 雜湊產生器中什麼都不輸入並複製 hex 輸出，你應該會看到完全相同的 64 字元字串。如果看到的結果一致，代表這個工具正確地實作了標準;若結果不同，則在進行任何比對之前，編碼或演算法本身就已經有問題。
若想進一步了解，請參閱 SHA-512 加鹽密碼雜湊:輸出的意義。
若想進一步了解，請參閱 在 Python 中轉換為 UTF-8:字串、檔案與失敗案例。