若要在 Windows 上計算 BCC 校驗和，請將協定指定的單一 byte 公式套用至確切涵蓋的位元組：XOR-8 從 00 開始，並將每個位元組 XOR；Modbus ASCII LRC 則是位元組總和模 256 后的二進位補數。
「checksum」一詞並不代表單一通用演算法。不同裝置與協定可能採用不同的寬度、初始值、納入欄位、補數、位元組順序及框架規則。有些文件甚至會將 BCC 用於加法校驗和、LRC 或 CRC，而非 8 位元 XOR。
Checksum Calculator 會明確呈現其三種公式，並在本機處理所選位元組。它不會猜測裝置預期採用哪種慣例，因此仍應以裝置文件為輸入與演算法方面的權威依據。
先識別校驗和慣例
開啟計算器之前，請記錄協定的輸入表示方式、校驗和寬度、演算法、初始值、涵蓋欄位、最終轉換及傳輸位元組順序。若需具體的供應商定義，BALTECH XOR-8 BCC 參考資料會說明如何對所選位元組執行 8 位元 XOR。
| 計算值 | 公式 | 意義 | 框架備註 |
|---|---|---|---|
| XOR-8 BCC | BCC = 00 XOR b0 XOR b1 至 bn | 對每個所選位元組執行單一 byte 的 XOR。順序不影響結果，進位也不相關。 | 僅納入文件定義為由校驗和涵蓋的欄位。 |
| Modbus ASCII LRC | LRC = (負的位元組總和) 模 256 | 最終 8 位元總和的二進位補數。 | 標準 Modbus ASCII 不包含起始冒號及結尾 CRLF。 |
| 原始總和模 256 | Sum = (b0 + b1 至 bn) 模 256 | 用於顯示一般位元組總和低 8 位元的診斷中間值。 | 這不是最終的 Modbus LRC。 |
MODBUS over Serial Line Specification V1.02 將起始冒號及結尾 CRLF 置於提供給 ASCII LRC 計算的位元組之外。其他協定可能定義不同的範圍。請確認相關供應商文件中的欄位，不要僅因某些字元看起來像框架便將其移除。
在 Windows 瀏覽器中計算 BCC 校驗和
- 閱讀裝置文件。找出確切由校驗和涵蓋的酬載或框架欄位。請注意手冊指定的是 XOR-8 BCC、Modbus ASCII LRC、加法總和或其他公式，並記錄任何必要的納入或排除規則。
- 在 Windows 瀏覽器中開啟 Checksum Calculator。此頁面分別提供 UTF-8 文字與十六進位位元組的控制項，以及計算操作。
- 選擇協定使用的輸入表示方式。若文件提供明確的位元組配對或二進位資料，請選擇十六進位位元組。只有在您輸入的字元會編碼成預期的協定位元組時，才選擇 UTF-8 文字。
- 輸入確切的涵蓋位元組。在十六進位模式下，每個位元組須輸入恰好兩位十六進位數字，位元組之間可加上空白。除非目標規格將起始冒號、CRLF、位址、功能碼或資料欄位納入校驗和，否則請勿加入。
- 執行計算。此頁面會以兩個小寫十六進位數字顯示三個值中的每一個，並回報已處理的確切位元組數量。請確認顯示的數量與裝置手冊所述的位元組序列相符。
- 將公式與文件比較。文件規定使用 8 位元 XOR 時，請採用 XOR-8 結果；採用標準二進位補數慣例時，請使用 Modbus ASCII LRC；只有裝置說明為加法結果時，才使用原始總和。計算器不會僅因手冊含有 BCC 一詞便聲稱與協定相容。
- 複製標示的輸出。複製的結果包含全部三個值與位元組數量，並保留所選的解讀方式，以便用於診斷備註或支援請求。
- 檢查錯誤與輸入大小。計算器最多接受 500,000 個位元組，絕不會默默截斷輸入，並會回報格式不正確的十六進位資料，而不產生部分值。
此瀏覽器式 Windows 工作流程可在您將結果與手冊比較時，讓位元組數量與公式保持可見。當協定實際處理二進位位元組時，它可避免輸入可列印框架所造成的歧義。
為任一輸入模式準備確切的位元組
文字與十六進位輸入並非可互換的表示方式。文字模式遵循 UTF-8，而十六進位模式會解析明確的位元組。請選擇能保留協定預期位元組序列的模式。
| 輸入模式 | 輸入內容 | 預期行為 |
|---|---|---|
| UTF-8 文字 | 確切由校驗和涵蓋的字元。 | 瀏覽器會先將字串編碼為 UTF-8。非 ASCII 字元可能佔用數個位元組，因此顯示的位元組數量可能超過可見字元數。 |
| 十六進位位元組 | 每個位元組兩個十六進位數字，並以選用的空白分隔。 | 解析器會拒絕 0x 前置詞、逗號、冒號、連字號、奇數長度的半位元組及註解，而不會猜測如何解讀。 |
當協定指定確切的二進位酬載、非 UTF-8 字元集，或需要使用從封包擷取複製而來的位元組時，請使用十六進位模式。只有在 UTF-8 確實是協定的表示方式時，才使用文字模式。ASCII 字元佔用一個 UTF-8 位元組，但加入非 ASCII 字元可能改變酬載與校驗和輸入。
框架仍是另一項獨立決策。若使用標準 Modbus ASCII LRC，請輸入不含起始冒號及結尾 CRLF 的訊息位元組。其他協定則應遵循該規格確定的涵蓋範圍。此頁面不會自動移除框架。
位元組 31 32 33 的實例
假設某裝置規格將 31 32 33 指定為涵蓋的位元組。這些是「123」的 ASCII 位元組。以下所有算術均以十六進位顯示。
- XOR-8 BCC：(00 XOR 31) XOR 32 XOR 33 = 30.
- 原始位元組總和：(31 + 32 + 33) 模 256 = 96.
- Modbus ASCII LRC：(00 - 96) 模 256 = 6A.
原始總和與 LRC 符合一致性關係 96 + 6A = 100，而 100 等於 00 模 256。此範例也顯示為何三個輸出必須清楚標示。只有在文件指定 XOR-8 BCC 時才使用 30；文件指定 Modbus ASCII LRC 時才使用 6A；僅憑此範例無法確立實際裝置預期的是哪個值。
插入結果前先加以檢查
將校驗和位元組放入訊息之前，請確認所選結果符合文件所指定的演算法、校驗和寬度、初始值、納入欄位、最終補數及位元組順序慣例。也請確認計算器顯示的位元組數量與您的框架相符。外觀相似的文字框架可能因輸入編碼或誤將框架納入而含有不同數量的位元組。
對 XOR-8 而言，涵蓋序列內的位元組順序不會改變結果，因為 XOR 具有交換性。但這項性質並不代表每種協定的 BCC 都與 XOR-8 可互換。加法慣例可能要求使用原始總和，Modbus 慣例可能要求使用二進位補數，其他裝置則可能採用完全不同的範圍或轉換方式。
這些單一 byte 校驗可偵測部分意外變更，但它們不是密碼學雜湊、訊息驗證碼、數位簽章、加密或來源證明。XOR 與加法校驗和具有許多碰撞，也可能遭人為調整。請勿用它們保護憑證、授權命令、驗證軟體下載或驗證具敵意的網路流量。如果文件指定的是 CRC-16、CRC-32、Fletcher、Adler、Internet checksum 或具名的密碼學雜湊，便不應使用此計算器。