Java解析HJ212协议：Netty拆包与CRC校验实战指南

简介：这份资源是一套基于Java语言解析国标HJ212协议的完整工程实现，主要面向环保监测系统开发、污染源数据接入及协议适配的工程师。HJ212是中国环境保护部发布的污染源在线自动监控数据传输标准，规定监测数据的编码格式、通信方式和交互流程。资源将协议解析过程封装为可直接调用的类与方法，包含数据帧拆分、数据段映射、类型转换及异常处理等核心逻辑。压缩包共收录三百零八个文件，其中Java源代码一百个、编译后的class文件一百九十七个，另含Eclipse工程配置、XML配置、许可文件及说明文档，整体仅三百二十七KB，便于快速下载与导入。已有五千零七十八人学习使用。阅读源码可以直观理解T212Mapper、SegmentParser、DataConverter等关键类的设计思路，掌握HJ212报文从接收、解析到对象映射的完整链路，并可直接基于Eclipse环境运行调试或集成到自有项目中，是环保数据对接与协议学习的高价值参考。

1. Java 解析国标 hj212 协议：环保污染物数采仪接入，先过粘包和 CRC 这两关

上半年接了一个环保平台的数据接入需求，设备端是各地环保数采仪，统一走国标 HJ212——污染物在线监控系统数据传输标准。刚看协议文档时觉得很简单，报文无非是##开头、\r\n结尾的一串文本，真正把 TCP 字节流拿在手里才发现，粘包半包、CRC 校验不过、中文乱码轮着来，差点把联调周期拖到翻车。这篇把完整的 Java 解析方案拆给你看，从 Netty 接收字节流到最终还原出污染物浓度值，覆盖协议拆包、CRC 校验、心跳应答和二次改造，适合正在对接 HJ212 设备、或者想把协议解析做成独立模块的开发者。

2. 协议报文结构拆解：一个完整报文从包头到包尾的每个字节

2.1 报文外壳：包头、长度、数据段、CRC、包尾

HJ212 的报文不是 JSON，也不是 XML，而是一个用分隔符拼起来的文本帧。完整结构固定为五段：

## + 4位长度 + 数据段 + 4位CRC + \r\n

##是固定包头，两个 ASCII 字符，用于识别报文起点。紧随其后的 4 位十进制数字表示"数据段"的字节长度，左补零，比如0211表示数据段有 211 个字节。数据段是从QN=一直延伸到 CP 区最后一个&&，中间所有字符按 ASCII 编码计算字节数。数据段后面是 4 位十六进制 CRC 校验值，最后以\r\n收尾。

下面是一条真实的抓包报文，设备主动上报两条污染物实时数据：

##0211QN=20240912103015001;ST=21;CN=2011;PW=123456;MN=6134000001;CP=&&DataTime=20240912103015;011-A0101-Rtd=12.8,011-A0101-Flag=N;011-A0102-Rtd=35.6,011-A0102-Flag=N&&C38D\r\n

拆开看：##后0211是数据段长度；数据段包含 QN、ST、CN、PW、MN、CP 六个字段；C38D是 CRC；\r\n是包尾。我一开始偷懒直接按;拆字符串，遇到设备把多条报文粘在一起发过来时，长度字段和 CRC 全对不上，后来才老老实实把"先取长度、再截数据段、最后校验"做成固定顺序。

长度字段在解析时是硬约束。收到一行后先验证是否以##开头，再取第 2 到第 6 个字符解析长度，通过长度截取数据段，数据段之后的 4 个字符才是 CRC。如果直接用整行字符串去做键值拆分，遇到异常数据会把半截报文当成完整报文解析，脏数据直接进库。

2.2 数据段字段：QN、ST、CN、PW、MN、CP 的职责划分

数据段由;分隔的键值对组成，顺序在标准里固定，但解析时不建议依赖顺序，按 key 取值更稳。各字段含义如下表：

CN 命令编码是这个协议里最需要熟悉的一张表。不同命令决定了消息是上行数据、上行心跳、下行请求还是下行应答。我项目里最常用的几个：2011是设备主动上传实时数据，2012是心跳，1011是平台下发请求实时数据，3011是设置参数。解析器在拿到消息后第一件事就是看 CN，不同命令走不同的处理分支。

