Issue with BERTLVPackager about jpos HOT 8 CLOSED

I understand why the revert. What I don't understand is the decision to truncate the first zero only. Why only the first 0?

According to EMVStandardTagType, it seems that 5F2A should have a length of 3, not 4. So the test expecting 840 is somewhat correct. However, for other tags, like 9F02, the length is expected to be 12. So the data manipulation for PACKED_NUMERIC is breaking that contract (since it returns a 11 digit number).

It seems that rather than dropping 1 leading zero, the unpackValue should add/remove enough zeros to make the length of the value match with what is defined in the EMVTagType.

from jpos.

Can you provide a Unit test? (see issue #315 for a recent example, feel free to add tests to that class)

from jpos.

@ar added PR #317

from jpos.

Added more tests that highlight the dropping of the leading 0.

For certain elements, such as country or currency codes like as 5F2A, dropping this zero does not change the meaning of the value.

However for other elements, such as transaction amounts like 9F02, dropping the leading zero, changes the actual value from 000000000033 to 00000000033 (note the missing leading 0).

The relevant code seems to be if condition (lines 409-411) within the BERTLVPackager.unpackValue class:

            case PACKED_NUMERIC:
            case PACKED_NUMERIC_DATE_YYMMDD:
            case PACKED_NUMERIC_TIME_HHMMSS:
                uninterpretLength = getUninterpretLength(dataLength, bcdInterpreterLeftPaddedZero);
                unpackedValue = bcdInterpreterLeftPaddedZero.uninterpret(tlvData, 0, uninterpretLength);

                if (unpackedValue.length() > 1 && unpackedValue.charAt(0) == '0') {
                    unpackedValue = unpackedValue.substring(1);
                }
                value = new ISOField(subFieldNumber, unpackedValue);
                break;

Is it a question of removing the if condition?

from jpos.

Hi @ar . I noticed that you reverted the change for PACKED_NUMERIC. As I had mentioned earlier, there are cases, like 9F02 where dropping a zero, changes the meaning of the value. Since the definition of the tag expects 12 digits, sometimes, we can expect to receive 11. Can you explain the reasoning behind this? Why only truncate the first 0 and not all of them? Or nothing at all?

from jpos.

I reverted because the change broke EMVTagSequenceTest.testPacking() gives:

Unpack error ==> expected: <840> but was: <0840>

I believe the test case is correct.

from jpos.

What I don't understand is the decision to truncate the first zero only. Why only the first 0?

You just need one 0 to pad an odd-length number, such as the currency code 840. A number such as '0001' would be coded as just one byte '01', and we would just swallow the first '0' to return '1'.

from jpos.

Sorry I missed your second comment:

However, for other tags, like 9F02, the length is expected to be 12. So the data manipulation for PACKED_NUMERIC is breaking that contract (since it returns a 11 digit number).

That's a good point. Will check that.

from jpos.