Java 使用cobol描述符解析数据时，将小数点放在正确的位置

我试图用java中的cobol描述符解析txt文件中的数据。当我使用此方法时，出现了一些错误：

Record net.sf.cb2java.copybook.Copybook.parseData(byte[] arg0). 

在cobol描述符中，有一行：

20 ACCD-LONG-SECONDS          PIC 99V9999.

在这种情况下，相应的结果应该是小数点左侧的2位和小数点右侧的4位。但我得到的是小数点右边的6位数字。 例如，如果原始文件中的数据是123456，那么我们期望的是12.3456，然而，我们得到的是0.123456

---

有人能帮我吗？

这是cobol处理数据的方式，即使它不显示昏迷，但它知道数量是12.3456

要显示它，您可以制作（PIC 99.9999或用于删除零的Z）：

为什么不看看JRecord呢？ 或

---

它比cb2java更新得更多。

在我看来，您的接口文件定义不正确。“COBOL”文件应仅为文本数据。如果有符号，则应有一个实际的+/-，如果有小数点，则应有一个实际的小数点。小数点的另一种选择是“比例因子”是可能的，并且对于浮点数据的文本表示是必需的

您有一个“隐含”小数点。您使用的方法似乎没有正确理解这一点。如果它给了你.123456，那么它就是不工作。如果它不适用于隐含的小数位数，那么它也可能不适用于其他定义

最安全的方法是切换方法。下一个最安全的方法是修复您正在使用的方法。下一个最安全的方法是，在收到结果后，自己进一步解析定义，以确定隐含小数位的位置，然后做一些愚蠢的事情，比如乘以十的正确幂

请记住，在这最后两种情况下，您可能还会遇到其他问题。如果cb2java可以处理文本数据，但在其他方面不可靠，为什么还要继续使用它

cb2java的文档说明了什么？也许有什么东西能帮上忙？系统设计、数据设计和程序规范说明了什么

在COBOL中，将所有数据生成为“文本”，并将所有数据接收为“文本”，并将其转换为COBOL系统所需的格式是很简单的。由于糟糕的设计，你不得不做额外的工作

如果您无法更改文件，我建议您使用JRecord。即使更改了文件，JRecord似乎也是一种更好的方法

是的，您已经完成了代码，但是当设计有问题时，这些事情就会发生。至少将这些信息反馈到设计过程中，这样就不会再发生这种情况

如果您只是为了保存代码而修补代码，那么您将有更难理解和维护的内容，并且更容易出错

在这个过程中的某个地方，一个概念的证明被遗漏了，而你就是那个受苦受难的人。在不知道它是否工作的情况下，不应该启动文件的代码。我希望你没有多个文件。如果您正在做的是POC，那么切换到JRecord应该没有问题，所以我猜不是

---

也许你会幸运地得到这些文档。除此之外，好处在于改进了设计过程和您的经验，这意味着您将来不会进行类似的mis步骤。

对不起，我可能解释得不太清楚。结果是0.123456。我使用java通过cobol描述符解析txt文件中的数据。我将看一看。但如果不改变方法，我的问题还能解决吗？JRecord将正确处理s9（？）V9（？）/9（？）V9（？）。本质上V表示假定的小数位数（文件中没有存储小数点）。没有存储小数点，这是正确的。但它不是应该在通过布局文件解析后添加小数点吗？是的，Cb2java应该在中添加小数点。在Cb2Java做了他需要的事情之后，开发人员停止了开发。不确定您使用的是哪个版本的cb2java（sourceforge或GitHub），Git hub版本（）中有一些修复。我的过程是通过ASCII将txt文件转换为字节。然后，我可以使用parseData（byte[]arg0）通过布局文件将它们解析为适当的结构。到目前为止，它只是不适用于小数点。我会试试JRecord。谢谢你的建议，伙计。

20 ACCD-LONG-SECONDS          PIC 99V9999.
20 ACCD-LONG-SECONDS-Z        PIC ZZ.ZZZZ.
   .
   .
   .
   MOVE ACCD-LONG-SECONDS TO ACCD-LONG-SECONDS-Z 
   DISPLAY ACCD-LONG-SECONDS-Z