Menu

Weird character encoding in numeric.

Help
Greg Dunn
2013-11-21
2013-11-25
  • Greg Dunn

    Greg Dunn - 2013-11-21

    Hello. We've been using thej8583 library for several years with good results. Thank you.

    I'm generating a new "Table" within a bit 63 message and I can't get it to generate the length correctly. The table is basically a Alpha message with a numeric length header of 4 places. The length of the value I have is 90 characters, or 0090 which should be set to 2 bytes null and ASCII 'Z' Instead I'm getting null and some unprintable character that translates to -112.

    The code is:

    IsoValue v1 = new IsoValue(IsoType.NUMERIC, <an int="" variable="" equaling="" 90="">, 4);
    IsoValue v2 = new IsoValue(IsoType.ALPHA, "SP", 2);
    IsoValue v3 = new IsoValue(IsoType.ALPHA, "01", 2);
    ...etc...

    ByteArrayOutputStream bout = new ByteArrayOutputStream();

    v1.write(bout, true, false);
    v1.write(bout, true, false);
    v2.write(bout, true, false);
    ...etc...

    The Bit 63 message has several of these "Tables" in the same format and the rest all work fine. There is no difference in my code generating the tables. The only difference is this item is longer than the others, which max out at 48 characters.

     
  • Enrique Zamudio Lopez

    I'm sorry but I don't know what you mean by "bit 63". Also I don't understand what you mean by "alpha message with a numeric length header of 4 places".

     
  • Greg Dunn

    Greg Dunn - 2013-11-22

    Bit 63 = Field 63. It's an LLLVAR fields that takes data which consists of one or more "tables" which themselves each consist of a 2 byte (4 digit) numeric length followed by their text.

    I've been able to determine the basic problem is we're ultimately sending these numeric length indicators within the table as HEX and not Binary.

     
  • Greg Dunn

    Greg Dunn - 2013-11-22

    e.g. we're sending ASCII H = HEX 48 = Binary 72 where we want to send ASCII 0 = HEX 30 = Binary 48.

    Our processor doesn't care if we're sending binary or hex, all they see are the digits.

     
  • Enrique Zamudio Lopez

    Maybe you should use LLLBIN instead of LLLVAR then. LLLBIN is used to contain binary data (a byte buffer).

     
  • Greg Dunn

    Greg Dunn - 2013-11-22

    I tried that with no luck. I worked with you on formatting this field a few years ago, thee is a message thread here:

    https://sourceforge.net/p/j8583/discussion/689418/thread/bc6e0957/

    IsoValue v1 = new IsoValue(IsoType.NUMERIC, 48, 4);
    IsoValue v2 = new IsoValue(IsoType.ALPHA, tableId, 4);
    //etc
    //now write the values to a stream, in binary format
    ByteArrayOutputStream bout = new ByteArrayOutputStream();
    v1.write(bout, true);
    v2.write(bout, true);
    //etc
    String s = new String(bout.toByteArray());
    //then you put this string inside a field in your message

    When I put this String s to the message field, it's no longer BCD but Hex, and we're sending Hex to the processor.

    As a hex dump, this is what they're seeing:

    00 92 00 5A 53 50 30 31 30
    30 31 31 30 32 30 30 31 32 30 33 30 30 31 32 30
    34 30 31 31 4E 49 53 43 31 3B 4E 49 53 43 31 30
    35 30 34 30 3B 35 31 35 31 31 31 34 37 36 35 38
    30 30 30 39 3D 36 31 30 31 39 30 33 38 39 35 39
    38 32 38 36 33 32 30 37 31 31 3F 37 30 36 30 30
    34 4C 41 4B 39

    This is what they expect:

    00 92 00 90 ... rest is the same

     
  • Greg Dunn

    Greg Dunn - 2013-11-22

    Apparently they expect the length header within the field 63 message to be in decimal but the rest in Hex.

     
  • Greg Dunn

    Greg Dunn - 2013-11-22

    To clarify, that hex is all of field 63 with one table item included. The total length of the field is 92 in 2 bytes, then the length of the table item should be 90 in 2 bytes, followed by the table text.

     
  • Greg Dunn

    Greg Dunn - 2013-11-24

    I think I may have narrowed my issue down a little more. When I use the IsoValue.write() method to write the length value to the output stream I'm getting the character I would expect, for example '...' for 85, but it's actually writing -123 to the byte array and sending 8230 in the message field.

     
  • Greg Dunn

    Greg Dunn - 2013-11-24

    It's blowing up if the hex code for the length length goes into extended ASCII. Up to 79 it works fine but 80 and above breaks.

     
  • Greg Dunn

    Greg Dunn - 2013-11-24

    I know exactly what is going wrong. If the length of the table value goes over 79 into extended ASCII the write method is not encoding it correctly. Instead it starts using negative numbers and counting backwards so 80 becomes -128, 81 becomes -127 etc.

    Specifically the error comes up in Bcd.encode on this line:

            buf[bufpos] = (byte)(((value.charAt(charpos) - 48) << 4)
                | (value.charAt(charpos + 1) - 48));
    
     
  • Enrique Zamudio Lopez

    And this happens with binary messages, right? LLVAR or LLBIN I suppose?

    The problem arises because the byte type in Java goes from -128 to 127. The line you refer to works with digits only, so that "99" becomes 0x99 for example. I'll add tests for encoding values above 79 as you mention just to be sure though.

    BTW I'm really hosting the project on github now (it's been there for a couple of years now) so feel free to open an issue there. github.com/chochos/j8583

     
  • Greg Dunn

    Greg Dunn - 2013-11-25

    Yes, binary LLLVAR in my case. Thanks.

     
  • Enrique Zamudio Lopez

    I think you are confusing hex with decimal. BCD encodes the decimal number 99 as 0x99, which is decimal 153.

     

Log in to post a comment.