Иврит данные из программы RPG для Java-программы неправильно упорядочены

Question

Я отправляю ивритские данные из программы RPG в программу Java, и некоторые данные поступают не так, как ожидалось. Программа RPG запускается на машине iSeries с CCSID 65535. Доступ к java осуществляется посредством удаленного вызова метода.
Большая часть иврита получена Java-программой в логическом порядке. Затем я обрабатываю его с помощью класса Bidi Java, чтобы получить его в визуальном порядке, поскольку я в конечном итоге пишу его в 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, а затем перевернулся на LTR, когда он попал в X. Есть ли у кого-нибудь какие-либо идеи относительно того, почему это было бы?

Спасибо за помощь.
EDIT: Java фактически вызывается через JNI, а не RMI.

Answer 1

Итак, я выяснил, что происходит здесь, и я отвечаю на свой вопрос, если кто-то еще сталкивается с подобной проблемой.

Иврит хранился на iSeries на кодовой странице 424. Это кодовая страница на иврите, поэтому все было хорошо с хранением на iSeries. У нас были некоторые драйверы печати на iSeries, которые правильно обрабатывали данные на иврите, поэтому я знал, что проблема должна быть либо в передаче между iSeries и Java, либо при создании строки данных на Java.

Оказалось, что iSeries хранит иврит в порядке печати, поэтому он уже был в том порядке, в котором мне нужно было записать его в PDF-файл. Когда мы переносили его в программу Java, мы использовали массив байтов символов RPG. Этот массив байтов символов преобразуется в Unicode, когда он отправляется методу Java. Это преобразование Юникода будет пытаться обработать данные bidi, которые уже были в правильном порядке, и вывести данные из строя. Исправление заключалось в том, чтобы переключиться на массив байтов целых чисел RPG, который не будет выполнять это преобразование. Затем, когда я получаю массив байтов в Java, я получаю CCSID задания от объекта AS400 и создаю с ним новую String.

CCSID задания возвращается в виде набора символов. Таким образом, в нашей американской системе это вернет Cp037, и я могу использовать это в конструкторе new String(byte[] source, String charsetName), и он преобразует массив байтов, который находится на кодовой странице EBCDIC, в кодировку Java. В системе на иврите это вернет Cp424, и я могу сделать то же самое с тем, чтобы его преобразовать.