验证方法、装置、介质以及设备与流程

本申请涉及公共交通技术领域，尤其涉及一种验证方法、装置、介质、以及终端设备和验证设备。

背景技术：

随着智能终端的普及和移动互联网技术的应用，移动支付已经深入人们生活的方方面面。当前，在公交和地铁等公共交通领域，采用较多的移动支付方式是乘车码方式，由于乘车码方式使用方便并且对终端设备配置要求不高，因此，该方式已经应用的非常成熟，其发展也相当迅速。

目前在地铁以及公交等分段计费的公交场景中，由于设备异常或者用户误操作常常会出现单边刷码的行为，所谓单边刷码是指用户在一次乘车消费时仅实施了一次刷码的行为，对应只有一条扫码记录；例如用户乘地铁时，仅进站时刷码但出站时未刷；或者仅进站时未刷但出站时刷码了；这种单边刷码的产生，会造成计费混乱，存在一定的资金风险。

现有技术中为了控制单边刷码行为的产生，在验票过程中，由验证设备实时与管理服务器进行网络通信，以获取用户的历史扫码记录，进而根据该历史扫码记录来判断用户当前的刷码行为是否正常，以有效控制单边刷码的异常交易发生；但由于公共交通的网络环境常不稳定，经常会出现网络异常现象，在网络异常或者管理服务器无法提供服务时，验证设备就无法判断用户当前的刷码行为是否正常，此时一般会禁止乘客乘车，造成交通混乱的情况，为了缓解交通混乱现象，有时也会允许乘客乘车，但这就会产生大量的单边刷码，造成计费混乱。

技术实现要素：

本申请实施例提供了一种验证方法、装置以及设备，使得验证设备能够离线判断乘车码的码状态，无需与管理服务器通信查找乘客的扫码记录，即使管理服务器网络异常，也能快速判断乘车码的有效性，能够有效防止用户由于误操作出现的单边刷码现象发生，避免单边计费。

有鉴于此，本申请一方面提供了一种验证方法，所述方法包括：

响应于第一乘车码生成指令，获取第一乘车码，所述第一乘车码中包括用户身份信息和第一码状态，所述第一码状态用于表示所述第一乘车码对应的行程状态，所述行程状态包括行程起始状态或者行程终止状态；

显示所述第一乘车码，以使所述验证设备扫描所述第一乘车码，并根据所述第一乘车码进行验票。

本申请一方面提供了一种验证装置，所述装置包括：

获取单元，用于响应于第一乘车码生成指令，获取第一乘车码，所述第一乘车码中包括用户身份信息和第一码状态，所述第一码状态用于表示所述第一乘车码对应的行程状态，所述行程状态包括行程起始状态或者行程终止状态；

显示单元，用于显示所述第一乘车码，以使所述验证设备扫描所述第一乘车码，并根据所述第一乘车码进行验票。

本申请一方面提供了一种终端设备，所述设备包括处理器以及存储器：

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令，执行如本申请提供的验证方法的步骤。

本申请一方面提供了一种验证方法，包括：

扫描终端设备上的第一乘车码，获取所述第一乘车码中的用户身份信息和第一码状态；所述第一码状态用于表示所述第一乘车码对应的行程状态，所述行程状态包括行程起始状态或者行程终止状态；

验证所述用户身份信息，以及根据验证设备的功能状态验证所述第一码状态，所述验证设备的功能状态表示所述验证设备用于验证一次行程的行程起始状态或者行程终止状态；

若验证均通过，则确定验票成功。

可选的，所述向所述终端设备返回所述第二码状态，包括：

通过近场通信、蓝牙或者无线网络与所述终端设备通信，以向所述终端设备返回所述第二码状态。

可选的，所述验证设备包括地铁闸机。

本申请一方面提供了一种验证装置，所述装置包括：

扫描单元，用于扫描终端设备上的第一乘车码，获取所述第一乘车码中的用户身份信息和第一码状态；所述第一码状态用于表示所述第一乘车码对应的行程状态，所述行程状态包括行程起始状态或者行程终止状态；

验证单元，用于验证所述用户身份信息，以及根据验证设备的功能状态验证所述第一码状态，所述验证设备的功能状态表示所述验证设备用于验证一次行程的行程起始状态或者行程终止状态；

确定单元，用于若验证均通过，则确定验票成功。

本申请一方面方面提供一种验证设备，所述验证设备包括处理器以及存储器：

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令，执行如本申请提供的验证方法的步骤。

本申请一方面提供一种计算机可读存储介质，所述计算机可读存储介质用于存储程序代码，所述程序代码用于执行本申请提供的验证方法。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请实施例中提供了一种验证方法，通过在乘车码中携带表征行程起始状态或者行程终止状态的码状态，使得验证设备在验证乘车码的有效性时，直接根据乘车码中携带的码状态快速判断乘车码的有效性，验证设备仅通过扫描客户端的乘车码即可在离线情况下完成验证，无需与管理服务器进行网络通信查询扫码记录，这样，即使管理服务器网络异常或无法提供服务，也不会影响乘车码有效性的判断，如此，可以有效防止用户由于误操作而出现的单边刷码发生，避免计费混乱。

附图说明

图1为本申请实施例中一种验证方法的场景架构图；

图2为本申请实施例中一种验证方法的流程图；

图3为本申请实施例中一种验证方法的流程图；

图4为本申请实施例中一种验证方法的流程图；

