一個 8 位元 XOR 區塊檢查字元 (BCC) 在大型酬載上是透過將累計值從 0x00 開始，並將每個選取的位元組透過 XOR 折疊運算而得出，可產生 256 種可能的一位元組結果之一。Checksum Calculator 直接在瀏覽器中實作該運算，單次呼叫最多可處理 500,000 位元組，並回報實際折疊進結果的位元組數量，而不是可見的字元數。由於 XOR 具交換律且進位無關，位元組順序並不會改變最終的 XOR-8 BCC，這使得該值對位元組重新排序具有穩健性，但也意味著許多不同的輸入會共用相同的總和檢查碼。大型文字會帶來一個特殊的變數：一個 200 個字元的字串，只要其中含有一個破折號、表情符號或非拉丁文字，就可能產生 350 位元組，因此裝置所檢查的位元組數量未必等於您所輸入的字元數。此工具一律將其輸出標示為 XOR-8 BCC、Modbus ASCII LRC，以及原始位元組總和模數 256，讓您能夠將公式對應到裝置說明文件實際描述的任何形式。

bcc checksum large text
大型文字上的 BCC 總和檢查碼：位元組精準的結果

「大型文字」對 BCC 計算的意義

當輸入是面向使用者的文字而非原始位元組的訊框時，「大型」是一個位元組的問題，而非字元的問題。UTF-8 將 ASCII 編碼為一個位元組，但將帶有腔調的字母、貨幣符號，以及任何超出基本拉丁範圍的字元編碼為兩個、三個或四個位元組。一行 200 個可見字元的紀錄，只要其中含有一個破折號、表情符號或非拉丁文字，就可能輕易產生 350 位元組。Checksum Calculator 會同時顯示已處理的位元組數量與總和檢查碼，讓您能夠確認您的目標裝置是否正在檢查您認為它正在檢查的位元組。在十六進位模式下，每一對十六進位數字剛好代表一個位元組，而頁面會拒絕奇數半位元組、雜散的逗號、冒號，以及 0x 前綴，而不是自行猜測，因此格式錯誤的輸入會明確失敗，而不會產生一個您必須手動重新推導的值。

計算器所公開的三個值

此頁面絕不會回傳一個通用的、未標示的總和檢查碼字串。它一律會針對同一筆輸入顯示三個已命名的一位元組值，必要時以前置零寫成兩個小寫十六進位數字：

值公式典型用途
XOR-8 BCC從 0x00 開始對每個選取的位元組進行 XOR某些序列通訊協定與裝置通訊協定，包括廠商定義的 BCC-8
Modbus ASCII LRC位元組總和模數 256 的二補數Modbus ASCII 訊框，其中冒號與 CRLF 排除在外
總和模數 256一般位元組總和的低八位元用於診斷的中間值，以區分加法總和與補數

Modbus 值在數學上為總和模數 256 的負值，因此總和與 LRC 相加會等於 0x00 (mod 256)。將兩者並列顯示，即可清楚看出廠商描述所預期的是加法總和、補數，或是完全不同的慣例。XOR-8 BCC 從 0x00 開始，並將每個位元組透過 XOR 折疊，因此 0x00 XOR 一個位元組會回傳該位元組本身，而一串 0x00 位元組會產生 0x00 的最終 BCC。

如何為大型文字計算 BCC 總和檢查碼

當您的酬載是一個長的 UTF-8 字串或一個長的十六進位位元組序列時，請依照下列具體步驟進行：

  1. 開啟 Checksum Calculator，並選擇與您的通訊協定相符的輸入模式：可列印內容使用 UTF-8 文字，原始訊框酬載使用十六進位位元組。
  2. 決定目標規格將哪些位元組納入其 BCC。對於 Modbus ASCII，請排除起始冒號與結尾的 CRLF；對於許多廠商定義的 BCC-8，則僅納入框架字元之間的位元組。請僅貼上或輸入那些被涵蓋的位元組，而非其外圍的框架。
  3. 在十六進位模式下，將每個位元組寫成剛好兩個十六進位數字，並可在位元組之間使用空白。0x 之類的前綴、逗號、冒號、破折號，以及奇數半位元組皆不被接受。
  4. 點選 Calculate 並讀取已標示的結果：XOR-8 BCC、Modbus ASCII LRC，以及位元組總和模數 256，每個皆呈現為剛好兩個小寫十六進位數字。
  5. 在將任何值與廠商說明文件進行比對之前，請先確認所顯示的位元組數量符合您預期的酬載長度，而非可見的字元數。
  6. 將已標示的結果集 (包括位元組數量) 複製到您的診斷紀錄中，如此一來當您將其貼到別處時，所選用的詮釋方式便能保留。

