CRC32 計算器的範例是 ASCII 位元組字串 123456789，其產生的 CRC-32/ISO-HDLC 檢查值為 cbf43926。這個已知答案可讓你快速確認計算器在用於自己的資料之前，採用了預期的變體與固定參數。CRC32 計算器使用 32 位元暫存器、反射多項式 0xEDB88320、初始暫存器 0xFFFFFFFF、最終 XOR 0xFFFFFFFF，以及最低有效位元優先的位元組處理方式。你可以輸入可見文字（會編碼為 UTF-8），或提供確切的十六進位位元組序列。工具會以小寫傳回全部 8 個十六進位數字，在瀏覽器中完成運算而不會上傳輸入內容，且只會複製確切的 32 位元值。唯有當 UTF-8 與涵蓋的位元組符合適用規格時，才適合使用文字模式。當通訊協定定義了確切位元組時，十六進位模式可避免字元編碼與隱藏字元方面的不確定性。123456789 案例是校準測試，而非安全性測試：相符只證明 CRC 一致性，不代表真實性，也不能證明資料來自受信任的發布者。
測試標準 123456789 向量
標準數字字串是最適合的初始範例，因為 CRC-32/ISO-HDLC 的預期結果已有文件記載。它會以單一已知答案檢查，測試反射多項式、初始化、最終轉換、位元組順序與 8 位數十六進位格式。
- 開啟 CRC32 計算器並選擇 UTF-8 文字模式。
- 確切輸入 123456789，不要加上引號、空格或結尾換行符。
- 開始計算。
- 確認輸出為 cbf43926。
- 將結果用於紀錄或測試之前，先比較全部 8 個字元。
此範例中的內容資料是 123456789 的 9 個 ASCII 位元組。任何新增的空格、歸位符、換行符或其他字元，都會成為涵蓋資料的一部分，並產生不同的結果。因此，這個範例可確認計算器與所宣告的變體及位元組處理方式一致，但無法判定你自己的通訊協定需要哪些位元組。
計算實際內容資料的 CRC32
- 確認變體。確認目標格式要求 CRC-32/ISO-HDLC。此計算器不會切換至 CRC-32C、Castagnoli、Koopman、MPEG-2、BZIP2、JAMCRC 或其他 32 位元公式。
- 找出涵蓋的位元組範圍。閱讀適用規格，判定它只涵蓋內容資料，或也包含標頭、長度欄位、分隔符或儲存的檢查和欄位。
- 選擇相符的輸入模式。當規格明確使用文字位元組時，選擇 UTF-8 文字；當規格提供確切位元組或原始編碼不確定時，選擇十六進位模式。
- 輸入內容資料，不要新增任何內容。不要插入不在涵蓋範圍內的空格、行結尾、標籤或註解。十六進位模式可接受位元組配對之間的空白字元，但除此之外必須使用偶數個數字。
- 計算檢查和。輸入內容上限為 5,000,000 個位元組，以維持查表式計算的效能。
- 讀取完整輸出。計算器會將結果視為無號值，顯示剛好 8 個小寫十六進位數字，必要時補上前置零，且絕不會在未提示的情況下截斷數值。
- 比較並複製。將每個字元與預期值核對。複製動作只會複製確切的 8 位數、32 位元 CRC 值。
由於運算是在瀏覽器本機進行，輸入的文字或位元組不會上傳。只要選擇正確的位元組並瞭解檢查和能證明什麼，這項工具便適合處理私人內容資料。
讓此 CRC32 變體與眾不同之處
多項檢查通常都被稱為「CRC32」，但僅憑名稱並不能保證參數完全相同。此實作採用一項固定定義：
| 參數 | 固定設定 |
|---|---|
| 變體 | CRC-32/ISO-HDLC |
| 寬度 | 32 位元 |
| 反射多項式 | 0xEDB88320 |
| 初始暫存器 | 0xFFFFFFFF |
| 位元組處理 | 反射，最低有效位元優先 |
| 最終 XOR | 0xFFFFFFFF |
| 標準檢查輸入 | ASCII 123456789 -> cbf43926 |
計算器會先依據反射多項式建立具有 256 個項目的餘數表。對於每個輸入位元組，它會將該位元組與暫存器的低 8 位元組進行 XOR，查詢對應的表格值，再將該值與右移 8 個位元後的暫存器結合。處理完所有位元組後，會將暫存器取反相，並格式化為剛好 8 個十六進位數字。這些固定步驟可避免瀏覽器特有的數字格式改變顯示值。
gzip、ZIP 與 PNG 等格式會使用 CRC-32/ISO-HDLC，不過各格式可能定義不同的涵蓋範圍或儲存慣例。例如，RFC 1952會規範 gzip 及其對 CRC-32/ISO-HDLC 的使用。如果其他系統對 123456789 預期得到不同結果，它很可能採用了不同變體或不同的輸入位元組組合。
依位元組需求選擇文字或十六進位
輸入模式應依據資料定義，而不是內容資料的外觀。只有在編碼、正規化、行結尾與涵蓋範圍都已確知時，可見訊息及其確切位元組才可互換使用。
| 考量因素 | UTF-8 文字模式 | 十六進位模式 |
|---|---|---|
| 輸入 | 計算前先編碼為 UTF-8 的可見字串 | 直接轉換為位元組的十六進位配對 |
| 最適用於 | 明確定義為 UTF-8 文字的資料 | 具有確切規格的通訊協定、檔案或位元組序列 |
| 空白字元 | 若包含空格與行結尾，可能會改變檢查和 | 移除位元組配對之間的空白字元 |
| 編碼控制 | 取決於確切字元及其 UTF-8 位元組表示法 | 每組 2 位數字轉換成 1 個位元組 |
| 驗證 | 確切位元組很重要時，不應假設有隱藏的正規化 | 數字個數必須為偶數；會拒絕 0x 前置詞、非空白分隔符、註解及奇數個尾端半位元組 |
在文字模式中，ASCII 字元各自佔用 1 個位元組，而許多帶重音字母、CJK 字元及表情符號會佔用多個 UTF-8 位元組。以 UTF-16 程式碼單元、舊式字元集、正規化文字或不同換行慣例計算出的檢查和可能不同。當通訊協定提供確切位元組時，請使用十六進位模式，不要將它們重新輸入為可見文字。
十六進位模式也會保留會影響結果的重要前置 00 位元組。0x 等前置詞、註解、位元組配對之間的標點符號及未配對的最後一個數字，都會遭到拒絕，而不會被當成資料。對於容器格式，請先準確分離出規格涵蓋的位元組；計算器只會計算你提供的範圍，不會代你推斷標頭或儲存的檢查和欄位。
診斷不相符的結果
當預期值不一致時，請維持演算法固定，並檢查輸入內容與位元組範圍。這份選擇正確 CRC32 變體與位元組範圍的指南可提供結構化方法，找出是哪個細節不同。
- 變體錯誤：某個系統可能將其公式稱為 CRC32，實際上卻使用 CRC-32C、BZIP2、MPEG-2 或其他多項式與轉換方式。
- 涵蓋範圍錯誤：其中一次計算可能包含標頭、分隔符、長度或儲存的檢查和，而另一次則排除這些內容。
- 文字位元組不同：UTF-8 正規化、行結尾、空格或舊式字元編碼可能會改變檢查和。
- 十六進位解讀問題：確認每組配對都代表 1 個預期位元組，且重要的前置零位元組仍然存在。
- 預期表示法不同：請將計算器的確切數值與格式文件中記載的檢查和欄位比較，不要憑假設反轉或重新排列數字。
如果 ASCII 位元組 123456789 未產生 cbf43926，請先從變體開始檢查。如果此校準測試通過，但實際資料失敗，最可能的問題是所選的位元組範圍或其位元組的準備方式。
將 CRC32 用於錯誤偵測，而非驗證身分
CRC32 是一種循環冗餘檢查，用來偵測資料中常見的意外變更。它具有線性特徵，且容易遭到蓄意操控，因此值相符只能證明意外錯誤的一致性。CRC32 不是加密、密碼學雜湊、訊息驗證碼、數位簽章或來源證明。
不要單獨使用 CRC32 來驗證不可信任的軟體、授權命令、保護認證資料，或證明檔案來自受信任的發布者。若需要對抗惡意行為的完整性保護，請使用已公開的密碼學摘要搭配經驗證的散布頻道。對於一般格式檢查，只要變體、確切位元組、完整的 8 位數比較及規格定義的範圍均正確，結果就很有用。