一、类型对比总结

二、核心区别与选用原则

1. 字节类型（1 字节）

• 永远不要用char来存储原始字节，因为它的符号性是平台相关的。0x80可能变成-128，在比较和位运算中产生错误。

• 首选unsigned char或uint8_t或quint8，三者本质相同：

unsigned char byte1 = 0x80; // C 风格 uint8_t byte2 = 0x80; // 标准 C++ 风格 quint8 byte3 = 0x80; // Qt 风格

• 在纯 Qt 项目中用quint8风格一致；需要跨非 Qt 环境时用uint8_t

2. 双字节类型（16 位）

• unsigned short是 C++ 内建类型，标准只规定“至少 16 位”，但现代平台都是 16 位。Qt 的quint16就是unsigned short，并明确保证为 16 位。

• uint16_t是 C++11 标准类型，严格 16 位，无符号。在跨平台或非 Qt 代码中更安全。

• 工业协议中两者可互换，但建议统一风格：Qt 项目用quint16，通用代码用uint16_t。
  注意：不要混用unsigned short和uint16_t去接收同一个变量，因为理论上unsigned short可能大于16位（极少见），不过实践中没问题。

3. 字节容器

• QByteArray是字节流的理想容器，提供自动内存管理、拼接、索引、与 C 接口互操作的能力。

• 内部存储使用char*，但 Qt 承诺将其内容视为无符号字节，并提供constData()、data()等函数。读取单字节时强转成quint8或unsigned char以避免符号扩展：

• quint8 val = static_cast<quint8>(buffer.at(0));

三、工业协议中的黄金组合

下面是用这些类型构建一个“写浮点数”的典型流程（西门子 S7、Modbus 等场景）：

// 1. 原始数值 float realVal = ui->write_real_value->text().toFloat(); // 2. 位模式复制到32位无符号整数（平台字节序无关，只复制二进制） quint32 raw; std::memcpy(&raw, &realVal, sizeof raw); // 3. 手动将 raw 转为 4 字节大端，放入 payload QByteArray payload; payload.resize(4); // 高字节在前（大端） payload[0] = static_cast<char>((raw >> 24) & 0xFF); payload[1] = static_cast<char>((raw >> 16) & 0xFF); payload[2] = static_cast<char>((raw >> 8) & 0xFF); payload[3] = static_cast<char>( raw & 0xFF); // 4. 构造完整报文 QByteArray telegram; // 功能码（单字节，0x01 安全，不会出现符号问题） telegram.append(static_cast<char>(0x01)); // 起始地址 264 (0x0108) 手动拆成大端两字节 quint16 startAddr = 264; telegram.append(static_cast<char>((startAddr >> 8) & 0xFF)); // 高字节 0x01 telegram.append(static_cast<char>( startAddr & 0xFF)); // 低字节 0x08 // 追加浮点数据（已经是4字节大端） telegram.append(payload); // 后续计算校验、发送...

解析响应时同理：

// 假设 response 是从 PLC 收到的 QByteArray，offset 是浮点数据起始偏移 const unsigned char *ptr = reinterpret_cast<const unsigned char*>(response.constData()) + offset; // 1. 手动将两个 16 位寄存器从大端转为主机字节序 quint16 regHi = (static_cast<quint16>(ptr[0]) << 8) | ptr[1]; // 高16位 quint16 regLo = (static_cast<quint16>(ptr[2]) << 8) | ptr[3]; // 低16位 // 2. 组合成 32 位，注意 regHi 在高位 quint32 combined = (static_cast<quint32>(regHi) << 16) | regLo; // 3. 位模式复制回 float float result; std::memcpy(&result, &combined, sizeof result); /************************************************************************ quint16 regHi = (static_cast<quint16>(ptr[0]) << 8) | ptr[1]; // 高16位 quint16 regLo = (static_cast<quint16>(ptr[2]) << 8) | ptr[3]; // 低16位 1. 为什么不是“转换成 8 位”？ 工业协议中，一个 16 位寄存器本身就是 16 位的数据，本来就应该用 16 位类型承载。 从字节流解析的过程，就是从两个 8 位“原料”组装成一个 16 位“成品”，而不是把 16 位“压缩”成 8 位。 2. 整个思路 text 字节流: [ptr[0]] [ptr[1]] ← 两个 8 位 └─高8位─┘ └─低8位─┘ ↓ 拼接 regHi (16位) ptr[0] 贡献高 8 位，ptr[1] 贡献低 8 位，组合起来就是原本传输的 16 位寄存器值。这个值自然要存在 quint16 变量里，后续才能继续左移 16 位组合成 32 位浮点的位模式。 ************************************************************************/