SHA-512 是一種加密雜湊函式，而非加密演算法，因此它所產生的 512 位元摘要無法以任何有意義的方式「解密」。它沒有祕密金鑰、沒有反轉換，也沒有任何捷徑可以把 128 字元的十六進位輸出還原成原始訊息或檔案。所謂的 SHA-512 字串，是 NIST FIPS 180-4 中所定義的 SHA-2 家族成員的產出：一種將任意輸入對應到恰好 64 位元組（512 位元）輸出的決定式映射。相同的輸入永遠會產生相同的摘要，但只要改變一個位元組——一個不同的字母、多一個空格、不同的換行符號，或一個非預期的 Unicode 正規化步驟——就會產生完全不同的 128 字元字串。這種不可逆性正是讓 SHA-512 適用於完整性驗證的性質。若目標是確認一份文件、密碼或二進位資料區塊是否符合某個已知值，其流程並非解密，而是重新運算。將精確的來源位元組送入 SHA-512 實作，擷取完整的摘要，並逐字元與可信的參考值比對。Sha512 雜湊產生器 正是在瀏覽器中執行此計算，會回傳完整的小寫十六進位結果以及填補過的 Base64，且不會上傳所選的訊息或檔案。

人們帶著截然不同的問題來到這個頁面，其中只有部分能透過工具輔助解決。第一種情境是夢想反轉雜湊以還原忘記的密碼——SHA-512 的設計刻意使搜尋在運算上不可行，這也是為什麼密碼資料庫不儲存裸摘要的原因。第二種情境是透過應能識別資料的摘要（例如發布在可下載檔案旁的 SHA-512 校驗碼）來辨識一筆資料。第三種情境是根據規格、稽核日誌或加密測試向量重現某個值，以驗證某個實作是否正確串接。這三種已解決的形式都是重新運算的工作：將精確的來源送入 SHA-512 實作並比對結果。它們都不依賴持有金鑰。

how to decrypt sha512 hash
how to decrypt sha512 hash

SHA-512 沒有解密金鑰——這是刻意設計的

SHA-512 摘要是 NIST FIPS 180-4 中所規範的、八個 64 位元狀態值逐塊更新輸入後，最終串接的結果。該演算法將訊息切分為 1024 位元的區塊，進行填補使最後一個區塊符合限制，將每個區塊展開成 80 個 64 位元字的排程，再將排程摺疊進執行中的狀態。最後留下的八個狀態字會被串接起來，形成 512 位元的輸出。輸入中的每個位元組都會在壓縮函式中流經數百次，而雪崩效應確保翻轉任何單一輸入位元大約會改變一半的輸出位元。原像抗性（Pre-image resistance）是此性質的正式名稱：僅給定一個摘要，要找出任何能雜湊到該摘要的輸入，必須對可能的訊息進行暴力搜尋——而在 512 位元下，這種搜尋遠超當前或近期的運算能力。可逆的運作存在於其他地方：AES、ChaCha20 以及公開金鑰密碼系統都依賴一個可套用且稍後可反轉的金鑰。SHA-512 沒有這樣的金鑰，任何聲稱能付費解密 SHA-512 字串的服務，只是在對短小的候選輸入進行字典查詢，而非真正的演算法反轉。

當你搜尋這個主題時，你實際需要的是什麼

來到這個頁面最常見的原因，是檢查下載的檔案是否符合廠商網站上公布的 SHA-512 校驗碼。該流程只需要三項要素：原始檔案、已公布的十六進位字串，以及能從相同位元組產生相同 128 字元摘要的工具。第二個原因是手上有一個 128 字元的十六進位字串，需要確認它代表某個特定的設定或建置產物——同樣地，重新運算是唯一誠實的方法，因為不存在從輸出推導輸入的捷徑。第三個原因是為了離線稽核而需要一個摘要，並希望確保實作回傳的是正規值。可重現的測試向量（例如著名的以 cf83e135 開頭的空輸入摘要）可作為此情境的健全性檢查。在上述每一種情況中，原始來源位元組都必須可用；若沒有，摘要是無法驗證的資訊。

使用 Sha512 雜湊產生器來產生並比對

這個在瀏覽器中執行的 Sha512 雜湊產生器會對精確的 UTF-8 文字或最大 100 MB 的原始檔案位元組執行完整的 FIPS 180-4 運算，回傳整個 64 位元組摘要，並以 128 個小寫十六進位字元以及標準填補過的 Base64 表示。由於計算在本機進行，所選的訊息或檔案永遠不會被上傳到應用程式伺服器。要將該輸出轉為驗證步驟，請依照以下步驟操作。

  1. 選擇與來源對應的輸入模式——輸入字串使用 UTF-8 文字，下載檔案或二進位檔則使用檔案模式——並提供精確的位元組，包括任何刻意保留的空白或結尾換行。
  2. 讀取或貼上完整的結果摘要。十六進位窗格永遠會顯示恰好 128 個小寫字元，因為 64 個摘要位元組 × 每位元組 2 個十六進位字元 = 128 個十六進位字元；Base64 窗格則顯示相同 64 位元組的標準填補編碼。
  3. 開啟可信的參考摘要。若該值是由專案或廠商公布，請將其視為唯一可信來源，而非反過來。
  4. 依序比對 128 個十六進位字元。即使只有一個不同的字母、一個交換過的位元組，或多一個前置零，都代表輸入與參考所預期的內容不符。
  5. 確認使用者端需要的是完整 SHA-512，而非截斷變體——SHA-512/256、SHA-512/224、SHA-384 或 HMAC-SHA-512 即使在來源位元組完全相同的情況下，也無法與此輸出對齊。

