校驗和是一個固定大小的數值，由接收端的裝置根據收到的位元組重新計算，並與傳送過來的校驗和進行比對，以偵測損壞的資料。若要為 Modbus ASCII 等串列通訊協定，或使用 XOR-8 的簡單框架封包計算校驗和，請將準確的酬載位元組逐一輸入會套用文件公式的工具。校驗和計算工具正好可以做到這一點：它會回傳明確的 XOR-8 BCC、Modbus ASCII 二次補數 LRC，以及單純的位元組總和模數 256，讓你能比對裝置手冊中指定的演算法，並複製標示的結果。
從簡單的微控制器 UART 到工業匯流排等串列通訊協定，都會在每個訊框末端附上幾個位元組，讓接收端能驗證訊息的其餘部分未被雜訊破壞。這些位元組並非密碼學雜湊——而是簡單的總和或 XOR，用來偵測位元翻轉與訊框截斷。對工程師與業餘玩家來說，難處在於不同家族的裝置會預期使用不同的公式：有些需要 XOR-8，有些需要 Modbus ASCII LRC，有些則規定原始位元組總和取模數 256。正確答案取決於規格書實際寫了什麼，而非搜尋引擎摘要出的內容。
此工具計算的三種校驗和
校驗和計算工具公開三種明確且定義清楚的演算法，讓你無需猜測就能選擇硬體所預期的演算法。
| 演算法 | 公式（白話說明） | 常見用途 |
|---|---|---|
| XOR-8 BCC（區塊檢查字元） | 從 0x00 開始，依序對每個酬載位元組做 XOR，僅保留低 8 位元。 | 許多微控制器的串列訊框、Modbus RTU 結尾欄位、通用 UART 通訊協定。 |
| Modbus ASCII LRC | 將位元組加總，保留低 8 位元，然後取二次補數（從 0x100 扣除，捨棄溢位）。 | Modbus ASCII 模式，在附加 CR LF 之前，會對 ASCII 十六進位的酬載計算 LRC。 |
| 位元組總和模數 256 | 將所有位元組相加，僅保留總和的低 8 位元。 | 自訂的工業通訊協定、舊系統中的簡易檔案完整性檢查。 |
Modbus LRC 本身記載於 Modbus Organization 的規格頁面上，而 XOR-8 BCC 的概念與許多通訊框架所用的基本完整性機制相同。了解你的通訊協定預期使用哪個公式，就完成了一半的工作。
選擇正確的輸入格式
在點任何按鈕之前，先決定你的通訊協定是將酬載描述為可列印文字（UTF-8），還是原始的十六進位位元組。此工具提供這兩種模式正是為了這個原因。
- UTF-8 文字模式適用於規格書將酬載以 ASCII 字元表示的情況，例如 "01 03 00 00 00 0A" 是 Modbus 查詢位元組的人類可讀十六進位表示法。
- 十六進位位元組模式適用於規格書將酬載描述為一連串位元組值的情況，例如 01 03 00 00 00 0A，此模式讓工具將每兩個十六進位數字視為一個位元組。
將兩者混用是最常見的錯誤。如果你的裝置手冊將酬載列為可列印字元，計算器就需要那些確切的字元；若列出的是原始位元組，則應直接貼上位元組值。若有疑慮，請先用一個已知的訊框，比較你的工具所產生的結果與手冊中的範例。
逐步計算校驗和
- 開啟 校驗和計算工具，並選擇符合你通訊協定的輸入模式：可列印酬載字串使用 UTF-8 文字，原始位元組序列使用 十六進位位元組。
- 依照傳輸時的順序，逐一輸入或貼上校驗和涵蓋的位元組，並省略規格書中規定應排除的訊框字元（Modbus ASCII 須停在最後一個資料位元組之前，不含 CR 與 LF）。
- 點擊計算。工具會並排回傳三個標示的值：XOR-8 BCC、Modbus ASCII LRC（兩位數十六進位位元組），以及位元組總和模數 256。
- 將每個回傳值與裝置文件中的公式進行比對。複製與你通訊協定指定的演算法相符的特定結果——不要從三個結果中挑最大或最小的。
- 依照通訊協定的規則，將選定的值附加至訊框：Modbus ASCII 預期在 CR LF 之前放置兩個 ASCII 十六進位字元；簡單的 XOR-8 通訊協定通常預期附加一個原始位元組。
- 在接收端上，對相同的位元組範圍重新計算相同的校驗和，並確認新值與你送出的位元組相符。若不相符，表示訊框已損毀，應予以捨棄。
XOR-8 BCC 的建構方式
XOR-8 BCC 是三者中最簡單的，值得親手演算一次。假設你的酬載位元組（以十六進位表示）為 01 03 00 00 00 0A。將累加器起始設為 0x00，並依序對每個位元組做 XOR，結果保持 8 位元寬度：
- 0x00 XOR 0x01 = 0x01
- 0x01 XOR 0x03 = 0x02
- 0x02 XOR 0x00 = 0x02
- 0x02 XOR 0x00 = 0x02
- 0x02 XOR 0x00 = 0x02
- 0x02 XOR 0x0A = 0x08
該六位元組酬載的 XOR-8 BCC 為 0x08。同一組輸入送進位元組總和模數 256 會得到 0x0E（總和 0x10E，低位元組 0x0E），而 Modbus LRC——即該低位元組的二次補數——則為 0xF2。如果你的規格書要求這三個數值中的任何一個，複製工具輸出中對應的欄位即可。親自驗證一次這類範例後，你將能立即辨識出哪個輸出對特定通訊協定而言是錯誤的。
為何工具對每個結果都明確標示
計算器只吐出「一個校驗值」是不夠的。同一組輸入依你使用的演算法不同，合理地會產生三個不同的位元組。這就是為什麼 校驗和計算工具 會在清楚的標籤下個別印出每個結果：XOR-8 BCC 欄位、Modbus ASCII LRC 欄位，以及位元組總和模數 256 欄位。標籤是工具輸出與你通訊協定文件之間的合約。在傳輸前，請將標籤與手冊中的公式比對，這樣就能消除「選對了數字卻用錯名稱」所導致的所有「校驗和錯誤」類型 bug。
會改變結果的常見訊框錯誤
串列通訊中的大多數校驗和錯誤並非數學錯誤——而是範圍錯誤。校驗和是根據訊框中明確定義的一段範圍計算出來的，而這段範圍不一定是整段可見的訊息。
- 把訊框字元包含進來。Modbus ASCII 訊框以歸位與換行字元結尾。這兩個位元組不屬於 LRC 計算範圍；把它們納入會得到與任何實際裝置都不相符的值。
- 位址位元組放錯位置而被包含進來。有些通訊協定是從起始定界符之後的第一個位元組開始計算校驗和；有些則是從位址開始計算。請閱讀規格書的虛擬碼，而非僅看文字描述。
- 跳脫字元後重複計算。訊框位元組被跳脫後，接收端必須根據未跳脫的酬載計算校驗和。如果你的酬載包含通訊協定的跳脫標記，請確認你交給計算器的是去跳脫後的位元組，而非線路上的原始位元組。
- 文字轉位元組的方式不正確。若你將 01030000000A 當作 ASCII 文字貼上，工具會將其視為 14 個字元的位元組；若你將同一字串當作十六進位對貼上，則視為 6 個位元組。請先在已知的正常參考訊框上確認輸入模式與位元組數。
校驗和適用與不適用的時機
校驗和刻意設計成容易碰撞：兩個不同的酬載可能共用同一個 XOR-8 值，接收端能偵測單位元錯誤但無法還原原始資料。這在容易發生位元遺失或翻轉的雜訊串列鏈路上正是你想要的。但在你需要密碼學完整性時，這就不夠了——此時應使用 SHA-256 之類的雜湊或 HMAC。在實際的串列除錯、傳輸期間的檔案完整性檢查，或為微控制器酬載建立快速健全性檢查時，計算器中的這三種演算法已涵蓋了絕大多數的通訊協定。若你為了幾個以上的位元組而手動計算這些值，請將酬載貼入工具並使用其標示好的結果。
若你的除錯工作還涉及線路上的 base-64 或十六進位編碼資料，將相關的轉換工具就近備用會很有幫助。Base64 轉十六進位轉換工具能將標準的 Base64 字串解碼為精確的十六進位位元組——當你的裝置酬載承載於 Base64 信封中時，校驗和計算工具預期接收的就是這個格式。對於將封包序列化為 ASCII 十六進位字串的通訊協定，十六進位轉文字轉換工具則提供相反方向的轉換，讓你無需手動解碼即可讀取錄製的訊框。這兩者與校驗和步驟搭配起來很自然，而且和計算器一樣完全在瀏覽器中執行。
相關主題：如何翻譯摩斯密碼 | 工具與方法。
若想更深入了解，請參閱如何計算 CRC-32 校驗和以確保資料完整性。