从物理量到CAN报文：Scale/Offset与字节序解析全攻略

1. 从物理量到CAN报文：先在脑子里把这条链路走通

上周调试控制器时，同事拿着抓包软件走过来，指着一帧十六进制报文问我：这帧数据是C2 5D 78 9E 7F 00 00 00，对应的物理量到底是多少？转速多少、温度多少、电压多少？这句话几乎是每个做CAN总线开发的人都会遇到的灵魂拷问。物理量如何变成CAN报文里的十六进制数？它并不是某一个魔法步骤，而是从传感器、ADC采样、Scale/Offset标定、位和字节排列，再到十六进制编码的一整套链路。这篇我打算把这条链路从头到尾拆开，配合可以直接复现的C语言和Python代码，让新手能照着算，让老手在处理"十六进制数怎么计算成float"这类问题时也有章可循。

搞懂这件事之前，先别纠结某一位是不是填反了，脑子里得有整条数据流的框架。一个物理量要进CAN总线，一般要经历五步：传感器把物理量变成模拟电压；ADC把模拟电压量化成一个有限精度的整数；协议设计者用Scale、Offset和位宽把物理量映射成协议允许的原始整数；原始整数转成十六进制并按字节顺序塞进CAN报文数据场；接收端按同样规则反算，把十六进制还原成物理量。第三步和第四步是绝大多数人卡住的地方——第三步是"约定"，第四步是"编码方式"。很多人拿着报文不知道怎么解析，就是因为不知道这个约定；如果是自己发一帧数据，又容易在进位、舍入、字节序上栽跟头。

1.1 链路全览：五个环节谁也躲不掉

CAN报文的经典数据场是8个字节，也就是64个bit。一帧里可以放一个信号，也可以按位切开放好几个信号，具体怎么切由DBC文件或者协议表说了算。拿我上面那个例子来说，一帧报文里其实放了三个信号：16位转速、8位温度、16位电压，剩下的字节是预留或填充零。接收到以后再把每个信号按位抠出来，套公式还原成有单位的数值。

所以"物理量变十六进制"这个动作，本质上是两件事：一是按公式把真实物理数值算成整数，二是把这个整数按照协议规定的位置和字节序摆进数据场。如果只做第一件事，值算对了也可能因为字节序搞反导致整车报错；如果只做第二件事，协议定错了或者舍入规则不一致，收发双方看到的物理量就会出现0.0几的漂移。这五步每一步都影响最终结果，缺一个都不行。

1.2 为什么CAN总线上跑的是整数而不是float

很多刚入门的同学会问：既然温度是25.5℃，直接把float塞进报文不就行了？当然可以塞，IEEE754标准下的float最终也是4个字节，CAN完全传得动。但绝大多数车载、工业控制协议都选择整数加Scale/Offset的方案，原因很实在。

第一是省位。一个float固定占32bit，而一个温度信号如果只要1℃精度、范围从-40到215℃，8bit无符号整数配合Offset=-40就够用了。同样一帧8字节数据，整数方案可以塞下好几个信号，float方案可能只能塞下两个，带宽利用率完全不同。第二是嵌入式端计算负担小。很多MCU没有硬件浮点单元，整数乘除法用几条指令就完事，float运算慢一个数量级。第三是协议可读性更好。DBC里写的是"0.125 rpm/bit""0.01 V/bit"，现场工程师拿计算器就能验算，没必要对着4字节浮点猜字节序。

我见过一些私有协议图省事，直接把float怼进CAN报文，结果解析端稍微写错一点字节序，数值就变成天文数字。其实float不是不能用，但要做好端序约定、对齐规则、特殊值处理，成本比整数方案高不少。这也是J1939、CANopen等主流应用层协议优先选择整数标定方案的原因。

1.3 十六进制只是"给电脑看的人肉友好格式"

聊到CAN报文，绕不开十六进制。为什么不用纯二进制写报文？因为二进制一长串0和1，人眼极难分辨。为什么不用十进制？因为计算机存储的最小单位是字节，而一个字节8bit刚好可以用两位十六进制数表示：从00到FF。比如0x5D就是二进制0101 1101，也是十进制93。CAN报文解析工具里默认用十六进制显示，本质上是把一个字节拆成两个"半字节"看，方便人对齐和检查位。

