简体   繁体   English

J8583 Api和EMV凭证

[英]J8583 Api and EMV credentials

I've been looking at J8583: http://j8583.sourceforge.net/xmlconf.html . 我一直在研究J8583: http ://j8583.sourceforge.net/xmlconf.html。

It's a fantastic Api and well maintained, kudos to the author/dev. 这是一个很棒的Api,并且维护得很好,对作者/ dev表示敬意。

I'm wondering if anyone has successfully used it for EMV transactions and/or whether or not the library can handles this data and/or whether it would be safe to do so. 我想知道是否有人成功地将其用于EMV交易,和/或库是否可以处理此数据,和/或这样做是否安全。

It looks as though I'd need to use a composite custom field looking at field 55 of the primary bitmap. 看来我需要使用一个复合自定义字段来查看主位图的字段55。 If the data is present I'd then need to investigate the EMV Tags and parse as required. 如果存在数据,则需要调查EMV标签并根据需要进行解析。

My sample ISO messages looks like: 我的示例ISO消息如下所示:

666600000000000002001495F2A0201245F34010182021C008407A0000000031010950580000000009A031102249B0268009C01009F02060000000000009F03060000000000009F0607A00000000310109F0802008C9F0902008C9F100706010A039000009F1A0201249F2608423158936ED6C38F9F2701809F3303E0B0C89F34034103029F3501229F360200019F3704ACAC66E89F5800DF0100DF0200DF0400

The 6666 prefix is a template I've set up just to test this scenario, it only has field 55 of type LLLVAR 6666前缀是我为测试该场景而设置的模板,它只有字段LLLVAR类型的55

If we are then to look at decoding the EMV data we can use http://www.emvlab.org/tlvutils/ and pasting in: 如果要查看EMV数据的解码,可以使用http://www.emvlab.org/tlvutils/并粘贴:

5F2A0201245F34010182021C008407A0000000031010950580000000009A031102249B0268009C01009F02060000000000009F03060000000000009F0607A00000000310109F0802008C9F0902008C9F100706010A039000009F1A0201249F2608423158936ED6C38F9F2701809F3303E0B0C89F34034103029F3501229F360200019F3704ACAC66E89F5800DF0100DF0200DF0400

will yield a table of results that I'm effectively trying to reproduce. 会产生一张我正在有效尝试复制的结果表。

My output is simply: 我的输出很简单:

Output: 

666600000000000002001495F2A0201245F34010182021C008407A0000000031010950580000000009A031102249B0268009C01009F02060000000000009F03060000000000009F0607A00000000310109F0802008C9F0902008C9F100706010A039000009F1A0201249F2608423158936ED6C38F9F2701809F3303E0B0C89F34034103029F3501229F360200019F3704ACAC66E89F5800DF0100DF0200DF0400
Message type: 6666
FIELD TYPE    VALUE
   55 LLLVAR [5F2A0201245F34010182021C008407A0000000031010950580000000009A031102249B0268009C01009F02060000000000009F03060000000000009F0607A00000000310109F0802008C9]

as I haven't worked on the custom fields yet as I wanted to ask the SO community their thoughts first. 因为我还没有在自定义领域工作,所以我想先问一下SO社区他们的想法。

Thank in advance for any help/suggestions. 在此先感谢您的帮助/建议。

also...if someone reading this has 1500 rep, maybe J8583 si deserving it's own tag? 还...如果有人读这篇文章有1500个代表,也许J8583 si值得拥有自己的标签?

Posting in case anyone else should stumble across this post. 张贴,以防其他任何人偶然发现这篇文章。

It was determined that the J8583 library would not be suitable for EMV data. 确定J8583库不适用于EMV数据。 It is a great library but not suited for the task of parsing the BER-TLV tags. 它是一个很棒的库,但不适合解析BER-TLV标签的任务。
Usign a composite field would also be unsuitable as these sub fields are accessed via indexing and it wouldn't be obvious if one were missing or not. Usign一个复合字段也不合适,因为这些子字段是通过索引访问的,如果一个子字段不存在,则不明显。

Anyway, the good news - this library is incredible for parsing the Tags : https://github.com/binaryfoo/emv-bertlv 无论如何,好消息-这个库对于解析标签来说是不可思议的: https : //github.com/binaryfoo/emv-bertlv

You can wrap it in field 55 of the J8583 lib is you're already using it. 如果已经在使用它,则可以将其包装在J8583库的字段55中。 55 is considered the standard, I think. 我认为55被认为是标准。

Have fun! 玩得开心! :) :)

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM