基於瀏覽器的 CRC32 計算機是遠端 CRC32 校驗和 API 最直接的替代方案：它使用 RFC 1952 的固定參數，在頁面內部完整計算出 CRC-32/ISO-HDLC 的校驗值，因此不需要呼叫任何 HTTP 端點、不需要配置 API 金鑰，也不會有任何資料離開你的機器。典型的 CRC32 API 會要求你 POST 負載、註冊方案、遵守速率限制，並把你的輸入託付給第三方;而瀏覽器替代方案只需在表單中輸入 UTF-8 文字或精確的十六進位位元組，就會回傳一個你可以直接從頁面複製的八位數小寫十六進位值。實作採用反射多項式 0xEDB88320、初始暫存器 0xFFFFFFFF、反射位元組處理，以及最終 XOR 0xFFFFFFFF，針對 123456789 的 ASCII 位元組會產生規範的校驗值 cbf43926。單看這個八位數結果就能確認實作與 gzip、ZIP 和 PNG 相符，因此你可以把 API 呼叫換成貼上並計算的工作流程，而不需改變下游系統所期望的內容。

crc32 calculator api alternative
CRC32 計算機 API 替代方案:在瀏覽器中本機執行

以基於瀏覽器的計算機取代 CRC32 API

許多工程師會選擇使用 CRC32 HTTP API，因為他們假設遠端校驗和服務是唯一可靠的選項。實際情況往往相反:遠端 API 會增加延遲、第三方依賴、認證介面，以及一條把你試圖驗證的資料上傳出去的路徑。本機瀏覽器計算機則完全避開了這些疑慮。當你按下按鈕時，計算會同步執行，結果無需來回即可顯示，而且輸入永遠不會跨越網路邊界，因為 JavaScript 是在已開啟的頁面上執行。

最後一點在受到規範的環境中特別重要。如果你正在檢查客戶檔案、內部封存，或任何受到保密義務約束的負載的 CRC32 值，為了讀回一個 32 位元數字就把位元組上傳到公開 API，通常比在本機執行相同的演算法更難以合理化。瀏覽器計算機提供相同的演算法與標準校驗值，並完全移除了上傳步驟。它也消除了營運上的擔憂——金鑰過期、配額被限流、服務中斷、廠商鎖定——這些都是依賴託管端點來執行任何客戶端都能做之計算時所伴隨的問題。

本工具實作的 CRC-32/ISO-HDLC 參數

這個計算機不是通用的 CRC32 工具。它實作一個特定變體——CRC-32/ISO-HDLC，使用更廣泛生態系所依賴的參數。這些參數為:寬度 32 位元、反射多項式 0xEDB88320、初始暫存器值 0xFFFFFFFF、反射輸入位元組處理(最低位元優先)，以及最終 XOR 0xFFFFFFFF，輸出保留前置零的八位小寫十六進位數字。

確認 CRC32 實作為 ISO-HDLC 變體最快速的方式，就是對 123456789 的 ASCII 位元組計算校驗值，並確認其等於 cbf43926。這個八位數值是用來區別此變體與 CRC-32C(Castagnoli)、MPEG-2、BZIP2、JAMCRC 等其他共享相同寬度但多項式或初始化方式不同的 32 位元公式的標準發佈校驗值。以單一範例來看:輸入位元組 31 32 33 34 35 36 37 38 39 → 輸出 cbf43926，無需進一步反覆運算。

在內部，演算法會從反射多項式建立一個 256 項的查詢表。對於每個輸入位元組，它會將該位元組與暫存器的低八位元做 XOR，查詢對應的表格項目，並將其與右移八位元的暫存器結合。接著將暫存器取補數並格式化。這遵循 RFC 1952 中記載的實用範例方法，也就是 gzip 格式所使用的同一份規格，因此校驗值會與 zlib 的校驗和函式 傳回的結果一致。

如何在不呼叫 API 的情況下計算 CRC32

