完整的 SHA-512 會產生 512 位元的摘要，在 Devglan 風格的 SHA-512 雜湊產生器中，永遠會以 128 個小寫十六進位字元以及標準填補 Base64 的形式呈現。該演算法在 NIST FIPS 180-4 中作為 SHA-2 系列的一部分加以規範:它以 1024 位元的訊息區塊進行運作，將每個區塊展開為 80 個 64 位元字所構成的排程，並更新 8 個 64 位元的狀態值，其最終串接即為 512 位元的輸出。由於輸入的每個位元組都會影響輸出的每個位元組，因此摘要是確定性的，並且對空白字元、行尾符號、位元組順序標記以及 Unicode 正規化形式極為敏感。工具中的文字模式會先將字串轉換為 UTF-8，並回報產生的位元組數量;檔案模式則會在不解析檔名、字元集或 MIME 類型的情況下，直接對原始位元組進行雜湊。瀏覽器會在本地端執行運算，因此所選擇的訊息或檔案絕不會離開你的機器，你所複製的也只是摘要，絕對不是底下的檔案位元組。
Devglan 風格的 SHA-512 產生器實際計算的是什麼
Devglan 發布了一系列以瀏覽器為基礎的開發人員工具，而秉持同樣精神的 SHA-512 雜湊產生器所產生的是完整的 SHA-512 摘要，而不是它縮短版本中的任何一個。該產生器會將你所提供的精確位元組送入完整的 FIPS 180-4 SHA-512 壓縮迴圈:它會將訊息填補為 1024 位元的區塊，把每個區塊展開為 80 個 64 位元字所構成的排程，並更新 8 個 64 位元的鏈結變數，其最終串接即構成 512 位元的輸出。由於 64 個位元組的摘要會被完整保留，因此在 Hex 模式下你應該會看到剛好 128 個小寫十六進位字元，在 Base64 模式下則會看到單一行的標準填補 Base64。任何長度短於 128 個 Hex 字元的結果都代表該值被截斷了 —— 通常是因為不小心把 SHA-512 與 SHA-512/256 或 SHA-512/224 搞混，後兩者使用不同的初始化向量，分別會輸出 256 或 224 位元。Lizely 所提供的 Sha512 雜湊產生器遵循相同的合約:完整的 512 位元 SHA-512、確定性、位元組精確、在你的瀏覽器中依據 NIST FIPS 180-4 規範進行運算，並透過 8 個黃金測試案例涵蓋空序列、"abc" 向量、FIPS 多區塊訊息、標點符號變化、UTF-8 文字、任意二進位位元組，以及常見的措辭。
逐步產生完整的 SHA-512 雜湊
依照下列步驟產生一份可以與可信賴參考值逐字元比對的完整 SHA-512 摘要。
- 開啟 Sha512 雜湊產生器並選擇你的輸入模式 —— UTF-8 文字或本機檔案。若為文字模式，請貼上完全相同的字串，保留每個空格、Tab、換行，以及任何前置或後置字元。若為檔案，請從磁碟中選擇該成品;工具會讀取原始位元組，並忽略檔名、字元集宣告以及 MIME 類型，如此你雜湊的便是實際的成品，而不是經過解碼後的表示形式。
- 觸發運算。瀏覽器會在本機端執行完整的 FIPS 180-4 SHA-512 壓縮，在文字模式下回報輸入的位元組數，並以 128 個小寫 Hex 字元加上同樣 64 個位元組以標準填補 Base64 編碼的方式，回傳 512 位元的摘要。
- 複製你所使用的消費者端所預期的表示形式 —— 給校驗碼清單用的 Hex、給精簡傳輸用的 Base64 —— 並將它貼在你的可信賴參考值旁邊。請逐字元進行比對，包括小寫的大小寫，以及 Base64 結尾的等號。
- 確認消費者端確實需要的是完整 SHA-512，而不是 SHA-384、SHA-512/256、HMAC-SHA-512 或數位簽章。若該通訊協定指定的是截斷版本或是有金鑰的建構方式，請使用完全相同的建構方式重新產生;手動修剪 128 字元的輸出並不會相符。
此介面刻意將瀏覽器的輸入上限設定為 100 MB，以確保單次摘要運算能讓分頁保持回應速度並控制記憶體用量。SHA-512 本身在理論上支援大得多的訊息，但若是針對數 GB 級的映像檔或磁碟映像，請使用值得信賴的串流式命令列實作，並在本地端運算完成後再比對完整結果。工具中的非同步檔案讀取與摘要呼叫會使用單調遞增的工作識別碼，因此在舊的運算尚未結束時切換輸入模式，也不會讓過時的結果覆寫新的狀態。複製控制項只會公開摘要表示形式，絕不會將所選檔案的位元組放進剪貼簿。
讀懂 128 字元 Hex 與填補 Base64
兩種輸出代表的是同一組 64 個摘要位元組;差異純粹在於編碼方式。Hex 表示法會將 1 個位元組以 2 個小寫十六進位字元寫成，因此:
64 個摘要位元組 × 每位元組 2 個 hex 字元 = 128 個 Hex 字元
這個固定的長度是第一道健全性檢查。若某個系統給你 56 個 Hex 字元，你看到的是 SHA-224 或被截斷的輸出，而不是完整的 SHA-512。若給你 64 個字元，則是 SHA-256。96 個字元的 Hex 字串是 SHA-384。只有 128 個字元才代表完整的 SHA-512。
填補式 Base64 使用標準的 RFC 4648 字母表，以更精簡的方式對同樣的 64 個位元組進行編碼。由於 64 並非 3 的倍數，最後一組會剩下 1 個位元組，Base64 會將其編碼為 2 個輸出字元，再加上 2 個等號作為填補:
64 個位元組 ÷ 每組 3 個位元組 = 21 個完整組，剩餘 1 個位元組 21 組 × 每組 4 個輸出字元 = 84 個字元 剩餘 1 個位元組 → 2 個 Base64 字元 + "==" 填補 = 4 個字元 總計 = 84 + 4 = 88 個填補 Base64 字元
因此，填補式 Base64 下的完整 SHA-512 長度剛好為 88 個字元，當位元組長度為 64 時會以 "==" 結尾。任何其他長度都代表不同的輸入、不同的演算法，或是填補被去掉了。關於逐字元精確比對的完整流程，請參閱 如何計算 SHA-512 雜湊並逐字元進行驗證。
NIST 標準測試向量中，三位元組字串 "abc" 的 Hex 形式為 ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f —— 剛好 128 個字元。該產生器會以 NIST 的來源對此摘要進行斷言，並在驗證過程中以 OpenSSL 獨立重現，使其與 SHA-512 的 NIST 密碼學演算法驗證計畫參考組相符。另有一項獨立的斷言會確認該 "abc" 摘要的填補式 Base64 編碼，因此這兩種表示形式是分別獨立進行檢查的，而不是憑假設通過。
完整 SHA-512 與截斷版本
不同的初始化向量與明確的截斷長度，是每個變體規範的一部分。SHA-512/256 與 SHA-512/224 的輸出與完整 SHA-512 並不共用 —— 兩者的前導位元不同 —— 因此你無法透過從尾端切掉幾個位元組來從其中一個衍生出另一個。
| 演算法 | 輸出位元 | 輸出位元組 | Hex 長度 | 填補式 Base64 長度 | 備註 |
|---|---|---|---|---|---|
| SHA-512 | 512 | 64 | 128 | 88 | 完整的 SHA-2 成員;FIPS 180-4 的預設變體。 |
| SHA-512/256 | 256 | 32 | 64 | 44 | 不同的 IV;輸出截斷為 256 位元;並非完整 SHA-512 的子字串。 |
| SHA-512/224 | 224 | 28 | 56 | 40 | 不同的 IV;輸出截斷為 224 位元。 |
| SHA-384 | 384 | 48 | 96 | 64 | IV 不同，且截斷長度比 SHA-512 短。 |
Sha512 雜湊產生器永遠會輸出完整的 SHA-512。若某個校驗碼清單、套件簽章或 API 合約列出的是 64 字元的 Hex 值、96 字元的 Hex 值，或是任何 40 或 44 字元的 Base64 字串，該請求其實是要使用不同的變體或有金鑰的建構方式，你應該改用其他工具，而不是自行將 128 字元的輸出截斷。
為什麼每個位元組都至關重要:會悄悄改變摘要的輸入
雜湊函式天生就是脆弱的:輸入的任何變動都會在壓縮的每一輪中擴散。Devglan 風格的工具正是圍繞著這個特性所打造，因此它會由始至終保留精確的來源位元組。
- 行尾換行:從終端機貼上 "abc" 時，通常會附加 '\n' (0x0A)，所產生的摘要會與 NIST 對該三位元組字串所定義的向量不同。
- 位元組順序標記:部分編輯器會在開頭加上 UTF-8 BOM 位元組 (EF BB BF);如此產生的文字在雜湊時，會將這些位元組視為訊息的一部分。
- Unicode 正規化:含有變音符號的字元之 NFC 與 NFD 形式，即便呈現出來的文字看起來一模一樣，也可能產生不同的 UTF-8 位元組序列。
- 行尾符號:CRLF (Windows)、LF (Unix) 與 CR (傳統 Mac) 對摘要而言是三種不同的位元組模式。
- 編碼重新解讀:以文字模式開啟二進位檔案，可能會在雜湊之前先進行解碼、取代或刪除位元組 —— 這正是為什麼該工具在檔案模式下堅持使用原始位元組、在文字模式下只使用 UTF-8 的原因。
- 空輸入:空文字也是一則有效的訊息。其完整 SHA-512 摘要的開頭為 cf83e135，任何非空輸入都會立刻從該前綴分歧出去。請明確地產生摘要，不要把空白欄位當成「不需要計算」。
SHA-512 的適用場景——以及不適用的場景
完整的 SHA-512 是一個強大的通用摘要演算法，有幾種工作流程非常適合使用它：
- 高保證度的完整性檢查，且通訊協定已明確指定 SHA-512 ——例如 TLS 加密套件、已簽署的軟體套件清單，或 DNSSEC NSEC3 紀錄。
- 重現以 512 位元 SHA-2 成員為核心所建構之系統所發布的值，例如將下載的檔案與廠商提供的校驗碼檔案進行比對。
- 在已約定以完整 SHA-512 作為標準指紋的系統之間，比對大型識別碼。
然而，它並非通用的安全原語：
- SHA-512 不是加密機制。它沒有解密金鑰，也沒有可反推的密文；摘要本質上就是單向的。
- 較長的摘要並無法驗證檔案的真偽。驗證需要透過可信的外部參考來源、例如 HMAC-SHA-512 之類的帶金鑰建構方式，或是數位簽章。針對共用密鑰的驗證，請使用 HMAC 產生器，而非原始雜湊。
- 原始的 SHA-512 不適合用於密碼儲存。通用雜湊刻意設計得很快，而這樣的速度會助長離線的暴力破解。密碼資料庫需要唯一的鹽值，以及像 Argon2id、scrypt 或 bcrypt 這類記憶體密集型函式，並依硬體調整工作量參數。此瀏覽器工具不附加鹽值、不進行延展計算，也不保留任何帳號相關資訊。
- 較長的雜湊無法修補不可信的參考來源。預期的值仍必須透過經驗證的管道傳送，無論是經簽署的發布頁面、受到 TLS 保護的廠商網站，或是硬體權杖。
若周邊的通訊協定指定的是 SHA-384、SHA-512/256、SHAKE、BLAKE2 或 HMAC-SHA-512，請改用該協定實際要求的建構方式。將完整 SHA-512 視為通用替代方案，將會產生不一致的輸出結果，讓檢查機制在不知情的狀況下失效，無論您多麼仔細地複製和比對那 128 個十六進位字元。
如果您正在權衡各種方案，HMAC 產生器替代方案：無需伺服器、完整 HMAC 標籤對此有詳細說明。