一、类型对比总结
| 类型 | 符号 | 大小 | 本质 | 在工业协议中的角色 |
|---|---|---|---|---|
char | 由实现定义（通常有符号） | 1 字节 | C++ 内建字符类型 | 不推荐用于字节操作，（范围 –128 ~ 127）存 ≥128 的值会溢出/符号扩展 |
unsigned char | 无符号 | 1 字节 | C++ 内建无符号字节类型 | 单字节的首选类型，0~255 无歧义 |
uint8_t | 无符号 | 1 字节 | C++11 标准 8 位整型 | 与unsigned char等价，可跨非 Qt 项目 |
quint8 | 无符号 | 1 字节 | Qt 的typedef unsigned char quint8 | Qt 项目中等同于 |
| unsigned short | 无符号 | ≥2 字节（通常 2 字节） | C++ 内建无符号字节类型 | 可与uint16_t混用，但大小不完全保证严格 16 位 |
uint16_t | 无符号 | 2 字节 | C++11 标准 16 位整型 | 存放 16 位寄存器值（Modbus、Profibus 等） |
quint16 | 无符号 | 2 字节 | Qt 的unsigned short(保证 16 位) | 同上，Qt 专用 |
QByteArray | 内部char，但逻辑无符号 | 动态 | Qt 字节数组容器 | 整个报文的承载者：拼接、存储、传输 |
二、核心区别与选用原则
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 位浮点的位模式。 ************************************************************************/