对于BCD码类型的解析BUG

[pruneWw]

例如二进制串1234会被解析成字符串1234，而123A则会被解析成12310

[hylexus]

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 的话，请提供更多信息。

[pruneWw]

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中是存在字母的

[hylexus]

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

[pruneWw]

ICCID中并非纯数字

[pruneWw]

我的理解是这样的，这里808协议中对于BCD字段类型的定义是错误的或者说编撰人没有考虑到ICCID并非纯数字。但是协议是肯定无法改变的，除非来个202X版协议对此处修改了，所以设备厂商对于ICCID的填写仍然是按照BCD的形式。所以我认为对于BCD
类型的解析应该使用ByteBufUtil.hexDump(byte[] input)。

[hylexus]

我的理解是这样的，这里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 之外的数字。