校驗位元是附加在訊框末端的一個位元組，讓接收端能偵測意外的資料損毀，而計算它的確切規則取決於該訊框所屬的通訊協定。對於 GST 類型的承載資料以及其他小型序列訊框，最常見的兩種單一位元組規則是 XOR-8 BCC，它從零開始將每個涵蓋的位元組摺疊進一個八位元的互斥或累加器，以及 Modbus ASCII LRC，它將涵蓋的位元組取 256 模數加總，然後再取結果的二補數。這兩種規則都刻意設計得很短，都會產生一個兩字元的十六進位輸出，而且都只能套用於目標規格所定義的位元組 —— 起始冒號或結尾 CRLF 這類框定字元的包含與否應依照裝置手冊決定，而非憑空猜測。由於「校驗和」這個詞在各家廠商文件中可能指上述任一種小型公式，選擇正確規則的安全做法是閱讀該協定的位元組配置，找出規格中指派給校驗值的位元組範圍，然後將同一段位元組範圍代入一個明確標示所實作公式的計算工具。這正是 校驗和計算機 所扮演的角色：它接受 UTF-8 文字或明確的十六進位位元組，針對同一輸入回傳三個帶有標籤的數值，並顯示位元組數量，讓你能確認自己所提供的位元組正是裝置所預期的那組。
哪一種校驗位元規則適用於 GST 訊框
「GST 中的校驗位元」這個說法在讀者之間有兩種重疊的意涵。在稅籍識別的脈絡下，GST 號碼本身帶有文件定義的字元規則，以及一個套用於最後一個字元的獨立模數驗證碼，本計算工具並不會計算這項。在裝置訊框的脈絡下，GST 類型承載資料通常指的是一則小型序列或匯流排訊息，會在末端附加一個位元組，讓接收端不需重新計算更複雜的內容就能拒絕損毀的封包。本文探討的是第二種情況：末端位元組由裝置手冊明確指定的單一位元組規則，根據其前面的承載資料所計算出的小型訊框。因此，第一步並非直接執行計算工具，而是先閱讀廠商的規格說明，找出哪些位元組屬於涵蓋範圍、規則從哪個初始值開始，以及框定字元是否納入計算。只有在釐清這三點之後，才有意義從校驗和計算工具所實作的三個公式中挑選一個，並套用於正確的位元組。
XOR-8 BCC：從零位元組到末端校驗位元
XOR-8 區塊檢查字元是兩種規則中較簡單的一種。它將一個八位元累加器從零開始，使用位元互斥或將每個涵蓋的位元組摺疊進去。由於 XOR 具交換律且不存在進位，位元組的順序並不影響結果，最終的累加器值也與承載資料如何切分無關。最終結果是一個以兩位小寫十六進位數字表示的單一位元組，該位元組會作為校驗位元附加於訊框末端。此慣例出現在多家廠商的通訊協定中，並在 BALTECH XOR-8 BCC 參考手冊 中明確定義為對選定位元組進行八位元 XOR 運算。其他廠商則可能將 BCC 一詞用於加總式校驗和、LRC、CRC，或用於訊框中不同部分的校驗和，因此單憑該詞本身不足以判斷裝置實際執行的是哪一條規則。在插入計算結果前請先確認文件說明，並記住 XOR-8 BCC 只能防範偶發的位元翻轉 —— 它存在許多碰撞，並非一種安全性基元。
Modbus ASCII LRC：二補數位元組加總
Modbus ASCII 縱向冗餘檢查是第二種常見的單一位元組規則。它將每個涵蓋的訊息位元組加總到一個八位元欄位中，捨棄從最高位溢出的進位，然後取最終加總的二補數。等價地說，結果就是位元組加總值的負數取 256 模數。官方的 Modbus 序列線規格排除起始冒號與結尾的歸位換行字元，不將它們納入計算的位元組中，而校驗和計算工具刻意不自動移除框定字元，以便由呼叫者精確控制涵蓋的位元組範圍。256 模數加總也會作為診斷用的中間值一併顯示，因為原始加總值與 LRC 在 256 模數下必定相加為零；同時並列顯示兩者，能更容易判斷裝置說明所期待的是加總值本身、其補數，還是其他慣例。請注意，工具標籤中的「Modbus」僅指這個特定的八位元規則 —— Modbus RTU 使用的是不同的 16 位元 CRC，並未在此計算。
如何使用工具計算校驗位元
以下步驟以一個具代表性的四位元組承載資料為例，展示三個帶標籤的數值各自如何產生。範例承載資料為四個位元組 0x01、0x03、0x00、0x0A —— 一段不含任何框定字元的簡短請求訊框。請以規格指定給涵蓋範圍的位元組取代範例，套用相同步驟處理你自己的承載資料。
- 開啟校驗和計算工具，並選擇與你的承載資料相符的輸入模式。若協定將訊框描述為一串位元組，請選擇十六進位位元組；若訊框被描述為字面字串且接收端解碼的是同一字串，則選擇 UTF-8 文字。
- 輸入裝置規格明確指派給涵蓋範圍的位元組。以本例而言，請輸入十六進位字串 01 03 00 0A —— 空白可有可無，每個位元組恰好兩位十六進位數字，而 0x 之類的前綴會被拒絕而非自行猜測。
- 執行計算。工具會回報三個數值加上位元組數量：XOR-8 BCC、Modbus ASCII LRC，以及 256 模數加總。針對 0x01 0x03 0x00 0x0A，加總為 1 + 3 + 0 + 10 = 14 = 0x0E，因此 256 模數位元組加總顯示為 0x0E。
- 讀取 XOR-8 BCC。累加器依序摺疊每個位元組：0x01 XOR 0x03 = 0x02，0x02 XOR 0x00 = 0x02，0x02 XOR 0x0A = 0x08，因此本例的 XOR-8 BCC 為 0x08。
- 讀取 Modbus ASCII LRC。對加總值取二補數：256 - 14 = 242 = 0xF2。你可以驗證此一致性特性，因為 0x0E + 0xF2 = 0x100，在 256 模數下為零。
- 將你所需要的帶標籤結果與裝置文件比對。若規格指定的是八位元 XOR 或 BCC，請使用 XOR-8 BCC；若規格指定 LRC 且排除冒號與 CRLF，請使用 Modbus ASCII LRC；而 256 模數加總可作為診斷中間值，用以確認廠商所指的是哪一種解讀。
- 將帶有標籤名稱的數值複製到訊框的末端位置，並保留工具所顯示的位元組數量，讓你的診斷註記能記錄產生該位元的精確位元組。
解讀三個帶標籤的十六進位數值
頁面上的每個結果皆以恰好兩位小寫十六進位數字呈現，當數值低於 0x10 時會包含前導零。位元組數量是輸入經 UTF-8 編碼或十六進位解析後的位元組數，而非可見字元數，因此一段非 ASCII 字串所顯示的位元組數量可能大於其字元長度。可複製的輸出包含標籤與位元組數量，讓貼上的診斷註記能保留產生該位元的解讀依據。下表整理了每個帶標籤數值的意義，以及它在訊框中通常插入的位置。
| 帶標籤的數值 | 公式 | 常見用途 | 插入位置 |
|---|---|---|---|
| XOR-8 BCC | 從 0 開始，對每個涵蓋位元組進行 8 位元 XOR | 明確指定八位元 XOR 或 BCC 的廠商協定 | 依裝置規格置於訊框最後一個位元組 |
| Modbus ASCII LRC | (位元組加總 mod 256) 的二補數 | Modbus ASCII 訊息，排除冒號與 CRLF | 訊框中結尾 CRLF 之前的一個位元組 |
| 256 模數加總 | 一般位元組加總的低八位元 | 用於驗證廠商期待哪種解讀的診斷中間值 | 不單獨傳送 |
當訊框使用其他演算法時
此工具刻意保持範圍狹窄，而這份狹窄正是它的安全特性。若你的規格指定的是 CRC-16、CRC-32、Fletcher、Adler、網際網路校驗和、特定的密碼雜湊函數，或是套用於英數識別碼的模數驗證碼，這三個帶標籤的數值都不會符合裝置的預期。以 GSTIN 類型的識別號碼為例，其最後一個字元使用獨立且由文件定義的字元規則，將該識別碼的 ASCII 位元組餵入本計算工具並無法重現該驗證碼。Modbus RTU 同樣如此，它使用的是 16 位元 CRC 而非八位元 LRC。當文件說明與三個帶標籤的公式皆不相符時，請改用具備該指定演算法的工具。關於 XOR-8 與 Modbus LRC 的獨立逐步說明有助於確認位元組範圍，而 32 位元的情況則可使用 CRC-32 計算工具。
限制、位元組數量與遭拒絕的輸入
本頁每次執行最多處理 500,000 個位元組，且絕不會悄悄截斷過長的輸入，因此過大的承載資料會產生錯誤而非誤導性的校驗位元。在十六進位模式下，每個位元組必須恰好兩位十六進位數字，位元組之間可有可無的空白，而 0x 前綴、逗號、冒號、連字號、奇數半位元組以及註解皆會直接遭到拒絕。在文字模式下，瀏覽器會先將字串以 UTF-8 編碼，這表示單一非 ASCII 字元可能貢獻多個位元組，顯示的位元組數量可能超過可見字元數。格式錯誤的十六進位輸入會產生明確錯誤且不輸出部分結果，因此帶標籤的輸出不可能悄悄出錯。這類單位元組校驗能偵測部分偶發變動，但並非密碼雜湊、訊息鑑別碼或來源證明，不應用於保護憑證、授權指令或驗證具敵意的網路流量。
若你正在權衡各種選項，如何計算電腦網路中的校驗和對此有詳細說明。