第4章浮点与布尔类型序列化

第4章：浮点与布尔类型序列化

好，咱们今天聊聊浮点和布尔类型的序列化。说实话，这两个类型看起来简单，但坑是真不少。我在做SOME/IP协议栈的时候，就因为在布尔类型上栽过跟头，排查了整整两天才找到原因。

4.1 float32/float64的IEEE754编码

先说说浮点数。SOME/IP里浮点数的序列化，说白了就是直接套用IEEE754标准。你可能会问，这有什么好讲的？直接把内存里的二进制拷贝过去不就行了？

嗯，理论上确实是这样。但实际项目中，我遇到过跨平台传输时浮点数精度丢失的问题。原因很简单——不同平台的字节序不一样。

核心要点：IEEE754标准定义了单精度(float32)和双精度(float64)的二进制表示格式。SOME/IP要求使用网络字节序（大端序）传输。

float32的格式是这样的：

1位符号位（S）
8位指数位（E），偏移127
23位尾数位（M）

float64呢，就是：

1位符号位（S）
11位指数位（E），偏移1023
52位尾数位（M）

举个例子，把3.14序列化成float32：

import struct

def serialize_float32(value):
    # 使用struct打包，'>'表示大端序
    packed = struct.pack('>f', value)
    return packed

# 测试
value = 3.14
packed = serialize_float32(value)
print(f"原始值: {value}")
print(f"序列化后: {packed.hex()}")
# 输出: 4048f5c3

# 反序列化
def deserialize_float32(data):
    return struct.unpack('>f', data)[0]

print(f"反序列化: {deserialize_float32(packed)}")
# 输出: 3.140000104904175

看到没？反序列化回来不是精确的3.14。这就是浮点数的本质——它就是个近似值。我在做ADAS（高级驾驶辅助系统）的传感器数据融合时，就因为这个精度问题，导致两个ECU对同一个障碍物的距离判断差了0.1米。你想想看，这在自动驾驶里可是要命的事。

我的建议：如果对精度要求极高，比如金融交易或精确控制，别用float32。用float64，或者干脆用定点数。我在车载项目中，对于车速、里程这类数据，就强制要求用float64。

4.2 布尔类型的序列化陷阱

布尔类型，看着最简单，对吧？不就是0和1吗？

错！大错特错！

SOME/IP规范里，布尔类型占1个字节。但问题来了——它到底怎么编码？

我查过多个SOME/IP实现，发现有两种做法：

实现方式	true编码	false编码	问题
严格模式	0x01	0x00	兼容性好
宽松模式	非0值	0x00	可能产生歧义

我曾经在一个项目中，A模块用严格模式，B模块用宽松模式。结果A发了一个true（0x01），B收到了，没问题。但B发了一个true（0xFF），A收到后直接报错——因为它只认0x01。

避坑指南：我曾经因为这个问题，在集成测试时被折腾得够呛。后来我定了个规矩：所有SOME/IP接口的布尔类型，必须严格遵循0x01/0x00编码。任何非0x01的值都视为非法。

来看看正确的序列化代码：

def serialize_boolean(value):
    if value:
        return b'\x01'
    else:
        return b'\x00'

def deserialize_boolean(data):
    if len(data) != 1:
        raise ValueError("布尔类型必须占1个字节")
    if data[0] == 0x01:
        return True
    elif data[0] == 0x00:
        return False
    else:
        # 严格模式：抛出异常
        raise ValueError(f"非法布尔值: 0x{data[0]:02x}")

# 测试
test_values = [True, False]
for v in test_values:
    packed = serialize_boolean(v)
    unpacked = deserialize_boolean(packed)
    print(f"{v} -> {packed.hex()} -> {unpacked}")

4.3 实战中的注意事项

好了，理论讲完了，说说实战中的坑。

第一个坑：字节对齐

SOME/IP里，float32要求4字节对齐，float64要求8字节对齐。如果你前面序列化了一个布尔类型（1字节），紧接着序列化float32，那就得补3个填充字节。

我见过一个新手写的代码，没做对齐处理，结果解析出来的浮点数全是错的。排查了半天，最后发现是偏移量算错了。

第二个坑：NaN和Infinity

IEEE754标准里定义了NaN（非数字）和Infinity（无穷大）。这些在SOME/IP里怎么处理？

我的做法是：序列化时直接按IEEE754编码，反序列化时检查是否是NaN或Infinity。如果是，根据业务逻辑决定是报错还是特殊处理。

import math

def safe_deserialize_float32(data):
    value = struct.unpack('>f', data)[0]
    if math.isnan(value):
        print("警告：反序列化得到NaN")
        # 根据业务决定返回什么
        return 0.0
    if math.isinf(value):
        print("警告：反序列化得到Infinity")
        return float('inf') if value > 0 else float('-inf')
    return value

个人经验：在车载网络中，我建议对NaN和Infinity做特殊处理。比如传感器故障时返回NaN，上层应用收到后就知道这个数据不可用，而不是用错误的数据做决策。

第三个坑：布尔数组

有些SOME/IP实现支持布尔数组。但注意，每个布尔元素还是占1个字节，不是按位压缩的。别想着省空间，SOME/IP不是为极致压缩设计的。

好了，这一章就讲到这里。浮点和布尔类型，看似简单，但细节决定成败。下一章我们聊聊字符串和数组的序列化，那才是真正考验功底的地方。

📚 课程目录