CRC-32/ISO-HDLC 會為 123456789 的 ASCII 位元組產生八位數十六進位值 cbf43926，使用反射多項式 0xEDB88320，初始與最終 XOR 值均為 0xFFFFFFFF。若要為一個 hex 檔案計算 CRC，請先確認正確的 CRC 變體以及目標格式預期涵蓋的位元組範圍，從檔案中取出這些位元組，送入使用正確參數的 CRC 引擎，然後將所得的八位數小寫十六進位值與預期的校驗和進行比對。CRC32 計算機精確實作了 CRC-32/ISO-HDLC，接受 either UTF-8 文字或原始十六進位位元組作為輸入，全程在瀏覽器內進行計算而不上傳任何資料，並一律顯示八位十六進位數字，保留前導零。Hex 檔案使用者通常會使用十六進位位元組模式而非文字模式，因為來源檔案已直接列出他們想要涵蓋的位元組。選擇正確的輸入模式並確認涵蓋的位元組序列，是區分有效驗證與無意義相符結果的兩個關鍵步驟。
為何 HEX 檔案需要特定的 CRC 變體
Hex 檔案常見兩種形式：單純列出位元組值的原始 hex 傾印，以及韌體燒錄使用的結構化 Intel HEX 紀錄。兩者皆包含十六進位字元，但內嵌的內容幾乎都要求使用具名的 CRC 變體，而非「任意」校驗和。Gzip、ZIP、PNG 以及許多嵌入式開機載入器皆使用 CRC-32/ISO-HDLC，亦即本頁所實作的變體。即使輸入位元組相同，使用錯誤的變體仍會產生不同的數值，因此只有當變體與規格相符時，與預期值的比對才有意義。
另有數個 32 位元公式共用「CRC32」之名，但使用不同的多項式、初始值或最終轉換。CRC-32C 又稱 Castagnoli，使用不同的反射多項式，常見於 iSCSI 與 BTRFS。Koopman、MPEG-2、BZIP2 與 JAMCRC 則是其他具名變體，針對相同輸入各自有其校驗值。若您的目標規範列出的是其中之一而非 CRC-32/ISO-HDLC，則對相同位元組計算出的數值將無法與預期校驗相符。確認所需變體的可靠方法是查閱規範對 123456789 的 ASCII 位元組所公布的校驗值，並將該字串送入您的工具。CRC-32/ISO-HDLC 必須產生 cbf43926；任何其他八位數結果皆代表啟用了不同的變體。
為 HEX 檔案計算 CRC
- 確認所需的 CRC 變體與位元組範圍。確認主控格式使用的是 CRC-32/ISO-HDLC，並詳閱規範中定義涵蓋範圍內位元組的章節。標頭、長度欄位、分隔符號以及任何儲存的校驗和欄位本身通常都會被排除。
- 取出需涵蓋的精確位元組。若為原始 hex 傾印，僅複製資料區段中的位元組對，並略去任何前導 00 填補或尾端的校驗和。若為 Intel HEX 檔案，有意義的承載為各紀錄資料欄位內的位元組，依紀錄次序串接，並排除冒號、長度、位址、類型以及每筆紀錄的校驗和欄位。
- 開啟 CRC32 計算機並切換至十六進位位元組模式。本頁接受 UTF-8 文字或 hex 位元組，因此對於 hex 檔案而言，hex 模式幾乎總是正確選擇。
- 貼上取出的位元組。Hex 模式會移除位元組對之間的空白，但仍要求偶數個十六進位數字。前綴如 0x、非空白的分隔符號、註解以及奇數個尾端半位元組皆會被拒絕，因此請先去除任何紀錄框架再行貼上。
- 讀取八位數小寫十六進位結果。前導零會保留，數值視為無符號，並一律顯示完整的八位數字。本頁限制輸入為 5,000,000 位元組，以維持查表處理的回應速度。
- 將結果與規範中的預期值進行比對。相符僅能視為檔案與您預期涵蓋之位元組一致的證據，而非真實性的證明。當涉及惡意竫改時，請使用密碼學摘要與經認證的散布管道。
CRC-32/ISO-HDLC 參數與 cbf43926 檢查值
CRC32 計算機遵循 RFC 1952 中所述的實務範例方法，亦即 gzip 校驗和欄位所用的同一參考資料。引擎會依反射多項式建立 256 項查表，並以最低有效位元優先的方式處理每個輸入位元組。當您需要向工具鏈說明兩個校驗和為何不一致時，了解這些參數會很有幫助。
| 參數 | 值 |
|---|---|
| 寬度 | 32 位元 |
| 反射多項式 | 0xEDB88320 |
| 初始暫存器 | 0xFFFFFFFF |
| 反射輸入位元組 | 是（最低有效位元優先） |
| 反射輸出 | 是 |
| 最終 XOR | 0xFFFFFFFF |
| ASCII "123456789" 的校驗值 | cbf43926 |
| 輸出格式 | 8 位小寫十六進位，保留前導零 |
請將 ASCII 字串 123456789 送入本頁，確認結果符合 cbf43926，再將其用於實際資料。此標準檢查向量正是 CRC-32/ISO-HDLC 與其他 32 位元公式的區別，因此若比對不符即代表啟用了錯誤的變體。本頁亦提供一小組外部檢查字串，涵蓋空輸入、短訊息、常見訊息摘要與字串集、標準數值檢查以及 quick-brown-fox 句子，並對多位元組 UTF-8 邊界使用 Python zlib 交叉檢查。這些數值能證明所宣告的變體與位元組處理方式，而不僅僅是顯示編碼器與其解碼器彼此一致。
Intel HEX 紀錄與涵蓋的位元組範圍
Intel HEX 檔案是一連串的 ASCII 行，每行以冒號開頭，並以一個校驗和位元組結尾，該位元組為該行其他位元組總和的二補數。該每筆紀錄的校驗和與您欲計算的整體 CRC-32 無關。當您需要韌體映像的單一 CRC 時，相關位元組為規範所列紀錄類型內的資料欄位，依紀錄次序串接，並排除前置冒號、長度、位址與類型欄位，再加上尾端的每筆紀錄校驗和。
確切的涵蓋範圍由您的規範決定。部分開機載入器要求 CRC 涵蓋快閃記憶體中呈現的完整映像，包括任何標頭、長度欄位或向量表。其他則排除儲存的校驗和欄位，以便在校驗和計算後再行填入。請在貼上位元組前先確認規則，因為即使韌體承載相同，包含或排除數個標頭位元組仍會改變八位數結果。
CRC32 計算機的 hex 模式非常適合此工作，因為來源資料已是十六進位。每對數字成為一個位元組，前導 00 位元組會被保留並影響結果，位元組對之間的空白則會被忽略。若您的工具鏈以不同形式提供映像位元組，請先將其轉為乾淨的 hex 字串再行貼上，以便本頁能順利解析而不拒絕輸入。關於同一計算機在文字與 hex 之間抉擇的深入說明，請參閱如何從文字或十六進位位元組產生 CRC32。
為 Hex 檔案計算 CRC 的常見陷阱
最常見的錯誤是在來源檔案為十六進位時使用文字模式。CRC32 計算機在計算前會將文字編碼為 UTF-8，因此若將 hex 傾印的可見字元貼入文字模式，引擎涵蓋的將會是 0、1、2、3、A、B、C、D、E、F 的 ASCII 位元組及其之間的空白，而非它們所代表的二進位值。所得結果仍是有效的 CRC-32/ISO-HDLC 值，只是並非您的韌體所預期的值。當主控規範列出的是位元組而非字元時，請切換至 hex 模式。
其他陷阱出現在輸入的邊界：
- 來源檔案與計算機所見的換行差異。文字模式對 ASCII 與 UTF-8 字元一視同仁，但規範可能會包含或排除 CR、LF 或 CRLF。請逐位元組對齊來源慣例。
- 包含或排除每筆 Intel HEX 紀錄的校驗和位元組。請先去除尾端的校驗和欄位，再串接資料。
- 忽略前導 00 位元組。引擎會保留這些位元組並影響結果，因此貼上前請勿修剪 hex 字串。
- 僅比對可見的非零數字。系統一律顯示八位數字，前導零不符仍代表計算結果不同。
- 輕信來自不同 CRC 變體的相符結果。即使輸入相同，正確的 CRC-32C 值並非有效的 CRC-32/ISO-HDLC 值。
CRC 並非認證機制
CRC-32 能偵測資料中的意外變更，包括位元翻轉、截斷與傳輸損毀。但它無法偵測惡意竫改，因為 CRC 具線性且易於刻意操控。兩個值在 CRC-32/ISO-HDLC 下相符，僅代表涵蓋的位元組與原先涵蓋的內容一致，並不代表這些位元組來自可信來源。
對於韌體下載、已簽署的套件，或任何可能遭到惡意竫改的資料，請使用諸如 SHA-256 的密碼學摘要搭配經認證的管道，然後在信任 CRC 之前先驗證簽章。CRC32 計算機可在您的建置或驗證流程中支援完整性檢查步驟；它並不提供認證，其結果不應被視為出處證明。請將相符的校驗和視為僅針對意外錯誤的一致性證據；當計算值與預期校驗不符時，請重新檢視輸入。
欲深入了解，請參閱如何產生 HMAC-SHA256 簽章：位元組精確步驟。