CRC-32/ISO-HDLC 是一種 32 位元循環冗餘校驗，基於反射多項式 0xEDB88320 建構，初始暫存器為 0xFFFFFFFF，採用反射位元組處理，並以 0xFFFFFFFF 進行最終 XOR；對於字串 "123456789" 的 ASCII 位元組，它會回傳標準校驗值 cbf43926，這是用來區分此變體與 CRC-32C、BZIP2、JAMCRC 及其他 32 位元公式的參考簽章。CRC32 計算工具在瀏覽器中精確實作此變體，可接受 UTF-8 文字或十六進位位元組作為輸入，並一律輸出八位數小寫十六進位值，方便將結果與預期校驗值逐字元比對。由於計算在本地端執行，您可以在 Linux 系統上計算 CRC32，而無需呼叫 cksum、crc32、zip 或任何其他命令列工具，這在目標機器無介面、缺少工具鏈，或您只想在將值透過指令稿管線傳送之前先行驗證時特別有用。
CRC32 在 Linux 系統上的意義
在 Linux 主機上，CRC32 出現在 PNG 區塊結尾位元組內嵌的校驗和、ZIP 封存的本地檔案標頭，以及由 gzip -1 到 gzip -9 和基於 libz 的函式庫所產生的每個 gzip 串流的結尾中。標準的 Unix cksum 指令與 libz 所附的 crc32 工具都預設使用此 ISO-HDLC 變體，這就是為何下載的 ZIP 檔與 cksum file.zip 的輸出會以相同的八個十六進位數字結尾。該演算法本身是確定性的：由反射多項式建構一個 256 項的查表，每個輸入位元組與低位元組的最低位元組進行 XOR，查表結果取代低位元組，暫存器向右位移八個位元，最後透過互補步驟將運行中的暫存器轉換為公布的校驗值。
相同的程序可適用於任何位元組序列，但只有在雙方涵蓋完全相同的位元組並使用相同參數時，結果才會與其他工具一致。這就是為何對 UTF-8 字串計算的 CRC32 與對其 UTF-16 碼元計算的結果不同，也為何使用 CRLF 換行符號的檔案會與使用 LF 換行符號的相同檔案產生不同的值。若您的目標格式指定了位元組範圍，您必須只將落在該範圍內的位元組（而非其他位元組）送入計算工具。
CRC32 計算工具與 Linux 命令列工具的比較
| 方法 | 執行位置 | 輸入格式 | 變體 |
|---|---|---|---|
| CRC32 計算工具（瀏覽器） | 本地 JavaScript，不上傳 | UTF-8 文字或十六進位位元組 | 僅 CRC-32/ISO-HDLC |
| cksum | Shell | 檔案路徑或 stdin | 預設為 CRC-32/ISO-HDLC |
| crc32（libz contrib） | Shell | 檔案路徑或 stdin | 預設為 CRC-32/ISO-HDLC |
| gzip -tv file.gz | Shell | Gzip 串流結尾 | CRC-32/ISO-HDLC，僅內嵌位元組 |
| zip -v file.zip | Shell | 本地檔案標頭項目 | CRC-32/ISO-HDLC，未壓縮位元組 |
命令列選項的優勢在於可直接從磁碟讀取，並列印出對內嵌值的驗證校驗，但這需要 Shell、可運作的工具鏈，以及通往待測位元組的路徑。基於瀏覽器的 CRC32 計算工具則接受任何您能貼上的位元組，對其執行相同的反射演算法，且不會離開本機，因此在鎖定的工作站、Chromebook 或未安裝開發環境的 Linux 主機上皆可使用。
如何從瀏覽器計算 CRC32
- 確認 CRC 變體以及目標規格所涵蓋的確切位元組範圍。本工具僅實作 CRC-32/ISO-HDLC；其參考校驗值為 ASCII 位元組 123456789 對應的 cbf43926。
- 決定輸入最適合以 UTF-8 文字或十六進位位元組表示。凡是來源定義了精確位元組的情況（例如已記錄的標頭、一段機器碼，或從封包傾印複製下來的記錄），請使用十六進位。
- 將承載資料貼到計算工具的輸入區。在文字模式下，字串在處理前會編碼為 UTF-8，因此含變音符號的字母、CJK 字元和表情符號各會貢獻一個以上的位元組。在十六進位模式下，剖析器會移除位元組對之間的空白，拒絕 0x 前綴、註解以及空白以外的分隔符，並要求位數為偶數。
- 執行計算。頁面使用由 0xEDB88320 建構的 256 項查表、初始暫存器 0xFFFFFFFF、反射位元組順序，以及最終 XOR 0xFFFFFFFF 來處理位元組序列，遵循 RFC 1952 中的實作範例方法。
- 將八位數小寫十六進位結果與預期校驗值進行比對。請將每一位數（含前置零）視為有效位元；即使使用者介面要求輸入資料，空白的程式化輸入其 CRC 仍為 00000000。
- 透過複製動作複製精確的 32 位元值，該動作只會將八個十六進位數字放上剪貼簿，不包含其他內容。
文字模式與十六進位模式：哪些因素會改變結果
這兩種輸入模式描述相同的演算法，但餵入不同的位元組序列。文字模式會將可見字串編碼為 UTF-8，因此單一 ASCII 字母佔一個位元組，像 "é" 這樣的字元可能佔兩個位元組，而 CJK 表意字元通常佔三個位元組。對 UTF-16 碼元、ISO-8859-1 等舊式字碼頁、NFC 或 NFD 標準化文字，或不同換行慣例計算所得的結果，將無法與計算工具的輸出相符，即使畫面上的文字看起來完全相同。
十六進位模式的存在，是為了處理協定提供精確位元組而非字元的情況。每對十六進位數字成為一個位元組，空白會被移除，任何多餘的 0x 前綴、逗號、冒號、分號或註解都會被拒絕，而非悄悄忽略。前導的 00 位元組會被保留並影響結果，這在與以低值填補開頭的結尾進行比對時很重要。若目標格式在涵蓋範圍內包含標頭、長度欄位、分隔符或儲存的校驗和欄位，請將它們依其在線路上的確切形式納入十六進位輸入；若它們落在範圍外，則予以排除。
將八位數輸出與目標進行驗證
計算工具回傳八個十六進位數字後，比對即為逐字字串比對。像 0xcbf43926 或 CBF43926 這類目標必須在比對前標準化為小寫，而任何長度不足八個字元的預期值應以前置零補齊，而非視為較短的前綴。本工具隨附八個外部校驗字串以確認所宣告的變體：空輸入、數則簡短訊息、常見字母組、標準數值校驗，以及 quick-brown-fox 句子，外加在多位元組 UTF-8 邊界上以 Python zlib 進行的交叉驗證。
該相符僅能證明偶然錯誤的一致性。CRC-32/ISO-HDLC 是線性的且易於竄改，因此無法用於確認檔案來自可信任的發行者、指令來自授權來源，或下載的二進位檔未被攻擊者替換。當防範惡意竄改很重要時，請將 CRC 與加密摘要（例如 SHA-256 或 SHA-512）搭配使用，並透過經驗證的管道散佈簽署式清單，或使用訊息驗證碼而非循環冗餘校驗。
限制、安全性，以及何時應選擇其他工具
計算工具接受最多 5,000,000 位元組，以確保基於查表的內部迴圈保持回應性，且輸出絕不會被悄悄截斷：該值被視為無符號數，並一律顯示八個十六進位數字。計算在瀏覽器中執行，輸入不會被上傳，複製動作僅複製精確的 32 位元值。若 "123456789" 的預期校驗值不是 cbf43926，代表其他系統使用了不同的 32 位元公式（例如 CRC-32C、MPEG-2、BZIP2 或 JAMCRC），此時 CRC32 計算工具並非該比對的合適基準；您需要一個能公開相同多項式及相同初始與最終轉換的工具。在 Linux 系統上需要加密驗證時，較安全的做法是使用 coreutils 中的 sha256sum 或 sha512sum 所產生的摘要，並搭配經由帶外驗證的簽章。
若您正在權衡選項，如何在終端機中使用 ROT13 解碼器指令對此有詳細說明。
若您正在權衡選項，在 Linux 上產生 SHA-1 雜湊以進行校驗和比對對此有詳細說明。