这里有一个基本功：看到十六进制要能快速估算它对应的量级。1字节最大0xFF是255；2字节最大0xFFFF是65535；3字节最大0xFFFFFF是16777215；4字节最大0xFFFFFFFF是4294967295。做CAN协议时，脑子里要有这张表，否则很容易出现"8bit信号塞了300这个数"的溢出事故。后面第3章我会用具体报文演示整个换算过程，先把链路走通，再谈细节。

2. 决定换算关系的三个铁律：Scale、Offset、位宽

CAN报文解析时，最核心的信息全在DBC文件里。一个信号通常写作这样：MotorSpeed : 0|16@1+ (0.125,0) [0|8000] "rpm"。这一行里包含了起始位0、长度16、字节序@1（Intel）、符号+（无符号）、Scale0.125、Offset0、物理范围0~8000 rpm。很多人只看数值，忽略了这个表达式的每一部分都是在给你规定换算规则。

换算公式并不难，但要分清楚方向。接收端解码时用的是：物理值 = 原始整数 × Scale + Offset。发送端编码时用的是反过来：原始整数 = (物理值 - Offset) / Scale。写代码时我习惯把原始单位叫Raw，把物理单位叫Physical，这样代码里一眼就能看出谁是协议值、谁是真实值，避免混用。

2.1 编码公式与解码公式，方向千万别搞反

常见的坑是拿着发送公式去解析报文。假设协议定义EngineSpeed = raw × 0.125，收到0x0E 0x50这种数据时，正确做法是先拼成0x0E50 = 3664，再乘0.125得到458 rpm。但如果你用反了，拿物理量458去乘0.125，得到57.25，那就完全错了。

所以我在写标定公式时，一定会写两行注释放在代码里：一行是Encode（物理量转Raw），一行是Decode（Raw转物理量），并且用实际数值验证一遍。这个习惯帮我排掉过很多低级错误。公式看起来简单，但在16进制、10进制之间来回切的时候，人的注意力稍一分散就会把分子分母搞反。

2.2 为什么温度要带Offset，电压就不带

Offset的存在是为了解决"协议里没有负数"的问题。CAN报文数据场通常按无符号整数解释，而温度、海拔这类物理量天生是负数。如果不想引入有符号补码，最简单的办法就是给信号加一个固定的偏移量，把所有负数都"整体抬高"到非负区间。

比如温度范围-40~215℃，我们用8bit无符号数表示，如果Offset=0，-40℃根本没法表示。于是协议把温度做成"存储值 = 温度 + 40"，收到0x78=120时，反算120 - 40 = 80℃。在DBC里这个Offset会被写成-40，公式是物理值 = raw × 1 + (-40)，看起来好像很奇怪，其实它表达的就是"存储值先经过一个-40的修正才是真实值"。电压、转速这类物理量通常不出现负数，所以Offset经常是0，新手容易忽略Offset，只在有符号负数场景下才想起它。

峰值提醒一句：不要为了省一个符号位就硬把负数塞进无符号字段，如果协议没定义Offset也没定义补码，那这帧报文就只能表示正数，电路稍一异常，采集到的负值就直接溢出变成巨大正数，排查起来非常头疼。

2.3 位宽决定表达范围，别把0xFFFFFFFF当自由世界

信号位宽直接决定原始整数能放到多大。8bit最大255，12bit最大4095，16bit最大65535，24bit最大16777215，32bit最大4294967295。这是无符号情况下的上限；如果协议定义成有符号，上限还要减半。

选位宽时要同时考虑范围和分辨率。举个例子，电压范围0~655.35V，如果分辨率要做到0.01V，那么一共需要65535个码值，16bit刚好够用；如果只给8bit，最多255个码值，分辨率最多只有655.35/255≈2.57V，这精度显然没法用。反过来，如果某信号只需要0~200，你却给它16bit，那高8位常年是0，浪费了宝贵的报文空间，还会让DBC文件里出现一堆没有任何意义的空余位。

我建议在协议设计阶段就把这张表贴在电脑旁边：

算位宽时，永远按"最大物理值/Scale + 1"来反推最小位数。比如最大转速8000rpm，Scale=0.125，那最大Raw就是64000，16bit刚好兜得住；如果Scale改成0.5，最大Raw就是16000，也可以；如果改成0.01，最大Raw变成800000，16bit就爆了，得用32bit或者调整协议。

