檔案的 SHA-512 是一個 64 位元組的密碼學摘要，具有確定性，且對原始內容的每一個位元組都極為敏感，通常以 128 個小寫十六進位字元表示。該演算法定義於 NIST FIPS 180-4，以 1024 位元區塊處理輸入，使用八個 64 位元工作變數，並產生確定性的輸出，其中任何單一位元組的變更都會在整個 512 位元結果中級聯擴散。當你取得檔案的 SHA-512 雜湊值時，你是在產生一個指紋，可以與可信賴的已發布值逐字元比對，以確認檔案在傳輸或儲存過程中沒有遭到修改。對於遵循該標準的每個平台，相同的輸入都會產生相同的輸出，因此同一份 ISO 下載兩次，只要兩份副本在位元組層級完全相同，就會顯示相同的摘要。
大多數下載頁面都會發布檢查碼，讓你能確認工件未損毀或遭到替換。SHA-512 是與 MD5、SHA-1 和 SHA-256 並列的常見格式之一，512 位元摘要在軟體發布、套件管理員、已簽署的容器清單，以及高保證度的備份驗證中仍被廣泛使用。兩個實際原因使 SHA-512 對檔案具有吸引力:在目前的運算資源下，結果實際上具有零碰撞風險，且較長的摘要為整合者提供了餘裕，適用於碰撞抗性比吞吐量更重要的密碼學承諾場合。此格式也足夠精簡，可以直接貼到論壇文章中，或在發布公告中引用，無需特別處理。
512 位元檔案摘要的結構
SHA-512 摘要是 FIPS 180-4 中所指定的 SHA-2 系列成員的輸出。該演算法接受任何實際長度的訊息，使用長度欄位將其填充為 1024 位元的倍數，將每個區塊展開為 80 字的排程，並在八個 64 位元工作變數上套用 80 輪壓縮。最後的狀態串接成 64 位元組，這就是每個消費者所稱的「雜湊值」。128 個字元的十六進位字串正好是每個位元組對應兩個十六進位數字，因此完整的 512 位元輸出永遠只會產生 128 個字元，不會多也不會少。
Sha512 雜湊產生器 會以兩種編碼方式回傳完整的 512 位元摘要:128 個小寫十六進位字元，以及標準的填充 Base64。兩者編碼的是相同的 64 位元組，因此底層的摘要是相同的數字——只是表示方式不同。十六進位是 Linux sha512sum、Windows Get-FileHash 以及大多數已發布檢查碼所使用的慣例。Base64 在儲存空間或協定負載有限時更為精簡，包括 JSON 清單和類似 JWT 的封套。
| 編碼方式 | 長度 | 字元集 | 典型使用者 |
|---|---|---|---|
| 小寫十六進位 | 128 個字元 | 0–9, a–f | sha512sum、Get-FileHash、已發布的檢查碼 |
| 填充 Base64 | 88 個字元 | A–Z, a–z, 0–9, +, /, = | API、清單負載、已簽署的權杖 |
空輸入也有其定義好的 SHA-512 摘要，其開頭為 cf83e135。將空欄位視為「不進行計算」會完全不產生輸出，這並非相同的值，因此刻意對空檔案進行雜湊仍會回傳標準的空訊息摘要。如果你的工具對空輸入什麼都沒印出，代表計算被略過而非執行。在不小心上傳了佔位檔案的情況下，這個差異值得留意——沒有出現錯誤並不代表摘要已被產生。
如何取得檔案的 SHA-512 雜湊值
以瀏覽器為基礎的工作流程會將檔案保留在你的電腦上，並在本機產生摘要，因此適合用於內部文件、客戶檔案，以及不適合或不允許上傳至遠端服務的已下載工件。
- 在瀏器中開啟 Sha512 雜湊產生器，並將輸入模式切換為檔案位元組而非文字。
- 從磁碟中選擇檔案。該頁面會透過瀏覽器檔案 API 讀取位元組;此步驟中不會將任何資料傳送至伺服器。
- 等待摘要產生。結果面板會顯示 128 個字元的十六進位摘要、Base64 摘要，以及實際進行雜湊之檔案的位元組數。
- 複製你的消費者所需的表示方式。若要比對 sha512sum 的輸出，請複製十六進位;若是給 API 或已簽署的負載使用，請複製 Base64。
- 逐字元與你的參考值比對。即使底層檔案完全相同，任何單一的錯字、大小寫變更或空白中斷都會導致比對失敗。
- 將摘要記錄在檔案路徑旁，以便在重新傳輸、複製或重新封裝後，能再次執行相同的比對。
同一個工具在文字模式下也可用於輸入上限以下的訊息，但檔案路徑才是真正回答「如何取得檔案的 SHA-512 雜湊值而不需手動進行位元組轉換」的途徑。文字模式會先將輸入的字串轉換為 UTF-8，然後回報產生的位元組數;而檔案模式則直接對原始位元組進行雜，不會將檔名、MIME 類型或任何文字解碼步驟視為訊息的一部分。這種區隔可避免將二進位檔案當作文字解碼，然後對修改後的表示進行雜湊而非原始工件的常見錯誤。
導致檔案雜湊不符的常見陷阱
SHA-512 具有確定性且極為敏感。「正確」的檔案產生「錯誤」摘要的最常見原因，是雜湊執行前發生了某些看不見的變更。已發布的檢查碼與新產生的摘要幾乎總是不一致，原因通常出在來源位元組與雜湊函數之間的某個步，而非演算法本身有問題。
| 陷阱 | 改變了什麼 | 該檢查什麼 |
|---|---|---|
| 先將二進位檔案當作文字解碼 | 行尾符號、BOM 位元組、無效 UTF-8 的修復 | 使用檔案模式，而不是貼上解碼後的輸出 |
| 重新命名或重新儲存檔案 | 容器內的位元組、ZIP 重新壓縮、中繼資料重新編碼 | 與原本下載的工件進行驗證 |
| 下載被截斷 | 缺少尾端的位元組 | 確認回報的位元組數與已發布的檔案大小一致 |
| 從錯誤的偏移位置讀取 | 雜湊的首位元組位於串流中間 | 確認位元組數等於磁碟上的檔案大小 |
| 與 SHA-512/256 或 SHA-384 進行比對 | 即使輸入相同，演算法也不同 | 確認已發布的摘要明確指定完整的 SHA-512 |
檔名與 MIME 類型並非雜湊的一部分，而這正是我們想要的特性:重新命名後摘要依然有效。檔案內部的位元組就是完整的訊息，演算法不會解讀這些位元組以外的任何內容。在雜湊之前將影像、封存檔或編後的二進位檔當作文字解碼，會產生一個全新的訊息，任何已發布的檢查碼都無法與之相符，即使可見的檔案路徑完全相同。
將摘要與可信賴的檢查碼進行驗證
較長的雜湊本身並無法驗證檔案。如果檢查碼與工件一起發布在同一個被入侵的頁面上，攻擊者就能同時替換檔案和對應的摘要。參考值必須透過獨立且經過驗證的管道傳遞——例如已簽署的發布公告、PGP 簽署的清單，或與維護者的頻外比對。一旦參考值獲得信任，逐字元比對就是剩下的唯一驗證步驟。
並排開啟參考值與新產生的摘要。在確認工具輸出的是小寫之後，從左到右逐一檢視全部 128 個十六進位字元，此時可忽略換行與大小寫差異。有些消費者會發布大寫的十六進位;若是如此，請以不區分大小寫的方式進行比對，或在比對前重新編碼為小寫。僅在開頭或結尾視覺上相符並不能作為證明——中間部分也要比對，因為 SHA-512 會將每個輸入位元組傳播到全部 512 個輸出位元。
如果數值不同，請勿向下調整為 SHA-256，也不要拿前 64 個十六進位字元與 SHA-512/256 的參考值進行比對。SHA-512/256 使用不同的初始值，且僅輸出 256 位元;手動將 SHA-512 截斷為 64 個十六進位字元並不等於 SHA-512/256。若協定指定的是截斷變體或 HMAC 構造，請執行該確切的構造，而不是手動截斷此輸出。
檔案大小限制與格式選擇
以瀏覽器為基礎的工具將輸入上限設為 100 MB，以保持分頁的回應速度，因為平台摘要操作會接收一整個完整的緩衝區。SHA-512 本身在理論上支援遠大於此的訊息;此限制來自介面而非演算法。對於數 GB 的 ISO、磁碟映像或備份封存檔，請改用串流式的命令列實作，例如 OpenSSL 的 sha512 指令，在操作完成後驗證位元組數，然後再將摘要與參考值進行比對。輸出格式與演算法仍須與已發布的檢查碼相符——切換工具只會改變效能，不會改變語意。如需可在數 GB 工件上處理串流摘要的終端機工作流程，請參閱 如何在 Linux 系統上計算 SHA-512 雜湊值。
空檔案與小型已知輸入是實用的健全性檢查。空檔案的 SHA-512 與空字串的 SHA-512 相同，開頭為 cf83e135，因此若新建的工具對空輸入印出任何其他結果，就存在值得在實際工件上使用前抓出的錯誤。一個隨附自身檢查碼的小型已知檔案——例如發布時附帶的 README 或廠商發布的測試向量——可讓你在信任該管線用於 4 GB 映像之前，先確認編碼、位元組數與比對程序是否正確串接。
最後，請將可信賴的參考值與受檢查的工件分開儲存。將兩者儲存於同一個網路共用、同一支 USB 隨身碟，或同一封電子郵件討論串中，將使完整性驗證失去意義。雜湊是用來防範靜默損毀的一道防線;儲存紀律則是用來防範參考值本身遭到靜默竄改的一道防線。請將摘要與檔案視為兩項獨立證據，僅在透過獨立路徑會合時才會互相交叉驗證。
若想深入瞭解，請參 如何計算 SHA-512 雜湊值並逐字元驗證。