區塊檢查字元 (BCC) 是所選訊框中每個位元組的 XOR-8,並以兩個小寫十六進位數字回傳;像 Checksum Calculator 這類本機瀏覽器工具,可在不將酬載傳送至遠端 API 的情況下,以同一輸入計算該值、Modbus ASCII 縱向冗餘檢查,以及原始位元組總和模數 256。工程師、整合商與韌體玩家經常搜尋「BCC 校驗和 API 替代方案」,因為他們現有的服務是按次收費、需要帳號、限制免費層級的呼叫次數、會記錄請求,或根本無法從隔絕網路的工站存取。一個在瀏覽器中執行的純 JavaScript 計算工具能完全消除這些疑慮:位元組從不離開頁面、不需要權杖,且計算過程可重現,公式會明確顯示在畫面上。代價是範圍。單一位元組 XOR 與加總式校驗和能捕捉偶發的單一位元翻轉,卻無法防範刻意竄改,而且並非每個使用「BCC」一詞的產品,實際上指的就是 XOR-8 形式。當你已確切知道裝置所預期的演算法,並想為診斷、回歸測試或手動核對廠商手冊取得快速、可確定、可直接複製貼上的結果時,選擇本機工具是正確的做法。
「BCC」在各通訊協定中的真正含義
縮寫 BCC 代表「block check character」(區塊檢查字元),是一個附加在訊框末端的單一位元組錯誤偵測值。以最明確的型態而言,XOR-8 BCC 從零開始,將通訊協定指定要涵蓋的每個位元組 XOR 進一個八位元累加器。XOR 具有交換性,沒有進位問題,且位元組順序不會影響結果。例如 BALTECH 參考手冊 便記載了多款讀取器產品所採用的正是這種八位元 XOR;同樣的概念也出現在工業硬體上許多 RS-232 與 RS-485 的訊框慣例中。
問題在於其他廠商使用「BCC」一詞時,可能代表不同的意義。有些是指截斷為一個位元組的加總式校驗和,有些是指加上二補數最終步驟的縱向冗餘檢查,也有些其實是指以別名稱呈現的 CRC。在動用任何計算工具之前,請先閱讀裝置規格,並釐清六項具體事項:輸入位元組表示方式 (ASCII 或二進位)、校驗和寬度 (一個位元組或多個)、演算法 (XOR、加總、CRC、Fletcher)、初始值、納入或排除哪些欄位,以及最終轉換 (不處理、補數或位元組交換)。一個把這些參數藏在籠統「校驗和」標籤背後的工具,並非文件化演算法的可靠替代品。
為何要以瀏覽器工具取代遠端 BCC API
託管式 BCC 校驗和 API 通常接收帶有十六進位或 base64 酬載的 JSON 主體,並回傳含結果的 JSON 物件。在後端運作時沒有問題,但在除錯工作階段、課堂練習與離線開發中會產生多項實務困擾:
- 網路相依性。任何連線中斷、強制登入頁面或沙箱限制都會讓查詢立即中斷。
- 按次計費與配額。部分業者將結果設為付費方案、節流免費帳號,或封鎖大型酬載。
- 隱私疑慮。工業酬載常含有裝置識別碼、儀表讀數或其他遙測資料,不宜外洩至網路之外。
- 不透明性。回應只是一個單一數字,並未留下實際執行了哪個公式的稽核軌跡。
瀏覽器端計算工具反轉了這些取捨。位元組由頁面上的 JavaScript 讀取並在本機處理,頁面會印出實際實作的公式、所消耗的位元組數,以及標示清楚的結果。缺點是你無法從其他應用程式驅動它,必須複製貼上,因此它是用於生產管線中真正的 API 時的補充,而不是取代。
如何在不呼叫 API 的情況下取得 XOR-8 BCC
- 在目前的桌面瀏覽器中開啟 Checksum Calculator。
- 挑選與裝置說明文件相符的輸入模式。當裝置送出 ASCII 命令字串時選擇 UTF-8 文字;若訊框以原始十六進位傳輸,則切換為十六進位位元組。
- 輸入校驗和所涵蓋的確切位元組。若為 Modbus ASCII 訊框,請排除起始冒號與結尾的 CRLF;若為 BALTECH BCC,則需排除手冊標示為訊框用途的起始、停止與同位位元組。除非規格明確說明,否請勿移除訊框字元。
- 執行計算。頁面會對三個值各回傳兩個小寫十六進位數字,以及實際消耗的總位元組數。
- 複製標明為 XOR-8 BCC 的值,並貼到裝置預期放置檢查字元的位置。若說明文件將該欄位標示為「LRC」或「總和」,則複製對應的標明值。
以 ASCII 位元組「ABC」 (0x41、0x42、0x43) 為例說明。XOR-8 公式從 0 開始,將 0x41 XOR 得出 0x41,接著 XOR 0x42 得出 0x03,再 XOR 0x43 得出 0x40,因此 BCC 為 0x40。同一輸入的位元組總和模數 256 為 0xC6,而 Modbus 二補數 LRC 為 0x3A。作為健全性檢查,0xC6 加上 0x3A 等於 0x100,也就是模數 256 下剛好為零,這正是 Modbus 規格所保證的代數關係。
三個值並列對照
| 標籤 | 公式 | 裝置預期此標籤的時機 |
|---|---|---|
| XOR-8 BCC | 從 0 開始,將每個位元組 XOR 進一個八位元累加器。 | 明確標示為「XOR-8」或「區塊檢查字元」且寬度為 8 位元的序列裝置與廠商手冊。 |
| Modbus ASCII LRC | 將位元組加總後取模數 256,再對低位元組取二補數。 | 輸入排除冒號與 CRLF 的 Modbus ASCII 訊框。 |
| 位元組總和模數 256 | 將位元組相加並保留低八位元。 | 診斷過程中的中間值;部分裝置會在進行任何補數步驟之前記錄其加總值。 |
同時顯示三個值能讓結果頁化身為對照表,只要快速讀取標籤,即可挑出目標裝置實際需要的值,而無需以不同演算法重新計算。
輸入規則:UTF-8 文字 vs 十六進位位元組
計算工具接受兩種模式的酬載,并嚴格進行解析。在文字模式下,字串會先編碼為 UTF-8,這代表一個可見字元若落在 ASCII 範圍之外,可能佔用兩個、三個或四個位元組。因此顯示的位元組數可能超過可見字元數,且計算工具不會隱藏這個差距。
在十六進位模式下,每個位元組必須以剛好兩個十六進位數字呈現,位元組之間可有空白。前綴如 0x、逗號、冒號、連字號、註解,以及奇數長度的半位元組皆會被拒絕而非猜測處理,頁面會回報剖析錯誤,而不是產出部分值。剖析器接受大小寫輸入,但輸出一律為小寫。
這些嚴格規則至關重要,因為手動計算 BCC 時最常見的錯誤就是把訊框字元一起送進 XOR。嚴格的十六進位剖析器強制輸入必須正好是通訊協定所涵蓋的位元組序列,而結果列上標明的位元組數,是在裝置拒收訊框之前,最易於抓出複製貼上錯誤的依據。
單位元組校驗和的限制與誠實邊界
XOR-8 與加總式校驗和可偵測部分偶發變動,但並非身分驗證、加密、訊息完整性碼、數位簽章或來源證明。它們存在大量碰撞:對任何目標位元組值而言,皆可刻意構造單一位元組編輯,使 XOR 或總和保持不變,這正是它們被搭配訊框、同位元與實體層檢查,而非單獨用於安全性的原因。
頁面強制設定每次計算 500,000 位元組的硬性上限,絕不會默默截斷輸入,因此超過上限的酬載會明確失敗,而不是產出誤導性的部分摘要。兩個十六進位數字的輸出會以前置零補齊,因此 0x07 會顯示為「07」而非「7」。複製輸出包含標籤、三個值與位元組數,因此貼上的診斷註記會保留計算時所選的解讀。
最後,當通訊協定指定 CRC-16、CRC-32、Fletcher、Adler、Internet 校驗和,或 SHA-256 等加密雜湊時,XOR-8 BCC 便是錯誤的工具。這些演算法具有更寬的欄位、不同的多項式,以及明確的初始與最終 XOR 常數,沒有一個與單位元組 XOR 相同。XOR-8 與 Modbus LRC 逐步解說 更深入地說明這些公式;BALTECH 參考資料則是明確八位元 XOR 的廠商端範例。
若想進一步了解,請參閱 計算 CRC32 校驗和並對應 8 個十六進位數字。