SHA-512 永遠會產生一個 512 位元的摘要，其編碼方式為剛好 128 個小寫十六進位字元，或是 88 個字元的填充 Base64。當你計算 SHA-512 雜湊時，你是在一串精確的輸入位元組上執行完整的 FIPS 180-4 演算法——每個前置或尾隨空白、換行，或是位元組順序標記，都會改變結果，而相同的輸入永遠會產生相同的摘要。輸出是確定性的，但不可逆：無論雜湊看起來多長，都沒有解密金鑰。Sha512 雜湊產生器在瀏覽器內部執行完整計算，因此你提交的文字或檔案絕不會離開你的裝置，結果會以兩種格式呈現，並附上輸入位元組數量，讓你在發布或接受該摘要之前，能與可信賴的參考值進行比對。
輸出內容的樣貌（128 字元與 64 位元組）
SHA-512 屬於 SHA-2 系列，使用 64 位元的字。該演演算法會將輸入填充為 1024 位元的區塊，將每個區塊展開為 80 字的排程，並在每一輪更新八個 64 位元的狀態值。處理完最後一個區塊後，這八個值會串接成 512 位元的輸出——剛好 64 位元組。由於每個位元組需要兩個十六進位字元，因此完整的十六進位表示法永遠是 128 個小寫字元，而標準的填充 Base64 形式則永遠是 88 個字元。如果你看到 56 個、64 個或更短的十六進位字元，那它就不是完整的 SHA-512；而是某個截斷或初始化方式不同的變體。
正是這種長度上的嚴謹，讓逐位元組的比較具有意義。當校驗和檔案、軟體清單或廠商發布的文件中引用 SHA-512 摘要時，它永遠是 128 個十六進位字元，而這個長度本身，在你開始比較個別字元之前，就是一項合理性檢查。
| 輸出 | 長度 | 編碼方式 | 備註 |
|---|---|---|---|
| 完整 SHA-512 十六進位 | 128 字元 | 小寫十六進位 | 編碼自 64 位元組；校驗和檔案的標準格式 |
| 完整 SHA-512 Base64 | 88 字元 | 填充式 RFC 4648 Base64 | 同樣的 64 位元組，更為精簡 |
| SHA-512/256 十六進位 | 64 字元 | 小寫十六進位 | 初始化方式不同；並非截斷版本 |
| SHA-384 十六進位 | 96 字元 | 小寫十六進位 | 演算法不同，輸出經過截斷 |
精確取得輸入位元組（文字 vs 檔案）
產生器的兩種輸入模式對位元組的處理方式不同，而這個差異正是大多數比對不符的根源。文字模式會先將輸入的字串轉換為 UTF-8，再對這些位元組進行雜湊。所回報的位元組數量可讓你確認那些肉眼看不見的字元——例如編輯器多加的尾隨換行字元，或是從其他文件貼上來的位元組順序標記——確實存在於緩衝區中。檔案模式則直接對檔案的原始位元組進行雜湊，不會解讀檔名、字元集或 MIME 類型。這種區隔避免了將二進位檔案當成文字解碼，進而雜湊到經過修改的表示法而非原始檔案內容的常見錯誤。
當你需要比對已發布的校驗和時，請重現當初被雜湊的位元組序列。如果參考值是根據原始下載檔計算的，就對原始檔案進行雜湊。如果參考值是根據包含換行字元在內的清單文字計算的，請貼上完全相同的清單文字，並保留所有換行字元。標準化空白字元、智慧型引號標點，或移除 BOM，都會在無聲無息中產生一個無法比對的不同摘要。
逐步計算 SHA-512 雜湊
- 開啟 Sha512 雜湊產生器並選擇輸入模式——可輸入或貼上的字串選擇文字，下載下來的檔案（最大 100 MB）選擇檔案。
- 提供完全相同的來源。對於文字，貼上字串並確認回報的 UTF-8 位元組數量符合預期，包含刻意保留的空白字元。對於檔案，從你的裝置中選擇，使原始位元組在不解讀的情況下被雜湊。
- 產生摘要。瀏覽器會在本機執行 FIPS 180-4 SHA-512 演算法，產生 64 位元組的輸出，並提供兩種編碼方式。
- 複製你所需格式的表示法。標準校驗和檔案請使用 128 字元的小寫十六進位；當通訊協定或文件指定使用 Base64 時，請使用填充式 Base64。
- 逐一比對每個字元與可信賴的參考值。任一處出現單一字元不符，就代表輸入位元組或使用的演算法不同——並不是「差不多」的問題。
- 確認所儲存的值標示為完整 SHA-512。預期應為 128 字元的十六進位結果，而非重複或格式錯誤；較短的數值代表使用了不同的變體。
一個實用的合理性檢查是空字串。空訊息的標準 SHA-512 開頭為 cf83e135，完整摘要是 NIST 與 RFC 文件中眾所周知的固定值。如果你的產生器在欄位刻意留空時產生該值，就代表演算法正確，且空輸入會被視為有效的零長度訊息，而非未執行的計算。
為什麼雜湊無法比對（變體、編碼、空白字元）
SHA-512 有幾個近親變體，容易因名稱混淆。SHA-512/224 與 SHA-512/256 使用不同的初始化值，分別回傳 224 或 256 位元；它們並非透過標記或隨意截斷完整 SHA-512 而來。SHA-384 是另一種演算法，擁有自身的初始狀態與 384 位元的輸出。如果另一個系統預期使用 SHA-384、SHA-512/256、HMAC-SHA-512 或數位簽章，即使可見的輸入完全相同，其輸出也不會相符。正確的做法是依照通訊協定所要求的精確建構方式，而非手動截斷較長的摘要。
編碼問題是另一大類不符的主因。新增句號、將換行字元從 LF 改為 CRLF、標準化 Unicode（例如組合或分解附加符號），或是加入 BOM，都會產生不同的數值。部分應用程式會先將文字轉為小寫或去除 HTML 標籤再進行雜湊；本產生器預設不會如此處理，因此如果參考值是先經過小寫轉換，你必須同樣先進行小寫轉換。只要情況許可，請根據發布者所描述的精確位元組序列來產生——例如「你所下載的檔案」、「簽署前的訊息本文」，或是「包含尾隨換行的清單」。
| 症狀 | 可能原因 | 解決方式 |
|---|---|---|
| 結果為 56 或 64 個十六進位字元 | 使用了不同的 SHA-2 變體 | 改用完整的 SHA-512 演算法或接收端預期的變體 |
| 輸出長度正確但字元不符 | 輸入位元組遭到修改（空白字元、BOM、換行字元） | 比對產生參考值時所使用的精確來源位元組 |
| 參考值是根據小寫文字計算的 | 原始文字先經過標準化處理 | 在雜湊前套用相同的標準化處理 |
| 預期雜湊用於驗證傳送者身分 | 原始 SHA-512 沒有金鑰 | 改用 HMAC-SHA-512 或公開金鑰簽章 |
與可信賴的參考值進行比對
較長的摘要無法彌補來源不可信的問題。預期的數值仍必須透過已驗證的管道取得——例如已簽署的發布頁面、廠商的 HTTPS 網站、以 PGP 簽署的清單，或是透過你已信任的管道所傳遞的值。一旦取得參考值，請將其與待檢查的檔案分開保存，避免攻擊者同時竄改兩者。逐字元比對（最好由能標示出第一個相異位置的工具執行）才是正確的驗證方式；「看起來差不多」並不算數。
對於特別要求高可靠性的完整性作業流程，建議使用第二套獨立的實作來重新計算摘要——例如 OpenSSL 之類的命令列工具，或是可用於極大型檔案的串流工具——並確認兩者皆與已發布的值相符。本產生器使用了八組黃金測試案例，涵蓋空序列、「abc」、FIPS 多區塊訊息、標點變化、UTF-8、任意二進位位元組，以及常見文字，其預期輸出皆已與 NIST 及 RFC 來源進行核對。
SHA-512 並非加密或密碼雜湊
SHA-512 是單向摘要函式。它沒有解密金鑰，也不會洩漏關於輸入產生者的任何資訊；單憑雜湊無法證明訊息是由誰送出。身分驗證來自將摘要與秘密或金鑰對結合的建構方式。HMAC-SHA-512 加入共用秘密以提供對稱式身分驗證；公開金鑰簽章則提供建立在非對稱密碼學之上的來源驗證機制。請依通訊協定要求選擇正確的建構方式，而非將較長的原始摘要視為萬用的安全機制。
原始的 SHA-512 也不適合用於密碼儲存。通用雜湊刻意追求速度，而這樣的速度正好能對被竊取的資料庫進行離線暴力破解。正確的密碼儲存需要獨特的鹽值，以及專用的函式，例如具有適當運算參數的 Argon2id、scrypt 或 bcrypt。本產生器不會加入任何鹽值、運算拉伸、帳號脈絡或秘密胡椒值，因此適用於檔案完整性驗證與通訊協定指定的摘要，絕非用於雜湊使用者憑證。若你的目標是驗證已發布的校驗和、檢查下載的檔案，或是重現通訊協定指定的摘要，當你真正需要的是身分驗證時，請參考應採取的正確做法，而非嘗試「解密」SHA-512 雜湊。