2.4 字节顺序：Intel还是Motorola，错了就全乱

同样的0x5DC2，在Intel（小端）和Motorola（大端）格式下的线上字节顺序完全不同。Intel格式下，低字节在前：C2 5D；Motorola格式下，高字节在前：5D C2。如果接收端用错字节序，0x5DC2会被解析成0xC25D，物理量直接变成原来的几倍甚至几十倍，这一看就是典型的字节序错误。

DBC里@1表示Intel，@0表示Motorola。很多初学者以为Motorola只是简单地把两个字节交换，其实对于跨字节、跨位的信号，Motorola的位编号规则会和直觉完全相反。Motorola格式里的起始位通常指信号的最高有效位，而Intel格式里的起始位通常指最低有效位，两者在CANdb++这类工具里画出来的位序图也不一样。遇到不按字节对齐的Motorola信号，我强烈建议别手工拼位，直接用工具生成代码或者用解析库处理，否则非常容易在"看起来对、实际差一个位"的泥潭里折腾半天。

3. 一个真实报文实例：从转速到0x5DC2的完整实操

理论说再多，不如拿一个实际报文算一遍。假设某个电机控制器的DBC定义了三路信号：

BO_ 180 MotorData: 8 ECU SG_ MotorSpeed : 0|16@1+ (0.125,0) [0|8000] "rpm" ECU SG_ MotorTemp : 16|8@1+ (1,-40) [-40|215] "degC" ECU SG_ BatteryVolt : 24|16@1+ (0.01,0) [0|655.35] "V" ECU

这个DBC表达的意思非常简单：MotorSpeed从第0位开始，用16bit，Intel字节序，无符号，每1个Raw对应0.125rpm，偏移0；MotorTemp从第16位开始，用8bit，每1个Raw对应1℃，偏移-40；BatteryVolt从第24位开始，用16bit，每1个Raw对应0.01V，偏移0。

现在假设当前真实物理量是：转速3000.25rpm，温度80℃，电压326.70V。我们要把这组物理量变成一帧CAN报文。

3.1 先按公式算原始整数

先算MotorSpeed。因为Offset=0，Raw = 3000.25 / 0.125 = 24002。这里要注意，虽然结果是整数，但很多浮点上算出来的东西并不总是那么干净，尤其在不同语言、不同编译器下，3000.25 / 0.125可能算出24001.999999，直接强转成整数就变成24001了，白白丢掉一个LSB。所以编码时我会统一加四舍五入再取整：(3000.25 / 0.125 + 0.5f)，最后强转。

24002转成十六进制是0x5DC2，二进制是0101 1101 1100 0010。Intel格式下低字节在前，所以第0字节放0xC2，第1字节放0x5D。

再算MotorTemp。因为Offset=-40，Raw = (80 - (-40)) / 1 = 120。120转十六进制是0x78，只占8bit，放在第2字节。

最后算BatteryVolt。Raw = 326.70 / 0.01 = 32670，转十六进制是0x7F9E。Intel格式下低字节在前，放在第3字节的是0x9E，第4字节是0x7F。

这样一帧8字节报文就拼出来了：C2 5D 78 9E 7F 00 00 00。这就是我文章开头让同事犯晕的那帧数据，现在它已经有了明确物理意义。

3.2 逐字节打包：用C语言实现可靠发送

在实际嵌入式代码里，我通常用结构体指针直接操作uint8_t data[8]数组，把每个信号按位填进去。下面的代码专门针对上面这个DBC定义：

#include <stdint.h> typedef struct { uint8_t data[8]; } CanFrame; void motor_data_encode(CanFrame *f, float speed_rpm, float temp_c, float volt_v) { uint16_t speed_raw = (uint16_t)((speed_rpm - 0.0f) / 0.125f + 0.5f); uint8_t temp_raw = (uint8_t) (((temp_c - (-40.0f)) / 1.0f) + 0.5f); uint16_t volt_raw = (uint16_t)((volt_v - 0.0f) / 0.01f + 0.5f); f->data[0] = speed_raw & 0xFF; f->data[1] = (speed_raw >> 8) & 0xFF; f->data[2] = temp_raw; f->data[3] = volt_raw & 0xFF; f->data[4] = (volt_raw >> 8) & 0xFF; f->data[5] = 0; f->data[6] = 0; f->data[7] = 0; }