MN 是设备维度做会话管理的关键。一个 Netty 服务端会接入成百上千台数采仪，每台设备用MN唯一标识，解析入库、幂等去重、在线状态维护都要围绕它做索引。曾经踩过一个坑：设备重连后 TCP 连接变了，但平台侧还按旧的连接下发指令，设备收不到，后来改成按 MN 维护"当前活跃连接"映射才解决。

CP 是数据区，格式为&&包裹、内部用;分隔的多组键值对。CP 里既包含数据时间DataTime=20240912103015，也包含污染物因子，因子之间用;分隔，同一个因子的多个类型用,分隔。解析 CP 时必须先把外层&&剥掉，再按;拆，否则会把&&DataTime这种脏 key 带进结果集。

2.3 CP 数据区：污染物因子编码与数据类型

CP 里的污染物因子遵循监测项-因子编码-数据类型=值的规律。以011-A0101-Rtd=12.8为例，A0101是二氧化硫的因子编码，A0102是氮氧化物，A0106是颗粒物，Rtd表示实时值，Flag是数据状态标识。状态标识有固定取值：N正常、F故障、S停运、D检修、M人工。如果只解析数值不管 Flag，很容易把设备故障期间的异常浓度当成真实排放数据入库。

因子前缀011在不同厂家协议里含义略有差异，有的代表废气排放口编号，有的代表监测介质类型。解析时不能写死，要按key.split("-")的长度做兼容：两段格式因子编码-数据类型，三段格式监测项-因子编码-数据类型。我采用的是三段优先、两段兜底的解析方式，这样对老旧设备和新型数采仪都能兼容。

2.4 CRC16 校验：标准附录算法的 Java 落地

CRC 计算范围是数据段整体，也就是从QN=到 CP 区最后一个&&的字节流，不包括##、长度字段、CRC 本身和\r\n。标准附录给出的参考算法是初值0xFFFF、多项式0xA001的查表实现，很多设备文档里只给了 C 语言示例，移植到 Java 时多项式容易写错。