在信任大型結果之前，先以小型樣本進行驗證

在依賴此工具的輸出來處理長酬載之前，請先以一個已知的短向量進行測試。一個常見的教科書範例為五位元組序列 01 A0 7C FF 02。下方 XOR-8 的逐步推演採用與計算器內部相同的公式，因此先比對通過這個小型案例，即可證明較大型的執行將採用相同的規則。

以手動方式逐步推演 XOR-8：

  • 從 0x00 開始。
  • 0x00 XOR 0x01 = 0x01。
  • 0x01 XOR 0xA0 = 0xA1。
  • 0xA1 XOR 0x7C = 0xDD。
  • 0xDD XOR 0xFF = 0x22。
  • 0x22 XOR 0x02 = 0x20。

結果為 0x20。在小型向量上確認該值後，相同的常式即可套用於數千位元組的 UTF-8 酬載，除了執行中的累加器之外，無須改變任何狀態。

為何 UTF-8 編碼選擇在規模放大時至關重要

兩個看起來等效的字串，當其中一個含有非 ASCII 字元時，可能會產生不同的 BCC 值。例如，可見字元 "café" 會產生 UTF-8 位元組序列 63 61 66 C3 A9，雖然該字串僅有四個字元，但卻佔了五個位元組。若下游裝置以 Latin-1 編碼相同的字元，則只會看到四個位元組 (63 61 66 E9) 以及不同的 BCC。Calculator 無法為您解決這種模糊性，但它會回報所折疊的確切位元組數量，讓您能夠對照裝置所明的編碼方式來察覺其中的差異。

外部參考資料 (例如 BALTECH XOR-8 BCC 參考資料) 記載了計算器所預期的位元組表示方式，以及如何依據廠商的讀取器通訊協定來詮釋 BCC-8 輸出。當明定的輸入為原始十六進位而非文字時，請將計算器切換至十六進位模式，並將每個位元組以剛好兩位數字的形式貼上；如此可確保位元組表示方式與裝置端完全一致，並消除瀏覽器端 UTF-8 解譯所帶來的變數。

當這些值仍不足之時

無論是加法式或 XOR 式，一位元組總和檢查碼僅能偵測部分的偶發位元翻轉，並非訊息鑑別碼。BCC 值僅有 256 種可能，而能夠看到明文的攻擊者通常可以構造出一個修改後的酬載，使其 BCC 保持不變。請將這些檢查用於其設計目的——偶發的傳輸錯誤；而對於授權指令、驗證軟體下載或保護憑證等用途，則應仰賴您通訊協定所指定的加密機制——HMAC、數位簽章或經認證的加密模式。BALTECH 自身的建議是針對正式流量優先採用 CRC-16 而非 XOR-8 BCC，而相同的謹慎原則亦適用於 Modbus LRC。

依據您的裝置說明文件確認演算法

在將計算出的 BCC 貼入訊框之前，請先在裝置手冊中明確指出裝置所預期的輸入表示方式 (ASCII 文字、原始位元組或十六進位)、總和檢查碼涵蓋哪些欄位以及明確排除哪些欄位、累加器的初始值、最終的轉換方式 (恆等、一補數或二補數)，以及結果傳輸的位元組順序。兩部僅是順帶提及「總和檢查碼」的裝置，可能會要求截然不同的值。這三個公式及其限制的並列參考，可在 BCC 總和檢查碼速查表 中取得，以便在通訊協定除錯期間快速交叉查驗。

若通訊協定所規定的是 CRC-16、CRC-32、Fletcher、Adler、網際網路總和檢查碼或具名的加密雜湊，則此計算器並非適用工具，因為其刻意僅實作三個明確、具名的一位元組公式。此頁面的宗旨在於以透明的方式重現兩個簡單的 8 位元公式，而非自動偵測通訊協定。

如需更深入的探討，請參閱 在 UTF-8 文字上執行 gzcompress 線上工具是否安全？。