hylexus

请先临时使用下面代码覆盖掉默认实现，下一个版本修复。 ```java @Bean(BEAN_NAME_NETTY_HANDLER_NAME_808_HEART_BEAT) public Jt808TerminalHeatBeatHandler heatBeatHandler(Jt808SessionManager jt808SessionManager) { return new Jt808TerminalHeatBeatHandler(jt808SessionManager) { @Override public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception { if (!(evt instanceof IdleStateEvent)) { super.userEventTriggered(ctx, evt); return;...

厉害了我的哥

`BCD`码(`8421`码)中有效的二进制范围为 `0b0000~0b1001` 即十进制的 `0~9`。 虽然用 **4** 个 `bit` 表示一个十进制数，在理论上的范围为`0b0000~0b1111` 即十进制的 `0~15`，但是大于 `0b1001`即十进制的 `9` 的都是非法的。 所以，我认为输入中不应该有 `A` 这种大于 `9` 的值存在。 如果你提到的 `A` 表示的是十六进制中的 `A`即十进制的 `10` 的话，或许你应该用 `0b00010000` 来表示(前四位表示 `1`， 后四位表示 `0`，每...

[ICCID](https://baike.baidu.com/item/iccid/5181544) 应该是 **20 个纯数字** 例如 **8986xxxxxxxxxxxxxx**，不应该出现字母。 请找设备方确认设备上报的 **ICCID** 格式是否是标准格式。 如果你的设备上传的 **ICCID** 不是标准格式的话，建议你直接以普通字符串的格式解码，比如 `new String(byte[] input)`。

> 我的理解是这样的，这里808协议中对于BCD字段类型的定义是错误的或者说编撰人没有考虑到ICCID并非纯数字。但是协议是肯定无法改变的，除非来个202X版协议对此处修改了，所以设备厂商对于ICCID的填写仍然是按照BCD的形式。所以我认为对于BCD 类型的解析应该使用`ByteBufUtil.hexDump(byte[] input)`。 **CCID** 并非纯数字的话，我认为你应该用 `BYTE[n]` 或 `STRING` 来接收；然后再手动编码，比如你提到的 `ByteBufUtil.hexDump(byte[] input)` 或参考 [通过自定义注解来扩展新的数据类型](https://hylexus.github.io/jt-framework/v2/jt-808/guide/annotation-based-dev/custom-annotation.html) 。 换句话说就是我认为应该把 **CCID** 的类型从 `BCD[10]` 改为 `BYTE[n]` 或 `STRING`，而不是修改现有 `BCD` 类型的解析逻辑。  如上图所示： **JT/T 808** 中...

gradle 升级到 8.6 了。从 master 分支再拉一下代码。 1. 确保项目的编码是 `UTF-8` 2. 执行 `./gradlew clean build` (Linux/MacOS) 或者 `.\gradlew.bat clean build` (Windows)

可以先使用 `Jt808RequestFilter` (需要配置`jt808.features.request-filter.enabled=true`)来修改请求体或响应体，可以实现请求和响应的加解密。 但是 `Jt808RequestFilter` 无法拦截 `CommandSender` 下发的指令消息。 由于之前没遇到过加解密的场景，一直没支持这个特性。 请提供几个加解密的示例性的调试报文（不方便公开的话群里私发我）。 最近太忙了，预计这周末或下周末提供加解密特性的支持。

升级到 `2.1.4-rc.4`(最新版 `Jar` 预计 24 小时内同步到中央仓库)，然后提供一个 `Jt808MsgEncryptionHandler` 的实现即可，示例如下： ```java @Component public class Jt808MsgEncryptionHandlerDemo01 implements Jt808MsgEncryptionHandler { @Override public ByteBuf decryptRequestBody(Jt808RequestHeader header, ByteBuf body) { final int encryptionType = header.msgBodyProps().encryptionType(); if...

这个应该做不到。 无论是苏标还是粤标，请求头中的信息都是一样的，无法通过请求头区分出到底是苏标还是粤标。 据我所知，好像只能在解析消息体之后，通过消息附加项判断。比如苏标消息附加项中可能会出现(也可能不出现) 附加项 `ID` 为 `0x64`、`0x65`、`0x66` 、... 的扩展附加项。 可以参考示例项目中的写法： [LocationMsgService.java#L57](https://github.com/hylexus/jt-framework/blob/5f749f26be196d813cb20da38b5fd72777422b89/demos/jt-demo-808-server-webflux-boot3/src/main/java/io/github/hylexus/jt/demos/jt808/service/LocationMsgService.java#L57)

目前 `@Jt808RequestHandlerMapping` 就是通过消息头中的 `消息ID` 来分发的。 但是，仅仅通过消息头的 `消息ID` 和手机号是没法区分到底是苏标还是其他扩展的。比如对于你提到的 `0x0200 ` 位置上报消息来说，消息头中的 `消息ID` 都是 `0x0200 `(不论是苏标还是其他扩展)。一般而言，手机号并不能用来判断是苏标还是其他扩展。 如果你想干预消息处理器的分发逻辑 或 你想自定义消息处理器(比如实现自己的消息处理器注解) 的话，可以参考下面几个组件： - `Jt808DispatcherHandler` - `Jt808HandlerMapping` - `Jt808HandlerAdapter` - `Jt808HandlerResultHandler` 这几个组件都是从 `spring` 中借鉴(抄袭😂)过来的，扩展思路和...