數值、單位與位元

同樣的 ff 為何是 255 或 -1？

使用工具

同一個位元組在兩份日誌中分別為 255 與 −1，未必是損壞。FF 表示八位元全為 1，卻不能單獨決定整數含義。固定位元寬度與符號條件，可區分資料改變與解讀規則改變。

同一位元串的三種表示

11111111 (binary)
ff (hexadecimal)
255 (unsigned decimal)

選寬度 8、無符號、基數 16、OR，輸入 FF 與 0。OR 0 保持位元串，得到十進位 255、二進位 11111111、十六進位 ff。基數 10 時 FF 無效，輸入進位也是解讀條件。

八位元無符號範圍是 0～255，256 需九位元。用整數範圍工具檢查寬度 8，可解釋越界錯誤。把 255 理解為 2⁸−1，比記特殊數字更容易推廣。

八位元二補數

255 − 256 = −1
11111111 → −1 (signed)
11111111 → 255 (unsigned)

改為有符號、十進位，八位元下輸入 −1 OR 0。十進位為 −1，無符號值仍為 255，位元串仍是 11111111。二補數高位為 1 時，從無符號值減 2ʷ，即 255−256；不是負號加大小 127。

八位元有符號接受 −128～127。十六進位 FF 作為數值是 255，因此預設拒絕策略下越界。截斷可明確保留低位再解讀，但那是單獨操作，不是切換符號後自動發生。

擴為十六位元時

0000000011111111 = 255
1111111111111111 = −1 (signed 16-bit)
NOT 0, unsigned 8-bit  → 255
NOT 0, unsigned 16-bit → 65535

十六位元有符號 00FF 高位為 0，仍是 255；−1 是 FFFF。擴大負數寬度需符號擴展，而非補零。協定中一位元組或兩位元組會影響含義，不只是顯示長度。

NOT 0 在寬度 8 得 255、寬度 16 得 65535。工具按所選寬度保留結果。與 JavaScript Number 等語言位元運算比較時，也要統一其隱含寬度。大整數支援不能替代固定寬度規則。

八位元 −2 右移一位

11111110 → 01111111 (logical)   = 127
11111110 → 11111111 (arithmetic) = −1

八位元有符號 −2 右移一位，邏輯右移補 0 得 127，算術右移保留符號得 −1。只說右移就是除二會忽略差異。應先確定處理位元串還是有符號算術。

256 截為八位元會留下 0，這是資訊流失，不是成功保留。拒絕策略用於阻止此情況。僅在格式明確要求回繞或低位時選擇截斷，不要調到結果看似合適為止。

記錄原文 FF、基數 16、寬度 8 與符號條件；多位元組還需按規範確認位元組順序。整數解讀一致不證明欄位邊界與位元組順序正確。統一條件後仍不同，再比較實際擷取資料。