【具体实施方式】
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
图1为本申请一实施例提供的数据解析方法的流程示意图。如图1所示,该方法包括:
101、客户端从NFC卡中读取待解析的数据。
102、客户端将上述待解析的数据发送给服务端,以供服务端将待解析的数据解析成客户端可识别的结构化数据并返回。
103、客户端接收服务端返回的结构化数据。
本实施例提供一种数据解析方法,可由NFC应用的客户端(简称为客户端)来执行。本实施例提供的方法可用于各种基于NFC的应用中;相应的,本实施例的客户端可以是各种基于NFC的应用的客户端。
举例说明:本实施例的方法可应用于基于NFC的支付应用中,则客户端是基于NFC的支付类应用的客户端。
本实施例的方法可应用于基于NFC实现的各种信息卡(例如交通卡、门禁卡、车票)的读卡应用中;则客户端可以是基于NFC实现的各种信息卡对应的读卡应用的客户端。
本实施例的方法可应用于基于NFC的文件传输类应用中;则客户端可以是基于NFC的文件传输类应用的客户端。
本实施例的方法可应用于基于NFC的电子信息交换类应用中;则客户端可以是基于NFC的电子信息交换类应用的客户端。
本实施例的方法可应用于基于NFC的近距离联机游戏类应用中;则客户端可以是基于NFC的近距离联机游戏类应用的客户端。
在上述各种应用场景中,客户端都需要基于NFC卡中的数据执行相应操作。例如,在支付应用场景中,客户端需要根据NFC卡中的数据完成支付操作。又例如,在文件传输应用场景中,客户端需要根据NFC卡中的数据完成文件传输操作。
通常,NFC卡使用的数据格式与客户端所支持的数据格式没有直接关系,意味着客户端可能无法直接识别从NFC卡读取的数据。在现有技术中,客户端具有对NFC卡中的数据进行解析的功能,客户端可以将NFC卡中的数据解析成客户端可识别的数据,进而基于可识别的数据执行相应操作。但是,NFC卡的种类越来越多,客户端可能随时面对不同种类的NFC卡,并且NFC卡采用的数据格式可能不同,意味着客户端要能够对各种数据格式的NFC数据进行解析,这就要求客户端能够随着NFC卡种类的发展而不断更新。但是,由于客户端升级通常比较耗时、繁琐,所以很多用户不会及时升级客户端,即用户转化率无法达到100%,导致无法及时识别NFC数据。
为解决上述问题,本实施例提供一种数据解析方法,将数据解析功能转移到服务端,将客户端从数据解析中解放出来,使得NFC数据能够及时被解析。具体的:
客户端从NFC卡中读取待解析的数据,将待解析的数据发送给服务端,由服务端对待解析的数据进行解析,将成功解析出的结果数据封装成客户端可以识别的结构化数据并返回给客户端,客户端接收服务端返回的结构化数据,进而可以根据该结构化数据执行相应操作。
可选的,客户端在接收到服务端返回的结构化数据之后,可以通过客户端所在终端展示给用户,以便于用户通过该结构化数据了解相关信息。
在一可选实施方式中,客户端可以向NFC卡发送数据读取指令;NFC卡接收客户端的数据读取指令,并根据数据读取指令读取相应数据,将所读取的数据返回给客户端;客户端接收NFC卡返回的数据,对NFC卡返回的数据进行有效性验证,当NFC卡返回的数据是有效数据时,将NFC卡返回的数据作为待解析的数据。
一般来说,在数据存储和传输过程中,基于数据完整性或有效性等考虑,会在数据字节中额外增加一个或几个比特位作为校验位,以用来检验数据是否完整或有效。可选的,校验位的取值可以是预先设定的,例如0x900];或者,校验位的取值也可以是对数据值做异或处理等方式计算出来的。对NFC数据来说,可以将最后两字节作为校验位。基于此,客户端可以通过NFC卡返回的数据的最后两字节来判断该数据是否是有效数据。例如,若预先设定校验位的取值为0x9000,则客户端可以校验NFC卡返回的数据的最后两字节是不是0x9000,如果是,确定NFC卡返回的数据是有效数据;如果否,确定NFC卡返回的数据是无效数据。又例如,若校验位的取值是采用数据值做异或处理获得的,则客户端可以将NFC卡返回的数据中的数据值做异或处理,获得异或结果,将该异或结果与NFC卡返回的数据的最后两字节的取值进行比较,若一致,则确定NFC卡返回的数据是有效数据;若不一致,则确定NFC卡返回的数据是无效数据。
进一步,虽然NFC卡的种类很多,所应用的场景也很广泛,但是可以按照不同标准对NFC卡进行分类,并从总体上分为几大类别。例如,NFC卡可被分为IsoDep、NFCA、…、NFCV等几大类别。关于IsoDep、NFCA、…、NFCV可参见现有技术的描述。其中,每一大类别又可以划分为不同的小类别。例如,按照具体的传输协议划分,IsoDep类别还可以分为Iso7816和Iso14443。对于Iso7816和Iso14443来说,还可以进一步细分。
本实施例并不限定具体如何对NFC卡分类,但是对于同一类别的NFC卡来说,所使用的指令类别以及指令码等都相同。在本实施例中,指令类别用于指示不同类别的NFC卡所使用的指令码信息;每种类别的NFC所使用的指令码信息包括读取NFC卡各字段值(如NFC卡的ID、NFC卡中的余额、NFC卡的发卡公司的名称等)的指令码,即不同字段对应不同指令码。值得说明的,同一指令码可能会对应多个参数,一个参数对应该类别下一个具体的NFC卡。
在一可选实施方式中,可以通过参数指令映射表来管理每类NFC卡下的指令码和指令码对应的参数。进一步,客户端可以将该参数映射表存储在本地,有利于提高获取指令码对应的参数的效率,并且不需要每次都向服务端请求,有利于节约流量资源。
进一步可选的,客户端可以对该参数指令映射表进行更新,例如定时向服务端发送更新请求,接收服务端发送的更新指令,根据更新指令,更新参数指令映射表。或者,服务端也可以主动向客户端发送更新指令,客户端接收服务端发送的更新指令,根据更新指令,更新参数指令映射表。
值得说明的是,上述更新指令可以包括全部参数与指令码的映射关系,则客户端可以直接用更新指令中的参数与指令码的映射关系替换参数指令映射表中的参数与指令码的映射关系,实现全量更新。或者,上述更新指令也可以仅包括发生变化的参数与指令码的映射关系,则客户端可以直接将更新指令中的参数与指令码的映射关系替换参数指令映射表中相应的参数与指令码的映射关系,或者直接将更新指令中的参数与指令码的映射关系添加到参数指令映射表中,实现增量更新。
基于上述,客户端在向NFC卡发送数据读取指令之前,可以按照以下方式生成数据读取指令:
确定业务需求对应的指令码,在NFC应用中,业务需求一般是指读取NFC数据的需求,预先定义了业务需求与读取字段之间的映射关系,也就是说,业务需求一旦确定了,也就知道需要读取NFC数据的哪个字段。由上述可知,不同字段使用不同指令码,因此可以直接根据业务需求,确定所使用的指令码;根据NFC卡所属的类别下的参数指令映射表,确定业务需求对应的指令码对应的参数;根据业务需求对应的指令码和该指令码对应的参数,生成数据读取指令。
上述数据读取指令中的指令码用于指示要读取NFC数据的哪个字段;指令码对应的参数用于指示要读取哪张NFC卡中的数据。
值得说明的是,一个指令码可能对应多个参数。对于这种情况,客户端可以采用穷举的方式,生成数据读取指令以从NFC卡中读取数据。简单来说,客户端每次获取指令码对应的一个参数,并根据该指令码和该指令码对应的参数生成一个数据读取指令,并发送给NFC卡,当接收到NFC卡返回的数据时,通过对NFC卡返回的数据进行校验来判断NFC卡是否返回了有效数据,也意味着是否使用了正确的参数;如果NFC卡返回的数据是有效数据,意味着使用的参数是正确的,则可以停止尝试其他参数;反之,继续获取指令码对应的下一个参数,并生成数据读取指令发送给NFC卡继续读取NFC卡中的数据。
以基于NFC的交通卡为例,按照地理位置进一步划分,则Iso7816和Iso14443中每个类别下的交通卡包括:北京交通卡、上海交通卡、天津交通卡、深圳交通卡等等。对于每张交通卡来说,可读取的数据包括交通卡中的余额、公交公司的名称、交通卡的ID、以及最近交易记录等字段值,不同字段对应不同的指令码。进一步同一指令码可能对应不同地方的交通卡,则可以通过指令码对应的参数来区分。
对不同交通卡来说,客户端所使用的数据读取指令的格式和内容都会有所不同。例如,客户端发送的数据读取指令可以是应用协议数据单元(Application Protocol Data Unit,APDU)请求。该APDU请求的格式如图2所示,包括:头部和主体部分。头部包括CLA、INS、P1和P2等几个字段;CLA表示指令类别,INS表示指令码;P1和P2是两个参数。主体部分包括:数据长度Lc字段、数据字段和响应数据的长度Le字段。
一种客户端从交通卡中读取数据的代码如下:
按照基本的行业间规定,INS是APDU命令协议中的一个字节,定义该指令码的操作类型,INS的取值与操作类型的对应关系如表1所示。
表1
INS的取值 |
操作类型 |
|
|
‘0E’ |
ERASE BINARY |
‘20’ |
VERIFY |
‘70’ |
MANAGE CHANNEL |
‘82’ |
EXTERNAL AUTHENTICATE |
‘84’ |
GET CHALLENGE |
‘88’ |
INTERNAL AUTHENTICATE |
‘A4’ |
SELECT FILE |
‘BO’ |
READ BINARY |
‘CO’ |
GET RESPONSE |
其中,INS为B0时可以读取到二进制(binary)的比特流,且sfi的取值不同,所读取到的数据也会不同。比如,若要读取上海交通卡中的数据,则需要传入sfi值为21,若要读取北京交通卡中的数据,则需要传入的sfi值为4。对客户端来说,由于无法直接识别出是哪的公交卡,所以可以尝试先向交通卡传入值为21的sfi进行数据读取,如果读取的数据无法通过有效性验证,则继续向交通卡传入值为4的sfi进行数据读取,直到读取到有效数据为止。
在一可选实施方式中,终端设备自身可以提供一NFC系统框架,可称为NFC卡识别应用,该NFC卡识别应用可以在NFC卡贴近具有NFC功能的终端设备时,自动感应到该NFC卡的标签并识别出NFC卡所属的类别,将这些信息提供给上述客户端。
对于NFC卡识别应用来说,可以包括感应单元、Activity、ActivityManager等。感应单元在NFC卡贴近具有NFC功能的终端设备时,自动感应到该NFC卡的标签;Activity Manager用于管理已经注册的Activity;Activity用于处理该Activity对应的NFC标签,主要是识别出NFC标签所标识的NFC卡的类别属性信息。当Activity Manager存在已经注册的Activity,并且可以处理感应单元感应到的NFC卡时,Activity Manager识别出NFC标签所标识的NFC卡的类别属性信息,将该类别属性信息封装到Intent里面传给相应的Activity;Activity将Intent发送给客户端。
上述Activity是安卓系统中常用组件,通常作为一个屏幕的载体。Intent是安卓系统中不同组件之间相互导航的纽带,封装了互相查找的条件信息。
基于上述,客户端可以接收NFC卡识别应用发送的NFC卡的类别属性信息,该类别属性信息用于指示NFC卡所属的类别。在获得NFC卡所属的类别的情况下,客户端可以确定向NFC卡发送数据读取指令所使用的参数指令映射表。
在一可选实施方式中,客户端在将待解析的数据发送给服务端之前,可以对待解析的数据进行编码处理,例如可以采用Base64编码方式,将待解析的数据编码成字节流,以便于传输。其中,Base64是一种比特流转化为字节流的一种编码方式。进一步,客户端通过HTTP方式将编码成的字节流发送到服务端。对服务端来说,在接收到待解析的数据之后,可以先对待解析的数据进行解码处理,再对解码后的数据进行解析处理。
在一可选实施方式中,客户端本身也具有解析NFC数据的功能。基于此,客户端在将待解析的数据发送给服务端之前,可以先判断本地是否可以解析待解析的数据;若本地可以解析,则客户端可以直接在本地对待解析的数据进行解析处理,将其解析成客户端可识别的数据结构;若本地无法解析,则客户端再将待解析的数据发送给服务端,以供服务端将待解析的数据解析成客户端可识别的结构化数据并返回。该实施方式优先在客户端本地对待解析的数据进行解析,一方面可以降低服务端的处理负担,另一方面有利于提高解析效率。
图3a为本申请一实施例提供的数据解析方法的流程示意图。如图3a所示,该方法包括:
301、服务端接收客户端发送的待解析的数据,该待解析的数据是客户端从NFC卡中读取的。
302、服务端对上述待解析的数据进行解析,并将成功解析出的结果数据封装成客户端可识别的结构化数据。
303、服务端将上述结构化数据发送给客户端。
本实施例提供一种数据解析方法,可由NFC应用的服务端(简称为服务端)来执行。本实施例提供的方法可用于各种基于NFC的应用中;相应的,本实施例的客户端可以是各种基于NFC的应用的客户端;服务端可以是各种基于NFC的应用的服务端。在本实施例中,服务端具有解析各种NFC卡的能力。
举例说明:本实施例的方法可应用于基于NFC的支付应用中,则客户端是基于NFC的支付类应用的客户端;则服务端可以是基于NFC的支付应用中服务端。
本实施例的方法可应用于基于NFC实现的各种信息卡(例如交通卡、门禁卡、车票)的读卡应用中;则客户端可以是基于NFC实现的各种信息卡对应的读卡应用的客户端;则服务端可以是基于NFC实现的各种信息卡对应的读卡应用的服务端。
本实施例的方法可应用于基于NFC的文件传输类应用中;则客户端可以是基于NFC的文件传输类应用的客户端;则服务端可以是基于NFC的文件传输类应用的服务端。
本实施例的方法可应用于基于NFC的电子信息交换类应用中;则客户端可以是基于NFC的电子信息交换类应用的客户端;则服务端可以是基于NFC的电子信息交换类应用的服务端。
本实施例的方法可应用于基于NFC的近距离联机游戏类应用中;则客户端可以是基于NFC的近距离联机游戏类应用的客户端;则服务端可以是基于NFC的近距离联机游戏类应用的服务端。
在上述各种应用场景中,客户端都需要基于NFC卡中的数据执行相应操作。例如,在支付应用场景中,客户端需要根据NFC卡中的数据完成支付操作。又例如,在文件传输应用场景中,客户端需要根据NFC卡中的数据完成文件传输操作。
通常,NFC卡使用的数据格式与客户端所支持的数据格式没有直接关系,意味着客户端可能无法直接识别从NFC卡读取的数据。在现有技术中,客户端具有对NFC卡中的数据进行解析的功能,客户端可以将NFC卡中的数据解析成客户端可识别的数据,进而基于可识别的数据执行相应操作。但是,NFC卡的种类越来越多,客户端可能随时面对不同种类的NFC卡,并且NFC卡采用的数据格式可能不同,意味着客户端要能够对各种数据格式的NFC数据进行解析,这就要求客户端能够随着NFC卡种类的发展而不断更新。但是,由于客户端的升级包一般是由服务端按照一定频率发布的,所以更新不是很及时,导致无法及时识别NFC数据。
为解决上述问题,本实施例提供一种数据解析方法,将数据解析功能转移到服务端,将客户端从数据解析中解放出来,使得NFC数据能够及时被解析。具体的:
客户端从NFC卡中读取待解析的数据,将待解析的数据发送给服务端,服务端接收客户端发送的待解析的数据;服务端对待解析的数据进行解析,将成功解析出的结果数据封装成客户端可以识别的结构化数据;之后,将结构化数据发送给客户端,使得客户端可以根据该结构化数据执行相应操作。
在一可选实施方式中,服务端预先存储有客户端及客户端可识别的数据结构之间的映射关系。基于此,客户端还可以将客户端的标识发送给服务端,服务端根据客户端的标识,查询所存储的客户端及客户端可识别的数据结构之间的映射关系,获知客户端所支持的数据结构,进而将待解析的数据解析成客户端可识别的结构化数据。
在另一可选实施方式中,客户端可以将客户端可识别的数据结构信息发送给服务端。服务端接收客户端发送的客户端可识别的数据结构信息,根据客户端可识别的数据结构信息,将待解析的数据解析成客户端可识别的结构化数据。
在一可选实施方式中,服务端包括各种NFC卡对应的解析算法,并且随着NFC卡种类的增多,服务端会及时增加相应的解析算法。基于此,服务端对待解析的数据进行解析的一种实施方式包括:服务端确定NFC卡对应的解析算法,采用所确定的解析算法对应待解析的数据进行解析。
其中,客户端除了将待解析的数据发送给服务端之外,通常还会将NFC卡的类别属性信息发送给服务端;服务端可以根据NFC卡的类别属性信息确定NFC卡所属的类别,进而选择该类别对应的解析算法,使用该解析算法对待解析的数据进行解析。进一步,客户端还可以将读取待解析的数据所使用的数据读取指令发送给服务端,则服务端可以同时结合NFC卡的类别属性信息、读取待解析的数据所使用的数据读取指令、以及待解析的数据等信息,来确定所使用的解析算法。
值得说明的是,由于NFC卡的种类很多,相应NFC卡的厂商也会很多。部分NFC卡的厂商不是按照标准协议,所以服务端可以通过访问厂商官方网站或者其他公关渠道来了解具体协议文档,进而获得解析该待解析的数据需要使用的解析算法。
在一可选实施方式中,若客户端对待解析的数据进行了编码处理,则服务端在对待解析的数据进行解析之前,需要先对待解析的数据进行解码处理。其中,客户端和服务端可以预先约定所使用的编解码算法,例如可以是Base64算法,但不限于此。
在一可选实施方式中,若待解析的数据来自于新的NFC卡,则服务端有可能还没有该NFC卡对应的解析算法,则可能无法成功解析出结果数据。对无法成功解析出结果数据的情况,服务端可以根据该解析的数据和待解析的数据的相关数据,生成该NFC卡对应的解析算法。服务端可以存储该解析算法,以便于对后续接收到的该NFC卡的数据进行解析。待解析的数据的相关数据包括但不限于:客户端获取待解析的数据所使用的数据读取指令、以及用户输入的关于该NFC卡的信息等。
由于生成NFC卡对应的解析算法的过程会因厂商的不同而有所不同,且整体流程与现有技术相类似或相同,可参见现有技术,本申请不再赘述。
以云os生活服务为例,(但本申请不限于云os生活服务),云os生活服务根据业务需求确定指令码,并基于本地存储的参数指令映射表,确定该指令码对应的参数,根据该指令码和该指令码对应的参数生成APDU请求,将该APDU请求发送给NFC卡;接收NFC卡根据该APDU请求返回的数据;根据NFC卡返回的数据的最后两字节的校验码校验该数据是否是有效数据;如果不是,则继续获取指令码对应的下一个参数,并根据该指令码和该指令码对应的一下个参数重新生成APDU请求发送给NFC卡,以重新从NFC卡中读取数据;如果判断结果为是,则采用Base64编码方式将该数据编码成字节流,再通过HTTP方式发送到服务端;服务端对接收到的数据进行解码处理,并确定解析使用的解析算法,采用所确定的解析算法对解码后的数据进行解析,若成功解析出结果数据,将该结果数据封装成云os生活服务可识别的结构化数据,即云卡片(CloudCard)的形式返回给云os生活服务;云os生活服务以CloudCard形式将数据展现给用户。
因为云os生活服务一般内嵌于云os系统桌面,与桌面其他应用相比,云os生活服务的更新频率还是比较低的,对于这种情况,本申请提供数据解析方法将具有很明显的优势,用户可以不用升级整个云os生活服务,即可及时解析出各种NFC卡中的数据,进而将NFC卡中的数据封装成云os生活服务里的CloudCard形式展现给用户。进一步,如图3b所示,云os生活服务还可以通过连接该生活服务的关联服务系统精准推送相应的智能化的关联服务,例如基于用户的NFC卡的商户信息、余额信息等,可以向用户推送附近公交车站、充值中心等关联服务,有利于扩展生活服务的业务和提高用户体验。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请并不受所描述的动作顺序的限制,因为依据本申请,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本申请所必须的。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
图4为本申请一实施例提供的客户端的结构示意图。如图4所示,该客户端包括:读取模块41、发送模块42和第一接收模块43。
读取模块41,用于从NFC卡中读取待解析的数据。
发送模块42,用于将读取模块41读取的待解析的数据发送给服务端,以供服务端将待解析的数据解析成客户端可识别的结构化数据并返回。
第一接收模块43,用于接收服务端返回的结构化数据。
在一可选实施方式中,读取模块41具体用于:
向NFC卡发送数据读取指令;
接收NFC卡根据数据读取指令返回的数据;
对NFC卡返回的数据进行有效性验证,当NFC卡返回的数据是有效数据时,将NFC卡返回的数据作为待解析的数据。
在一可选实施方式中,如图5所示,该客户端还包括:确定模块44和生成模块45。
确定模块44,用于确定业务需求对应的指令码,并根据NFC卡所属的类别下的参数指令映射表,确定指令码对应的参数。
生成模块45,用于根据确定模块44确定的指令码和指令码对应的参数,生成数据读取指令。
在一可选实施方式中,如图5所示,该客户端还包括:第二接收模块46,用于在确定模块44根据NFC卡所属的类别下的参数指令映射表,确定指令码对应的参数之前,接收NFC卡识别应用发送的NFC卡的类别属性信息,类别属性信息用于指示NFC卡所属的类别。
在一可选实施方式中,如图5所示,该客户端还包括:第三接收模块47和更新模块48。
第三接收模块47,用于接收服务端发送的更新指令;
更新模块48,用于根据第三接收模块47接收的更新指令,更新参数指令映射表。更新模块48用于向确定模块44提供更新后的参数指令映射表。
在一可选实施方式中,如图5所示,该客户端还包括:编码模块49,用于在发送模块42将待解析的数据发送给服务端之前,对待解析的数据进行编码处理。
在一可选实施方式中,如图5所示,该客户端还包括:判断模块50。
判断模块50,用于判断本地是否可以解析所述待解析的数据,并在判断结果为否时,触发发送模块42执行将所述待解析的数据发送给服务端,以供所述服务端将所述待解析的数据解析成所述客户端可识别的结构化数据并返回的操作。
在一可选实施方式中,如图5所示,该客户端还包括:展示模块51。
展示模块51,用于通过客户端所在终端将第一接收模块43接收的结构化数据展示给用户。
本实施例提供的客户端,从NFC中读取待解析的数据,将待解析的数据发送给服务端,由服务端对待解析的数据进行解析并生成客户端可识别的结构化数据返回给客户端,实现对NFC数据的解析,同时由于该解析过程是由服务端完成的,不用等待对客户端的更新升级,可以更加及时的对各种NFC数据进行解析。
图6为本申请一实施例提供的服务端的结构示意图。如图6所示,该服务端包括:接收模块61、解析模块62和发送模块63。
接收模块61,用于接收客户端发送的待解析的数据,待解析的数据是客户端从NFC卡中读取的。
解析模块62,用于对接收模块61接收的待解析的数据进行解析,并将成功解析出的结果数据封装成客户端可识别的结构化数据。
发送模块63,用于将解析模块62解析出的结构化数据发送给客户端。
在一可选实施方式中,解析模块62具体用于:
确定NFC卡对应的解析算法;
采用解析算法对待解析的数据进行解析;
将成功解析出的结果数据封装成客户端可识别的结构化数据。
在一可选实施方式中,如图7所示,该服务端还包括:生成模块64。
生成模块64,用于在解析模块62无法成功解析出结果数据时,根据待解析的数据和待解析的数据的相关数据,生成NFC卡对应的解析算法。
在一可选实施方式中,如图7所示,该服务端还包括:解码模块。
解码模块65,用于在解析模块62对待解析的数据进行解析之前,对待解析的数据进行解码处理。
本实施例提供的服务端,与上述实施例提供的客户端相配合,接收客户端发送的从NFC卡中读取的待解析的数据,对待解析的数据进行解析并生成客户端可识别的结构化数据返回给客户端,实现对NFC数据的解析,同时由于该解析过程是由本实施例的服务端完成的,不用等待对客户端的更新升级,可以更加及时的对各种NFC数据进行解析。
本申请一实施例还提供一种数据解析系统,包括:客户端和服务端。
其中,客户端,用于从NFC卡中读取待解析的数据,将待解析的数据发送给服务端,并接收服务端返回的客户端可识别的结构化数据;
服务端,用于接收客户端发送的待解析的数据,对待解析的数据进行解析,并将成功解析出的结果数据封装成结构化数据,将结构化数据发送给客户端。
关于客户端的其他功能以及客户端的实现结构可参见前述相应实施例,在此不再赘述。同理,关于服务端的其他功能以及服务端的实现结构可参见前述相应实施例,在此不再赘述。
在本实施例提供的数据解析系统中,服务端与客户端相配合,接收客户端发送的从NFC卡中读取的待解析的数据,对待解析的数据进行解析并生成客户端可识别的结构化数据返回给客户端,实现对NFC数据的解析,同时由于该解析过程是由本实施例的服务端完成的,不用等待对客户端的更新升级,可以更加及时的对各种NFC数据进行解析。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元,可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。