这段代码的关键在于理解& 0xFF和>> 8的作用。speed_raw & 0xFF是取低字节，(speed_raw >> 8) & 0xFF是取高字节。因为CAN报文数据场是字节数组，我们必须把16bit整数拆成两个8bit往里填。看到data[0]放低字节、data[1]放高字节，就实现了一个标准的Intel小端存放。

温度那行因为只有8bit，直接赋值即可。+0.5f的作用是四舍五入，而不是截断。这是我在实际项目中反复强调的点：嵌入式平台上的浮点转整型，默认是向零截断的，9.9999f转成int就是9，不是10。加0.5能保证大多数情况下的舍入正确，但如果你需要严格四舍五入，建议用C99的roundf()再转换。

3.3 收到报文怎么反向解析：用Python快速还原

拿到一帧报文，第一件事是什么？先看DBC，确认每路信号的起始位、长度、字节序和Scale/Offset。没有DBC就开始解析，等于盲人摸象。以刚才的C2 5D 78 9E 7F 00 00 00为例，解析代码极简单：

frame = bytes.fromhex("C2 5D 78 9E 7F 00 00 00") speed_raw = frame[0] | (frame[1] << 8) speed = speed_raw * 0.125 print("MotorSpeed:", speed_raw, speed, "rpm") temp_raw = frame[2] temp = temp_raw * 1 + (-40) print("MotorTemp:", temp_raw, temp, "degC") volt_raw = frame[3] | (frame[4] << 8) volt = volt_raw * 0.01 print("BatteryVolt:", volt_raw, volt, "V")

运行结果应该是MotorSpeed = 24002 × 0.125 = 3000.25rpm，MotorTemp = 80℃，BatteryVolt = 326.70V。整个解析过程就是编码的逆过程：从字节数组拼整数，再乘Scale加Offset。

这里要注意Python里的frame[1] << 8会让整数变成十进制，再和frame[0]按位或即可。如果报文里是Motorola格式，拼接顺序要反过来，写成frame[0] << 8 | frame[1]。我看到过太多人把Python当成万能工具，却没有先问自己一句：DBC里写的到底是@1还是@0？这个顺序错了，后面全白算。

3.4 十六进制怎么计算成float：遇到IEEE754也别慌

有些协议的某些信号确实会直接传IEEE754的float，比如一些基于CANopen的设备对象字典。遇到这种需求，首先要确认协议文档里规定的字节序，然后按这个顺序把4字节拼成一个uint32_t，再把它按位解释成float。这里的"按位解释"不是强转，而是用memcpy或者联合体，避免违反严格别名规则。

先说一个经典例子：物理量5.0，IEEE754单精度浮点表示是0x40A00000。如果协议规定大端传输，线上看到的是40 A0 00 00；如果协议规定小端传输，线上看到的是00 00 A0 40。看到40 A0 00 00想还原成float，最稳的是直接用struct模块：

import struct data = bytes.fromhex("40 A0 00 00") value = struct.unpack('>f', data)[0] print(value) # 5.0

C语言里我常用这种方式：

uint32_t raw = ((uint32_t)data[0] << 24) | ((uint32_t)data[1] << 16) | ((uint32_t)data[2] << 8) | ((uint32_t)data[3]); float value; memcpy(&value, &raw, sizeof(value));

注意，大端拼接时第一个字节放最高位，小端拼接时第一个字节放最低位。如果只调换一两个字节的位置，结果可能是一个完全错误但看起来"很有规律"的数，比如20.0变成2.8e-44这种极小的数。我调试过一个传感器，上位机一直显示0.00001这样的值，后来发现是协议文档写着大端，但某个固件版本按小端发送，两边各信各的，导致尾数完全不对。排查这类问题，最直接的办法是拿一个已知物理量（比如5.0V标准电压源）灌进去，抓一帧原始报文，反推字节序和字节内位序。

4. 常见问题与排查技巧实录

4.1 小数点左移时最右侧的1怎么处理？

这个问题在搜索引擎里经常出现，翻译成工程语言就是：物理量乘Scale变成整数时，被丢掉的小数部分怎么办？比如一个物理量12.1，Scale=0.125，那么Raw = 12.1 / 0.125 = 96.8。96.8转成整数，是96还是97？这个"最右侧的1"其实就是二进制小数点移动后遗留下来的量化尾数。