public final class Crc16 { private static final int[] TABLE = new int[256]; static { for (int i = 0; i < 256; i++) { int crc = i; for (int j = 0; j < 8; j++) { crc = ((crc & 0x0001) != 0) ? (crc >> 1) ^ 0xA001 : (crc >> 1); } TABLE[i] = crc & 0xFFFF; } } public static String computeHex(byte[] data) { int crc = 0xFFFF; for (byte b : data) { crc = ((crc >> 8) & 0xFF) ^ TABLE[(crc ^ b) & 0xFF]; } // 高字节在前输出，例如 C38D return String.format("%02X%02X", (crc >> 8) & 0xFF, crc & 0xFF); } }

这个查表法和标准里的按位异或算法是等价的，只是预计算了 256 个表项，解析高频上报数据时能省不少 CPU。0xA001是反射多项式，对应标准里右移异或的写法，不要改成0x8005或0x1021，否则校验永远过不了。输出格式上有个隐藏坑：报文里 CRC 字段是高字节在前，很多通用 CRC 工具默认输出低字节在前，这里用(crc >> 8) & 0xFF先输出高字节。

我在联调时遇到过一次玄学问题：本地算出来的 CRC 和报文字符串逐位比较都一样，顺序却是反的。后来把报文里C38D拆开，发现C3是高字节、8D是低字节，才意识到是输出字节序的问题。校验时除了比较字符串，也建议把收到的 4 位十六进制还原成两个字节，与计算结果按字节比较，这样既能兼容字符串比对，也能定位大小端不一致。

3. Netty 服务端落地：从 TCP 字节流到整齐的 HJ212 报文帧

3.1 服务端骨架：Boss 与 Worker 线程池分配

接入层工程用 Maven 管理，依赖选 Netty 4.1 系列，稳定性和社区资料都够用。服务端监听一个固定端口，接收数采仪主动发起的 TCP 连接。HJ212 是长连接协议，设备连上后保持连接，按配置周期上报心跳和数据，服务端尽量不要主动关闭连接，断线重连由设备端负责。

EventLoopGroup boss = new NioEventLoopGroup(1); EventLoopGroup worker = new NioEventLoopGroup(4); try { ServerBootstrap bootstrap = new ServerBootstrap(); bootstrap.group(boss, worker) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 128) .childOption(ChannelOption.SO_KEEPALIVE, true) .childHandler(new ChannelInitializer<SocketChannel>() { @Override protected void initChannel(SocketChannel ch) { ch.pipeline() .addLast(new LineBasedFrameDecoder(2048)) .addLast(new Hj212MessageDecoder()) .addLast(new Hj212BusinessHandler()); } }); ChannelFuture future = bootstrap.bind(8888).sync(); future.channel().closeFuture().sync(); } finally { boss.shutdownGracefully(); worker.shutdownGracefully(); }

boss只负责 accept 新连接，worker处理读写 IO。SO_KEEPALIVE打开 TCP 层保活，但应用层仍然要依赖 HJ212 心跳做在线判断，TCP 保活只能兜底网络异常。LineBasedFrameDecoder(2048)指定单帧最大 2048 字节，超长帧直接抛异常断开连接，防止设备异常时把内存打满。

3.2 报文解码器：按行拆帧后解析长度与 CRC

HJ212 报文以\r\n结尾，所以拆帧最省事的方案是用 Netty 的LineBasedFrameDecoder，它会自动处理\n和\r\n两种换行，并把行尾换行符去掉。拆帧后每个ByteBuf就是一条完整报文，粘包和半包问题在这一层就解决掉了，后续解码器不用再关心字节边界。

public class Hj212MessageDecoder extends MessageToMessageDecoder<ByteBuf> { @Override protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) { String line = in.toString(Charset.forName("GBK")); line = line.replace("\r", "").replace("\n", ""); if (line.length() < 12 || !line.startsWith("##")) { // 非 HJ212 报文，直接丢弃 return; } int length = Integer.parseInt(line.substring(2, 6)); if (line.length() < 6 + length + 4) { // 长度字段与实际数据不匹配，丢弃 return; } String dataSegment = line.substring(6, 6 + length); String crcReceived = line.substring(6 + length, 10 + length); String crcCalculated = Crc16.computeHex(dataSegment.getBytes(Charset.forName("GBK"))); if (!crcReceived.equalsIgnoreCase(crcCalculated)) { // 校验失败，记录日志后丢弃，不向上抛异常 return; } Hj212Message message = Hj212Parser.parse(dataSegment); out.add(message); } }

解码器只做三件事：取长度、截数据段、校 CRC。校验通过后交给解析器转成业务对象，校验失败直接静默丢弃。不要在校验失败时抛出异常，数采仪在网络抖动时偶发坏包是常态，断开连接会触发设备重连风暴，日志记录告警即可。GBK编码是因为多数数采仪中文字段沿用 GBK，如果你的设备支持配置 UTF-8，把这里换成StandardCharsets.UTF_8就行。

3.3 数据段解析：把;分隔的键值对还原成消息对象

Hj212Parser.parse负责把数据段字符串拆成结构化对象。标准说字段顺序固定，但实现时不要依赖顺序，用 switch 按 key 取值更稳妥，这样即使设备调整字段顺序也不会解析失败。

public static Hj212Message parse(String dataSegment) { Hj212Message message = new Hj212Message(); String[] parts = dataSegment.split(";"); for (String part : parts) { int eq = part.indexOf('='); if (eq < 1) { continue; } String key = part.substring(0, eq); String value = part.substring(eq + 1); switch (key) { case "QN" -> message.setQn(value); case "ST" -> message.setSt(value); case "CN" -> message.setCn(value); case "PW" -> message.setPw(value); case "MN" -> message.setMn(value); case "CP" -> message.setCp(parseCp(value)); default -> message.getExtra().put(key, value); } } return message; }

parseCp处理&&包裹的数据区，截取内部内容后继续按;拆分。这里要注意substring(2, length - 2)的边界保护，如果报文被截断导致&&不完整，要先做长度判断再截取，否则直接抛StringIndexOutOfBoundsException会把整个连接打崩。

private static Map<String, String> parseCp(String cp) { int len = cp.length(); if (len < 4 || !cp.startsWith("&&") || !cp.endsWith("&&")) { return Collections.emptyMap(); } String inner = cp.substring(2, len - 2); Map<String, String> map = new LinkedHashMap<>(); for (String item : inner.split(";")) { int eq = item.indexOf('='); if (eq > 0) { map.put(item.substring(0, eq), item.substring(eq + 1)); } } return map; }

解析 CP 时有一个细节：DataTime和因子项混在一起，因子项里又可能包含逗号分隔的Rtd与Flag。所以 CP 解析不能只在parseCp里完成，因子拆解要等进入业务层后再做。LinkedHashMap保持插入顺序，方便按原始报文的顺序去遍历因子，排查问题时能够和抓包文件对上号。

4. 核心解析代码拆解：从 QN 到污染物浓度值的完整数据流

4.1 消息模型设计：协议对象与业务对象分离

解析器产出的Hj212Message是协议层对象，字段对齐 HJ212 报文的六个核心参数，不要直接拿去入库。我更建议在业务层再转一层MeterData，包含设备编号、数据时间、因子编码、因子值、数据状态，这样后续接 InfluxDB 还是 MySQL 都只和业务对象打交道，协议升级时替换解码器即可。

public class Hj212Message { private String qn; private String st; private String cn; private String pw; private String mn; private Map<String, String> cp = new LinkedHashMap<>(); private Map<String, String> extra = new LinkedHashMap<>(); // getter / setter 省略 } public class PollutionFactor { private String monitorCode; // 监测项前缀，如 011 private String factorCode; // 因子编码，如 A0101 private String dataType; // 数据类型，如 Rtd / Flag private String value; // 数值或状态 // getter / setter 省略 }

PollutionFactor把 CP 里的011-A0101-Rtd拆成三个字段，后续按因子编码聚合时可以直接 group byfactorCode，不用再对字符串做 substring。设备厂商可能扩展自定义因子，monitorCode允许为空，factorCode不允许为空，解析时只保留factorCode非空的数据，脏字段直接丢弃。

4.2 因子解析器：兼容两段和三段编码格式

public class Hj212FactorParser { public static List<PollutionFactor> parse(Map<String, String> cp) { List<PollutionFactor> result = new ArrayList<>(); for (Map.Entry<String, String> entry : cp.entrySet()) { String key = entry.getKey(); if ("DataTime".equals(key)) { continue; } String[] seg = key.split("-"); if (seg.length < 2) { continue; } PollutionFactor factor = new PollutionFactor(); if (seg.length == 2) { factor.setFactorCode(seg[0]); factor.setDataType(seg[1]); } else if (seg.length == 3) { factor.setMonitorCode(seg[0]); factor.setFactorCode(seg[1]); factor.setDataType(seg[2]); } else { continue; } factor.setValue(entry.getValue()); result.add(factor); } return result; } }

这个解析器按-拆分 key，两段格式对应旧版设备，三段格式对应带监测项前缀的新版设备。拆分后要过滤非法段数，比如011-A0101-Rtd-Time这种四段扩展字段，不属于标准因子，直接跳过，避免脏数据污染浓度指标。entry.getValue()里可能是数值也可能是 Flag 状态码，由dataType决定含义，业务层要分开存储。

4.3 业务分发：心跳应答与数据上报入库

Hj212BusinessHandler收到解析后的消息，先判断 CN，再走不同分支。心跳包响应要快，数据包响应可以异步入库，不要阻塞 Netty 的 IO 线程。

public class Hj212BusinessHandler extends SimpleChannelInboundHandler<Hj212Message> { @Override protected void channelRead0(ChannelHandlerContext ctx, Hj212Message msg) { switch (msg.getCn()) { case "2011" -> handleDataUpload(ctx, msg); case "2012" -> handleHeartbeat(ctx, msg); case "1011" -> handleDataRequest(ctx, msg); default -> ctx.writeAndFlush(buildResponse(msg, "9012", "SystemTime=" + System.currentTimeMillis())); } } private void handleHeartbeat(ChannelHandlerContext ctx, Hj212Message msg) { // 更新设备在线状态 deviceRegistry.touch(msg.getMn(), ctx.channel()); String cp = "SystemTime=" + LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyyMMddHHmmss")); ctx.writeAndFlush(buildResponse(msg, "2012", cp)); } private void handleDataUpload(ChannelHandlerContext ctx, Hj212Message msg) { List<PollutionFactor> factors = Hj212FactorParser.parse(msg.getCp()); for (PollutionFactor factor : factors) { if ("Rtd".equals(factor.getDataType())) { meterDataService.saveRtd(msg.getMn(), msg.getCp().get("DataTime"), factor.getFactorCode(), factor.getValue()); } } ctx.writeAndFlush(buildResponse(msg, "2011", null)); } }

心跳处理里deviceRegistry.touch维护设备在线表，把MN和当前Channel关联起来，同时记下最后一次心跳时间。数据上报处理里只取Rtd类型的因子入库，Flag类型单独存储或忽略，入库后立即应答，应答内容可以不带 CP，设备只关心有没有收到。9012是我用的通用应答码，如果平台和设备约定用别的应答码，改buildResponse里传参即可。

4.4 应答报文组装：长度字段与 CRC 一起算

private ByteBuf buildResponse(Hj212Message req, String cn, String cpContent) { StringBuilder body = new StringBuilder(); body.append("QN=").append(generateQn()).append(";") .append("ST=21;CN=").append(cn).append(";PW=123456;MN=").append(req.getMn()); if (cpContent != null && !cpContent.isEmpty()) { body.append(";CP=&&").append(cpContent).append("&&"); } byte[] bodyBytes = body.toString().getBytes(Charset.forName("GBK")); StringBuilder packet = new StringBuilder(); packet.append("##") .append(String.format("%04d", bodyBytes.length)) .append(body) .append(Crc16.computeHex(bodyBytes)) .append("\r\n"); return Unpooled.copiedBuffer(packet.toString(), Charset.forName("GBK")); }

应答报文和上报报文结构完全一致，长度字段必须基于bodyBytes.length动态计算，不能手写死。generateQn()生成新请求编号，不能复用设备上报的 QN，否则设备端做请求应答配对时会匹配错。组装好之后转成ByteBuf写出，Netty 会在写入完成后释放，不需要手动管理内存。

5. 落地避坑指南：粘包、CRC 字节序、重复包与中文乱码排查记录

5.1 粘包半包：一条报文被拆成两半导致解析失败

现象：服务端收到的数据有时缺后半段，有时两条报文拼接在一起，解析出的浓度值少一位或者多一位，CRC 校验频繁失败。

原因：TCP 是字节流协议，没有消息边界。设备端一次send可能发出多条报文，也可能一条长报文分多次send，服务端read拿到的字节流和报文边界完全不对齐。

解决：接入层必须做拆帧。先用LineBasedFrameDecoder(2048)按\r\n切出完整行，再在解码器里依赖长度字段截取数据段，无论粘包还是半包都会在这一层被还原。如果设备不遵守\r\n结尾，则要改成自定义状态机，按##包头识别起点、按长度字段跳过数据段、按 CRC 确认终点。

5.2 CRC 高低字节序相反：本地计算值和报文字符串对不上

现象：报文里的 CRC 字段是C38D，本地算法算出来是8DC3，十六进制字符完全一样，顺序相反，校验一直失败。

原因：HJ212 报文里 CRC 字段采用高字节在前、低字节在后的排列，而很多端口转发工具和在线 CRC 计算器默认按低字节在前输出，两者正好逆序。

解决：计算完成后按String.format("%02X%02X", (crc >> 8) & 0xFF, crc & 0xFF)输出，先高字节后低字节。校验时把收到的 4 位十六进制还原成两个字节再做比较，避免字符串比对被大小端带偏。

5.3 设备重复上报：同一时间戳的数据收到两次

现象：同一台设备、同一个QN的报文，在几秒内被处理了两遍，数据库里出现完全重复的浓度记录。

原因：HJ212 有超时重传机制，设备发出报文后如果没有及时收到应答，会按配置间隔自动重发。服务端处理慢或者应答在网络上延迟，就会触发重传。

解决：按MN + QN做幂等。处理前先检查去重缓存，存在则直接返回上次应答，不再重复入库。

String dedupKey = msg.getMn() + ":" + msg.getQn(); if (processedCache.putIfAbsent(dedupKey, Boolean.TRUE) != null) { // 已处理过，直接应答，不再入库 ctx.writeAndFlush(buildResponse(msg, msg.getCn(), null)); return; }

去重缓存要用有 TTL 的本地缓存或 Redis，不能一直积累。数采仪正常周期是 15 秒到 5 分钟，缓存过期时间建议设置 10 分钟，覆盖重传窗口即可，避免内存无限增长。

5.4 中文乱码：上报字段名解析成一串问号

现象：CP 里出现中文字段名或者带单位描述时，解析出来是??或者Ã¥Â这类乱码，入库后变成不可读字符串。

原因：大部分数采仪固件出厂编码是 GBK，服务端如果用 UTF-8 解码字节流，中文字符就会乱掉。

解决：解码器里统一用Charset.forName("GBK")，数据库连接串也保持 GBK 或转成 UTF-8 后入库。如果设备支持切换编码，优先在数采仪配置里改成 UTF-8，团队后续维护省很多事，但要确认设备固件版本真的支持，部分旧型号改了不生效。

5.5 空闲连接堆积：设备掉线但平台不知道

现象：设备侧断网或断电，TCP 连接没有正常关闭，平台侧在线列表里还显示在线，下发指令也发不出去。

原因：服务端没有做空闲超时检测，设备挂了一周，连接还残留在 worker 线程上，端口和内存慢慢被吃掉。

解决：在 Pipeline 里加IdleStateHandler，读空闲超过阈值直接断开连接并清理设备在线表。

ch.pipeline() .addLast(new IdleStateHandler(180, 0, 0, TimeUnit.SECONDS)) .addLast(new LineBasedFrameDecoder(2048)) .addLast(new Hj212MessageDecoder()) .addLast(new Hj212IdleHandler());

心跳周期按 60 秒算，180 秒读空闲阈值足够宽松。Hj212IdleHandler里监听READER_IDLE事件，触发时关闭连接并从deviceRegistry移除设备映射，下次设备重连时重新注册。

6. 二次开发改造：把解析器做成可复用的环保数据接入层

6.1 与存储解耦：接入层只负责出标准业务对象

解析器本身不要依赖任何数据库和消息队列，把MeterData通过接口交给上层，这样换存储不改协议代码。我习惯定义DataSink接口，入库、推送 Kafka、转发给第三方平台都实现同一个接口。

public interface DataSink { void saveRtd(String mn, String dataTime, String factorCode, String value); } public class InfluxDataSink implements DataSink { @Override public void saveRtd(String mn, String dataTime, String factorCode, String value) { // 写时序库，tag 用 mn 和 factorCode，field 用 value } }

接入层在业务分发处调用dataSink.saveRtd，不关心底层存储。后续要加告警规则，只要在DataSink实现里多写一个告警判断，不用改动 Netty 管线。

6.2 验证方法：用测试报文跑通解析全链路

搭建完成后的第一件事不是接真实设备，而是用本地测试报文把链路打通。我从抓包里摘一段报文，替换 CRC 后直接投递到解码器，验证解析结果是否符合预期。

@Test void testParseDataUpload() { String dataSegment = "QN=20240912103015001;ST=21;CN=2011;PW=123456;" + "MN=6134000001;CP=&&DataTime=20240912103015;" + "011-A0101-Rtd=12.8,011-A0101-Flag=N;" + "011-A0102-Rtd=35.6,011-A0102-Flag=N&&"; String crc = Crc16.computeHex(dataSegment.getBytes(Charset.forName("GBK"))); String packet = "##" + String.format("%04d", dataSegment.getBytes(Charset.forName("GBK")).length) + dataSegment + crc + "\r\n"; Hj212Message msg = Hj212MessageDecoder.decodeForTest(packet); assertEquals("2011", msg.getCn()); assertEquals("A0101", msg.getFactors().get(0).getFactorCode()); }

测试类能直接复用生产环境的Crc16和解析器，确保报文拼装和解析逻辑双向一致。真实设备联调时，再用 TCP 调试工具模拟发包，观察服务端日志里的心跳和数据上报记录。

6.3 多厂商扩展：因子表做成配置而不是常量

HJ212 因子编码在不同监测场景下不一样，废气用 A 开头，水质用 W 开头，如果都写死在代码里，每接一家新设备都要改代码。我后来把因子表挪到配置文件里，factorCode -> 中文名称的映射做成数据库字典，解析器只保留通用编码规则，具体业务含义由上层字典解释。

从那以后我接任何 TCP 协议接入，第一件事永远是先确认拆帧边界和去重策略，而不是急着写业务逻辑。协议解析这种东西，前期把字节边界和编码处理干净，后面接多少种设备都不会翻车。希望帮到你。

本文还有配套的精品资源，点击获取