图5为本申请实施例中一种验证方法的交互流程图；

图6为本申请实施例中一种验证方法的场景示意图；

图7为本申请实施例中一种验证装置的一个结构示意图；

图8为本申请实施例中一种验证装置的一个结构示意图；

图9为本申请实施例中一种验证装置的一个结构示意图；

图10为本申请实施例中一种验证装置的一个结构示意图；

图11为本申请实施例中一种验证装置的一个结构示意图；

图12为本申请实施例中一种终端设备的一个结构示意图；

图13为本申请实施例中一种验证设备的一个结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

针对现有技术中验证设备在网络异常或者管理服务器无法提供服务时，难以从管理服务器获取用户的历史扫描记录，进而难以判断用户当前的刷码行为是否正常，容易造成交通混乱或者单边刷码导致的计费混乱这一技术问题，本申请提供了一种验证方法，具体为，客户端响应于第一乘车码生成指令，获取第一乘车码，然后显示该第一乘车码，验证设备可以扫描第一乘车码，获得第一乘车码中的用户身份信息和第一码状态，然后验证用户身份信息，并根据验证设备的功能状态验证第一码状态，从而实现对乘车码有效性的验证。

在该方法中，由于乘车码中携带了表征行程起始状态或行程终止状态的码状态，因而验证设备在验证乘车码的有效性时，无需与管理服务器网络通信查询扫码记录，即可根据码状态以及验证设备的功能状态快速判断乘车码的有效性，并且该判断过程可以在离线情况下进行，即使管理服务器网络异常或无法提供服务，也不会影响乘车码有效性的判断，如此，可以有效防止用户由于误操作而出现的单边刷码发生，避免计费混乱。

应理解，本申请实施例提供的上述方法可以应用于终端设备，该终端设备安装有客户端，通过客户端与验证设备交互实现该方法；其中，客户端可以是独立的应用程序，也可以是集成于其他应用程序上的功能模块，如小程序、插件等等。在本实施例中，终端设备可以是具有数据处理能力的计算设备，包括智能手机、平板电脑或个人计算机(personalcomputer，pc)等设备。对应的，本申请实施例中的验证设备是一种对乘车码进行验证的设备，包括地铁闸机或者公交验票机等等，本实施例对此不作限定。

为了使本申请的技术方案更加清楚，下面将结合具体场景对本申请实施例提供的验证方法进行介绍。

图1为本申请实施例中验证方法的场景架构图，如图1所示，图1中包括终端设备10和验证设备20，终端设备10上安装有客户端，客户端通过终端设备10与验证设备20交互，从而实现乘车码验证。

具体地，客户端响应于第一乘车码生成指令，获取第一乘车码，第一乘车码中包括用户身份信息和第一码状态，其中第一码状态用于表示该乘车码对应的行程状态，行程状态是指行程起始状态或行程终止状态。然后，客户端显示该第一乘车码。

验证设备20扫描客户端上的第一乘车码，获取第一乘车码中的用户身份信息和第一码状态，然后，验证用户身份信息，以及根据验证设备的功能状态验证第一码状态，若验证均通过，则确定验票成功。

在该实施例中，由于乘车码中携带了表征行程起始状态或者行程终止状态的码状态信息，验证设备不仅对用户身份信息进行验证，还根据自身的功能状态对码状态进行验证，如此，保证了码状态的正确性，避免了单边刷码现象的发生。并且，验证设备无需用管理服务器网络通信，即可获取码状态，如此，可以实现离线验证乘车码的有效性，即使网络异常或者管理服务器无法提供服务，也不会对乘车码的有效性验证造成较大的影响。

为了便于理解，下面将分别从客户端以及验证设备的角度对本申请实施例提供的验证方法进行介绍。

图2为为本申请实施例提供的一种验证方法的流程图，该方法应用于终端设备，请参见图2，该方法包括：

s201：响应于第一乘车码生成指令，获取第一乘车码。

所述第一乘车码中包括用户身份信息和第一码状态，所述第一码状态用于表示所述第一乘车码对应的行程状态，所述行程状态包括行程起始状态或者行程终止状态。

在本实施例中，乘车码是用户乘车的一种凭据。用户出示乘车码，在该乘车码验证通过后可以乘车。乘车码具有多种表现形式，例如，可以是一维码，也可以是二维码。当乘车码为二维码时，该乘车码还可以是不同结构的二维码，作为一个示例，该乘车码可以是堆叠式二维码或者矩阵式二维码，其中，矩阵式二维码的一个典型示例为快速响应(quickresponse，qr)码。

第一乘车码是指一次行程中的一个乘车码。第一乘车码可以是行程起始时的乘车码，也可以是行程终止时的乘车码。第一乘车码中包括用户身份信息和第一码状态。其中，用户身份信息是指表征用户身份的信息，作为一个示例，用户身份信息可以为用户名、手机号等等。第一码状态则是用于表征乘车码对应的行程状态的一种信息。通过在第一乘车码中增加第一码状态信息，可以通过对第一码状态进行验证以避免漏刷码或误刷码的现象发生。

在本实施例中，终端设备中的客户端可以响应于第一乘车码生成指令，获取第一乘车码。其中，第一乘车码可以通过离线或在线的方式生成。可以理解，离线生成乘车码的方式使得即使网络异常，也可以生成第一乘车码，降低了网络环境对乘车过程的影响。而通过在线生成乘车码的方式，可以由应用服务器生成乘车码，降低客户端的计算压力。

