HJ212协议报文解析：Java解码、CRC16与粘包处理-北京尧图网络

简介面向环保监测系统开发者的HJ212协议Java解析实践包围绕《污染源在线自动监控监测系统数据传输标准》提供数据采集、编码解码与交互处理的参考实现适合需要对接污染源在线监测设备、处理XML/JSON报文或补充网络通信与异常处理思路的初中级Java工程师。压缩包共308个文件以197个class与100个java源文件为主体另含少量xml配置、properties属性文件及Eclipse工程描述文件整体约327KB工程结构完整便于直接调用解析类进行调试与二次开发。目前已有5083人学习下载。内容覆盖协议映射、数据层级反序列化、报文分段解析与转换等环节并配有JUnit测试与文档说明便于读者理解字段含义、验证解析结果、排查格式错误也可作为环保污染物数据接入模块的骨架参考。1. 一条##0256开头的报文引出 HJ212 解析的三个核心难点凌晨两点现场数采仪每五分钟往平台推一条以##开头的 ASCII 报文接收端日志却一直报“校验失败”。排查了一圈问题出在接收端拿String.length()当字节长度用并非设备故障。环保污染物在线监测对接里这类问题太常见了——HJ212 协议本身规则不多难的是要按通信协议去实现它不能只当成字符串来截取。这个 Java 解析项目的价值就在这儿把帧同步、CRC16、KV 数据段、CP 二级因子结构、应答与反控拆成独立模块可以直接嵌入 Spring Boot 采集服务也能单独拿来做报文回放。适合两类人正在做环保数采对接、被半包粘包和校验码反复困扰的 Java 后端以及要给多厂商设备做统一接入、需要按因子扩展的中间件开发。2. 协议骨架与工程分层把四段式报文拆成解码器加业务分发器先看一条完整报文长什么样。下面这条是示意CRC 用占位符代替实际是四位十六进制大写##0256QN20240115103000123;ST32;CN201;PW123456;MNDEV0001;Flag5;CPDataTime20240115103000;a01001-Rtd1.23,a01001-FlagNA1B2\r\n四个部分很清楚##包头、四位 ASCII 十进制长度、数据段、四位 CRC 加\r\n。长度指的是数据段的字节数既不含包头也不含 CRC 和换行。我见过不止一个实现把长度算成“数据段 CRC 换行”结果对端一直在读半条报文现象就是每个连接几秒后断开。2.1 报文四段式结构与各字段的真实含义数据段内部又分两层外层是;分隔的头部 KV内层是CP...包裹的命令参数。头部字段含义如下表这份表我基本是照着对接文档抄进代码注释的比记在脑子里靠谱字段含义落地时的注意点QN请求编号14 位时间戳加 3 位毫秒序列幂等键首选重发时不能变ST系统编码32 表示污染源在线监测固定值但别在代码里写死成常量比较CN命令编码101 实时、201 分钟、205 小时、206 日决定走哪个处理器PW访问密码平台侧下发时校验设备上传时一般是占位MN设备唯一标识和连接会话绑定别只信报文里的Flag标志位bit0 是否要求应答bit1 是否带包序号应答报文必须把 bit0 置 0PN包序号Flag 的 bit1 为 1 时才出现长报文分包重组用CP命令参数包裹因子数据都在这儿CP 里面还有一层结构;分组组内,分隔每个字段形如编码-属性值。比如a01001-Rtd1.23,a01001-FlagNRtd是实测值Flag是数据标记N 正常、D 故障、M 维护、T 超时。把这两层拆错后面所有统计都会变成错误数据。提示命令编码和因子编码各版本标准与地方平台存在差异编码表一律外置成配置不要写死在switch里。2.2 我在项目里用的五层目录结构分层目标很明确解码层只负责把字节流变成消息对象业务层只认消息对象两边靠一个Hj212Message解耦。这样换 Netty 还是换ServerSocket业务代码一行不用动。com.example.hj212 ├── codec/ Hj212FrameDecoder / Hj212Encoder / Hj212Crc16 / Hj212SegmentParser ├── model/ Hj212Message / Hj212Command / Hj212Ack / FactorGroup ├── server/ Hj212Server / Hj212ChannelHandler连接、会话、心跳 ├── dispatch/ MessageDispatcher handler/ 下按 CN 拆的处理器 └── support/ FactorDict因子字典、ChannelRegistry连接注册表层职责不该做的事codec帧同步、长度校验、CRC、KV 拆分不碰数据库、不认业务字段model承载解析结果提供取数接口不放解析逻辑server连接管理、会话与设备映射不写业务分支dispatch按 CN 路由到处理器不做协议级校验support字典、缓存、工具不反向依赖 dispatch这张表看着像八股但它解决的是实际问题新人接手时最容易犯的错就是在一个String.split(;)里顺手查一下数据库然后解码器线程被慢 SQL 卡住整条连接的报文全积压。2.3 为什么不用LengthFieldBasedFrameDecoderNetty 自带长度域解码器很多协议直接就能套。HJ212 却不适用它的长度域是四位 ASCII 十进制字符并非二进制整数lengthFieldLength只能按字节数读而且长度域前面还有##两个字节的魔数尾部还有 4 字节 CRC 和 2 字节\r\n。lengthAdjustment能补偿尾部偏移但没法把0..9转成数值。更麻烦的是现场的脏数据设备重连时会补发缓存报文流里可能出现半个包、双包头、甚至一段乱码后跟正常包。所以必须自己写解码器好处是可以在里面直接做“找包头、校验长度合理性、丢弃超长段”这些容错动作否则一条脏数据就能把整条连接搞挂。3. 解码核心从字节流到Hj212Message的完整链路这一章是整套代码里最值得抄的部分。四个步骤拆帧、拆字段、校验、组包。每一步我都给出可运行的实现和参数说明照着改基本能直接上。3.1 粘包处理Hj212FrameDecoder逐段拆TCP 是字节流一次read拿到半条报文是常态。解码器用累积缓冲只有凑够“长度域声明的总长”才往外抛一个完整帧剩下的留在缓冲里等下一次。public class Hj212FrameDecoder extends ByteToMessageDecoder { private static final int HEAD_LEN 2; // ## private static final int LEN_FIELD 4; // 四位 ASCII 长度 private static final int CRC_LEN 4; private static final int TAIL_LEN 2; // \r\n private static final int MAX_SEGMENT 8192; // 单条数据段上限防脏数据撑爆内存 Override protected void decode(ChannelHandlerContext ctx, ByteBuf in, ListObject out) { while (true) { int offset findHead(in); if (offset 0) { in.skipBytes(in.readableBytes()); // 没有包头整段丢弃 return; } if (offset 0) { in.skipBytes(offset); // 丢掉包头之前的垃圾数据 } if (in.readableBytes() HEAD_LEN LEN_FIELD) { return; // 长度域还没收全 } int segLen 0; boolean valid true; for (int i 0; i LEN_FIELD; i) { byte b in.getByte(in.readerIndex() HEAD_LEN i); if (b 0 || b 9) { valid false; break; } segLen segLen * 10 (b - 0); } if (!valid || segLen 0 || segLen MAX_SEGMENT) { in.skipBytes(HEAD_LEN); // 长度域非法跳过这个假包头继续找 continue; } int total HEAD_LEN LEN_FIELD segLen CRC_LEN TAIL_LEN; if (in.readableBytes() total) { return; // 半包等下次数据 } int base in.readerIndex() HEAD_LEN LEN_FIELD; byte[] body new byte[segLen]; in.getBytes(base, body); byte[] crc new byte[CRC_LEN]; in.getBytes(base segLen, crc); in.skipBytes(total); // 整帧消费掉 out.add(new Hj212Frame( new String(body, StandardCharsets.US_ASCII), new String(crc, StandardCharsets.US_ASCII))); } } private int findHead(ByteBuf in) { for (int i in.readerIndex(); i in.writerIndex() - 1; i) { if (in.getByte(i) # in.getByte(i 1) #) { return i - in.readerIndex(); } } return -1; } }几个参数得说清楚。MAX_SEGMENT是保护阈值正常一条分钟数据报文也就几百字节超过 8K 基本可以判定为错位或攻击流量直接跳包头重扫。findHead里writerIndex() - 1是必要的边界否则读到缓冲区最后一个字节会越界。skipBytes(total)必须在取出 body 和 crc 之后调用顺序反了就会读到下一帧。另外这里用getBytes而非readBytes是为了在确定整帧完整之后再推进读指针避免半包时把数据读走却没抛出对象。3.2 数据段 KV 解析与 CP 段二级结构帧拆出来以后是纯字符串接下来两层拆分。外层按;拆头部字段内层把之间的内容按;分组、再按,拆字段、最后按-拆因子编码和属性名。public final class Hj212SegmentParser { /** 解析去掉长度域和 CRC 之后的数据段 */ public static Hj212Message parse(String segment) { Hj212Message msg new Hj212Message(); int cpIdx segment.indexOf(CP); String head cpIdx 0 ? segment : segment.substring(0, cpIdx); for (String kv : head.split(;)) { int eq kv.indexOf(); if (eq 0) continue; msg.putHeader(kv.substring(0, eq).trim(), kv.substring(eq 1).trim()); } if (cpIdx 0) { int end segment.lastIndexOf(); if (end cpIdx) { msg.setCpRaw(segment.substring(cpIdx 5, end)); } } return msg; } /** CP 内部分号分组、逗号拆字段、减号拆因子编码与属性 */ public static MapString, MapString, String parseCp(String cpRaw) { MapString, MapString, String factors new LinkedHashMap(); if (cpRaw null || cpRaw.isEmpty()) return factors; for (String item : cpRaw.split(;)) { if (item.isEmpty()) continue; for (String part : item.split(,)) { int eq part.indexOf(); if (eq 0) continue; String key part.substring(0, eq).trim(); // a01001-Rtd String val part.substring(eq 1).trim(); int dash key.indexOf(-); if (dash 0) { String code key.substring(0, dash); // a01001 String attr key.substring(dash 1); // Rtd / Flag / Avg factors.computeIfAbsent(code, k - new LinkedHashMap()).put(attr, val); } else { // DataTime 这类顶层字段统一挂在 _global 下 factors.computeIfAbsent(_global, k - new LinkedHashMap()).put(key, val); } } } return factors; } /** 组装成业务对象一条记录对应一个因子 */ public static ListFactorValue toFactorValues(Hj212Message msg) { MapString, MapString, String cp parseCp(msg.getCpRaw()); String dataTime cp.getOrDefault(_global, Map.of()).get(DataTime); ListFactorValue list new ArrayList(); for (Map.EntryString, MapString, String e : cp.entrySet()) { if (_global.equals(e.getKey())) continue; MapString, String attrs e.getValue(); FactorValue fv new FactorValue(); fv.setCode(e.getKey()); fv.setDataTime(dataTime); fv.setValue(parseDecimal(attrs.get(Rtd))); fv.setFlag(attrs.getOrDefault(Flag, N)); list.add(fv); } return list; } private static BigDecimal parseDecimal(String s) { if (s null || s.isEmpty()) return null; try { return new BigDecimal(s); } catch (NumberFormatException ex) { return null; // 现场确实出现过 1.2.3 这种脏值 } } }这里有两个设计取舍。第一_global这个伪因子是为了放DataTime、Flag这类不属于任何因子的顶层字段用独立容器虽然不优雅但比在方法签名里再加一个出参清楚多了。第二parseDecimal捕获异常返回 null 而不是抛出去因为一条报文里某个因子脏了不应该让整条报文作废——但必须在日志里打一行 warn否则数据丢了都不知道。LinkedHashMap的选型也不是随手写的保持报文原始顺序在做报文回放比对时非常有用。3.3 CRC16 校验0xA001与那个容易被取反的坑HJ212 用的是 CRC16多项式0xA001初值0xFFFF结果四位十六进制大写。下面是最常见的实现public final class Hj212Crc16 { private static final int POLY 0xA001; private static final int INIT 0xFFFF; /** 入参必须是数据段原文不含 ##长度、不含 CRC、不含换行 */ public static String of(String segment) { int crc INIT; for (byte b : segment.getBytes(StandardCharsets.US_ASCII)) { crc ^ (b 0xFF); for (int i 0; i 8; i) { if ((crc 0x0001) 1) { crc 1; crc ^ POLY; } else { crc 1; } } } return String.format(%04X, crc 0xFFFF); } public static boolean verify(String segment, String crcFromFrame) { return of(segment).equalsIgnoreCase(crcFromFrame); } }参数只有一个数据段字符串。三个容易错的地方——入参范围、编码、输出格式。入参必须是数据段本身多算或少算一个字符结果全变##0256和\r\n都不能包含在内。编码必须统一用US_ASCII用平台默认编码在某些容器镜像里会得到不同字节。输出用%04X保证大写加前导零Integer.toHexString会丢掉前导零四位变三位对端直接判错。至于取反网上流传的版本里有的在最后做了一次按位取反我踩过这个坑——用平台侧一条能正常入库的历史报文做基准两种写法各跑一遍谁的输出和报文尾部的校验码一致就用谁别猜。这也是我在项目里固定放两条基准报文当单测用例的原因。3.4 组包发送长度域、编码与换行符接收和发送共用一套结构组包就是把上面反过来做一遍。顺序必须是拼数据段 → 算字节长度 → 拼 CRC → 补\r\n一步都不能提前。public final class Hj212Encoder { public static String pack(LinkedHashMapString, String headers, String cpRaw) { StringBuilder seg new StringBuilder(); headers.forEach((k, v) - seg.append(k).append().append(v).append(;)); if (cpRaw ! null !cpRaw.isEmpty()) { seg.append(CP).append(cpRaw).append(); } String body seg.toString(); // 长度是字节数不是字符数body.length() 在纯 ASCII 下才等价 int len body.getBytes(StandardCharsets.US_ASCII).length; if (len 9999) { throw new IllegalArgumentException(数据段超过 9999 字节需按 PN 分包: len); } return ## String.format(%04d, len) body Hj212Crc16.of(body) \r\n; } }headers用LinkedHashMap是硬性要求字段顺序虽然协议上没强制但部分平台做了字符串级别的比对和去重顺序乱跳会让对端把同一条数据当两条。len 9999抛异常而不是截断是因为长度域只有四位超了必须走PN包序号分包静默截断等于发了一条错的报文出去。CP前面那个;是我特意保留的——头部最后一个字段后面本来就有分号忘了加会导致 CP 段和上一个字段粘在一起接收端解析出个MNDEV0001CP排查起来非常费劲。4. 应答与反控Flag 位、QnRtn和一次完整的双向对话单向解析只能算看懂了协议的一半。真正上线跑起来必须有应答否则设备侧超时会重发一条数据在平台上出现三五次统计报表直接失真。4.1 应答报文怎么拼应答的核心是三点CN保持不变、Flag的 bit0 置 0、CP里带执行结果。QnRtn的取值按对接文档来常见 1 表示成功。public final class Hj212AckBuilder { /** 对收到的报文做应答req 为原始请求消息 */ public static String ack(Hj212Message req, int qnRtn) { LinkedHashMapString, String headers new LinkedHashMap(); headers.put(QN, Hj212Time.nowQn()); // 新的时间戳不能复用请求的 QN headers.put(ST, req.getHeader(ST)); headers.put(CN, req.getHeader(CN)); // 命令编码保持一致 headers.put(PW, req.getHeader(PW)); headers.put(MN, req.getHeader(MN)); headers.put(Flag, 0); // 关键bit0 置 0不再要求对方应答 return Hj212Encoder.pack(headers, QnRtn qnRtn); } }Flag0这一行是整个方法里最重要的。如果偷懒把请求里的Flag5原样带回来对方会认为这也是一条需要应答的报文于是再回一条两边无限对发几分钟就能把连接打满。这个错误我见过两次都是复制粘贴请求头造成的。QN必须重新生成虽然标准没明说但部分平台用QN做去重复用会让应答被当成重复包丢掉。4.2 平台下发反控命令的组包平台侧下发的命令PN包序号和超时重发要一起考虑。命令编码各版本标准有差异以对接文档为准这里用常见的提取实时数据命令说明结构public String buildFetchCommand(String mn, String pw, ListString polIds) { LinkedHashMapString, String headers new LinkedHashMap(); headers.put(QN, Hj212Time.nowQn()); headers.put(ST, 32); headers.put(CN, 3011); // 反控命令编码按对接文档确认 headers.put(PW, pw); headers.put(MN, mn); headers.put(Flag, 5); // bit01 要求应答bit10 不带包序号 headers.put(PN, 1); // 若 Flag 的 bit1 置 1 则必须带 String cp PolId String.join(,, polIds); return Hj212Encoder.pack(headers, cp); }注意Flag和PN的联动PN只在 bit1 置 1 时有意义如果Flag1却带了PN有些解析器会直接判为非法字段。我一般在配置里把Flag做成可配项不同平台要求不一样硬编码迟早要改。4.3 重发、幂等与超时设备侧没收到应答就会重发所以接收端必须幂等。幂等键用MN QNMN定位设备QN定位这一次请求两者组合在时间窗口内唯一。Component public class IdempotentGuard { // 只保留最近 10 分钟的 QN避免内存无限增长 private final CacheString, Boolean seen Caffeine.newBuilder() .expireAfterWrite(Duration.ofMinutes(10)) .maximumSize(200_000) .build(); public boolean firstTime(Hj212Message msg) { String key msg.getHeader(MN) | msg.getHeader(QN); return seen.asMap().putIfAbsent(key, Boolean.TRUE) null; } }超时时间设多少取决于现场网络。经验值是 15 到 30 秒太短会在弱网环境触发大量重发太长则设备侧缓存堆积。重发次数超过 3 次还没收到应答就该打告警了——一般不是网络问题而是对方平台进程挂了或者密码错了。5. 上线后的五类翻车HJ212 排查清单5.1 排查第一步把原始字节留下来所有排查的前提是能看到原始报文。我的做法是在解码器最前面挂一个LoggingHandler把入站字节按十六进制和 ASCII 两种形式写进按天滚动的文件同时线上只打前 200 字节的摘要。这个日志看着占空间但没有它你说的“收到了但解析失败”就永远停在猜的阶段。有了它对端说没收到、你这边说发了直接翻日志对时间戳五分钟出结论。5.2 五类高频翻车现象 / 原因 / 解决第一类对端一直读半条报文。现象是连接建立后几秒断开对方日志显示长度不匹配。原因是长度域写成了字符数或者把 CRC、换行也算进去了。解决很简单统一用getBytes(StandardCharsets.US_ASCII).length并且明确长度只覆盖数据段。第二类校验码始终对不上。现象是数据段肉眼看着完全正确verify就是返回 false。原因是 CRC 实现做了末尾取反或者输出用了小写、丢了前导零。解决是拿一条平台侧能正常入库的历史报文当基准两种实现各跑一遍比对结果把基准报文固化成单测。第三类数据重复入库。现象是同一时刻同一因子在库里出现三到五条。原因有两个要么应答没发或发慢了要么应答报文把Flag原样带回来导致双方对发。解决是加MN|QN幂等表并且严格保证应答Flag0。第四类偶发解析出乱码因子。现象是因子编码变成a0100后面跟一堆不可见字符。原因是数据段里混了中文设备名、备注编码不是纯 ASCII按字节切的时候断在了多字节字符中间。解决是解码统一按 ASCII 做遇到非 ASCII 字节直接拒绝并记录确实要传中文的话和平台约定好编码两边一起改。第五类时间对不上报表整体偏移。现象是DataTime解析出来差了八小时。原因是把 14 位本地时间当成时间戳去转换中间过了时区。解决是用LocalDateTime.parse(s, DateTimeFormatter.ofPattern(yyyyMMddHHmmss))直接解析全程不碰时间戳落库时再按业务约定转。6. 二次开发把因子编码表和命令处理器从if-else里拆出来第一次接手这套代码时MessageDispatcher里是一长串if (201.equals(cn))因子编码也在toFactorValues里写死成十几个常量。加到第十个厂商的时候我崩了——同一个a01001气态的厂说是烟尘水质的厂说是 pH谁也没错就是得配。后来我把两样东西抽出来因子字典和处理器注册表。因子字典外置成 YAML按平台维度做覆盖启动时加载成两级 Map字段说明是否需要按平台覆盖code因子编码如 a01001否name因子中文名是各厂叫法不同unit计量单位是type气/水/工况否scale保留小数位是处理器这边用注册表替掉if-else每个CN对应一个实现Spring 启动时扫Hj212Handler(cn 201)塞进 Map。要加新命令写个类加上注解就完事不用动分发器。改造后我做的第一件事是给每一类报文建一个样本目录跑回放测试——把现场导出的原始报文按文件丢进去断言解析出的字段和预期一致。这套用例后来救了我两次一次是升级 CRC 实现一次是某厂平台偷偷改了 CP 里的分隔符。还有一个技巧值得提给Hj212Message加一个raw字段把原始数据段原样存下来。排查线上问题时这行原文比任何日志都值钱改坏了还能拿它重放复现。代价不大多存一个字符串而已。从那以后我每次做协议解析类项目都先把“基准报文回放单测”搭起来再写业务宁可多花半天。这份 HJ212 解析代码按这个思路整理过解码、组包、分发三层都能独立拿走你也可以只取Hj212FrameDecoder和Hj212Crc16两个类塞进现有项目先跑通再谈扩展。希望帮到你。本文还有配套的精品资源点击获取

HJ212协议报文解析：Java解码、CRC16与粘包处理

相关推荐

Android城市选择器实战：拼音索引、定位与搜索过滤

UNet图像分割实战：PyTorch从掩膜生成到滑窗推理与ONNX校验

JSP相册管理系统实战：图片上传、缩略图与分页鉴权

更多资讯

NLP与LightGBM构建高效客服投诉分类系统

VuePress vdoing 私密文章权限控制：可见性收敛与路由门禁

Windows x64下libhackrf静态编译与USB信号链路稳定实践

开发者如何高效记忆编程语法：认知科学与实战技巧

单链表数据结构：原理、实现与优化技巧

PSO优化RBF神经网络在电力负荷预测中的应用

今日更新

PLFM_RADAR：从被动告警到主动感知的微服务健康监控系统

SPI隔离设计实战：MAX14431BAEE+与STM32F407工业级应用

数字隔离器如何根治SPI通信地环路干扰：MAX14431与TM4C129实战

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？