Java 的 String 类基于字符编码（如 UTF-8），无法无损表示任意二进制字节序列；当含负字节（如 0xF0）的 byte[] 被直接构造为 String 时，会因编码映射产生多字节替代序列，导致数据失真——应绕过 String，改用 byte[] 直接传递原始字节。
java 的 `string` 类基于字符编码（如 utf-8），无法无损表示任意二进制字节序列；当含负字节（如 `0xf0`）的 byte[] 被直接构造为 string 时，会因编码映射产生多字节替代序列，导致数据失真——应绕过 string，改用 `byte[]` 直接传递原始字节。
在与热敏打印机（如 Hengstler eXtendo X-56）等嵌入式设备通信时，常需发送包含控制命令（如 ESC/POS 指令）的原始二进制数据。典型指令如纸张切割命令 0x1B, 0xF0, 0x06, 0x01, 0x01，其中 0xF0 在 Java 中被解释为有符号字节 -16。若使用 new String(bytes) 构造字符串，JVM 会按默认字符集（如 UTF-8）尝试解码该字节序列：0xF0 单独不构成合法 UTF-8 字符，触发替换机制（通常转为 0xEF 0xBF 0xBD，即 `` 的 UTF-8 编码），造成原始字节被错误扩展为 3 个字节，最终发送给设备的数据完全失真。
根本原因在于：String 是语义化的文本抽象，不是二进制容器。Java 的 String 内部以 UTF-16 存储，构造时依赖字符集解码规则，无法保证 new String(bytes).getBytes() 与原 bytes 等价——这并非 Bug，而是设计使然。
✅ 正确做法是：避免将二进制命令塞入 String，直接操作 byte[]。尤其当底层 API（如 JNA 封装的 C 函数）实际接收 unsigned char* 时，应让 Java 层也保持字节原貌：
// ✅ 正确：直接使用 byte[] 传递原始指令
final byte[] cutCommand = {0x1B, (byte) 0xF0, 0x06, 0x01, 0x01};
int result = ExoAPI.INSTANCE.exo_api_printer_write(printerHandle, cutCommand, cutCommand.length, 5000L);对应 JNA 接口需修正为接收 byte[]（而非 String）：
立即学习“Java免费学习笔记（深入）”；
public interface ExoAPI extends Library {
ExoAPI INSTANCE = Native.load("ExoApi", ExoAPI.class);
// 关键修改：参数类型从 String → byte[]
int exo_api_printer_write(long printer, byte[] data, int size, long timeout_ms);
// 其他方法...
}⚠️ 注意事项：
- 切勿依赖 String.getBytes() 还原原始字节：即使指定 StandardCharsets.ISO_8859_1，也仅对 0x00–0xFF 映射有效，但 String 初始化阶段已因编码损坏原始数据，补救无效；
- *确认底层 C API 是否真正需要 `char**：unsigned char和char在内存布局上一致，JNA 的byte[]会自动映射为char*`，无需额外转换；
- 调试技巧：打印 byte[] 内容时，始终用 String.format("0x%02X", b & 0xFF) 避免符号混淆（如 -16 → 0xF0）；
- 扩展性考虑：若必须拼接文本与指令，可分别处理——文本转 byte[]（如 text.getBytes(StandardCharsets.US_ASCII)），再与指令 byte[] 合并，全程不经过 String。
总结：面向硬件协议的二进制通信，应坚守“字节即字节”原则。放弃用 String 承载控制指令的惯性思维，改用 byte[] 直驱底层接口，既符合语义契约，又杜绝编码陷阱——这是与打印机、扫码器、PLC 等设备可靠交互的关键实践。
