jpos / jPOS

jPOS Project
http://jpos.org
GNU Affero General Public License v3.0
609 stars 461 forks source link

BitMap seems to be mismatched #531

Closed arykov closed 1 year ago

arykov commented 1 year ago

While trying to parse part of a message

<BITMAP><FIELD1><FIELD2>...

bitmap does not seem to be correctly applied I believe it is due to the following two issues:

  1. It appears that ISOUtil byte2bitset populates bitset starting with the first bit instead of 0.
  2. Unpack cycle in ISOBasePackager iterates starting from getFirstField without an adjustment

The following code:

import org.jpos.iso.*;
public class ReproBitMapProblem {
    public static void main(String[] args) throws ISOException {
        ISOBasePackager gp = new ISOBasePackager() {};
        gp.setFieldPackager(new ISOFieldPackager[]{
                /*000*/ new IF_NOP(0, "nothing"),
                /*001*/ new IFB_BITMAP(16, "BIT MAP"),
                /*002*/ new IFB_NUMERIC(1, "F1", false),
                /*002*/ new IFB_NUMERIC(8, "F2", false),
                /*002*/ new IFB_NUMERIC(4, "F3", false)
        });
        ISOMsg m = new ISOMsg();
        gp.unpack(m, ISOUtil.hex2byte("8000000000000000123456789abcdefghijklmnopqrstuvw"));
        m.dump(System.out, "");
        gp.unpack(m, ISOUtil.hex2byte("4000000000000000123456789abcdefghijklmnopqrstuvw"));
        m.dump(System.out, "");
    }
}

produces in first case

<isomsg>
</isomsg>

and in the second

<isomsg>
<field id="2" value="1"/>
</isomsg>

Both of which seem incorrect

alcarraz commented 1 year ago

Why do you say they are incorrect?

The first only have first bit set, which indicate next bitmap is present, which is not, but since there aren't field defined greater than 63 in the packager I guess that's why it doesn't throw an error.

The second is ok, since the second bit is the one set. Bits start at one in bitmap, or are you talking about a system that requires them starting at 0? Zero is always present since it's the MTI, so it wouldn`t make much sense, since if it's not present, BITMAP starts with an offset already.

arykov commented 1 year ago

My understanding is that those bits refer to fields after the bitmap and does not include itself or preceding elements. At least this the way samples I have seen are structured. So in my first example I would expect

<isomsg>
<field id="2" value="1"/>
</isomsg>

and in the second

<isomsg>
<field id="3" value="2"/>
</isomsg>
alcarraz commented 1 year ago

Well, this class is extensively used in jPOS, and it is deployed in thousands of installations, if it were wrong, I guess we would have heard by now. Do you have any real example where it is failing for you?

alcarraz commented 1 year ago

Maybe you need an X92Packager? See X92Packager or X92GenericPacakger.

ar commented 1 year ago

The ISO 8583 Wikipedia page has good examples on ISO8583 bitmaps. Basically the first bit is reserved to indicate if there is a secondary bitmap, so everything get shifted one position.