我已经使用了下面链接中为java How to unpack COMP-3 digits using Java?提供的解包数据逻辑但是对于源数据中的空数据，它返回404040404，就像Java解包代码一样。我知道这是ebcdic中的空间，但是如何通过处理这个空间或者避免它来解包。
我们必须处理两个问题。首先，数据是有效的comp-3数据，其次是COBOL之类的旧语言实现认为“有效”的数据，因为提到了Comp-3。
如果offest没有错位，那么现有程序似乎将空格解释为0而不是空格。这可能是不正确的，但可能是设计为容忍这种不良行为的旧程序的工件。
我将在传统商店中采取的方法（假设没有错位）是将“空格”（其为0x404040404040的序列）视为零。这将是一个遗留检查，用于比较字段和空格，然后假设0x00000000000f作为实际默认值。这是个体商店必须确定的东西，并且不被认为是一般的编程方法。
就Java而言，必须记住字节是“已签名”的，因此根据代码的编写方式进行比较可能会非常棘手。我在java中记得的唯一“无符号”数据类型是char，它实际上是两个字节（单元16）。
与识别历史容忍度和补救措施相比，这不是一个编程问题。