BCC（區塊檢查字元，Block Check Character）校驗和是將訊息的每個位元組互斥或（XOR）成單一八位元值所得到的結果，會產生介於 0x00 與 0xFF 之間、剛好兩個小寫十六進位數字。累加器從 0x00 開始，每個輸入位元組都以 XOR 運算子折疊進去：相同的位元互相抵消，不同的位元保留。因為 XOR 具有交換律且自我反轉，最終結果只取決於所選位元組集合中每個位元的奇偶性，重新排列位元組不會改變結果。八位元的寬度代表最低八位元之後的所有位元都會被捨棄，因此無論輸入長度為何，輸出絕對不會超過 0xFF。結果可以放入一個位元組中，通常會附加在訊息末端，讓接收端可以重新計算並加以比對。這個簡單的區塊檢查字元被廣泛用於序列裝置通訊，因為運算速度快、程式碼又精簡；但同一個 BCC 一詞也被廠商重複用於加法式校驗和、LRC、CRC，甚至用於訊框中無關部分的校驗和，因此廠商文件是唯一能定義某個特定裝置所採用公式的地方。

bcc checksum explained
BCC 校驗和完整解析：XOR-8 的運作方式與其不足之處

XOR-8 公式完整說明

XOR-8 BCC 的公式相當簡短，可以一行寫完：

BCC = b[0] ⊕ b[1] ⊕ b[2] ⊕ … ⊕ b[n-1]

其中每個 b[i] 是範圍內的一個位元組，⊕ 是 XOR 運算子。累加器從零開始，任何位元組與自身 XOR 都會回到零，執行中的結果只反映整個區塊中未配對的位元。因為 XOR 不存在進位，所以位元組順序不重要，重複的位元組也能乾淨地互相抵消。

以五個位元組的序列 01 A0 7C FF 02 為例，逐步計算如下：

  • 起始：BCC = 00
  • 00 ⊕ 01 = 01
  • 01 ⊕ A0 = A1
  • A1 ⊕ 7C = DD
  • DD ⊕ FF = 22
  • 22 ⊕ 02 = 20

最終的 BCC 是 20。將同樣的五個位元組丟進 校驗和計算機，標示為 XOR-8 的結果同樣會顯示 20，回報的位元組數量為 5。BALTECH XOR-8 BCC 參考資料 描述了橫跨選定酬載位元組的這個八位元 XOR 定義，也就是計算機所重現的行為。

如何使用校驗和計算機計算 BCC 校驗和

  1. 在瀏覽器中開啟校驗和計算機。
  2. 選擇符合裝置實際表示方式的輸入模式：可列印字串使用 UTF-8 文字，或是原始封包使用十六進位位元組。只要規格明確引用位元組，就請使用十六進位。
  3. 只輸入規格指定要涵蓋的位元組。對於標準的 Modbus ASCII LRC，這代表要排除起始冒號與結尾的 CR/LF。對於通用的 XOR-8 BCC，則只納入廠商文件所指定框架之間的位元組。
  4. 在十六進位模式下，每個位元組必須剛好寫成兩個十六進位數字，位元組之間可以有空白。0x 前綴、逗號、冒號、連字號、奇數長度的半位元組或註解都會被拒絕，而非自動猜測。
  5. 在文字模式下，直接保留字串原樣；瀏覽器會先將其編碼為 UTF-8，因此一個非 ASCII 字元可能貢獻好幾個位元組，顯示的位元組數量可能會超過可見的字元數量。
  6. 執行計算。頁面會回傳三個標示好的數值：XOR-8 BCC、Modbus ASCII LRC，以及原始位元組總和模數 256，每個都是剛好兩個小寫十六進位數字（含前置零），再加上已處理的位元組數量。
  7. 對應到廠商文件所標示的結果。若文件稱該值為 BCC 並描述為 XOR，請採用該列；若文件稱該值為 ASCII 訊框的 LRC，請採用 Modbus ASCII LRC 那一列；若要求的是未取補數的加法總和，請採用總和模數 256 那一列。
  8. 複製輸出。複製的內容包含標籤、三個數值以及位元組數量，因此貼上的註解能讓下一位讀者保留對應的解讀。

XOR-8 BCC 與 Modbus ASCII LRC 的差異之處

BCC 與 LRC 這兩個詞並不能互換使用。它們描述的是兩種不同的單位元組公式，許多裝置若收到錯誤的公式，會直接拒絕該訊框。下表顯示兩者的實際差異。

