一個免費、無需註冊的 BCC 校驗和，就是將每個選定位元組送入一個從零開始的八位元暫存器後，所得到的 XOR-8 結果，並以兩個小寫十六進位數字呈現。對於正在接線串列裝置、調校 Modbus 連線，或在工廠筆電上除錯廠商訊框的工程師來說，瓶頸很少是運算本身，而是存取方式:不必安裝任何東西、不必註冊任何帳號，直接複製結果就能繼續下一步。Checksum Calculator 正是為了這種情境而打造。在任何現代瀏覽器中開啟頁面，選擇 UTF-8 文字或十六進位位元組，輸入你的目標裝置實際預期的酬載，三個已標籤化的單一位元組數值會立即顯示:XOR-8 BCC、Modbus ASCII 2 的補數 LRC，以及原始位元組總和 mod 256。處理結果旁會顯示精確的位元組數量，讓你隨時能確認是否不小心把框定字元也送進計算機。所有運算都在瀏覽器本地執行，資料不會離開這台機器，不會建立帳號，頁面也絕不會悄悄截斷過大的輸入。
免費、無需註冊的 BCC 計算機能為你做什麼
一個免費、無需註冊的 BCC 校驗和工具，解決的是一個非常具體的痛點:現在立刻就需要明確的 XOR-8 結果，卻不想建立帳號、安裝軟體或支付訂閱費用。Checksum Calculator 頁面正好滿足這個需求:在任何現代瀏覽器中載入，就能即時從同一份輸入產生三個已標籤化的數值。畫面上不會跳出登入表單、不會索取電子郵件、不會有付款彈窗打斷作業流程，而且因為所有處理都在本地進行，輸入內容永遠不會離開你的機器。
這個頁面把所實作的公式攤在陽光下，而不是藏在一個不知從何而來的十六進位數字背後。每一行輸出都會標示演算法名稱、實際處理的位元組數，以及結果的兩字元小寫十六進位表示。這種標示至關重要，因為「校驗和」並非一個通用的演算法，而這個工具刻意避免假裝它能猜出你的目標裝置究竟期待哪一種公式。
頁面執行的三個明確公式
計算機會從同一份輸入回傳三個數值，讓你在決定裝置究竟需要哪一個之前，能先與廠商文件交叉比對。
- XOR-8 BCC 從零開始，將每個選定位元組 XOR 進一個八位元的累加器。由於 XOR 符合交換律且沒有進位，位元組的順序並不會改變最終結果。
- Modbus ASCII LRC 將每個訊息位元組相加，只保留執行總和最低的八個位元，然後回傳其二補數。等效來說，結果就是位元組總和 mod 256 的負值。
- Sum modulo 256 是診斷用的中間值:也就是在 Modbus 二補數步驟之前，普通位元組總和的低八位元。把它和 LRC 並列顯示，就能輕易判斷裝置文件要求的究竟是加總值、補數，還是其他慣例。
這三個數值來自同一組位元組，因此你可以比對廠商說明，確認文件中的結果與其中一個數值吻合。若需要進一步確認你的協定究竟需要哪一個，BCC 校驗和速查表 將最常見變體的公式、位元組範圍與限制整理在同一處。
3 個步驟計算 BCC 校驗和
- 選擇輸入表示方式。如果裝置文件以可讀字元顯示酬載，請切換到 UTF-8 文字;若文件給的是像「01 03 0A 02」這樣的十六進位字串，則切換到十六進位位元組。選擇必須符合裝置真正傳送資料的方式，而不是手冊上呈現的樣貌。
- 準確輸入校驗和涵蓋的位元組。輸入訊息字元或貼上十六進位位元組。在 Modbus ASCII 中，請省略起始冒號與結尾的 CRLF，因為官方的 Modbus over Serial Line 規範在 LRC 計算中並不納入這兩者。其他協定則請依照廠商指南的規定;頁面不會自行猜測。
- 讀取已標籤化的輸出並複製所需項目。頁面會為三個數值各顯示兩個小寫十六進位數字，以及實際處理的位元組數。請比對文件中的結果與 XOR-8 BCC、Modbus ASCII LRC 以及 sum modulo 256，然後複製吻合的那一行。複製出來的內容包含標籤與位元組數，讓貼上的診斷註記仍保留你所選定的解讀。
UTF-8 文字 vs 十六進位位元組:選擇正確的輸入
之所以提供兩種輸入模式，是因為不同協定對同一則訊息有不同的描述方式。一個使用可列印 ASCII 的串列裝置可以直接讓你貼上「READ」。Modbus 請求通常在你的終端機中以十六進位傾印方式出現，這時十六進位模式讓你直接輸入精確的位元組，不必繞經額外的解碼器。
在文字模式下，瀏覽器會先將你的字串編碼為 UTF-8 再執行運算。一個非 ASCII 字元(例如「é」)會佔兩個位元組，因此六個字元的字串會產生十二個位元組的校驗和輸入。畫面上顯示的位元組數會精確告訴你究竟送入了什麼，這也正是值得花半秒看一眼的原因:一個五字元的 ASCII 命令若顯示「5 bytes processed」，就能確認 UTF-8 編碼並未悄悄擴增任何內容。
在十六進位模式下，解析過程十分嚴格。每個位元組必須正好是兩個十六進位數字，位元組之間允許選擇性的空白字元，但像是 0x 前綴、逗號、冒號、連字號、奇數長度的半位元組，以及註解，都會被拒絕，頁面不會自行猜測。如果你輸入這些內容，畫面會顯示格式錯誤訊息，且不會產生任何部分值。這份嚴謹能保護你不會拿到一個由猜測拼湊、你再也無法重現的數字。
並排比較三個結果
下表彙整了三個公式的行為差異，方便你與裝置文件中的措辭對照。任何特定輸入的精確數值，請一律以工具實算為準，不要依賴手動試算。
| 欄位 | XOR-8 BCC | Modbus ASCII LRC | Sum modulo 256 |
|---|---|---|---|
| 初始值 | 0x00 | 0x00 | 0x00 |
| 逐位元組運算 | XOR 進 8 位元暫存器 | 加進 8 位元欄位 | 加進 8 位元欄位 |
| 進位處理 | 不適用(XOR 無進位) | 超過 8 位元的溢位予以捨棄 | 超過 8 位元的溢位予以捨棄 |
| 最終轉換 | 無 | 執行總和的二補數 | 無 |
| 結果範圍 | 0x00 – 0xFF | 0x00 – 0xFF | 0x00 – 0xFF |
| 典型框定規則 | 由廠商定義;僅輸入規範涵蓋的位元組 | 排除起始「:」與結尾的 CRLF | 由廠商定義;僅輸入規範涵蓋的位元組 |
| 彼此關係 | 與另外兩者無關 | Sum modulo 256 + LRC = 0x00(mod 256) | 即 LRC 取補數前的數值 |
當裝置手冊使用模稜兩可的措辭時，最後一列能派上用場。如果廠商文件寫的是「傳送訊息位元組的反轉校驗和」,Modbus ASCII LRC 那一欄幾乎肯定是正解，而 sum modulo 256 那一欄就是裝置預期你進行反轉的數值。如果文件寫的是「傳送每個位元組的互斥或」，那就是 XOR-8 BCC 那一欄的答案。
以快速驗證為例，取三個位元組 01 02 03。XOR-8 為 0x00，因為 1 XOR 2 = 3，接著 3 XOR 3 = 0。位元組總和 mod 256 為 0x06，而 Modbus ASCII LRC 是 0x06 的二補數，即 0xFA。總和與 LRC 相加等於 0x100，也就是 0x00 mod 256 —— 正好對應表中所列的關係。
限制，以及單一位元組校驗和無法保證的事
單一位元組校驗和能捕捉一些意外變動，但它並非安全機制。兩段不同的訊息可能產生相同的 XOR-8 BCC，而蓄意的攻擊者可以翻轉配對的位元，使校驗和保持不變。根據 BALTECH XOR-8 BCC 參考文件，這個八位元 XOR 只是一種簡易的區塊檢查字元，適用於選定的串列與裝置協定，並非用於驗證具敵意的流量。當你需要的不只是偶發錯誤偵測時，請使用該協定實際要求的安全機制 —— 例如訊息驗證碼、數位簽章，或協定本身內建的驗證層。
頁面本身也畫出了同樣的界線:結果一律明確標示為單一位元組校驗和，絕不會以雜湊、MAC、簽章或加密之名呈現。請勿將憑證貼入輸入欄，不要把輸出視為來源證明，也不要用這個計算機取代較高安全性協定所要求的 CRC、Fletcher、Adler、Internet checksum 或加密雜湊。若廠商文件寫的是「CRC-16」、「CRC-32」或「SHA-256」，那這裡就是用錯的工具。
頁面最多處理 500,000 個位元組，絕不會悄悄截斷過大的輸入。格式錯誤的十六進位會直接回報，而不會產生部分結果，這代表看到紅色錯誤訊息，絕對比看到一個由猜測拼湊、看起來可疑地乾淨的十六進位數值來得安全。輸出結果一律恰好為兩個小寫十六進位數字，即使數值小於 0x10 也會保留前導 0，因此你可以直接將輸出貼進訊框，不需煩惱長度上的歧義。
如需深入了解，請參閱 在大型文字上計算 BCC 校驗和:位元組精確的結果。