工程上必须有一个明确的舍入规则，否则发送端和接收端对不上。我的默认做法是四舍五入：先加0.5再截断。还是96.8这个例子，96.8 + 0.5 = 97.3，截断后是97。如果Scale是0.125这种2的负幂，本质上可以写成左移3位：Raw = (uint32_t)(物理量 × 8 + 0.5)。这样更直观：小数点左移三位后，原本二进制小数部分最右侧的"1"会被移进整数部分，如果还有残余位，就被舍入规则吃掉。

但要注意，四舍五入只适用于正数。如果物理量是负的，加0.5再截断会出错。我建议负值场景直接用roundf()，或者先用Offset把所有物理量抬到非负区间再做四舍五入，这样逻辑简单且不容易踩坑。最彻底的办法是协议设计阶段就把单位定成"最小精度"，比如0.01℃就存"百分之一摄氏度"这个整数，全程不碰float，也就根本没有"小数点左移时最右侧的1"这种烦恼。

4.2 负数到底怎么传：有符号补码还是加Offset

CAN报文里的字节本身没有正负概念，负数信号要么用有符号补码，要么用Offset抬升。两条路线各有优劣。Offset路线的好处是简单直观，比如温度-40℃存成0，0℃存成40，解析时统一减40，所有字节都按无符号处理。有符号补码路线的特点是协议少存一个Offset字段，原始值直接就是int8_t、int16_t，解析时按类型读取。J1939里不少温度、压力信号走的是Offset路线，而很多私有协议喜欢直接用有符号数。

这里的坑在于混用。如果一个协议文档既写了Offset=-40，又写了"信号为有符号"，那解码结果会和预期差出一大截。比如原始字节0xD8，按无符号加Offset算：216-40=176℃；按有符号补码算：-40-40=-80℃。两者完全是灾难性的差异。所以我拿到一个DBC或者协议表，第一件事就是把所有信号的符号、Offset、Scale列成一张清单，确认没有二义性后再写代码。

4.3 解析结果跳变、大得离谱，先查这四件事

解析出来的物理量各种异常，原因通常集中在四个方向。一是字节序错误：Motorola被当成Intel解析，数值会在低位和高位之间发生错位。二是位宽错误：16bit信号被按8bit截断，高位信息直接丢失，数值周期性跳变。三是符号错误：无符号字段里存了负数补码，或者有符号字段被当成无符号解析，结果出现负值突然跳到巨大正数。四是公式方向错误：该乘的除、该加的减，甚至Scale和Offset跟相邻信号搞混了。

排查时不要上来就在报文里翻来翻去。先构造一个已知物理量，比如用标准源灌入5.0V，或者让执行机构停在3000rpm，再抓一帧报文，看原始字节是否符合协议定义。抓住那帧已知报文后，用十六进制计算器和DBC里的公式一笔一笔验算，最多十分钟就能定位问题在哪一个环节。最怕的是用一堆未知报文去试解析算法，那等于在黑暗里找一个颜色出错的小数点。

4.4 手算与工具速查：5种方式快速换算

日常调试中我不可能永远开着计算器，下面这几个方法能快速完成"物理量和十六进制"之间的换算。一是Windows自带的计算器切到程序员模式，16进制、10进制互转非常方便。二是Linux终端直接跑printf "%X\n" 24002，立刻得到5DC2。三是Python里用hex(24002)/int('5DC2', 16)，适合批量验算。四是很多CAN上位机自带"信号解析"窗口，输入原始字节和Scale/Offset直接显示物理值，这个最为直观。五是Excel或者WPS里用HEX2DEC、DEC2HEX函数，适合离线整理一大批协议表。

最后分享两个我个人坚持的习惯。第一，任何Scale/Offset不为1或0的信号，我都会在代码里写一个自测用例：编码函数算出原始值，解码函数再还原物理量，两次误差应在精度范围内。第二，抓包工具里看到的十六进制报文最好直接以字节为单位显示，不要用"bit流"模式，否则人眼很容易被位编号绕晕。踩过几次坑之后，你会发现CAN报文解析其实没有太多高深理论，剩下的就是严谨、可复现的操作流程。