在一些可能的实现方式，客户端可以向应用服务器发送第一生成请求，第一生成请求中包括用户身份信息和当前行程的行程状态，然后接收应用服务器返回的第一乘车码。在该实现方式中，第一乘车码是由应用服务器根据第一生成请求中的用户身份信息和当前行程的行程状态生成的。

具体的，以第一乘车码为qr码为例，简单说明一下第一乘车码的生成过程。应用服务器可以对用户身份信息和当前行程的行程状态等数据进行数据分析，确定编码的字符类型，按照相应的字符集转换成符号字符，并选择纠错等级，然后，应用服务器对符号字符进行数据编码，即将数据字符转换为位流，每8位构成一个码字，从而构成数据的码字序列，接着进行纠错编码，按需要将码字序列分块，根据纠错等级和分块的码字，产生纠错码字，将纠错码字加入到数据的码字序列之后，形成新的序列，接着在规格确定的条件下，将新的序列按次序放入分块中，构造最终数据信息，最后，将探测图形、分隔符、定位图形、校正图像和码字模块放入矩阵中，形成矩阵，对矩阵进行掩模，并生成格式和版本信息放入相应区域，即得到第一乘车码。

在一些可能的实现方式中，客户端也可以根据用户身份信息和当前行程的行程状态，直接生成第一乘车码。该实现方式中，客户端无需向应用服务器发送请求，而是根据自身存储的用户身份信息和行程状态信息，离线生成第一乘车码。其中，客户端生成第一乘车码的过程与应用服务器生成第一乘车码的过程类似，在此不再赘述。

s202：显示所述第一乘车码，以使所述验证设备扫描所述第一乘车码，并根据所述第一乘车码进行验票。

客户端在获取到第一乘车码后，显示第一乘车码，如此，验证设备可以扫描第一乘车码，根据第一乘车码进行验票，从而确定是否允许用户通过。

其中，显示第一乘车码可以有多种实现方式。在一些可能的实现方式中，可以在客户端的当前页面直接显示第一乘车码，当然，在有些情况下，也可以采用弹窗的方式显示第一乘车码，或者，在当前页面基础上新增一个页面，从当前页面跳转至新增页面，在该新增页面上显示第一乘车码。

由上可知，本申请实施例提供了一种验证方法，通过在乘车码中携带表征行程起始状态或者行程终止状态的码状态，使得验证设备在验证乘车码的有效性时，直接根据乘车码中携带的码状态快速判断乘车码的有效性，验证设备仅通过扫描客户端的乘车码即可在离线情况下完成验证，无需与管理服务器进行网络通信查询扫码记录，这样，即使管理服务器网络异常或无法提供服务，也不会影响乘车码有效性的判断，如此，可以有效防止用户由于误操作而出现的单边刷码发生，避免计费混乱。

在本实施例中，用户乘车时，在行程起始和行程结束时均需要刷码验证。以乘坐地铁为例，用户在进站时需要刷乘车码，在出站时也需要刷乘车码。基于此，验证设备不仅在行程起始时对乘车码的有效性进行验证，在行程结束时也需要对乘车码的有效性进行验证。

在验票成功后，应当对行程状态进行更新，以便进行下一次验证。客户端可以在收到验证设备的指示后，主动更新行程状态，也可以由验证设备更新行程状态，并将更新后的行程状态发送给客户端，以便客户端更新行程状态。一些可能的实现方式中，客户端接收验证设备在验票成功后返回的第二码状态，其中，第二码状态与第一码状态相反，然后，存储该第二码状态，并将该第二码状态作为下一次乘车码生成请求所需的行程状态。在具体实现时，第二码状态与第一码状态相反包括两种情况，一种情况是，第一码状态为行程起始状态，则对应的第二码状态为行程终止状态；另一种情况是，第一码状态为行程终止状态，则对应的第二码状态为行程起始状态。

其中，客户端需要与验证设备通信，以接收验证设备在验票成功后返回第二码状态。在一些可能的实现方式中，客户端可以通过近场通信(nearfieldcommunication，nfc)、蓝牙或者无线网络与验证设备通信，以接收验证设备在验票成功后返回的第二码状态。

在本实施例中，若码状态不一致，则可以导致验票失败。例如，在上一次行程中，用户在出站时，未刷乘车码，如此，客户端存储的码状态为表征行程终止状态的码状态，当客户端根据该码状态生成乘车码时，其码状态与用于进站验证的验证设备的功能状态不一致，验证设备验票失败。为此，可以通过客户端对历史行程进行补正，例如，将未刷乘车码的行程补录到管理服务器中，以便管理服务器维护较为准确的行程信息，并根据该准确的行程信息更新码状态。

在本实施例一些可能的实现方式中，客户端可以接收历史行程的补正行程信息，向管理服务器发送历史行程的补正行程信息，以使管理服务器根据历史行程的补正行程信息更新历史行程的行程信息，并更新码状态。可以理解，在将历史行程的补正行程信息更新到管理服务器中，管理服务器更新码状态后，客户端可以根据更新的码状态获取第二乘车码，显示该第二乘车码以便验证设备对该第二乘车码的有效性进行验证。

下面将结合附图，对本申请实施例中对历史行程补正后的验证方法进行介绍。

图3为本申请实施例提供的一种验证方法的流程图，该方法是在图2所示实施例基础上改进得到的，本实施例仅就与图2所示实施例的区别之处进行说明，相同部分可以参见图2所示实施例。如图3所示，该方法包括：

