我正在将RPG程序中的希伯来语数据发送到Java程序，并且一些数据不符合预期。 RPG程序在具有CCSID 65535的iSeries机器上运行。通过远程方法调用访问java。
大多数希伯来语都是由Java程序按逻辑顺序接收的。然后，我使用Java的Bidi类处理它，使其进入可视化顺序，因为我最终将其写入PDF。几乎所有数据都是正常的，除了几行是方程式。
假设大写H是希伯来数据。这就是这条线应该看起来的样子：300 X 250 X 500 :HHHH我收到了这条线：HHHH: 500 250 X 300 X
500不符合我的预期和Bidi类没有妥善处理。有一些这样的行，是Bidi类不能使用的唯一行。我假设这行是：HHHH: 300 X 250 X 500因为我认为这将是逻辑顺序。它似乎将500保留在RTL段中，然后一旦它碰到X就转向LTR。有没有人有任何想法为什么会这样？
感谢您的帮助。
编辑：java实际上是通过JNI而不是RMI调用的。
答案 0 :(得分：0)
所以我最终发现了这里发生了什么，并在回答我自己的问题，以防任何其他人遇到类似的问题。
希伯来语在代码页424中存储在iSeries中。这是一个希伯来语代码页，所以在iSeries上存储都很顺利。我们在iSeries上有一些正确处理希伯来语数据的打印驱动程序，因此我知道问题必须是iSeries和Java之间的转移，或者是我们用Java创建数据字符串。
事实证明，iSeries正在按照打印顺序存储希伯来语，所以它已经按照我需要将它写入PDF的顺序。当我们将它转移到Java程序时，我们使用的是RPG字符字节数组。将此字符字节数组发送到Java方法时将转换为Unicode。此Unicode转换将尝试处理已按正确顺序并且无序地移动数据的bidi数据。修复是切换到RPG整数字节数组，不会进行此转换。然后当我在Java中收到字节数组时，我从AS400对象获取作业的CCSID并用它创建一个新的字符串。
作业的CCSID作为字符集返回。所以在我们基于美国的系统上，这将返回Cp037，我可以在new String(byte[] source, String charsetName)构造函数中使用它，它会将EBCDIC代码页中的字节数组转换为Java的编码。在基于希伯来语的系统上，这将返回Cp424，我可以做同样的事情来转换它。