I wanted to update all of you on some progress I made with this issue. I've
been working with one of the people on this list and he has been extremely
helpful in pointing me to our issue. I haven't fixed the issue yet but I
think I have the solution.
So first off it turns out the Hebrew data is encoded in code page 424, which
is good because this is a Hebrew code page. When the data stays on the
iSeries it is fine and we have some native print drivers that can print the
spool file to paper in the format that we wanted the PDF in. When we
attempt to send it to our Java program though we run into the issue.
The iSeries is keeping the data in a visual order, so it is stored as you
would see it in the spool file. This is different than most encodings as
bidirectional data is usually stored in a logical/input order. When we send
the data to our Java program we are sending it as the character byte array.
See here for an explanation of the RPG data types:
http://publib.boulder.ibm.com/infocenter/iadthelp/v7r1/index.jsp?topic=/com.
ibm.etools.iseries.rse.doc/topics/rjavarpg.html. The issue with doing this
is that the character byte array does ASCII conversion when sending it to
Java. This causes it to process the Hebrew that was already in a correct
visual order and this would lead to some issues where data would get placed
in the wrong spot. The 3I integer byte array type will hopefully fix our
issue as it does no conversion.
Thank you all for your time and help,
Geren
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Dan Kimmel
Sent: Monday, July 01, 2013 11:43 AM
To: Java Programming on and around the IBM i
Subject: RE: Sending Hebrew data from RPG program to Java program
By the way, using system CCSID 65535 is dangerous. It forces the system to
assume all the data it is handling is in the same character set. The system
must assume some CCSID when converting to Unicode. In the US, this is
typically CCSID 37. Other countries have different defaults depending on the
language system value. It may simply be that your system is assuming a CCSID
with a BidiStringType different than what's actually in the data. See:
http://javadoc.midrange.com/jtopen/com/ibm/as400/access/BidiStringType.html
According to this, there are bidi flags embedded in the data and the bidi
flags vary according to the CCSID.
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Geren White
Sent: Friday, June 28, 2013 3:58 PM
To: java400-l@xxxxxxxxxxxx
Subject: Sending Hebrew data from RPG program to Java program
Hello All,
I'm having some issues with handling Hebrew data that I was hoping some
of you might be able to help me out on. I'm trying to send Hebrew data from
an RPG program to a Java program which the Java program then takes and
constructs a PDF. I'm having a few issues with processing the Hebrew data
to get it into a correct display order. I'm the Java programmer on this
project so please excuse any iSeries/RPG ignorance.
So first off the RPG program sends a string of data to the Java program
that is a mix of Hebrew/English/numerical data. The data comes from a
spooled file on the iSeries and is actually each line of the file. There is
no processing of the data on the iSeries side and it is sent as is. The
Java program is receiving most of the data as I would expect in a logical
order. Logical order being the order in which the characters were typed.
I've used the Java Bidi class to process the data and I've tried the
AS400BidiTransform class. Both of these classes can handle most of the data
correctly and get it into a correct display order. The issue is that there
are certain strings of data that are received in an unexpected order.
This is best explained through examples so assume capital H's are Hebrew:
An example of a situation that can be handled by the Java Bidi class or
AS400BidiTransform:
First the correct display order:
english :HHHH
I would receive this string as:
HHHH: english
The first H in the received string would be the right most H in the display
order. As you can see this would be a logical order for bidirectional data
as the user would type the Hebrew and then switch to LTR with the english
portion. There are much more complex situations that are handled correctly
by the Bidi classes as well but this is just a simple example.
Now an example of an incorrect ordering:
Correct display order:
350 X 250 X 150 :HHHH
Received order:
HHHH: 150 350 X 250 X
This data does not seem to be in a logical order. The first number after
the Hebrew, 150 in this case, seems to stay within the RTL segment while the
rest of the equation gets put into a LTR segment. The Java Bidi class and
the AS400BidiTransform class do not process this correctly. There are many
more situations where this happens and way too many to have special cases
for.
I've been reading all about bidirectional data processing and iSeries
support for it and can't seem to figure this out. I'm thinking it might be
an issue with the CCSID on the iSeries. The system's CCSID is 65535 and all
our jobs should be the same. So from my understanding there shouldn't be
any conversion on the iSeries side but somewhere along the line this data is
getting jumbled.
If any of you have any experience with this or any ideas they would be much
appreciated. Let me know if you need more information. Thank you for your
time.
Regards,
Geren White
CYBRA Corporation
--
This is the Java Programming on and around the IBM i (JAVA400-L) mailing
list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/java400-l.
--
This is the Java Programming on and around the IBM i (JAVA400-L) mailing
list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/java400-l.
midrange.com