s301：接收所述管理服务器返回的变更后的码状态。

在本实施例中，管理服务器可以对行程信息进行管理。当行程状态发生变更时，管理服务器可以更新表征行程状态的的码状态，得到变更后的码状态。其中，变更后的码状态可以是管理服务器响应于更新历史行程的行程信息的操作，对码状态进行更新得到的。

客户端接收管理服务器返回的变更后的码状态。由于码状态表征当前行程的行程状态，而行程状态包括行程起始状态或行程起止状态，则变更后的码状态即为两种状态中与原码状态不同的另一码状态。例如，若原码状态为行程起始状态，则管理服务器返回的变更后的码状态为行程终止状态；若原码状态为行程终止状态，则管理服务器返回的变更后的码状态为行程起始状态。

s302：响应于第二乘车码生成指令，获取第二乘车码，所述第二乘车码中包括用户身份信息和所述变更后的码状态。

客户端响应于第二乘车码生成指令，获取第二乘车码。第二乘车码是根据用户身份信息和变更后的码状态生成的，其中。第二乘车码可以是应用服务器生成，也可以由客户端直接生成。当第二乘车码为应用服务器生成时，客户端可以从应用服务器获取该第二乘车码。

s303：显示所述第二乘车码，以使所述验证设备扫描所述第二乘车码，并根据所述第二乘车码进行验票。

在获取到第二乘车码，客户端可以显示第二乘车码，以使验证设备扫描第二乘车码，并根据第二乘车码进行验票。其中，第二乘车码是根据更新后的码状态生成的，若原码状态与验证设备的功能状态不一致，例如原码状态为行程起始状态，而验证设备的功能状态为验证行程终止的功能状态，则变更后的码状态行程终止状态与验证设备的功能状态是一致的，在用户身份信息验证通过的基础上，可以使得验证设备验票通过。

其中，显示第二乘车码可以有多种实现方式。在一些可能的实现方式中，可以在客户端的当前页面直接显示第二乘车码，当然，在有些情况下，也可以采用弹窗的方式显示第二乘车码，或者，在当前页面基础上新增二个页面，在该新增页面上显示第二乘车码。

由上可知，本申请实施例提供了一种验证方法，在码状态与用户实际行程状态不一致时，为用户提供了历史行程信息更改通道，用户还可以通过客户端对历史行程进行补正，从而使得管理服务器更新码状态，客户端可以接收管理服务器返回的变更后的码状态，并根据第二乘车码生成指令，获取携带了用户身份信息和变更后的码状态的第二乘车码，显示该第二乘车码以便验证设备对该第二乘车码进行验证。通过该方法不仅可以离线对乘车码的有效性进行验证，还可以在码状态不一致时，通过对历史行程进行补正以获得正确的码状态，根据正确的码状态生成新的二维码，通过验证新的二维码，可以避免刷码错误以及计费混乱等现象发生，降低资金风险。

上述实施例是从客户端的角度对本申请实施例提供的验证方法进行介绍，接下来，将从验证设备的角度对本申请实施例提供的验证方法进行介绍。

图4为本申请实施例提供的一种验证方法的流程图，该方法应用于验证设备，参见图4，该方法包括：

s401：扫描终端设备上的第一乘车码，获取所述第一乘车码中的用户身份信息和第一码状态。

所述第一码状态用于表示所述第一乘车码对应的行程状态，所述行程状态包括行程起始状态或者行程终止状态。

在本实施例中，验证设备扫描终端设备上的第一乘车码，获取第一乘车码中的用户身份信息和第一码状态。其中，验证设备是对乘车码进行验证的设备。在本实施例中验证设备具有扫描功能，通过扫描乘车码获取用户身份信息和第一码状态，根据用户身份信息和第一码状态实现对乘车码有效性的验证。

在公共交通的应用场景中，验证设备包括地铁闸机。在有些情况下，例如，针对上车和下车均需要刷码验证的公交车，验证设备也可以是公交验票机。地铁闸机和公交验票机仅为本申请实施例中验证设备的一些具体示例，上述示例并不构成对本申请技术方案的限定。

s402：验证所述用户身份信息，以及根据所述验证设备的功能状态验证所述第一码状态。

所述验证设备的功能状态表示所述验证设备用于验证一次行程的行程起始状态或者行程终止状态。以地铁闸机作为示例，在地铁站的各个出入口，分别设置有入站闸机和/或出站闸机，入站闸机用于验证一次行程的行程起始状态，出站闸机用于验证一次行程的行程终止状态。用户可以通过在入站闸机刷码验证以便入站乘车，在出站闸机刷码验证，以便出站离开。

验证设备在获取到用户身份信息和码状态时，可以对用户身份信息和码状态分别进行验证。其中，对用户身份信息的验证包括对用户身份合法性的验证，还可以包括对用户支付信息的验证，例如，是否能够支付本次行程的费用等等。对第一码状态的验证是根据验证设备的功能状态实现的，具体可以参见如下实现方式。

在一些可能的实现方式中，可以将第一码状态与验证设备的功能状态进行比较，若一致，则第一码状态验证通过，若不一致，则第一码状态验证不通过。当第一码状态验证不通过时，则表明历史行程中存在行程信息缺失，例如，只有行程起始的扫描记录，而无行程终止的扫描记录，或者具有行程起始的扫描记录，而缺乏行程终止的扫描记录。基于此，可以通过客户端对历史行程信息进行补正，以便更新码状态，详细补正过程可以参见上文相关内容描述，在此不再赘述。