當你需要一次性或重複的 CRC-32/ISO-HDLC 值時，以下工作流程可取代 API 呼叫:

  1. 確認所需的 CRC 變體，以及你需要涵蓋的確切位元組序列。如果規範格式指定在特定範圍上使用 CRC-32/ISO-HDLC，在開始前先記下起始與結束偏移量，以便日後能驗證相同的位元組。
  2. 決定要輸入 UTF-8 文字還是精確的十六進位位元組。只有在格式確實為文字時才使用 UTF-8 文字;當規格提供精確的位元組序列時，請使用十六進位位元組，因為重新輸入可見文字可能會改變編碼、換行慣例，以及隱藏的標頭位元組。兩種輸入模式的取捨在 如何從文字或十六進位位元組產生 CRC32 中有詳細探討。
  3. 在任何現代瀏覽器中開啟 CRC32 計算機。頁面會在載入時建立查詢表，並立即準備好接受輸入。
  4. 將你的負載以所選模式貼到輸入欄位中。在十六進位模式下，位元組對之間僅以空白分隔;工具會拒絕 0x 之類的前綴、奇數長度的尾端半位元組，以及任何非空白分隔符號。
  5. 點擊計算。頁面會回傳一個八位字元的小寫十六進位值，永遠恰好八位數，因此前置零會被保留。
  6. 逐一比對結果的每一位數與期望值，包括任何前置零。出現一個字元的差異代表位元組或變體不相符，而不是工具本身存在近似誤差。如何逐位比對的逐步說明請見 計算 CRC32 校驗和並比對 8 個十六進位數字。
  7. 複製結果並貼到你的筆記、測試 fixture 或驗證腳本中。複製動作只會寫入精確的 32 位元值，不會附加任何格式。

如果你需要從不同環境交叉驗證結果，zlib 文件記載了相同的演算法與相同的校驗值，因此針對相同位元組呼叫 Python 的 zlib.crc32 應該會逐位數一致。

API 與瀏覽器工具:並列比較

下表從你在挑選替代方案時真正在意面向，比較典型的 CRC32 校驗和 API 服務與基於瀏覽器的計算機。

面向CRC32 校驗和 API瀏覽器 CRC32 計算機
每次檢查的網路來回每次請求都需要無——計算在本機執行
資料是否離開你的機器會，負載會被上傳不會，輸入永遠不會跨越網路
API 金鑰或註冊通常需要不需要
速率限制以每分鐘、每小時或每日計算無——僅受限於輸入大小上限
離線可用性否是，只要頁面曾載入一次
參數控制因服務而異;部分提供變體旗標，其他則硬編碼為 CRC-32/ISO-HDLC固定為 CRC-32/ISO-HDLC;也就是 gzip、ZIP 與 PNG 所使用的同一變體
計價模式免費方案附帶上限，超過配額採付費方案免費，無任何計量
結果格式依端點而定，可能是十六進位、十進位或二進位八位數小寫十六進位，永遠為非負值
空輸入行為傳回該演算法的固定值對於程式化的空輸入回傳 00000000;介面會提示輸入資料，因此意外的空點擊不會被誤判為真正的驗證

模式是一致的:凡是遠端 API 強迫你管理金鑰、遵守限流，或接受你的負載會被傳輸出去的地方，瀏覽器工具都能完全消除這項義務。

輸入限制與計算機會拒絕的內容

瀏覽器替代方案只有在它能接受你真正需要檢查的輸入時才有幫助。計算機施加一道硬性上限:輸入上限為 5,000,000 位元組，以確保基於查詢表的迴圈在頁面中保持回應速度。對於大多數校驗和工作——簡短訊息、檔案詮釋資料欄位、封存標頭、影像區塊——這個上限並不構成限制。

工具會直接拒絕格式錯誤的十六進位輸入，而不是靜默修正。像 0x 的前綴、非空白的分隔符號、註解，以及奇數長度的尾端半位元組，都會被一律拒絕。位元組對之間的空白會被去除，這代表你可以貼上 48 65 6c 6c 6f 或 48 65 6c 6c 6f 00，工具都會將兩者視為預期的位元組流。前導的 00 位元組會被保留，這一點很重要，因為填補位元組屬於涵蓋範圍的一部分，前綴不符會導致摘要改變。

輸出絕不會被靜默截斷。八位數格式是無條件的;即使是 00000000 也會以恰好八個字元顯示，因此較短的結果不會被誤認為部分值。32 位元值會被視為非負值處理，因此像 0xCBF43926 這樣的值會回報為正整數 3,421,780,262，而不是負的二補數整數。

當 CRC32 不夠用時:挑選合適的完整性工具

CRC32 是一種快速的錯誤偵測碼，而不是安全原語。它能偵測儲存與傳輸中常見的意外位元翻轉，但它是線性的、易於刻意偽造，且不提供任何認證保證。一個能竄改負載的惡意行為者，通常也能竄改 CRC32 來配合。因此，計算機適合用於針對 gzip、ZIP、PNG 等格式的相容性檢查，但不適合用來驗證下載是否來自可信賴的發行者、授權指令，或保護憑證。

對於這類工作，請使用在相同位元組範圍上計算的加密摘要，並透過你已信任的管道散佈。SHA-256、SHA-512，以及基於共用密鑰的 HMAC，都是合理的選擇，具體取決於你需要的是純粹的完整性，還是完整性加上認證。當目標是重現目標格式所預期的精確 32 位元值時，計算機是合適的工具;但當你需要安全性保證時，它無法取代雜湊，兩者不應在驗證流程中混為一談。