HMAC-SHA-512 雜湊產生器將 SHA-512 壓縮函式與 1024 位元 HMAC 架構結合，而原始 SHA-512 雜湊產生器則評估同一個 SHA-2 成員，不使用任何密鑰，並產生一個確定性的 128 字元十六進位摘要。兩者都會回傳一個 512 位元(64 位元組)的值，因此兩者無法互相替代:HMAC-SHA-512 使用特定的填補規則(ipad 為 0x36 位元組，opad 為 0x5c 位元組)將共享密鑰兩次混入輸入，並同時驗證訊息與密鑰;而原始 SHA-512 只對訊息進行指紋運算。若您的通訊協定指定 HMAC-SHA-512，則必須使用 HMAC-SHA-512。若僅指定 SHA-512，則需要一個無密鑰的產生器，保留全部 64 位元組，並將其輸出為剛好 128 個小寫十六進位字元，或為標準填補 Base64。Sha512 雜湊產生器是一個原始的、無密鑰的產生器。它接受 UTF-8 文字或本地檔案位元組，絕不上傳，並提供完整的 512 位元摘要，絕不會為了模仿 SHA-512/256、SHA-512/224 或 SHA-384 而切除任何位元。理解有密鑰 HMAC 與無密鑰 SHA-2 之間的界線是第一步，而選擇正確的工具則是第二步。
HMAC-SHA-512 vs 原始 SHA-512:加入密鑰會改變什麼
相同的壓縮函式，不同的架構。兩條路線都落在 FIPS 180-4 所定義的同一個 SHA-2 家族成員中，也都可以使用相同的 64 位元組內部狀態來實作，但 HMAC 使用有密鑰的填補方案將該壓縮函式包裹兩次(ipad 為 0x36 重複至區塊大小，opad 為 0x5c 以同樣方式重複)，而區塊大小變為 1024 位元。原始 SHA-512 只是以 1024 位元區塊壓縮您的訊息位元組，並將八個 64 位元工作變數串接成單一 512 位元的輸出。
這種結構上的差異會讓相同輸入產生不同的輸出。若兩個參與方共享一個 32 位元組的密鑰，並將相同的 "hello" 字串分別餵入原始 SHA-512 產生器與 HMAC-SHA-512 產生器，他們將會看到兩個完全無關的摘要。前者僅辨識訊息;後者辨識訊息並證明傳送方持有該密鑰。在二進位檔旁邊公布「校驗碼」的軟體更新通道並未使用 HMAC;而 JSON Web Token、AWS 請求簽章流程，以及 TOTP 式的身分驗證器則都穩穩地站在 HMAC 這一側。
當使用情境真正需要有密鑰的架構時，請將您的瀏覽器指向一個接受密鑰並切換架構的工具。Sha512 雜湊產生器刻意省略密鑰路徑，因為它的任務是完整、無密鑰的 512 位元 SHA-2。僅僅因為摘要「較長」就選擇 HMAC-SHA-512，是兩個系統聲稱相符卻不相符的最常見原因。
Sha512 雜湊產生器在本地端運算的內容
Sha512 雜湊產生器接受 UTF-8 文字或選定本地檔案的原始位元組，對其執行完整的 FIPS 180-4 SHA-512 壓縮，並將產生的 64 位元組回傳給您。摘要以兩種編碼方式呈現:剛好 128 個小寫十六進位字元，以及標準填補 Base64。這兩種表示法都帶有完整的 512 位元輸出，沒有一種是截斷版。八個涵蓋空序列、"abc"、FIPS 多區塊訊息、標點符號變化、UTF-8 字串、任意二進位位元組與常見文字的黃金案例，已根據 NIST 與 RFC 來源進行驗證，並透過 OpenSSL 獨立重現。另一個獨立的斷言則確認標準 "abc" 摘要的確切 Base64 編碼，包含其結尾填補。
提供兩種操作模式。文字模式將輸入字串轉換為 UTF-8，並回報產生的位元組數，讓您能對腔符處理、多位元組序列，以及位元組順序標記問題進行合理性檢查，然後對那些確切的位元組進行雜湊。檔案模式則完全跳過任何字元集假設，直接對檔案所包含的位元組進行雜湊，忽略檔名、字元集標籤與 MIME 類型。這種區隔避免了將二進位資料塊「當作文字」解碼後再進行雜湊的常見錯誤，因為解碼器會為無效序列替換位元組，從而悄悄改變該值。
所有運算皆在瀏覽器本地端完成。選定的訊息或檔案絕不會被上傳至應用程式伺服器;摘要運作以最多 100 MB 上限的單一記憶體緩衝區執行;複製控制項只會將摘要表示法(而非檔案)移至剪貼簿。非同步檔案讀取與摘要呼叫使用單調遞增的工作識別碼，因此即使在中途切換輸入模式，較舊的執行中作業也無法覆寫較新作業的狀態。
逐步產生 SHA-512 雜湊
請依照下列三個步驟產生完整的 512 位元摘要，並與已發布的參考值進行比對。這些步驟對應於 Sha512 雜湊產生器經過稽核的操作步驟，並可在 NIST CAVP 測試向量與 OpenSSL 輸出下重現。
- 選擇來源模式。若您雜湊的是自行輸入或貼上的字串(包括刻意保留的空白字元與任何結尾換行)，請選擇 UTF-8 文字;系統會回報位元組數，讓您確認編碼。若您要雜湊的是已下載且必須對照已公布校驗碼的工件，請選擇檔案位元組;檔案會在本機開啟，絕不會被上傳。
- 產生完整的 SHA-512 值。該工具以 1024 位元區塊壓縮訊息，將每個區塊展開為 80 字排程，並更新八個 64 位元工作變數;這八個最終值串接起來即構成 512 位元摘要。若要便於人眼比對，請複製 128 字元的小寫十六進位輸出;若消費者明確要求 Base64，或這兩種表示法必須透過 JSON 來回往返，則複製標準填補 Base64 輸出。
- 逐字元與可信賴的 SHA-512 參考值進行比對。透過獨立管道開啟發布者已公布的摘要，並逐字元重新讀取兩段字串;只要有一個字元互換，該工件就不相符。請在同一個步驟中確認消費者需要的是完整 SHA-512，而非 SHA-512/256、SHA-512/224、SHA-384 或 HMAC-SHA-512;因為即使可見輸入完全相同，此產生器的輸出也無法與上述任一種截斷版或有密鑰的變體對應。
SHA-512 輸出格式與演算法變體比較
| 表示法 | 可見長度 | 輸出 | 最佳用途 |
|---|---|---|---|
| 十六進位(小寫) | 128 個字元 | 64 位元組以每個位元組兩個十六進位字元編碼 | 人工可讀比對與複製到終端機 |
| Base64(已填補) | 88 個字元並含 = 填補 | 64 位元組以 RFC 4648 字母表編碼 | 透過 JSON、shell 管線或 HTTP 標頭進行精簡傳輸 |
| 原始二進位 | 64 位元組 | 直接的 512 位元摘要 | 原生處理位元組的程式化消費者 |
三列描述的是同一個摘要;僅是拼寫方式不同。選擇錯誤的表示法並不會產生不同的雜湊，而是會產生同一個雜湊的不同表示法。Sha512 雜湊產生器僅輸出前兩者;只有在下游程式碼在雜湊呼叫之後以位元組形式讀取摘要時，才選擇第三種。
更重要的是在官方定義的 SHA-2 變體之間進行比較。下表各欄來自 FIPS 180-4 規格;列出的長度與初始化設定無法就地重新命名。
| 變體 | 輸出長度 | 初始化設定 | 使用情境 |
|---|---|---|---|
| SHA-512 | 512 位元(128 個十六進位字元) | FIPS 180-4 標準初始向量 | 通用的 512 位元完整性與指紋運算 |
| SHA-512/256 | 256 位元(64 個十六進位字元) | 不同的初始向量，然後截斷 | 為圍繞 256 位元摘要設計的系統提供固定長度輸出 |
| SHA-512/224 | 224 位元(56 個十六進位字元) | 不同的初始向量，然後截斷 | 為圍繞 224 位元摘要設計的系統提供固定長度輸出 |
| SHA-384 | 384 位元(96 個十六進位字元) | 不同的初始向量與回合數 | 明確指定 SHA-384 的通訊協定 |
| HMAC-SHA-512 | 512 位元(有密鑰) | HMAC 架構處理密鑰與訊息 | 身分驗證、請求簽章、訊息驗證碼 |
SHA-512 產生器的輸出無法被重新命名、切片或以數學方式轉換，以符合任何較短的變體。若系統需要 SHA-512/256，您必須執行 SHA-512/256 演算法;SHA-384 與 HMAC-SHA-512 亦同。
逐字元比對可信賴的參考值
正確的 SHA-512 雜湊，其可信度僅與其比對的參考值相同。請以三幕流程重現此測試。
首先，透過已驗證的管道取得已公布的摘要。將校驗碼張貼在與檔案同一個頁面上雖然方便，但若該頁面本身已遭到入侵，則無法證明任何事情;當替換的後果重大時，該值應透過另一條已簽署的管道回傳。SHA-512 演算法本身定義於 NIST FIPS 180-4;而能讓您確認實作是否正確(包含可透過 OpenSSL 重現)的驗證計畫，是 NIST CAVP Secure Hashing 專案。
其次，逐字元比對兩段字串。SHA-512 對輸入的每個位元組都很敏感，因此預期值中只要有一個數字互換、產生的輸出中夾帶一個多餘的空白字元，或上游的編碼發生改變，就會產生純機械性的不相符，並非惡意行為。大多數 diff 工具都能進行逐字串比對。使用非 ASCII 空白字元、省略結尾換行，或在開頭加入位元組順序標記，都會產生同樣機械性、肉眼無法察覺的不相符。
第三，確認變體。若發布者將其校驗碼標示為 "SHA-512"，卻暗中公布 SHA-512/256 的值，則該值將無法與完整的 512 位元摘要相符。產生器的輸出始終為完整的 512 位元 SHA-512，因此不相符的問題必須在參考值端解決，而非透過重新執行本工具來解決。若預期值確實來自 SHA-512/256，請改用 SHA-512/256 實作重新產生，而不要手動截斷本產生器的輸出。
When SHA-512 Stops Being the Right Tool
Three situations call for a different mechanism rather than a longer raw SHA-512 digest.
Authentication of origin. If you need to prove who sent a message, raw SHA-512 cannot do that. An attacker can forge a message and its digest because the algorithm uses no secret. Move to the HMAC Generator when two parties share a secret, or to a public-key signature (RSA-PSS, Ed25519, ECDSA) when they do not. The keyed construction is what makes the difference between "this message has not changed" and "this message is from a holder of the key".
Password storage. Raw SHA-512 salts nothing and stretches nothing. A modern GPU evaluates billions of SHA-512 hashes per second against a leaked database, which makes raw SHA-512 an unworkable password hash even with a long passphrase. Reach for Argon2id, scrypt, or bcrypt with a unique per-account salt and parameterized work factors. The Sha512 Hash Generator exposes neither salts, peppers, nor tuning knobs because it is not a password hash function.
False confidence from length. A longer digest is not automatically more trustworthy. If the reference value is untrusted, the protocol is wrong, the salt is missing, or the keyed construction is required, doubling the digest length does not repair the underlying problem. Choose the construction the protocol specifies rather than treating raw SHA-512 as a universal security mechanism. For deterministic file integrity against a publisher's published value it remains excellent; for authentication it is the wrong tool.