CRC-32/ISO-HDLC 是循環冗餘校驗，gzip、ZIP、PNG 以及許多其他格式都使用它來偵測儲存資料中意外的位元翻轉，而 CRC32 計算機 可在瀏覽器內從 UTF-8 文字或明確的十六進位位元組計算出該精確變體。對於大量驗證，計算機在單次計算中可接受最多 5,000,000 位元組，因此大量的承載資料清單、串接的日誌段落或完整的十六進位傾印都能在一次處理中完成，無需上傳任何內容。輸出結果永遠是八個小寫的十六進位數字，而 123456789 的 ASCII 位元組的標準檢查值為 cbf43926，這讓您能確認變體與涵蓋的位元組序列正好是目標格式所預期的。實作遵循 RFC 1952 中所述的實用範例方法:從反射多項式 0xEDB88320 產生 256 項查詢表，暫存器從 0xFFFFFFFF 開始，每個輸入位元組以最低有效位元優先處理，並在格式化為八位數十六進位之前將暫存器與 0xFFFFFFFF 進行 XOR。由於計算是完全在本機進行，重複的大量總和檢查碼不依賴伺服器，而您的輸入永遠不會離開裝置。八位數輸出會被視為無符號數，絕不截斷，並且對於相同的位元組序列，會與 gzip 的 --best、Python 的 zlib.crc32 以及符合標準的 CRC-32/ISO-HDLC 實作所產生的結果完全一致。
本工具使用的 CRC-32/ISO-HDLC 參數
只有當公式與目標系統預期的相符時，每次批次檢查才有意義。本頁僅實作一種特定變體，也就是 IETF 在 RFC 1952 中為 gzip 定義的變體，以及大多數封存和影像格式所沿用的變體。固定參數為寬度 32、反射多項式 0xEDB88320、初始暫存器 0xFFFFFFFF、反射位元組處理，以及最終 XOR 0xFFFFFFFF。為了獨立驗證實作，對於字串 123456789 的 ASCII 位元組，計算機會產生 cbf43926;這就是 CRC-32/ISO-HDLC 的標準檢查值，也是 zlib checksum 手冊 針對相同變體所列出的值。如果您輸入的位元組不是 123456789，卻沒有得到預期的結果，這種不一致幾乎總是來自不同的變體，或是涵蓋的位元組範圍與目標格式不符。標頭、長度欄位、分隔符號以及儲存的檢查碼欄位，有時會包含在涵蓋範圍內，有時則不會，閱讀格式規格是唯一可靠的判斷方式。
如何批次計算 CRC32
當您想要確認多個輸入是否符合預期值，或是需要對單一大型承載資料進行總和檢查碼時，可執行批次檢查。無論是單一值或一長串清單，處理流程都相同，因為計算機對於整個輸入永遠只會回傳恰好一個八位數值。
- 開啟 CRC32 計算機，並確認目標格式所需的 CRC 變體與位元組範圍;本頁僅涵蓋 CRC-32/ISO-HDLC，其 123456789 的檢查值為 cbf43926。
- 當輸入為字串且確定 UTF-8 是正確編碼時，選擇文字模式;當規格提供明確的位元組時，選擇十六進位模式。
- 完全按照應被涵蓋的方式輸入承載資料;前置空白、尾端換行以及 BOM 字元都會影響結果，因此請刻意地修剪或保留它們。
- 讀取八位數輸出，包括前置的零，並在複製到其他地方之前，逐字元與預期值進行比對。
- 對於多項目的批次作業，請對每個承載資料重複此循環，或在目標格式有定義分隔符號時，以該分隔符號串接項目，使其屬於涵蓋位元組的一部分。
批次輸入的文字模式與十六進位模式
文字模式與十六進位模式無法互相替代。文字模式在執行 CRC 之前會先將輸入編碼為 UTF-8，因此單一 ASCII 字母佔一個位元組，而含重音字母、CJK 字元及表情符號則佔用多個位元組。如果您實際想要進行總和檢查碼的位元組序列正是規格所描述的，十六進位模式會是較安全的選擇，因為每對數字會直接成為一個位元組，且您無需依賴工具與文字編輯器在換行符號、標準化或隱藏字元方面達成共識。十六進位模式會移除位元組對之間的空白，要求偶數個十六進位數字，拒絕 0x 之類的前綴、非空白的分隔符號、註解以及奇數的尾端半位元組，並保留會影響結果的前導 00 位元組。快速參考如下:
| 面向 | 文字模式 | 十六進位模式 |
|---|---|---|
| 輸入類型 | UTF-8 字串 | 十六進位位元組對 |
| 編碼步驟 | 是，文字會先轉換為 UTF-8 位元組 | 否，數字會直接解析為位元組 |
| 空白處理 | 空格與換行屬於輸入的一部分 | 會去除位元組對之間的空白 |
| 前導 00 位元組 | 不適用於文字 | 會保留並影響結果 |
| 最適用於 | 驗證字串內容或日誌 | 符合規格中的精確位元組序列 |
如果您需要重現某個工具在 UTF-16、舊式代碼頁、標準化 Unicode 或不同換行慣例下所產生的總和檢查碼，在未使用十六進位模式或自行標準化輸入之前，結果不會與本工具相符。編碼上的差異是批次總和檢查碼看似只差一個字元、實際上卻相差整個位元組的最常見原因。
與其他工具不一致的批次總和檢查碼
當批次總和檢查碼與預期值不符時，原因幾乎總是以下三種之一:不同的 CRC 變體、不同的位元組範圍，或同一字串的不同位元組表示方式。不同系統使用的名稱如 CRC32、CRC-32C、Castagnoli、Koopman、MPEG-2、BZIP2 與 JAMCRC，代表具有不同多項式或不同初始與最終轉換的公式。本頁僅實作 CRC-32/ISO-HDLC;若您對 123456789 的預期檢查值不是 cbf43926，則另一個系統很可能使用不同的變體或不同的涵蓋位元組範圍。一個常見的實用工作流程是同時使用兩個工具計算一個小已知字串的總和檢查碼並加以比較:若小字串的結果不一致，表示您使用的是不同的變體;若小字串一致但批次輸入不一致，則表示您使用相同變體但涵蓋的位元組序列不同，通常是因為標頭或長度欄位被不一致地包含或排除。對於將 CRC32 儲存在檔案內部的格式，請在去除儲存欄位後重新計算，並將截斷後的範圍與參考值進行比對。
限制、空輸入以及 00000000 的意義
輸入限制為 5,000,000 位元組，以確保瀏覽器中以查詢表驅動的處理保持回應速度;較大的輸入必須依照目標格式的規則分割或分塊雜湊。輸出絕不會被靜默截斷:該值會被視為無符號數，且永遠顯示八個十六進位數字，因此結果 1a 會顯示為 0000001a，而不是 1a。空的程式化輸入其 CRC 為 00000000，雖然介面會要求輸入資料，以免誤按造成的空輸入被誤認為有意義的驗證。八組外部檢查字串涵蓋空輸入、短訊息、常見訊息摘要與字母組、標準數值檢查，以及 quick-brown-fox 句子，並以 Python zlib 交叉檢查多位元組 UTF-8 邊界;這些值證明了所宣告的變體與位元組處理方式，而不僅僅是證明編碼器與其解碼器本身一致。如需更深入了解八位數如何從每個輸入位元組形成，請參閱 如何逐步計算 CRC 總和檢查碼。
CRC32 不適用的情境
CRC-32 是循環冗餘校驗，設計用於偵測資料中常見的意外變更。它具有線性且易於被人為操控的特性，這表示它不是加密、不是密碼雜湊、不是訊息驗證碼，也不是數位簽章。請勿使用它來驗證不受信任的軟體、授權指令、保護憑證，或是證明檔案來自受信任的發行者;在對抗性完整性情境中，請使用 SHA-256 等密碼學摘要以及經驗證的散布管道。然而，對於以權威性的預期值清單進行批次檢查的場合，CRC-32 正好是合適的工具，因為它在傳輸、儲存與重新封裝過程中，偵測意外損壞的效率遠高於讀取完整內容。將相符的 CRC-32 視為您所涵蓋的位元組與參考系統所涵蓋的位元組相同的證據;將不相符視為在信任任一方之前，調查變體、位元組範圍與編碼的提示。
相關閱讀:批次產生密碼:安全的本機工作流程。