64 位元組與 128 個十六進位字元的對應關係值得記住：64 位元組正好是 512 位元，每個位元組會呈現為兩個十六進位字元，而 Base64 窗格則以更精簡的方式編碼相同的 64 位元組。因此，來自產生器的 128 字元十六進位結果是預期的，而非偶然的重複。當可信的參考值與重新產生的摘要從頭到尾相符時，來源位元組即被確認相同；若兩者不同，請先在來源中找出差異所在——常常是一個多餘的 CR、一個前置的 BOM，或一個不同的 Unicode 正規化步驟——再去懷疑演算法本身。

區分 SHA-512 與 SHA-512/256 以及 SHA-512/224

SHA-512 屬於一整族相關的 SHA-2 成員，混淆它們是「正確」的摘要卻在紙面上看起來錯誤的最常見原因之一。SHA-512/256 和 SHA-512/224 並不是替換標籤的完整演算法：它們從不同的初始化值出發，執行相同的壓縮結構，然後將結果截斷為較短的長度。這代表 SHA-512/256 無法透過擷取完整 SHA-512 摘要的前 64 個十六進位字元來重現；而預期接收 SHA-512/256 的系統，即使輸入確實是預期的來源，也會拒絕完整的 SHA-512 輸出。下表簡要彙整了三者之間的差異。

屬性SHA-512SHA-512/256SHA-512/224
輸出涵蓋完整的壓縮結果是否——已截斷否——已截斷
初始化值與標準 SHA-512 相同是否否
十六進位表示長度128 字元較短較短
可透過手動縮短 SHA-512 重現—否否

若某個協定或工具預期較短的十六進位值，它要求的會是 SHA-512/256、SHA-512/224、SHA-384 或 SHA-256，而不是 SHA-512 的前段。請直接使用該確切變體，而非截斷本產生器的輸出，因為其內部初始化並不相同，任何表面的長度重疊只是巧合，而非結構上的等價。這些變體的存在，是為了讓應用程式在不離開 SHA-2 家族的前提下選擇所需的摘要寬度；請將它們視為共用同一壓縮核心的不同演算法。

SHA-512 本身無法為你做到的事

單純的 SHA-512 也是人們有時試圖將三種用途合而為一時的糟糕替代方案。儲存使用者密碼：這個演算法刻意設計得很快，而這樣的速度會助長對外洩資料庫的離線猜測。生產環境的密碼儲存需要唯一 salt，以及具備合適工作參數的專用函式，例如 Argon2id、scrypt 或 bcrypt——這些都是本產生器不提供的。驗證訊息發送者：單獨的雜湊只能確認訊息在傳輸過程中未被竄改，但無法證明是誰產生的。HMAC-SHA-512 加入共享密鑰以進行認證，而公開金鑰簽章則採不同的來源驗證模型。加密訊息：SHA-512 沒有金鑰，因此無法加密；可逆的隱私來自 AES-256-GCM 或 RSA-OAEP 等演算法，這些演算法使用可套用且稍後可反轉的金鑰。下表將每個情境對應到正確的機制。

使用情境單獨使用原始 SHA-512 可行嗎？正確做法
以廠商公布的摘要驗證下載檔案可以，但須有可信的參考值使用 Sha512 雜湊產生器重新產生完整的 128 字元十六進位，並逐字元比對
儲存使用者密碼否搭配每位使用者 salt 的 Argon2id、scrypt 或 bcrypt
驗證訊息發送者身分否搭配共享密鑰的 HMAC-SHA-512，或使用公開金鑰簽章
重現標準測試向量（例如以 cf83e135 開頭的空輸入摘要）可以對精確的 UTF-8 位元組或原始檔案內容進行雜湊
符合另一個系統所預期的 64 或 56 字元十六進位值可能不行確認使用者端需要的是 SHA-512/256、SHA-512/224 或 SHA-256，並直接切換到該變體

較長的摘要並無法修補不可信的參考來源。預期值仍須透過經認證的路徑取得，且演算法的選擇必須符合消費者端的設計。請將 SHA-512 保留給其設計目的——完整性與摘要比對工作；當任務需要機密性、來源認證或較慢的密碼儲存時，請選擇其他機制。Sha512 雜湊產生器謹守本分：它會對所提供的精確位元組計算完整的 512 位元摘要，同時回傳十六進位與 Base64 兩種表示法，讓你能與早已受信任的參考值進行比對。

若你正在權衡選項，使用已知金鑰加密與解密 Vigenere 密碼 對此有詳細說明。

若你正在權衡選項，計算檔案的 SHA-1 雜湊並比對校驗碼 對此有詳細說明。