hylexus
对于BCD码类型的解析BUG
BCD码(8421码)中有效的二进制范围为 0b0000~0b1001 即十进制的 0~9。
虽然用 4 个 bit 表示一个十进制数，在理论上的范围为0b0000~0b1111 即十进制的 0~15，但是大于 0b1001即十进制的 9 的都是非法的。
所以，我认为输入中不应该有 A 这种大于 9 的值存在。
如果你提到的 A 表示的是十六进制中的 A即十进制的 10 的话，或许你应该用 0b00010000 来表示(前四位表示 1， 后四位表示 0，每 4 个 bit 表示一个十进制数)。
如果这个 A 不是十六进制中的 A 的话，请提供更多信息。
BCD码(8421码)中有效的二进制范围为0b0000~0b1001即十进制的0~9。 虽然用 4 个bit表示一个十进制数，在理论上的范围为0b0000~0b1111即十进制的0~15，但是大于0b1001即十进制的9的都是非法的。所以，我认为输入中不应该有
A这种大于9的值存在。如果你提到的
A表示的是十六进制中的A即十进制的10的话，或许你应该用0b00010000来表示(前四位表示1， 后四位表示0，每 4 个bit表示一个十进制数)。如果这个
A不是十六进制中的A的话，请提供更多信息。
例如协议中
，ICCID中是存在字母的
ICCID 应该是 20 个纯数字 例如 8986xxxxxxxxxxxxxx，不应该出现字母。
请找设备方确认设备上报的 ICCID 格式是否是标准格式。
如果你的设备上传的 ICCID 不是标准格式的话，建议你直接以普通字符串的格式解码，比如 new String(byte[] input)。
我的理解是这样的，这里808协议中对于BCD字段类型的定义是错误的或者说编撰人没有考虑到ICCID并非纯数字。但是协议是肯定无法改变的，除非来个202X版协议对此处修改了，所以设备厂商对于ICCID的填写仍然是按照BCD的形式。所以我认为对于BCD
类型的解析应该使用ByteBufUtil.hexDump(byte[] input)。
我的理解是这样的，这里808协议中对于BCD字段类型的定义是错误的或者说编撰人没有考虑到ICCID并非纯数字。但是协议是肯定无法改变的，除非来个202X版协议对此处修改了，所以设备厂商对于ICCID的填写仍然是按照BCD的形式。所以我认为对于BCD 类型的解析应该使用
ByteBufUtil.hexDump(byte[] input)。
CCID 并非纯数字的话，我认为你应该用 BYTE[n] 或 STRING 来接收；然后再手动编码，比如你提到的 ByteBufUtil.hexDump(byte[] input) 或参考 通过自定义注解来扩展新的数据类型 。
换句话说就是我认为应该把 CCID 的类型从 BCD[10] 改为 BYTE[n] 或 STRING，而不是修改现有 BCD 类型的解析逻辑。
如上图所示： JT/T 808 中 BCD 类型就是 8421码，不应该出现 0~9 之外的数字。