CRC-32/ISO-HDLC 是 gzip、ZIP、PNG、乙太網路以及許多歸檔格式所使用的特定 32 位元循環冗餘核對，由寬度 32、反射多項式 0xEDB88320、初始暫存器 0xFFFFFFFF、反射位元組處理，以及最終 XOR 0xFFFFFFFF 所定義。本 CRC32 計算機速查表會釐清每個固定參數、位元組處理規則，以及參考核對值，讓您能計算出與任何符合標準的實作相同的 8 位數十六進位結果。ASCII 位元組 123456789 的標準健全性測試為 cbf43926 —— 如果某個工具對該字串產生不同的 8 位數值，您所面對的就是不同的 CRC-32 公式，例如 CRC-32C、MPEG-2、BZIP2 或 JAMCRC。計算過程完全在瀏覽器本機執行，不會上傳任何輸入，而複製按鈕會回傳精確的 32 位元值，格式化為 8 個小寫十六進位數字，並保留前導零。
CRC-32/ISO-HDLC 參數一覽
本計算機鎖定單一變體 —— CRC-32/ISO-HDLC —— 不會根據猜測切換公式。每個實作細節都是固定的，因此 8 位數輸出在瀏覽器、作業系統和程式語言之間都能重現。無論您選擇哪種模式或貼上哪些字元，下方的參數表都是計算機在每次執行時遵守的契約。
| 參數 | 值 |
|---|---|
| 寬度 | 32 位元 |
| 多項式（反射） | 0xEDB88320 |
| 初始暫存器 | 0xFFFFFFFF |
| RefIn（輸入位元組） | true（LSB 優先） |
| RefOut（輸出暫存器） | true |
| XorOut（最終 XOR） | 0xFFFFFFFF |
| ASCII 123456789 的核對值 | 0xCBF43926 |
這些值對應 RFC 1952 gzip 範例方法，以及驅動 ZIP 本地標頭 CRC 與 PNG 區塊 CRC 的相同多項式。由於採用查表驅動的實作，每個位元組皆以最低有效位元優先處理，並在最後對暫存器取補數，因此像 000000d4 這類前導零的結果會完整保留其零，而不會縮短為較短的字串。
三步驟取得您的 CRC32
在您知道目標格式預期哪種變體之後，完整的工作流程包含三個具體動作。開啟 CRC32 計算機 並依照下列步驟操作。
- 確認所需的 CRC 變體以及目標規格涵蓋的確切位元組範圍。本頁面實作 CRC-32/ISO-HDLC，123456789 的核對值為 cbf43926，因此任何引用不同核對值或諸如 Castagnoli、MPEG-2、BZIP2、JAMCRC 等名稱的規格都不會相符。
- 選擇 UTF-8 文字或十六進位位元組，輸入確切的承載資料，然後執行計算。在文字模式下，貼上可見字元，計算機會為您編碼位元組。在十六進位模式下，貼上偶數個十六進位數字，計算機會去除空白並將每一對視為一個位元組。
- 比較全部 8 個數字與預期值，然後複製結果。當涉及惡意竄改時，請使用加密驗證機制；相符的 CRC 僅能證明對意外錯誤的一致性。
若想更深入了解在計算之前如何辨識變體，挑選正確的 CRC32 變體與位元組範圍 的對應指南與本速查表可相互搭配使用。
標準核對值：123456789 對應 cbf43926
任何 CRC-32/ISO-HDLC 工具最實用的單一健全性測試，就是字串 123456789 的 9 個 ASCII 位元組。從 zlib 的 crc32 到 PNG 區塊驗證工具，每個符合標準的實作都會為該輸入產生 0xCBF43926。如果您測試的計算機產生其他結果，該工具使用的就是不同的多項式、不同的初始值，或是以不同的順序處理位元組。
| 參考輸入 | 預期 32 位元 CRC | 備註 |
|---|---|---|
| 空輸入 | 0x00000000 | 程式化預留位置；介面會要求資料，避免意外的空點擊看起來像是有效驗證。 |
| ASCII 123456789 | 0xCBF43926 | 用於區分 ISO-HDLC 與其他 32 位元公式的標準數值測試。 |
| 變體不相符 | 其他任何值 | 不同的 8 位數值表示 CRC-32C、MPEG-2、BZIP2、JAMCRC 或非符合標準的實作。 |
無論何時在工具、語言或硬體區塊之間切換，請將此列放在手邊。以 Python zlib 進行交叉檢核，是確認瀏覽器端結果與經實戰驗證的參考實作一致的最快方式。
文字模式與十六進位模式：位元組處理規則
文字模式與十六進位模式外觀相似，但強制執行不同的位元組契約；混淆兩者正是「正確」結果看起來錯誤的最常見原因。
只有在 UTF-8 明確是目標格式預期的位元組編碼時，文字模式才是正確的選擇。計算機會先將字串編碼為 UTF-8 再進行處理，因此 ASCII 字元佔 1 個位元組，許多帶腔調字母佔 2 個位元組，CJK 字元佔 3 個位元組，表情符號或位於基本多語言平面之外的字元則佔 4 個位元組。若是基於 UTF-16 字碼單元、舊式字元集、正規化文字或不同換行慣例所計算的結果，即使可見字串對一般讀者而言完全相同，結果也會不同。
當通訊協定、檔案格式或線路格式提供精確位元組時，十六進位模式才是正確的選擇。計算機會移除位元組對之間的所有空白，但除此之外要求偶數個十六進位數字、拒絕 0x 之類的前綴、非空白的分隔符號、註解以及奇數個尾端半位元組。每一對成為一個位元組，前導 00 位元組會被保留並影響結果，而 8 位元輸出將該值視為無符號，因此前導零必定會顯示出來。
經驗法則很簡單：當規格提供精確位元組時，請以十六進位貼入，而非重新輸入為可見文字。這兩種模式之間的關係，最適合透過以同一筆承載資料分別在兩種模式下執行，並將 8 位數結果與 Python 的 zlib.crc32 等可信參考實作進行比對來驗證。
破壞相符結果的常見陷阱
即使變體正確且工具符合標準，些微的輸入選擇也可能將輸出偏移至完全不同的 8 位數值。
- 包含或排除標頭、長度欄位、分隔符號或儲存的核對欄位，會改變涵蓋的位元組範圍，進而改變結果。請依據規範格式確認這些位元組是否落在 CRC 的涵蓋範圍之內或之外。
- 將二進位資料重新輸入為可見文字，而非以十六進位貼上位元組，會在來源為逸出序列時，將 0x0A 之類的位元組悄悄替換為字面字元 backslash-n。
- 正規化換行字元、將定位字元轉換為空格，或移除尾端空白，會產生不同的位元組計數，進而產生不同的 CRC。
- 將前導 00 位元組視為可忽略而從計算中扣除；計算機刻意保留它們，使 8 位元輸出能與十六進位傾印逐位元組相符。
- 將 CRC 值讀回為有符號 32 位元整數，會在任何高位元為 1 的結果產生負數，導致無法通過無符號字串比對。請一律以字元方式比對這 8 個十六進位數字。
如果您信任的承載資料在計算機與參考實作之間產生分歧，請先逐步檢視上述陷阱，再懷疑工具或多項式本身。
CRC32 無法做到的事：安全性界線
CRC32 是設計用於偵測資料中常見意外變更的完整性核對碼，而非對抗式控制項。它具有線性特性，容易遭到刻意操控，且在不知道原始承載資料的情況下也能建構出碰撞結果。請將相符的 CRC32 視為傳輸、複製或解壓縮步驟中未隨機翻轉少數位元的證據，而僅此而已。
CRC-32 既不是加密、不是加密雜湊、不是訊息驗證碼、不是數位簽章，也無法證明來源。請勿將其用於驗證不受信任的軟體、授權指令、保護憑證，或證明檔案來自可信的發行者。針對這些用途，請使用像 SHA-256 之類的加密摘要，並搭配經驗證的發佈管道（例如 HTTPS 加上來自發行者的帶外簽章），將 ZIP、PNG 或數位 gzip 框架內的 CRC32 視為次要的健全性檢查，而非安全性控制項。
不同系統會以 CRC32、CRC-32C、Castagnoli、Koopman、MPEG-2、BZIP2、JAMCRC 等名稱表示具有不同多項式或不同初始與最終轉換的公式。由於本計算機僅實作 CRC-32/ISO-HDLC，8 位元輸出僅對採用相同反射多項式 0xEDB88320 以及相同 0xFFFFFFFF 初始與最終 XOR 的規格具有意義。當 123456789 的預期核對值不是 cbf43926 時，幾乎可以確定該系統使用不同的變體或不同的位元組範圍，此時正確的起點是改用其他工具。