一、类型对比总结类型符号大小本质在工业协议中的角色char由实现定义通常有符号1 字节C 内建字符类型不推荐用于字节操作范围 –128 ~ 127存 ≥128 的值会溢出/符号扩展unsigned char无符号1 字节C 内建无符号字节类型单字节的首选类型0~255 无歧义uint8_t无符号1 字节C11 标准 8 位整型与unsigned char等价可跨非 Qt 项目quint8无符号1 字节Qt 的typedef unsigned char quint8Qt 项目中等同于unsigned char风格统一unsigned short无符号≥2 字节通常 2 字节C 内建无符号字节类型可与uint16_t混用但大小不完全保证严格 16 位uint16_t无符号2 字节C11 标准 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_t2. 双字节类型16 位unsigned short是 C 内建类型标准只规定“至少 16 位”但现代平台都是 16 位。Qt 的quint16就是unsigned short并明确保证为 16 位。uint16_t是 C11 标准类型严格 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_castquint8(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_castchar((raw 24) 0xFF); payload[1] static_castchar((raw 16) 0xFF); payload[2] static_castchar((raw 8) 0xFF); payload[3] static_castchar( raw 0xFF); // 4. 构造完整报文 QByteArray telegram; // 功能码单字节0x01 安全不会出现符号问题 telegram.append(static_castchar(0x01)); // 起始地址 264 (0x0108) 手动拆成大端两字节 quint16 startAddr 264; telegram.append(static_castchar((startAddr 8) 0xFF)); // 高字节 0x01 telegram.append(static_castchar( startAddr 0xFF)); // 低字节 0x08 // 追加浮点数据已经是4字节大端 telegram.append(payload); // 后续计算校验、发送...解析响应时同理// 假设 response 是从 PLC 收到的 QByteArrayoffset 是浮点数据起始偏移 const unsigned char *ptr reinterpret_castconst unsigned char*(response.constData()) offset; // 1. 手动将两个 16 位寄存器从大端转为主机字节序 quint16 regHi (static_castquint16(ptr[0]) 8) | ptr[1]; // 高16位 quint16 regLo (static_castquint16(ptr[2]) 8) | ptr[3]; // 低16位 // 2. 组合成 32 位注意 regHi 在高位 quint32 combined (static_castquint32(regHi) 16) | regLo; // 3. 位模式复制回 float float result; std::memcpy(result, combined, sizeof result); /************************************************************************ quint16 regHi (static_castquint16(ptr[0]) 8) | ptr[1]; // 高16位 quint16 regLo (static_castquint16(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 位浮点的位模式。 ************************************************************************/