在本实施例中，一次行程通常需要两个乘车码，一个乘车码的码状态为行程起始状态，另一个乘车码的码状态为行程终止状态。基于此，为了便于下一次生成乘车码，可以在验票通过后更新码状态。可以理解，更新码状态可以通过验证设备实现。在一些可能的实现方式中，在码状态验证通过后，验证设备可以根据第一码状态生成第二码状态，其中，第二码状态与第一码状态相反，然后，验证设备向终端设备返回第二码状态。如此，在下一次发起生成乘车码的请求时，终端设备上的客户端可以响应于该请求，获取根据第二码状态生成的乘车码。

需要说明的是，验证设备在终端设备中回写第二码状态时，可以通过近场通信、蓝牙或者无线网络等方式实现。具体地，验证设备通过近场通信、蓝牙或者无线网络与终端设备通信，以向终端设备返回所述第二码状态。相较于其他方法，通过近场通信、蓝牙或者无线网络等方法进行会回写更加方便、快捷，并且可以使得验证设备的结构更为简单，降低设备成本。

s403：若验证均通过，则确定验票成功。

在本实施例中，若验证设备对用户身份信息的验证和对第一码状态的验证均通过，则表明用户身份合法，并且第一乘车码中的行程状态与实际行程状态一致，乘车码是有效的，验证设备确定验票成功。

进一步地，若验证设备对用户身份信息和第一码状态的验证，至少有一个验证不通过，则表明第一乘车码是无效的，验证设备确定验票失败。为了便于用户进行针对性地调整，验证设备还可以提示验票失败原因。其中，验证设备可以直接向用户提示，例如，通过语音的方式提示验票失败原因，或者在验证设备的显示屏上显示验票失败原因。作为本实施例的扩展，验证设备也可以向客户端发送验票失败原因，并在客户端上显示验票识别原因。

在验票失败的情况下，若失败原因为码状态不一致，则可以对历史行程的行程信息进行补正，对应地，服务器可以根据补正行程信息对码状态进行更新，得到变更后的码状态，并客户端返回变更后的码状态。客户端获取携带了变更后的码状态的新的乘车码，例如第二乘车码，并显示该第二乘车码，则验证设备可以扫描该第二乘车码，获取用户身份信息和变更后的码状态，并对用户身份信息和变更后的码状态验证，以确定是否验票通过。

由上可知，本申请实施例提供了一种验证方法，通过扫描终端设备上的第一乘车码，获取第一乘车码中的用户身份信息和第一码状态，然后验证用户身份信息，以及根据验证设备的功能状态验证第一码状态，根据对用户身份信息和第一码状态的验证结果确定是否验票通过。在该方法中，由于乘车码中携带了码状态，验证设备无需与管理服务器网络通信即可根据码状态离线判断乘车码的有效性，实现对乘车码的验证。并且，在该验证方法中增加了对码状态的验证，每次验证时，均需对码状态进行验证，降低了单边刷码的几率，避免了计费混乱和资金风险，提高了用户体验。

以上分别从终端设备的客户端和验证设备的角度对本申请实施例提供的验证方法进行介绍，为了使本申请实施例中的验证方法更易于理解，接下来，将结合附图，从客户端、验证设备、管理服务器交互的角度对本申请实施例提供的验证方法进行介绍。

图5为本申请实施例提供的一种验证方法的交互流程图。参见图5，该方法包括：

s501：客户端响应于第一乘车码的生成请求，获取第一乘车码，第一乘车码中包括用户身份信息和第一码状态。

s502：客户端显示第一乘车码。

s503：验证设备扫描第一乘车码，获取第一乘车码中的用户身份信息和第一码状态。

s504：验证设备验证用户身份信息，以及根据验证设备的功能状态验证第一码状态。若验证均通过，则执行s512；否则执行s505。

s505：验票失败，拦截乘客。

用户身份信息和第一码状态中至少有一个验证不通过，则验票失败，可以拦截乘客，暂不允许乘客出入。其中，乘客是指通过该乘车码乘坐公共交通工具的用户。

s506：提示乘客验票失败原因。

s507：在客户端的行程补登功能界面补齐缺失的历史行程信息。

行程补登功能界面是客户端中对历史行程信息进行补正的功能界面。在该功能界面可以补充登记缺失的历史行程信息。其中，补充登记的历史行程信息是指上文所述的历史行程的补正行程信息，具体可以参见上文相关内容描述。

s508：客户端向管理服务器发送补登的历史行程信息。

s509：管理服务器根据补登的历史行程信息，补齐缺失的历史行程信息。

s510：管理服务器根据补齐的历史行程信息更新码状态，并将变更后的码状态发送给客户端。

s511：客户端响应于第二乘车码的生成请求，获取第二乘车码，第二乘车码中包括用户身份信息和更新后的码状态。然后，客户端重新执行显示乘车码，以使验证设备扫描乘车码，验证用户身份信息和码状态。

其中，客户端重新执行显示乘车码步骤，以使验证设备扫描乘车码，验证用户身份信息和码状态与s502类似，区别在于，本步骤显示第二乘车码，而s501显示第一乘车码，验证设备是对第二乘车码中变更后的码状态进行验证。

s512：验票成功，放行乘客。

