現象復現
- 串口助手選 Hex 模式 → 顯示正常十六進制（如
0x01 0xA3 0xFF）。
- 選 ASCII 模式 → 顯示亂碼/不可見字符。
- 用工具把 Hex 轉 ASCII → 依然是亂碼。
根本原因：數據本質不是文本
傳感器輸出的是**原始二進制數據**（浮點數、結構體、壓縮格式等），**根本不是 ASCII 文本編碼**。
數學證明
- 1 字節 = 8 位 = 256 種取值 (0x00~0xFF)。
- ASCII 可打印字符僅 95 個 (0x20~0x7E)，佔比 **37%**。
- 隨機二進制數據落在可打印區間的概率極低，大部分落在控制字符區（0x00~0x1F, 0x7F）或擴展區（0x80~0xFF），顯示為亂碼/空白/。
正確處理流程
- 查閱傳感器協議文檔：確定數據幀結構（幀頭、長度、數據類型、校驗）。
- 按協議解析二進制：
// 例：小端序 float
float value = ByteBuffer.wrap(bytes, offset, 4).order(ByteOrder.LITTLE_ENDIAN).getFloat();
- 僅在協議明確指定「字符串字段」時，按指定編碼（ASCII/UTF-8/GBK）解碼該段字節。
常見誤區
- 以為「十六進制轉 ASCII」是萬能解碼器 —— 它只是把每個字節強行對應字符表，不代表原始語義。
- 忽略大小端序、浮點數格式（IEEE754）、定點數縮放因子。
拿到協議文檔，用結構體/ByteBuffer 解析二進制，才是工程師的正確姿勢！