特性XOR-8 BCCModbus ASCII LRC
結合運算跨所有位元組的位元 XOR跨所有位元組相加，再取二補數
初始值0x000x00
進位處理進位無關緊要（XOR 沒有進位）進位捨棄，保留低 8 位元
輸出累加器本身總和的二補數，等同於總和模數 256 的負值
配對特性位元組與自身 XOR 後會抵消回前一個執行中的值LRC 加上其訊息位元組的總和模數 256 為 0x00
框架慣例依廠商指定的為準排除起始冒號與結尾的 CR/LF
權威來源標示 XOR 的廠商手冊Modbus over Serial Line 規格 V1.02

計算機會對同一組位元組同時回傳這兩種公式，讓對比一目了然。只要更動輸入一個位元組，XOR-8 BCC 會以一種明確的方式改變，而 Modbus LRC 則以另一種方式改變，將兩列並列往往是抓錯最快的途徑。模數 256 的總和就是 Modbus 二補數步驟之前、一般位元組總和的低八位元，這也是為什麼總和與 LRC 在模數 256 之下永遠相加為 00。

計算機強制執行的輸入規則

頁面絕不會悄悄截斷或修補錯誤的輸入。因此在貼上長訊框之前，值得先讀過這些規則。

  • 最大輸入為 500,000 個位元組。更大的輸入會被拒絕，且不會產生部分結果。
  • 十六進位模式只接受兩位數的十六進位位元組，位元組之間可有空白。奇數長度的半位元組、逗號、冒號、連字號及 0x 前綴都會被拒絕。
  • 文字模式在計算前會將字串編碼為 UTF-8。像 é 這樣的字元會貢獻兩個位元組，像 🚀 這樣的字元則貢獻四個，因此顯示的位元組數量可能會超過可見的字元數量。
  • 輸出永遠剛好是兩個小寫十六進位數字，低於 0x10 的值會自動補上前置零。

複製動作會完整保留所有內容：標籤、三個數值以及位元組數量會一起帶走，因此貼上的診斷註解能讓下一位讀者保留對應的解讀。

為何 XOR-8 BCC 不足以用於身分驗證

XOR-8 BCC 是錯誤偵測機制，而非身分驗證機制。它能在吵雜的線路上抓到一些意外的位元錯誤，運算速度快，程式碼也能塞進微控制器中，而這正是它適切的貢獻範圍。它無法做到下列事項，若將它當作具備這些功能，將是嚴重的誤用：

  • 它不是密碼學雜湊函式。兩個完全不同的訊息在結構上可以擁有相同的 BCC。
  • 它不是訊息驗證碼（MAC）。任何能傳送訊框的人，同樣也能傳送一個帶有合法 BCC 的訊框。
  • 它不是數位簽章。它沒有金鑰、沒有信任錨點，也沒有來源證明。
  • 它不是加密。酬載內容是明文。
  • 它無法授權指令。只檢查 BCC 的裝置，等於是以信任的方式接受了訊息。

對於憑證、軟體下載、指令授權或任何不受信任的網路流量，請使用該協定實際要求的安全機制。若協定指定的是 CRC-16、CRC-32、Fletcher、Adler、網際網路校驗和，或是具名的密碼學雜湊函式，那麼這個計算機就用錯了。它的價值在於透明重現兩個簡單的八位元公式，而非自動偵測協定。

當你需要不同的演算法時

如果裝置文件指定的是八位元 XOR 以外的演算法，或是加法式二補數 LRC 以外的演算法，計算機回傳的結果就不是你需要的值。下表列出最常見的替代方案，以及對應可處理這些方案的工具路徑。

文件指定的演算法為何 XOR-8 BCC 無法取代在哪裡計算
CRC-16（Modbus RTU、USB 等多種）使用 16 位元狀態的多項式除法，而非單一 XOR 位元組能指定多項式、初始值、反射與 XOR-out 參數的 CRC-16 計算機
CRC-32（ZIP、乙太網路、PNG）32 位元狀態、固定多項式，且輸入與輸出皆經反射標準 ISO-HDLC 變體請使用 CRC32 計算機
Fletcher-16 或 Adler-32使用兩個並行累加器，而非單位元組 XOR專用的 Fletcher 與 Adler 工具
網際網路校驗和（RFC 1071）跨 16 位元字組的 16 位元一補數總和能保留字組順序與位元組順序的網路協定工具
SHA-256 或其他密碼學雜湊函式需求本身就是密碼學強度如需真正的摘要，請使用 SHA256 雜湊產生器

每一列的模式都相同：先找出廠商文件所指定的精確演算法、寬度、初始值、涵蓋欄位、補數與位元組順序，再計算相符的公式。若想更深入地逐步演練 XOR-8 這條路徑本身，請參閱 BCC 校驗和逐步範例。特別是 Modbus 框架部分，官方 Modbus over Serial Line 規格 V1.02 就是精確定義 LRC 的參考依據。

若你正在權衡各種選項，如何為初學者計算 BCC 校驗和 一文對此有詳細說明。