SHA-512 是一種定義於 NIST FIPS 180-4 的加密雜湊函式，能將任意輸入壓縮成固定長度的 512 位元摘要，完整結果永遠是 64 位元組 —— 以剛好 128 個小寫十六進位字元顯示，或以標準填補的 Base64 表示。當你開始建立 SHA-512 雜湊時，演算法會透過 64 位元字處理訊息、將輸入填補為 1024 位元區塊、把每個區塊展開為 80 字排程，並更新八個 64 位元狀態值，再串接成最終輸出。該輸出的每一個位元都有意義；改變輸入中的一個位元組就會產生截然不同的摘要，而相同輸入永遠會產生相同的摘要。這種確定性正是讓已發佈的參考雜湊能作為檔案或訊息指紋的關鍵，但也代表你必須對原本被雜湊的內容進行精確的、逐位元組的複製。本文接下來將說明完整的 SHA-512 輸出長相、它與截斷版本的差異，以及如何使用 Sha512 雜湊產生器來產生並驗證它。
完整 SHA-512 輸出的長相
SHA-512 摘要的長度固定，與輸入大小無關。單一位元組輸入和多 GB 的檔案都會產生相同的 64 位元組、512 位元輸出。Sha512 雜湊產生器以兩種表示法呈現該輸出，兩者編碼的是同一段位元組序列：
- 小寫十六進位：128 個字元，每個位元組對應兩個字元，a–f 為小寫。這是校驗碼清單、套件管理員清單和簽署文件最常見的格式。
- 填補 Base64：64 位元組的輸入會產生 88 個字元，使用標準的 RFC 4648 字元集，並以兩個「=」填補字元結尾。這會將摘要壓縮為十六進位格式大約 69% 的大小。
若你對空字串產生雜湊，標準的完整 SHA-512 值會以 cf83e135 開頭。該常數是一個有用的健全性檢查：宣稱能計算完整 SHA-512 的工具在輸入為空時應產生此前綴，任何其他值都代表演算法或編碼有誤。因此，128 字元的十六進位結果是完整 SHA-512 輸出應有的形狀，而非意外的複製或格式異常。
完整 SHA-512 與截斷版 SHA-2 變體的比較
SHA-512 是 SHA-2 家族的成員，定義於 NIST FIPS 180-4，並在 RFC 6234 中針對網際網路協定進一步描述，但有數個相關演算法會重複使用同一壓縮函式的部分，且與完整的 512 位元輸出無法互換。若你餵入的系統只接受 SHA-512/256，無論如何截斷或重新標記完整的 SHA-512 十六進位字串都無法滿足它 —— 因為初始值和最終截斷點不同。
| 演算法 | 輸出位元 | 輸出位元組 | 十六進位長度 | Base64 長度 |
|---|---|---|---|---|
| SHA-384 | 384 | 48 | 96 | 64 |
| SHA-512（完整） | 512 | 64 | 128 | 88 |
| SHA-512/256 | 256 | 32 | 64 | 44 |
| SHA-512/224 | 224 | 28 | 56 | 40 |
兩支腳本若使用這些演算法對相同輸入雜湊，將會回傳不同長度的摘要，而長度比對錯誤是驗證步驟失敗最常見的原因。當協定指定特定成員時，請產生該精確的演算法，而非手動截斷完整輸出。
如何逐步建立 SHA-512 雜湊
取得經驗證的完整 SHA-512 值最快的方法，是使用能在你打算雜湊的確切位元組上執行完整 FIPS 180-4 操作的工具。Sha512 雜湊產生器在瀏覽器中執行完整的摘要運算，因此原始文字或檔案不會上傳到任何伺服器。
- 開啟 Sha512 雜湊產生器，並選擇 文字或檔案輸入模式。
- 若選擇文字，請以應被雜湊的原始樣貌貼上或輸入訊息。保留開頭與結尾的空白、行尾符號以及任何位元組順序標記。
- 若選擇檔案，請選取本機檔案。工具會讀取原始位元組；檔名、字元集或 MIME 類型都不會被納入摘要。
- 觸發計算。工具會在雜湊前回報輸入位元組數，讓你確認實際餵入的內容。
- 讀取 128 字元的小寫十六進位結果與填補的 Base64 字串。兩者代表相同的 64 個位元組。
- 複製接收系統所預期的表示法，並貼到驗證欄位、清單或參考文件中。
瀏覽器輸入上限為 100 MB，其設計目的是讓平台摘要操作接收一塊完整的緩衝區。超過此大小的輸入應使用支援串流的命令列實作來產生，而非仰賴瀏覽器分頁，並僅在本機運算完成後再進行完整摘要比對。
為你的消費者選擇十六進位或 Base64
這兩種表示法並非互相競爭的格式；它們是同一 64 位元組的可互換編碼。十六進位人類可讀，且能輕鬆逐字元視覺比對，因此成為已發佈校驗碼、簽署發行說明與設定檔的預設格式。Base64 大約縮短三分之一，對於已經傳輸 Base64 權杖、JSON Web Token 或 PEM 編碼二進位資料的系統更為友善。
一個實用的經驗法則：若消費者將摘要儲存或顯示為一行文字，請交付十六進位。若消費者將摘要嵌入 Base64 原生結構（例如簽章標頭或 JWT），請交付 Base64，並驗證填補字元在整個過程中都被保留。在兩個應一致的系統之間混用這兩種編碼，是比對失敗的常見原因，特別是在複製貼上時去除了結尾的「=」填補或重寫了字母大小寫的情況下。
位元組精確的輸入與常見陷阱
SHA-512 是確定性的，對每個位元組都極為敏感。相同的可見文字可能因為輸入邊界的隱藏位元組而產生不同摘要。在你信任結果之前，有幾個陷阱值得檢查：
- 結尾空白與行尾符號。以 CRLF 行尾儲存的檔案，與相同內容以 LF 儲存的雜湊結果不同，而編輯器可能會加上原始檔案沒有的結尾換行。
- 位元組順序標記。UTF-8 BOM（EF BB BF）是三個位元組，部分編輯器會悄悄加上。只有在原始來源包含 BOM 時才應保留。
- Unicode 標準化。預組成的「é」（U+00E9）與分解的「e」加上組合尖音符（U+0065 U+0301）會編碼為不同的 UTF-8 位元組序列，因此雜湊結果不同，即使兩者呈現完全相同。
- 空輸入。在空白欄位上按產生，仍會得到以 cf83e135 開頭的有效摘要；空結果本身是有意義的答案，並非計算缺失。
- 文字模式與檔案模式。文字模式會雜湊該字串的 UTF-8 編碼。檔案模式會雜湊檔案的原始位元組。兩者在相同內容上可能產生不同結果，若文字工具會套用字元集轉換而檔案工具跳過該轉換時尤為如此。
關於驗證工作流程的詳細逐步說明，請參閱如何計算 SHA-512 雜湊並驗證每個字元。
與信任參考來源進行驗證
產生的摘要只有在與透過已驗證管道取得的預期值進行比對時，才具備證明力。更長的雜湊無法修補不可信的參考來源；已發佈的校驗碼本身必須來自簽署過的發行頁面、頻外訊息或其他你能獨立確認的管道。
比對時，請逐字元進行。只要有單一十六進位數字不符或字母大小寫不同，就代表輸入並非逐位元組相同，而最常見的原因就是上述陷阱，而非工具錯誤。若你餵入的消費者預期的是 HMAC-SHA-512 而非純 SHA-512，或是預期使用數位簽章，Sha512 雜湊產生器的輸出將無法匹配，即使可見輸入完全相同 —— 因為這些構造需要共享秘密或私鑰。若想了解為何 SHA-512 無法被反解，以及哪些構造實際能提供認證，請參閱如何「解密」SHA-512 雜湊以及該怎麼做。
無論你何時儲存或分享結果，有兩個事實值得記住。SHA-512 並非加密，也沒有解密金鑰，因此摘要本身無法證明訊息是由誰發送 —— HMAC 或簽章才能做到。而原始的 SHA-512 並不適合作為密碼雜湊：通用雜湊刻意設計得很快，這使得離線猜測的成本很低。密碼資料庫需要獨特的鹽以及像 Argon2id、scrypt 或 bcrypt 這類具備適當工作參數的記憶體硬函式。請將 128 字元的結果視為指紋，而非憑證。