验证用户身份信息为合法，第一码状态与实际行程状态一致，则表明乘车码有效，验票成功，可以放行乘客。需要说明的是，在第一码状态验证通过后，验证设备还可以根据第一码状态生成第二码状态，第二码状态与第一码状态相反，然后向终端设备返回第二码状态，以便作为下一次乘车码生成请求所需的行程状态。

由上可知，本申请实施例提供了一种验证方法，客户端获取第一乘车码，第一乘车码中包括用户身份信息和第一码状态，然后显示该第一乘车码，验证设备扫描该第一乘车码，获取第一乘车码中的用户身份信息和第一码状态，验证用户身份信息和第一码状态，从而实现了离线验证乘车码的有效性。当码状态不一致时，还可以补登历史行程信息，得到变更的码状态，根据该变更的码状态生成第二乘车码，然后扫描第二乘车码，获取用户身份信息和变更的码状态，并对其进行验证，如此，降低了单边刷码的几率，避免了计费混乱和资金风险，提高了用户体验。

为了使本申请的技术方案更清楚，下面将结合具体应用场景从交互的角度对本申请实施例的验证方法进行介绍。

以乘坐地铁为例，客户端可以为腾讯乘车码这一微信小程序，验证设备可以为地铁闸机，管理服务器可以为地铁后台服务器，用户可以通过腾讯乘车码的微信小程序与地铁闸机、地铁后台服务器进行交互，从而实现乘坐地铁。

图6为本申请实施例提供的对乘车码进行验证的方法的场景示意图，如图6所示，该场景中包括终端10，地铁闸机20以及地铁后台服务器30，其中，终端10上安装有微信客户端，微信客户端加载有腾讯乘车码的小程序，如此，微信客户端相当于本实施例中与地铁闸机20交互，提供乘车码验证服务的客户端。

当用户需要乘车时，可以在小程序界面触发乘车码的生成操作，如图6中的界面100所示，用户可以在腾讯乘车码界面点击“生成乘车码”控件，触发乘车码的生成操作，如此，客户端可以响应于第一乘车码的生成请求，根据用户身份信息和第一码状态生成第一乘车码，然后，客户端可以显示该第一乘车码，如图6中的界面200所示，客户端在当前页面显示第一乘车码。

接着，用户可以手持终端，使得第一乘车码在地铁闸机20的扫描范围内，地铁闸机20可以对客户端上的第一乘车码进行扫描，获得第一乘车码中的用户身份信息和第一码状态，地铁闸机20可以对用户身份信息和第一码状态进行验证，其中，对第一码状态的验证可以通过与地铁闸机20的功能状态比较实现，若第一码状态与地铁闸机20的功能状态一致，则对第一码状态的验证通过；例如第一码状态为行程起始状态，地铁闸机20的功能状态具体表示用于验证行程起始状态，也即地铁闸机20为入站闸机，则表明第一码状态与地铁闸机20的功能状态一致。

若用户身份信息和第一码状态均验证通过，则地铁闸机20确定验票通过，可以对该用户放行。其中，第一码状态为行程起始状态，则用户可以进站，第一码状态为行程终止状态，则用户可以出站。

若用户身份信息和第一码状态至少有一个验证不通过，则地铁闸机20确定验票失败，可以提示验票失败原因。例如，验票失败原因为第一码状态与验证设备的功能状态不一致时，用户可以在客户端的行程补登功能界面补齐缺失的历史行程信息。在该示例中，用户可以在界面100中点击“行程管理”控件，进入“行程补登”功能界面，如界面300所示，在该示例中，显示有4条行程信息，其中，最新的1条行程信息缺乏终止记录，可以在该界面补充终止站点信息，实现行程补登。

具体的，客户端可以接收历史行程的补正行程信息，向地铁后台服务器30发送历史行程的补正行程信息，地铁后台服务器30根据历史行程的补正行程信息更新历史行程的行程信息，并更新码状态。然后，地铁后台服务器30向客户端返回变更后的码状态。

客户端可以响应于第二乘车码的生成请求，根据变更后的码状态和用户身份信息生成第二乘车码，然显示该第二乘车码，地铁闸机20可以扫描第二乘车码，获取第二乘车码中的用户身份信息和上述变更后的码状态，然后对用户身份信息和变更后的码状态进行验证，从而实现对第二乘车码有效性的验证。

在该实施例中，客户端获取的乘车码中不仅包括用户身份信息，还包括码状态，如此，地铁闸机在对乘车码进行验证时，无需与地铁后台服务器通信即可获取码状态，通过对用户身份信息和码状态进行验证可以实现对乘车码的离线验证，即使地铁后台服务器网络异常或无法提供服务，也不会对乘车码的验证造成较大的影响。并且，在码状态不一致时，可以补正历史行程信息，获得变更的码状态，如此，可以避免单边刷码，进而避免了计费混乱，降低了资金风险，提高了用户体验。

以上为本申请实施例提供的验证方法的一些具体实现方式，基于此，本申请还提供了一种验证装置，下面将从功能模块化的角度对本申请实施例提供的装置进行介绍。

图7为本申请实施例提供的一种验证装置的一个结构示意图，参见图7，该装置700包括：

获取单元710，用于响应于第一乘车码生成指令，获取第一乘车码，所述第一乘车码中包括用户身份信息和第一码状态，所述第一码状态用于表示所述第一乘车码对应的行程状态，所述行程状态包括行程起始状态或者行程终止状态；

