PBOC规范(2.0->3.0)对照表
1 数据方面
TAG |
PBOC2.0 |
PBOC3.0 |
5F20 |
持卡人姓名 |
如果小于26H,不允许使用9F0B |
9F0B |
存放5F20大于26H的部分 |
如果姓名大于26H,全部存放 |
9F63 |
卡产品标识信息 字节9-11改为产品标识信息 字节10 改为本规范保留 |
产品标识信息 字节9-11改为卡产品标识信息 字节10 改为移动支付规范保留 qPBOC 联机或拒绝交易的 GPO 响应数据返回 |
9F68 |
可支持交易日志 |
应支持交易日志(开启) |
9F6B |
没有明确 |
可PUT Data |
9F74 |
建议最后一条记录仅放置9F74 |
|
9F08 |
0020 |
0030 |
DF4F |
无 |
新增圈存日志文件格式 |
DF4D |
无 |
新增圈存日志文件 |
9F69 |
无 |
Fdda为01,返回 |
DF60 |
无 |
CAPP交易指示位 |
DF61 |
无 |
分段扣费应用标识 |
DF62 |
无 |
分段扣费抵扣限额 |
DF63 |
无 |
分段扣费已抵扣金额 |
DF69 |
无 |
SM算法支持指示器 |
2 规范分析
2.1 安全增强
出于对国家金融安全等多种因素的考虑,PBOC3.0在第17部分详细定义与说明了国密算法在金融IC卡中的应用,即PBOC3.0的金融IC卡可以支持SM2/SM3/SMS4(国密算法)与RSA/SHA-1/3DES(国际算法)。这两套算法通过 SM算法支持指示器标签DF69进行切换。
两套算法切换的原则是:终端和卡片使用共同支持的算法完成交易;遵循国密算法优先处理的原则。
2.2 增加应用
(1) 非接触式IC卡小额支付扩展应用
为适应金融IC卡跨行业多应用需求,推动金融IC卡的一卡多用惠及民生,PBOC3.0在第14部分增加qPBOC扩展应用,分配了扩展应用文件,从而满足了金融IC卡在地铁、公交、高速公路收费、停车收费、铁路(高铁)等领域的多种应用,同时预留了其它银行自定义应用及保留应用。
(2) 电子现金双币应用
随着国际IC卡迁移的推进,我国的金融IC卡进一步兼容国际标准,为港澳台及国外持卡人提供便利,PBOC3.0第15部分增补了双币电子现金和双币qPBOC应用,对双币种交易时的TAG进行了映射,最大限度地方便持卡人在两种币种间的快速转换。
(3) IC卡互联网终端
为推动金融IC卡与网络支付和移动支付的整合发展,PBOC3.0在第16部分中增补了IC卡互联网终端的内容,对IC卡互联网终端的安全体系、应用场景、交易流程等环节进行了详细的定义与阐释。IC卡互联网终端有效地引入了移动支付的新元素,多种应用场景圈存解决了持卡人到银行柜台排队办理业务的苦恼。
2.3 原有内容升级
(1) 增加了AID预留和分配
对TAG进行了预留以供将来使用;定义了AID的编码规则、保留规则。
(2) 修订了GAC与GPO命令数据的相关内容。
明确了GAC与GPO命令数据不一致时卡片处理方法;
在终端层面,也明确了若卡片返回标签重复,终端应当终止交易;
卡片联机GPO响应数据中新增了9F63的要求,以适应不断增长的应用需求;
明确了GPO响应应遵循的格式。
(3) 明确了执行发卡行认证与执行发卡行脚本之间的关系。
卡片应当能正常处理应用解锁命令,无论发卡行认证是否执行,若发卡行认证执行但失败,则卡片应拒绝执行发卡行脚本,并推荐以“6985”响应发卡行脚本命令。
(4) 修改9F63产品标识信息。
9F63命名为“产品标识”,用于标识持卡人设备产品的物理形态,用途等。
(5) 增加了第6.5节“个人化数据必须遵循的规则”
在增加规则的同时,也明确了9F10中发卡行自定义数据的要求,这些部分的修订,结合了各商业银行接入银联网络的有关经验,对于商业银行发卡的个人化数据具有指导性意义。
(6) 修订非接触式IC卡通讯的参数
参数的修订目的在于兼容ISO/IEC 14443:2011。
(7) 增加两种交易日志
圈存日志的要求:当卡片中的电子现金余额(9F79)被设置数据(Put Data)命令成功改写时,卡片应当记录一条圈存日志。
增加了qPBOC交易日志要求(发卡行可选)。
(8) 其它终端部分的主要修订内容
终端也不应因持卡人姓名有误而终止交易;
终端在交易时及交易后取得卡片中电子现金余额的方法;
授权金额为0的处理方式:如果授权金额为零,除非终端支付qPBOC扩展应用,具有联机能力的终端应在终端交易属性字节2的第8位表示要求联机应用密文;如果授权金额为零,除非终端支付qPBOC扩展应用,仅支持脱机的终端应终止交易,提示持卡人使用另一种界面(如果存在)。
(9) 其它卡片部分的主要修订内容
修订了卡片连续MAC错的处理方法。当卡片执行了收到一个MAC错的发卡行脚本命令,则不应允许执行后续的发卡行脚本命令;
修订了关于“闪卡”的处理办法;
明确了qPBOC不再设置LOATC。
4、删除不适用部分
删除了电子钱包/电子存折应用及其扩展应用;
删除了借贷记应用中对DDF的描述,删除了终端在应用选择时对DDF的支持,同时强制卡片不使用DDF;
删除了非接触支付应用中的MSD应用相关内容。
3 规范变化
规范 |
描述 |
主要变化(JR/T 0025—2010相比主要变 化) |
备注 |
第1部分:电子钱包电子存折应用卡片规范 |
废止 |
——修订了标准的前言。 |
|
第2部分:电子钱包电子存折应用规范 |
废止 |
——修订了标准的前言。 |
|
第3部分:与应用无关的IC卡与终端接口规范 |
修订 |
――修订了标准的前言与引言; |
|
――删除了终端对DDF的支持; |
12.2.3 支付系统目录编码 新增“支付系统目录记录中应当不包含任何通往DDF的入口。如果终端在处理这些记录时遇到了DDF的入口,终端可以忽略这些入口或者处理这些入口,处理入口的方法不在JR/T 0025的讨论范围内。” |
||
――要求IC卡不使用DDF; |
|||
—— 增加了 第13章“AID 预留和分配”。 |
在原规范基础上新增“13 AID 的预留与使用”本规范采用 GB/T16649.5规定的应用标识符 (AID)基本结构,应用标识符 (AID)长度为5-16个字节,由5个字节的注册的应用提供者标识 符(RID)和0-11个字节的专有应用标识符扩展(PIX)组成。 |
||
第4部分:借记/贷记应用规范 |
修订 |
—— 修订了标准的前言; |
|
—— 全文删除对DDF的描述; |
将原3.10支付系统环境“当符 合JR/T 0025的支付系统应用被选择,或者用于支付系统应用目的的目录定义文件(DDF)被选择后,IC卡中所确立的逻辑条件集合。”修改为“当符合JR/T 0025的支付系统应用被选择,IC 卡中所确立的逻辑条件集合。” 将原5.1.4目录结构“目录结构允许以应用标识符(AID)检索一个应用,或以AID的前n个字 |
||
|
节作为DDF名检索一组应用。” 修改为“目录结构允许以应用 标识符(AID)检索一个应用。” 将原6.2.1.4 READ RECORD命令描述“终端发送READRECORD命令到卡片,读取PSE中的记录(如果支持目录选择)或其他AID选择方法列表中的DDF。”修改为 “终端发送READRECORD命令到卡片,读取PSE中的记录(如果支持目录选择)。命令包括读取文件的短文件标识(SFI)以及文件里的记录号。” |
||
—— 对原标准在文字描述上的勘误做出修正。 |
|||
第5部分:借记/贷记应用卡片规范 |
修订 |
——修订了标准的前言; |
|
——删除终端和卡片对 DDF的处理的要求; |
删除原6.4.1目录选择方式-卡片处理步骤“步骤3:终端处理记录中的每一个入口。如果入口表明一个DDF,终端发一个有此 DDF 名字的选择(SELECT)命令,卡片响应DDF 的FCI。FCI 包括一个目录文件的SFI。 终端读取属于此DDF 的目录文件中的所有记录,卡片对每个读记录(READ RECORD)命令返回请求的记录和状态字“9000”。当请求的记录不存在,卡片响应 “6A83”,终端返回步骤2 继续 读PSE 下的目录文件。” 删除原6.4.1目录选择方式-终端执行步骤“步骤4:选择记录2 中入口1 指出的DDF 目录;步骤 5:读DDF 目录文件中的记录1;步骤6:检查记录1 中ADF 入口1 或2 中的AID 是否和终端AID 匹配。如果匹配,加入候选列表;步骤7:当卡片响应目录中没有其它记录时,返回前一个目录的处理入口和记录;步骤8:检查支付系统目录文件中记录2 内入口2 是否和终端AID 匹配。如果匹配,加入候选列表”。 删除原表A.1卡片和终端的数据 |
||
|
元描述“目录数据文件(DDF)名称”的描述。 |
||
——对TAG进行了预留,以供将来使用; |
在原附录A-卡片和发卡行数据元表(规范性附录)新增“当一个数据元从一方传递到另一方时(例如:从卡片传递到终端),不论该数据元原来是如何被存储的,应当将该数据元从高字节至低字节传递。构造数据时也应遵循此规则。”。 将原规范5F20持卡人姓名描述 由“持卡人姓名,按GB/T17552 的规定”修改为“如果持卡人姓名小于等于26字节,此时不应使用标签9F0B,完整的持卡人姓名应当存放在该标签下。按GB/T 17552的规定。”。 将原规范9F0B持卡人姓名扩展描述由“如果持卡人姓名大于 26 字节,多出部分放在此数据元中。按GB/T 17552 的规定” 修改为“如果持卡人姓名大于 26字节,此时不应使用标签 5F20,完整的持卡人姓名应当存 放在该标签下。按GB/T 17552 的规定。” |
||
——明确了GPO响应的两种格式; |
将原规范B.8.4 响应报文的数据域中GPO响应报文格式“响应报文中的数据对象是一个标签为‘80’的基本数据对象。数据域由如表B.13所示的应用交互特征(AIP)和应用文件定位器(AFL)的值域连接而成,各数据对象之间没有分隔符(标签和长度)。”定义为格式一,另外增加格式2“响应报文中的数据对象是一个标签为‘77’的基本数据对象。数据域可以包含多 |
||
|
个BER-TLV编码的对象,但至少要包含应用交互特征(AIP)和应用文件定位器(AFL)。” |
||
——明确了发卡行脚本的 执行与发卡行认证的关系; |
将原规范17.5应用解锁命令描述“即使卡片支持发卡行认证,也不需要执行。”修改为“卡片应当能够正常处理应用解锁命令,无论发卡行认证是否执行。” 在原规范17.6.2 卡片脚本处理中添加“卡片不应当因发卡行认证未执行而拒绝执行发卡行脚本。若发卡行认证执行但失 败,则卡片应当拒绝执行发卡行脚本,推荐此时卡片以‘6985’ 响应发卡行脚本命令。” |
||
——修改标签9F63的名称和值的定义; |
将原规范9F63名称由“卡产品标识信息”修改为“产品标识信息”;将字节9-11“卡产品标识”修改为“产品标识”;将字节10由“本规范保留”修改为“移动支付规范保留”。 |
||
——删除附录F中对SSF33 算法标识的定义; |
删除原规范附录F算法标识 “SSF33”的描述。 |
||
——明确了终端在GAC命令给出的标签的值与GPO 命令给出的同标签的值不一致时卡片的处理; |
在原规范14.4.1GAC卡片收到密文请求描述中增加“如果CDOL1 和PDOL中均含有某个标签(这些标签包括但不仅限于交易货币代码‘5F2A’、授权金额 ‘9F02’,但不包括终端验证结果‘95’,交易状态信息‘9B’ 和不可预知数‘9F37’),但终 端在生成应用密文(GENERATE AC)命令中给出的标签的值与取处理选项(GPO)命令中给出的标签的值不一致,卡片应当以生成应用密文(GENERATE AC)命令中收到的该值为准,在该笔交易的后续所有流程中均应使用 该值。卡片不应因生成应用密文 (GENERATE AC)命令中某个标签的值与取处理选项(GPO)命令中某个标签的值不一致而以非‘9000’响应生成应用密文 |
||
|
(GENERATE AC)命令。” |
||
——对原标准在文字描述上的勘误做出修正。 |
|||
第6部分:借记/贷记应用终端规范 |
修订 |
——修订了标准的前言; |
|
——删除了第7.2节中终端 构建候选应用列表时对 DDF的支持; |
删除了原第7.2节中终端构建候选应用列表时对DDF的支持; |
||
——在第7.4节中明确了若卡片返回标签重复,终端应当终止交易; |
将原7.4.4读应用数据处理流程中描述“如果读取到终端无法理解的数据,将其忽略。”修改为“如果读取到TLV格式正确但规范未定义的标签,终端应将其保存以备后用,终端不应因此而终止交易。” 将原7.4.4读应用数据处理流程中终端应当终止交易的情况一 “一个基本数据对象在卡片中出现超过一次”修改为“卡片在一条或多条记录中返回同一个标签两次及两次以上”;新增另外一种可能终止交易的情况 “卡片在某条记录中返回了卡片已经在GPO响应中返回的标签”。 |
||
——在第7.4节中明确了终端不应当应为持卡人姓名和/或持卡人姓名扩展有误而终止交易; |
在原7.4.4读应用数据处理流程中增加了几种不应当终止交易 的情况:“——卡片返回了持卡人姓名(5F20)但该标签的长度 不符合JR/T 0025.5的规定; ——卡片返回了持卡人姓名扩 展(9F0B)但该标签的长度不符合JR/T 0025.5的规定;——卡片既返回了持卡人姓名(5F20) 也返回了持卡人姓名扩展 (9F0B)。” 删除原7.12发卡行脚本处理描述“发卡行脚本的处理应参见 EMV4.1第三册10.10节和第四册 6.3.9节的规定进行。” |
||
|
——在第7.12节中明确了发卡行脚本的格式和终端的处理方法; |
将原7.12发卡行脚本处理描述 “主机返回的是封装在72模板里的一个或多个发卡行脚本命 令。发卡行脚本格式的具体描述参见EMV4.1第三册的10.10中图 10和图11。”修改为“一个标签 72的BER-TLV编码的结构数据对象称为一个发卡行脚本。一个发卡行脚本里应当包含一条或多条准备发送给IC卡的发卡行脚本命令,每一条发卡行脚本命令以标签为86的BER-TLV格式编 码。一个发卡行脚本还可以包含且仅包含一条发卡行脚本标识,发卡行脚本标识的标签为9F18。 发卡行脚本中是否包含发卡行脚本标识是可选的,终端和卡片无须解释该标识的含义。发卡行脚本的具体格式请见表33(发卡行脚本格式)和表34(发卡行脚本命令格式)。” 在原7.12.4.1发卡行脚本描述中增加“无论发卡行是否批准交易,也无论卡片是否批准交易,终端都应当执行发卡行脚本。” 在原7.12.4.3脚本错误中当命令处理失败终端的处理中增加步骤4“置发卡行脚本结果低半 字节为出错的命令序号。” 将原7.14.4.7给发卡行通知的 描述“脚本处理完成之后,终端应该以清算报文、下次联机授权报文或通知报文向发卡行传送脚本处理结果。”修改为“终端必须具备将发卡行脚本结果传送给发卡行的能力。脚本处理完成之后,终端应当在下一笔联机交易报文(包括但不仅限于冲正、批上送、批结算、联机授权、通知)报文向发卡行传送脚本处理结果。” |
|
——对原标准在文字描述上的勘误做出修正。 |
|||
部分:借记贷记应用安全规范 |
修订 |
——修订了标准的前言。 |
|
第8部分:与应用无关的非接触式规范z |
修订 |
——修订了标准的前言; |
|
——删除了对JR/T0025已废止部分的引用。 |
|||
第9部分:电子钱包扩展应用指南 |
废止 |
——修订了标准的前言。 |
|
第10部分:借记贷记应用个人化指南 |
修订 |
——修订了标准的前言; |
|
——增加了第6.5节“个人 化数据必须遵循的规则”。 |
在原规范基础上增加“6.5个人化数据必须遵循的规则,详情如下: 如果发卡机构期望启用qPBOC功能,则卡片附加处理(9F68)必 须被个人化至卡中。 如果CVM列表中存在脱机PIN的 入口,则脱机PIN的值以及PIN 尝试限制数应当被个人化至卡 中,且PIN尝试计数器(9F17) 的值应当能被GetData命令取回。 依据JR/T0025.12,电子现金余额(9F79)的取得方式为GetData 命令,故电子现金余额(9F79)不应当被写入可供终端用Read Record命令读出的记录中。 发卡机构应当发行支持DDA和/ 或CDA的卡片,不应发行仅支持 SDA的卡片。 CDOL1和CDOL2应被放置在AFL 中指明的参与脱机数据验证的记录中。 如果卡片上存在磁条,那么芯片中数据应当遵循下列规则: ——磁条2等效数据(57)中的主账号应当与磁条第2磁道数据中的主账号保持一致; ——磁条2等效数据(57)中的失效日期应当与磁条第2磁道数据中的失效日期保持一致; ——磁条2等效数据(57)中的服务代码应当与磁条第2磁道数据中的服务代码保持一致; ——应用主账号(5A)应当与磁 |
||
|
条第2磁道数据中的主账号保持一致; ——应用失效日期(5F24)的年月值应当与磁条第2磁道数据中 的失效日期保持一致; ——服务码(5F30)应当与磁条第2磁道数据中的服务代码保持一致。 在任何情况下,AFL与数据分组的设计,必须同时遵循下列规则: ——同一笔交易,同一条记录同一个数据元应只出现一次; ——同一笔交易,不同的记录中同一个数据元应只出现一次; ——同一笔交易,GPO响应中已经返回的数据不应在读记录时 再次返回。(特别注意的是,包括但不仅限于qPBOC脱机批准交易时的5F34)。” |
||
第11部分:非接触式IC卡通讯规范 |
修订 |
——修订了标准的前言; |
|
——对一些参数的值做出 修订,使之兼容ISO/IEC 14443:2011。 |
|||
第12部分:非接触式IC卡支付规范 |
修订 |
——修订了标准的前言; |
|
——删除了所有MSD 的相关内容; |
|||
——删除了授权金额为零时,卡片必须请求联机的要求,以兼容新增补的qPBOC 扩展应用; |
将原6.2.2 具有qPBOC能力终端中的交易预处理中描述“如果授权金额为零,具有联机能力的终端应在终端交易属性字节2的第8位表示要求联机应用密文;如果授权金额为零,仅支持脱机的终端应终止交易,提示持卡人使用另一种界面(如果存在)” 修订为“如果授权金额为零,除非终端支持qPBOC 扩展应用,具有联机能力的终端应在终端交易属性字节2的第8位表示要求 联机应用密文;如果授权金额为零,除非终端支持qPBOC 扩展应用,仅支持脱机的终端应终止交易,提示持卡人使用另一种界面 (如果存在)” |
||
|
——将原规范各章节中 “PBOC 应用”更改为更确切的描述“借记/贷记应用”; |
||
——将交易日志由不记录更改为发卡机构可选地记录; |
将原6.1.5qPBOC通用卡片选项描述“卡片可以支持交易日志”修改为“卡片应支持记录交易日志的功能,该功能可在个人化时通过卡片附加处理开启或关闭(详见表13 卡片附加处理(标签“9F68”))。是否启用交易日志功能由发卡机构决定。” |
||
——卡片联机GPO 响应数据中新增了9F63 的要求,以适应不断增长的使用需求; |
在原规范卡片联机GPO 响应数 据中新增了9F63(卡标识信息)的要求,以适应不断增长的使用需求,详见“表11 qPBOC 联机交易或拒绝交易的GPO 响应数据”。 |
||
——将第7.7.13 节中计数器增长与比较的方法做出 修正,使之与JR/T0025.5 的描述保持一致; |
将原7.7.13 节中计数器增长与比较的方法描述“如果连续交易计数器(国际)小于或等于连 续交易上限(国际—标签 “9F53”),那么卡片应当”修改为“如果连续交易计数器(国际—货币)小于连续脱机交易限 制数(国际—货币)(标签 “9F53”)”,去除“连续交易计数器等于连续交易上限的情况” |
||
——明确了GPO 响应应遵循JR/T 0025.5 中的格式 2; |
将原6.5.1终端初始化应用处理的通用要求描述“所有终端应 支持采用JR/T 0025.5的GPO响应”修改为“所有终端应支持采用JR/T 0025.5 的格式2 的 GPO 响应”。 |
||
——明确了9F10 中发卡行自定义数据的要求; |
将原规范9F10中发卡行自定义数据的描述“当请求联机处理 时(ARQC),标签‘9F10’中的发卡行自定义数据也可以包含可用脱机消费金额。”修改为 “标签‘9F10’中的发卡行自定义数据也可以包含可用脱机消费金额。”,去除掉“请求联 |
||
|
机处理(ARQC)”的条件,详见 “表11 qPBOC 联机交易或拒绝交易的GPO 响应数据”。 |
||
——明确了附录C.1 中的 TAG 的取得及修改方式; |
对原附录C.1中关于TAG的取得和修改方式做了明确:卡片CVM 限额9F6B标签应可以被PUTDATA 命令修改;电子现金余额9F79、电子现金余额上限9F77、电子现金重置阈值9F6D、电子现金单笔 交易限额9F78不应在READ RECORD 命令中返回;新增了电 子现金发卡行授权码9F74的描述,详见“表 C.1 数据元”。 |
||
——明确了qPBOC 脱机交易最后一条记录的长度; |
在原7.5qPBOC卡片需求中,为保证脱机交易的挥卡成功率,新增描述“qPBOC 脱机批准的交易, AFL 指明的终端须读取的最后一条记录的70 模板的长度应不超过32字节。建议在这条记录中 仅放置电子现金发卡行授权码 (9F74)。” |
||
——修订了原规范中一些 排版及文字描述上的勘误。 |
|||
第13部分:基于借记贷记应用的小额支付规范 |
修订 |
——修订了标准的前言; |
|
——新增了圈存日志的要求; |
在原5.1卡片及终端技术要求新增数据元中增加标签DF4D圈存日志入口和DF4F圈存日志格式, 详见“表1 卡片数据元”、 “5.8圈存日志”、“10.2日志查询”。 |
||
——明确了终端在交易时及交易后取得卡片中电子现金余额的方法; |
将原8 调整电子现金余额中描述“如果要更新的电子现金余额大于电子现金余额上限,返回失败。”修改为“如果要更新的电子现金余额大于电子现金余额上限,卡片对更新数据(Put Data)命令应返回失败。如果更新电子现金余额成功,卡片应记录一条圈存日志。圈存日志的要求见本部分第5.8节和第10.2 节。”;圈存日志格式详见表10、表11 |
||
|
——明确了表1中数据元的取回方法; |
将原表1(卡片数据元)电子现金重置阈值的描述“触发卡片进行自动圈存的可用余额下限,当卡片上的脱机可用余额低于该阈值时,卡片即请求联机并自动进行充值。”修改为“触发卡片进行自动圈存的余额下限,当卡片上的电子现金余额小于该阈值时,终端即请求联机,发卡行可对该交易下发发卡行脚本,以完成自动圈存。”;将电子现金终端交易限额的描述“若存在此数据元,当授权金额高于此限制时,该交易不为电子现金交易;若不存在此数据元,当授权金额高于终端最低限额时,该交易不为电子现金交易。”修改为 当授权金额大于等于终端最低 限额(9F1B)时,终端将电子现金终端支持指示器的值置为零,并不将该交易作为电子现金交易处理。” |
|
——明确了终端在GAC命令给出的标签的值与GPO 命令给出的同标签的值不一致时卡片的处理; |
在原7.4.5卡片行为分析的步骤描述中增加了终端在GAC命令给出的标签的值与GPO命令给出的同标签的值不一致时卡片的处理步骤,将“若终端请求脱机批准,卡片从电子现金余额中扣除授权金额”修改为“若终端请 求脱机批准,则卡片应检查终端在GENERATEAC命令中给出的标签的值与GPO命令中给出的标签的值是否一致(这些标签包括但 不仅限于交易货币代码 ‘5F2A’、授权金额‘9F02’,但不包括终端验证结果‘95’,交易状态信息‘9B’和不可预 知数‘9F37’)。如果检查的结果为一致,则卡片从电子现金余 |
||
|
额中扣除授权金额并在 GENERATE AC命令响应中返回 TC,否则卡片在GENERATEAC命令响应中返回AAC”。 |
||
——删除参考文献; |
|||
——修订了原规范中一些文字描述上的勘误。 |
|||
第14部分:非接触式IC卡小额支付扩展应用 |
制定 |
||
第15部分:电子现金双币支付应用规范 |
制定 |
||
第16部分:IC卡互联网终端规范 |
制定 |
||
第17部分:借记贷记应用安全增强规范 |
制定 |
文/yanxin8原创,获取更多信息请访问http://yanxin8.com/275.html
PBOC规范(2.0->3.0)对照表的更多相关文章
- C# 语言规范_版本5.0 (第12章 数组)
1. 数组 数组是一种包含若干变量的数据结构,这些变量都可以通过计算索引进行访问.数组中包含的变量(又称数组的元素)具有相同的类型,该类型称为数组的元素类型. 数组有一个“秩”,它确定和每个数组元素关 ...
- C# 语言规范_版本5.0 (第10章 类)
1. 类 类是一种数据结构,它可以包含数据成员(常量和字段).函数成员(方法.属性.事件.索引器.运算符.实例构造函数.静态构造函数和析构函数)以及嵌套类型.类类型支持继承,继承是一种机制,它使派生类 ...
- [转载]GBK 汉字内码扩展规范编码表(1.0 版)
编码表源地址:http://ff.163.com/newflyff/gbk-list/ 编码在线查询:http://www.qqxiuzi.cn/bianma/zifuji.php GBK 汉字内码扩 ...
- 为什么有的编程规范要求用 void 0 代替 undefined
Undefined Undefined 类型表示未定义,它的类型只有一个值,就是 undefined. 任何变量在被赋值前它的值都是 undefined,但是在 JavaScript 引擎中,unde ...
- C# 语言规范_版本5.0 (第18章 不安全代码)
1. 不安全代码 **(注:此章对于跨多语言编程开发非常重要,如遇异常无法完成跨语言,建议使用此种方式.) 如前面几章所定义,核心 C# 语言没有将指针列入它所支持的数据类型,从而与 C 和 C++ ...
- C# 语言规范_版本5.0 (第7章 表达式)
1. 表达式 表达式是一个运算符和操作数的序列.本章定义语法.操作数和运算符的计算顺序以及表达式的含义. 1.1 表达式的分类 一个表达式可归类为下列类别之一: 值.每个值都有关联的类型. 变量.每个 ...
- C# 语言规范_版本5.0 (第1章 介绍)
1. 介绍 C#(读作“See Sharp”)是一种简洁.现代.面向对象且类型安全的编程语言.C# 起源于 C 语言家族,因此,对于 C.C++ 和 Java 程序员,可以很快熟悉这种新的语言.C# ...
- PBOC规范研究
一.ISO14443协议和PBOC关于CID的约定 看过协议的人其实都明白,RATS命令中参数字节的低半字节是CID,期中,CID不能为15. ISO14443协议中要求当RATS命令的CID等于0时 ...
- 开源搜索引擎Iveely 0.7.0发布,不一样,那就让他不一样!
2012年08月05日,Iveely Search Engine 0.1.0发布,今天,怀着对于未来的追求,终于,0.7.0如期和大家见面了,7个版本,历时2年4个月,感谢大家的支持,感谢我不离不弃的 ...
随机推荐
- oracle数据库中的表设置主键自增
oracle中没有自增字段,可通过序列+触发器间接实现,cmd中sqlplus登录,直接运行即可.一般要经过一下几步: 1建立数据表 create table Test_Increase( ...
- 关于cookie
CookieHelper.WriteCookie("DEPID", "theway", depid); //先写入cookie //再读取cookie Us ...
- mac下的一些常识
1,环境变量 EddydeMacBook-Pro:~ eddy$ vi ~/.bash_profile EddydeMacBook-Pro:~ eddy$ vim /etc/profile Eddyd ...
- 常用颜色的RGB值
RGB颜色表 白色:rgb(255,255,255) 黑色:rgb(0,0,0) 红色:rgb(255,0,0) 绿色:rgb(0,255,0) 蓝色:rgb(0,0,255) 青色:rgb(0,25 ...
- iface eth0 inet dhcp
- nagios plugin 开发
https://nagios-plugins.org/doc/guidelines.html#DEVREQUIREMENTS https://blog.centreon.com/good-practi ...
- SQL Server 数据库基础编程
Ø Go批处理语句 用于同时执行多个语句 Ø 使用.切换数据库 use master go Ø 创建.删除数据库 方法1. --判断是否存在该数据库,存在就删除 if (exists ...
- Android WebRTC 音视频开发总结(一)
本系列文章主要总结和分享WebRTC开发过程中的一些经验,转载请说明出处(博客园RTC.Blacker),更多交流与合作请看页面上方的子标题! 一.WebRTC是什么? 可能您还不知道WebRTC是什 ...
- IIS7 配置URL_REWRITE
webconfig 文件 system.webServer节点下配置rewrite 报错 是因为需要安装URL重写 需要安装: https://www.microsoft.com/zh-cn/down ...
- Android 中断线程的处理
我现在对一个用户注册的功能1.用ProgressDialog将当前页面设成不可操作(保留返回键 退出ProgressDialog)2.用一个线程clientThread执行数据的提交和返回 问题:考虑 ...