本文主要是介绍关于native卡、java卡、GP规范，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
PBOC借贷记和小额支付将为Java卡带来新商机目前从全球来看，第一波的EMV迁移进程已经接近尾声，现在人们关注的是如何从SDA(静态数据认证)进一步升级到DDA（动态数据认证）或者CDA（关于SDA、DDA、CDA的定义参见EMV规范），从而进一步增强卡片的防欺诈能力。
反观国内市场，EMV迁移几乎还停留在起步阶段，只有为数不多的几家银行发行了少量的EMV卡。更多的银行还在热火朝天地推广普通的磁条信用卡，五花八门的促销手段和普天盖地的广告，让人目不暇接。国内各家银行会同威士、万事达、JCB、美国运通发行的各种双币种信用卡，不仅让普通的消费者无所适从，也让国内银行间交易处理业务的中国银联感到了市场的严峻，所以中国银联采取各种策略，希望国内的银行能够发行银联卡，并且不遗余力地推广PBOC借贷记和小额支付规范的应用，这样从市场上为PBOC借贷记和小额支付的大量普及消除了阻力。
PBOC规范和EMV规范
在EMV2000芯片卡规范颁布之后，各个主要的银行卡组织都根据自身的需要对EMV规范进行了细化和修订，其中包括威士推出的VSDC，万事达推出的 Mchip以及JCB推出的Jsmart等。通过各个银行卡组织的细化，进一步明确了在EMV规范中一些笼统的定义，并且把一些发卡行可以灵活定义的选项作了明确的约定，这样可以保证同一个银行卡品牌在全球各地的成员银行进行EMV芯片迁移的时候可以做到一致，更好地实现互操作性，当然这也为众多的智能卡厂商在产品开发方面提供了必要的参考依据。
PBOC规范可以说是中国人民银行针对EMV规范的本地化版本，在EMV规范的整体框架内，根据中国的银行卡实际进行了适当的修订，所以卡片交易的流程以及个人化指南方面和EMV规范几乎完全一致。
PBOC规范和Java卡以及GP规范
我们都知道Java卡是SUN公司推出的面向智能卡的一种Java体系结构，利用Java卡可以加快应用开发的进度，避免开发者苦苦钻研具体的智能卡芯片底层结构，能够以更灵活的方式支持卡片多应用以及卡片发行后的应用添加和删除。不同应用之间具有防火墙，可用通过安全通道的方式实现卡片和终端之间的保密通讯。
当然如果仅仅从功能上来看，Java卡的各种功能也都可以在Native卡上实现，不过Native卡实现上述功能的方法在不同厂商之间会存在很大的差别，增加了用户在个人化、应用开发方面的困难。
对于Java卡在应用的下载、删除、个人化、卡片生命周期管理等方面都有明确的定义，这就是GP（Global Platform）规范的内容。很多智能卡厂商、芯片厂商、银行卡组织和电信运营商都是GP的成员，而GP规范最早是威士开发的Open Platform，所以在EMV卡的个人化方面参照GP规范也就不足为奇了。
PBOC规范在第10部分《中国金融集成电路（IC）卡借记贷记应用个人化指南》中所定义的命令和流程以及EMV卡的个人化流程也是一致的，也就是说同样符合GP规范。
因此如果采用Java卡进行PBOC借贷记应用开发的话，在个人化方面很容易满足个人化指南的要求。但是对于Native卡而言，如果要达到同样的结果不仅所需要的开发周期长，而且开发难度也大。
所以从规范的角度看，虽然PBOC规范没有像威士那样明确定义Open Platform，但是从内容上看和Java卡以及GP规范都是一致的，在PBOC规范中也同样定义了如何利用INITIALIZE UPDATE，EXTERNAL AUTHENTICATE，STORE DATA（详情参见GP规范）等命令进行数据和密钥的个人化。
国内的Java卡和Native卡应用
虽然支持GP规范的Java卡在全球市场已经得到了广泛普及，但国内市场的一些项目主要还是Native卡占据主导地位。其中的原因除了成本考虑外，还有其它几方面的因素：
◆ 国内各个不同应用部门机构之间利益分割严重，难以达成统一的多应用平台，缺少Java卡的应用环境，使得Java卡的多应用优势难以有效发挥；
◆ 因为开发Java卡需要向SUN公司支付一定的技术转让费用，所以国内一些卡商宁可投入大量的人力物力，开发属于自己的Native卡，也不愿意开发Java卡，这样从技术上缺少相应的储备；
◆ 进入国内市场的一些国外厂商虽然有很好的Java卡产品，但是在国内的应用环境中丝毫发挥不了Java卡的优势，比如电信领域的OTA应用，在Java卡中都有很好的实现，可惜不论是中国移动还是中国联通都撇开成熟的技术不用，另起炉灶开发自己的OTA系统，把众多的卡商弄的无所适从；
◆ 开发国内银行IC卡电子钱包应用和社保应用的一些系统集成商已经熟悉了广泛应用于Native卡的那套密钥传递、管理机制和文件建立的流程，对于Java卡缺少了解。
但是我们也看到相关的单位和部门在智能卡多应用方面已经有所行动，比如去年成立的国家金卡工程多功能卡应用联盟，号召各个应用部门之间协调合作，力推一卡多用。而Java卡是得到全球用户广泛认可的多应用产品，在未来中国的多功能卡应用中也同样会发挥其独特的作用。
部分国内银行开始选择Java卡
随着PBOC借贷记卡项目的逐步启动，一些银行在卡片选型方面已经往Java卡方面倾斜。银行之所以选择Java卡，主要看中的就是Java卡所支持的GP规范，为银行开发自己的增值应用提供了可能。
从国外EMV迁移的经验来看，在项目启动初期大家都急于寻找一个商业模式，以便能够平衡EMV迁移带来的投入，虽然其中包含减少欺诈损失的因素，但是银行还是希望能够在这个功能强大的芯片卡上面挖掘更多的潜能。于是人们自然会把注意力放在芯片卡的多应用方面，银行也会根据不同的客户群开发不同的增值应用，既防止客户流失，也带来了增值收入。
比如国内部分商业银行正在进行的一些项目预测试，就希望采用具备一定存储空间的Java卡，这样才能够把自己开发的一些应用下载到Java卡上，而且可以利用自己的发卡商权限更好地管理各种应用。
另外，中国银联也起草了支持非接触交易的PBOC以及小额支付的规范，于是商业银行在PBOC卡片的发行方面就会有自己不同的应用组合模式，Java卡在应用下载、安装、删除方面的通用性和灵活性无疑将会成为最佳选择。
Java卡在PBOC借贷记和小额支付应用中的优势
◆ 能够满足不同的市场需求：因为国内PBOC借贷记项目以及小额支付项目刚刚开始启动，而且对于项目中如何取舍PBOC规范没有明确定义的数据项，各个商业银行之间也可能存在一些差异，那么在这个时候如果采用完全固化到芯片中的Native卡则很难具备应有的灵活性。但是Java卡因为应用程序本身可以灵活下载，所以可以更好地适应多变的市场；
◆ 具备快速进入市场的能力：因为多数银行应用的Native卡都需要进行COS的掩模，而且这一过程通常需要2-3个月的周期，无疑延缓了产品上市的时间。而Java卡在应用程序开发完成之后，就可以对外销售，相当于节省了掩模的时间，对于瞬息万变的市场而言，这2-3个月显得弥足珍贵；
◆ 可以简化产品开发过程：如果采用Native卡开发PBOC借贷记和小额支付应用，需要从底层一点一滴做起，包括通讯协议、加密算法、内存管理、数据存储等，任何环节出现错误都会导致整个项目的崩溃。而利用Java卡进行开发的话，则只需要关注应用本身，只要理清整个交易流程很快就能够开发出满足规范的产品，前面提到的那些底层开发工作已经都包含在Java卡的API里面了，使得开发工作变得简单而容易；
◆ 项目初期整体成本低：一般来说单张Java卡的成本比Native卡略高，但是Native卡的成本优势只有在大规模应用的时候才能够体现出来，因为芯片厂商都会收取一笔不菲的掩模费。对于初期的PBOC借贷记和小额支付项目应用而言，一般试点规模都是以数万张为限，所以Java卡反而具备更好的成本优势。
总结
目前，Java卡在国内的市场虽然所占的份额还很小，但是我们看到未来的趋势正朝着有利于Java卡的方向发展。而且国内一些具有前瞻性的卡商也开始着手进行Java卡的开发，在GP成员的名单中也有了中国公司的身影。这都说明Java卡得以普及的内部和外部环境都在逐步改善，我们相信伴随着未来几年国内商业银行针对PBOC借贷记、小额支付以及qPBOC芯片卡项目的逐步启动，以及NFC移动支付业务的发展，Java卡的前景也会越来越乐观。
关于Native卡：
Native卡是和Java卡相对应的概念，通常所说的Native卡是指卡片的COS和硬件平台紧密相关，卡片不具有通用性和二次开发的API接口，应用的开发和底层COS密不可分，而且多数的Native卡仅支持单一应用，即便是支持多应用也是事先固化在芯片里的多应用，不能够像Java卡那样支持多应用的动态下载。
这篇关于关于native卡、java卡、GP规范的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