显示单元720，用于显示所述第一乘车码，以使所述验证设备扫描所述第一乘车码，并根据所述第一乘车码进行验票。

可选的，所述获取单元710具体用于：

向应用服务器发送第一生成请求，所述第一生成请求中包括用户身份信息和当前行程的行程状态；

接收所述应用服务器返回的第一乘车码。

可选的，所述获取单元710具体用于：

根据用户身份信息和当前行程的行程状态，生成第一乘车码。

可选的，参见图8，图8为本申请实施例提供的一种验证装置的一个结构示意图，所述装置还包括接收单元730和存储单元740：

所述接收单元730，用于接收所述验证设备在验票成功后返回的第二码状态；所述第二码状态与所述第一码状态相反；

所述存储单元740，用于存储所述第二码状态，并将所述第二码状态作为下一次乘车码生成请求所需的行程状态。

可选的，所述接收单元730具体用于：

通过近场通信、蓝牙或者无线网络与所述验证设备通信，以接收所述验证设备在验票成功后返回的所述第二码状态。

可选的，参见图9，图9为本申请实施例提供的一种验证装置的一个结构示意图，所述装置还包括发送单元750；

所述接收单元730还用于：

接收历史行程的补正行程信息；

所述发送单元750用于：

向管理服务器发送所述历史行程的补正行程信息，以使所述管理服务器根据所述历史行程的补正行程信息更新所述历史行程的行程信息。

可选的，所述接收单元730还用于：

接收所述管理服务器返回的变更后的码状态；

所述获取单元710还用于：

响应于第二乘车码生成指令，获取第二乘车码，所述第二乘车码中包括用户身份信息和所述变更后的码状态；

所述显示单元720还用于：

显示所述第二乘车码，以使所述验证设备扫描所述第二乘车码，并根据所述第二乘车码进行验票。

由上可知，本申请实施例提供了一种验证装置，通过在乘车码中携带表征行程起始状态或行程终止状态的码状态，使得验证设备在验证乘车码的有效性时，无需与管理服务器网络通信查询扫码记录，即可根据码状态以及验证设备的功能状态快速判断乘车码的有效性，并且该判断过程可以在离线情况下进行，即使管理服务器网络异常或无法提供服务，也不会影响乘车码有效性的判断，如此，可以有效防止用户由于误操作而出现的单边刷码发生，避免计费混乱。

图10为本申请实施例提供的一种验证装置的一个结构示意图，参见图10，该装置1000包括：

扫描单元1010，用于扫描终端设备上的第一乘车码，获取所述第一乘车码中的用户身份信息和第一码状态；所述第一码状态用于表示所述第一乘车码对应的行程状态，所述行程状态包括行程起始状态或者行程终止状态；

验证单元1020，用于验证所述用户身份信息，以及根据所述验证设备的功能状态验证所述第一码状态，所述验证设备的功能状态表示所述验证设备用于验证一次行程的行程起始状态或者行程终止状态；

确定单元1030，用于若验证均通过，则确定验票成功。

可选的，所述确定单元1030还用于：

否则，确定验票失败，提示验票失败原因。

可选的，参见图11，图11为本申请实施例提供的一种验证装置的一个结构示意图，所述装置还包括：

生成单元1040，用于在所述第一码状态验证通过后，根据所述第一码状态生成第二码状态，所述第二码状态与所述第一码状态相反；

返回单元1050，用于向所述终端设备返回所述第二码状态。

可选的，所述返回单元1050具体用于：

通过近场通信、蓝牙或者无线网络与所述终端设备通信，以向所述终端设备返回所述第二码状态。

由上可知，本申请实施例提供了一种验证装置，通过扫描终端设备上的客户端上的第一乘车码，获取第一乘车码中的用户身份信息和第一码状态，然后验证用户身份信息，以及根据验证设备的功能状态验证第一码状态，根据对用户身份信息和第一码状态的验证结果确定是否验票通过。在该方法中，由于乘车码中携带了码状态，验证设备无需与管理服务器网络通信即可根据码状态离线判断乘车码的有效性，实现对乘车码的验证。并且，在该验证方法中增加了对码状态的验证，每次验证时，均需对码状态进行验证，降低了单边刷码的几率，避免了计费混乱和资金风险，提高了用户体验。

以上实施例是从功能模块化的角度，对本申请实施例提供的验证装置进行介绍，接下来将从硬件实体化的角度对本申请实施例提供的验证装置进行介绍。

本申请实施例还提供了一种验证设备，该验证设备为终端设备，如图12所示，为了便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请实施例方法部分。该终端可以为包括手机、平板电脑、个人数字助理(英文全称：personaldigitalassistant，英文缩写：pda)、销售终端(英文全称：pointofsales，英文缩写：pos)、车载电脑等任意终端设备，以终端为手机为例：

图12示出的是与本申请实施例提供的终端相关的手机的部分结构的框图。参考图12，手机包括：射频(英文全称：radiofrequency，英文缩写：rf)电路1210、存储器1220、输入单元1230、显示单元1240、传感器1250、音频电路1260、无线保真(英文全称：wirelessfidelity，英文缩写：wifi)模块1270、处理器1280、以及电源1290等部件。本领域技术人员可以理解，图12中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图12对手机的各个构成部件进行具体的介绍：

rf电路1210可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器1280处理；另外，将设计上行的数据发送给基站。通常，rf电路1210包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(英文全称：lownoiseamplifier，英文缩写：lna)、双工器等。此外，rf电路1210还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(英文全称：globalsystemofmobilecommunication，英文缩写：gsm)、通用分组无线服务(英文全称：generalpacketradioservice，gprs)、码分多址(英文全称：codedivisionmultipleaccess，英文缩写：cdma)、宽带码分多址(英文全称：widebandcodedivisionmultipleaccess,英文缩写：wcdma)、长期演进(英文全称：longtermevolution，英文缩写：lte)、电子邮件、短消息服务(英文全称：shortmessagingservice，sms)等。

存储器1220可用于存储软件程序以及模块，处理器1280通过运行存储在存储器1220的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器1220可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器1220可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元1230可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元1230可包括触控面板1231以及其他输入设备1232。触控面板1231，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板1231上或在触控面板1231附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板1231可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器1280，并能接收处理器1280发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板1231。除了触控面板1231，输入单元1230还可以包括其他输入设备1232。具体地，其他输入设备1232可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元1240可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元1240可包括显示面板1241，可选的，可以采用液晶显示器(英文全称：liquidcrystaldisplay，英文缩写：lcd)、有机发光二极管(英文全称：organiclight-emittingdiode，英文缩写：oled)等形式来配置显示面板1241。进一步的，触控面板1231可覆盖显示面板1241，当触控面板1231检测到在其上或附近的触摸操作后，传送给处理器1280以确定触摸事件的类型，随后处理器1280根据触摸事件的类型在显示面板1241上提供相应的视觉输出。虽然在图12中，触控面板1231与显示面板1241是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板1231与显示面板1241集成而实现手机的输入和输出功能。

手机还可包括至少一种传感器1250，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板1241的亮度，接近传感器可在手机移动到耳边时，关闭显示面板1241和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路1260、扬声器1261，传声器1262可提供用户与手机之间的音频接口。音频电路1260可将接收到的音频数据转换后的电信号，传输到扬声器1261，由扬声器1261转换为声音信号输出；另一方面，传声器1262将收集的声音信号转换为电信号，由音频电路1260接收后转换为音频数据，再将音频数据输出处理器1280处理后，经rf电路1210以发送给比如另一手机，或者将音频数据输出至存储器1220以便进一步处理。

wifi属于短距离无线传输技术，手机通过wifi模块1270可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图12示出了wifi模块1270，但是可以理解的是，其并不属于手机的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器1280是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器1220内的软件程序和/或模块，以及调用存储在存储器1220内的数据，执行手机的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器1280可包括一个或多个处理单元；优选的，处理器1280可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1280中。

手机还包括给各个部件供电的电源1290(比如电池)，优选的，电源可以通过电源管理系统与处理器1280逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本申请实施例中，该终端所包括的处理器1280还具有以下功能：

响应于第一乘车码生成指令，获取第一乘车码，所述第一乘车码中包括用户身份信息和第一码状态，所述第一码状态用于表示所述第一乘车码对应的行程状态，所述行程状态包括行程起始状态或者行程终止状态；

显示所述第一乘车码，以使所述验证设备扫描所述第一乘车码，并根据所述第一乘车码进行验票。

在一些可能的实现方式中，处理器1280还可以执行本申请实施例提供的验证方法的任意一种实现方式的步骤。

图13是本申请实施例提供的一种验证设备的结构示意图，该验证设备1300可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessingunits，cpu)1322(例如，一个或一个以上处理器)和存储器1332，一个或一个以上存储应用程序1342或数据1344的存储介质1330(例如一个或一个以上海量存储设备)。其中，存储器1332和存储介质1330可以是短暂存储或持久存储。存储在存储介质1330的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对验证设备中的一系列指令操作。更进一步地，中央处理器1322可以设置为与存储介质1330通信，在验证设备1300上执行存储介质1330中的一系列指令操作。

验证设备1300还可以包括一个或一个以上电源1326，一个或一个以上有线或无线网络接口1350，一个或一个以上输入输出接口1358，和/或，一个或一个以上操作系统1341，例如windowsservertm，macosxtm，unixtm,linuxtm，freebsdtm等等。

验证设备1300还可以包括一个或一个以上扫描器1362，一个或一个以上显示屏1364。其中，扫描器1362能够扫描各种形式的乘车码，包括一维码或二维码，以便获取用户身份信息和码状态。显示屏1364可以显示用户身份信息和/或验票结果等信息。

上述实施例中由验证设备所执行的步骤可以基于该图13所示的验证设备结构。

其中，cpu1322用于执行如下步骤：

扫描终端设备上的第一乘车码，获取所述第一乘车码中的用户身份信息和第一码状态；所述第一码状态用于表示所述第一乘车码对应的行程状态，所述行程状态包括行程起始状态或者行程终止状态；

验证所述用户身份信息，以及根据所述验证设备的功能状态验证所述第一码状态，所述验证设备的功能状态表示所述验证设备用于验证一次行程的行程起始状态或者行程终止状态；

若验证均通过，则确定验票成功。

在一些可能的实现方式中，中央处理器1322还可以执行本申请实施例提供的验证方法的任意一种实现方式的步骤。

本申请实施例还提供一种计算机可读存储介质，用于存储程序代码，该程序代码用于执行前述各个实施例所述的一种验证方法中的任意一种实施方式。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(英文全称：read-onlymemory，英文缩写：rom)、随机存取存储器(英文全称：randomaccessmemory，英文缩写：ram)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。