CN116887204A - 号码处理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请适用于通信技术领域，提供了一种号码处理方法、装置、设备及存储介质，该方法包括：获取具备接收智能短信功能的待存储用户号码信息，所述待存储用户号码信息包括待存储第一号段信息和待存储第二号段信息，所述待存储第一号段信息是每一个所述待存储用户号码信息的通用信息，所述待存储第二号段信息是每一个所述待存储用户号码信息的专用信息；删除所述待存储第一号段信息；根据所述待存储第二号段信息的数值的大小顺序把所述待存储用户号码信息依次存储在预设数组中。该方案通过将待存储用户号码进行自定义区分和自定义存储，从而有利于节省内存空间，也便于在后续查询过程中提升查询速度。

Description

号码处理方法、装置、设备及存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种号码处理方法、装置、设备及存储介质。

背景技术

随着5G技术的推广，用户终端接收的短信消息出现了更多的消息形态。目前，大部分的智能手机都可以接收智能短信(AI Message，AIM)消息，该消息内容丰富，形式多样，包括但不限于单图文形式、多图文形式、音视频形式、应用软件的跳转链接形式等等。通常，在向用户终端发送AIM消息时，网关需要实时查询用户终端对应的用户号码是否具备接收AIM消息的能力。

在相关方案中，主要是将用户终端对应的用户号码等信息依次存储在计算机中，网关在查询的时候按照用户号码的顺序依次查询该用户号码是否能够接收AIM消息。

但是，当待查询的用户号码的数量较大时，采用上述存储和查询的方法，会导致查询速度较慢，占用内存较高的问题，影响用户体验。

发明内容

本申请实施例提供了一种号码处理方法、装置、设备及存储介质，可以解决如何节省内存空间和提升查询速度的技术问题。

第一方面，本申请实施例提供了一种号码处理方法，该方法包括：

获取具备接收智能短信功能的待存储用户号码信息；

待存储用户号码信息包括待存储第一号段信息和待存储第二号段信息，待存储第一号段信息是每一个待存储用户号码信息的通用信息，待存储第二号段信息是每一个待存储用户号码信息的专用信息；

删除待存储第一号段信息；

根据待存储第二号段信息的数值的大小顺序把待存储用户号码信息依次存储在预设数组中。

采用此种存储方式，在批量存储，尤其是大批量地存储用户号码信息时，通过删除待存储第一号段信息再进行存储剩余的待存储第二号段信息，既可以节省大量内存空间，又可以提升存储速度，同时在后续的查询过程中，也可以减少查询内容，有利于提升查询速度。

在一个实施例中，上述号码处理方法还包括：

获取待查询用户号码信息，待查询用户号码信息包括待查询第一号段信息和待查询第二号段信息；

删除待查询第一号段信息；

将待查询第二号段信息的数值作为查询索引在预设数组中进行查询；

当从预设数组中查找到查询索引对应的数组时，认定待查询用户号码信息对应的用户号码具备接收智能短信功能。

采用此种查询方式，利用专用的待查询第二号段信息作为查询索引可以快速定位到对应的数组，有利于提升查询效率。

在一个实施例中，上述号码处理方法还包括：

获取待存储用户号码信息对应的用户终端的厂商名称信息和软件开发工具包的版本号信息；

将厂商名称信息和软件开发工具包的版本号信息合并存储为待存储用户号码信息对应的数组数值，厂商名称信息和软件开发工具包的版本号信息用于判断待查询用户号码信息对应的用户号码是否能接收智能短信。

在一个实施例中，上述号码处理方法还包括：

当数组数值不等于0时，则认定该数组对应的用户号码信息对应的用户号码可以接收智能短信；

当数组数值等于0时，则认定该数组对应的用户号码信息对应的用户号码不可以接收智能短信。

在一个实施例中，上述获取待查询用户号码信息，包括：

获取待查询用户号码信息对应的请求包，请求包中包括请求头和请求体，请求头中包括鉴权认证信息，请求体中包括至少一个待鉴定用户号码信息；

根据鉴权认证信息判断是否在预设数组中查询待鉴定用户号码信息。

在一个实施例中，上述根据鉴权认证信息判断是否在预设数组中查询待鉴定用户号码信息，包括：

当鉴权认证信息通过时，解析请求包，获取请求体中的待鉴定用户号码信息，并在预设数组中查询待鉴定用户号码信息；

当鉴权认证信息未通过时，不解析对应的请求包，并判断下一个请求包的鉴权认证信息是否通过，直至鉴权认证信息通过。

在一个实施例中，上述号码处理方法还包括：

在预设数组中新增和/或删除待存储用户号码信息时，把对应的变更指令追写入AOF文件中，并将所有的待存储用户号码信息保存到本地；

当待存储用户号码信息丢失时，根据AOF文件恢复数据。

在一个实施例中，在根据AOF文件恢复数据之前，上述号码处理方法还包括：

重启后，加载保存在本地的待存储用户号码信息对应的文件，加载AOF文件。

通过利用AOF文件，可以保障用户数据安全，防止用户数据丢失。

第二方面，本申请实施例提供了一种号码处理装置，该装置具有实现第一方面或其任意可能的实现方式中的方法的功能。具体地，该装置包括实现第一方面或其任意可能的实现方式中的方法的单元。

在其中的一个实施例中，该装置包括：

获取单元，用于获取具备接收智能短信功能的待存储用户号码信息，待存储用户号码信息包括待存储第一号段信息和待存储第二号段信息，待存储第一号段信息是每一个用户号码信息的通用信息，待存储第二号段信息是每一个用户号码信息的专用信息；

处理单元，用于删除待存储第一号段信息；

存储单元，用于根据待存储第二号段信息的数值的大小顺序把待存储用户号码信息依次存储在预设数组中。

第三方面，本申请实施例提供了一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，该处理器执行计算机程序时，使得计算机设备实现上述第一方面任意一种实现方式的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被计算机设备执行时，使得计算机设备实现上述第一方面任意一种实现方式的方法。

第五方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在计算机设备上运行时，使得计算机设备执行上述第一方面任意一种实现方式的方法。

本申请实施例与现有技术相比存在的有益效果是：

通过把待存储用户号码区分为待存储第一号段和待存储第二号段，将通用的待存储第一号段信息删除，只存储专用的待存储第二号段信息，可以剔除冗余数据，大幅度节省内存空间，同时在查询的时候可以缩减查询内容，有利于提升查询效率。

附图说明

图1是本申请实施例提供的查询用户号码是否支持接受AIM消息的场景示意图。

图2是本申请实施例提供的一种号码存储的流程示意图。

图3是本申请实施例提供的另一种号码存储方法的流程示意图。

图4是本申请实施例提供的一种号码存储的结构示意图。

图5是本申请实施例提供的一种号码查询方法的流程示意图。

图6是本申请实施例提供的另一种号码存储方法的流程示意图。

图7是本申请实施例提供的装置的结构示意图。

图8是本申请实施例提供的计算机设备的结构示意图。

具体实施方式

智能短信(AI Message，AIM)消息，也可以称之为富媒体卡片消息，是传统短信的一种升级形态。用户终端通过智能解析，可以将普通的文本短信升级为富媒体消息，从而为用户展现多种媒体元素，如图片、音频、视频、支付链接等等。用户接受到AIM消息之后可以实现浏览器内置访问、打开小程序、快捷支付等多种功能，增强应用交互的实时体验。例如，销售商可以向用户终端发送包含购物链接的AIM消息，用户在收到该AIM消息之后可以点击链接跳转到购物网站进行购物。

通常，在向用户终端发送AIM消息时，会查询用户终端对应的用户号码是否支持接受该AIM消息。

下面结合图1来具体解释查询用户终端对应的用户号码是否支持接受该AIM消息的应用场景。

图1是本申请实施例提供的查询用户号码是否支持接受AIM消息的场景示意图。

如图1所示，图1中包括：网关、查询接口、同步服务端。

网关是一种连接不同网络的网络互连设备，用于实现数据的互通和管理。作为示例而非限定，此处的网关可以是5G网关。5G网关是指可以连接5G有线网络或5G无线网络的网关设备。采用5G网关可以实现高速数据传输、降低延迟，极大地提升用户体验。

查询接口可以理解为是一个提供查找用户号码是否支持AIM消息服务的接口。接口是不同系统之间互相连接的通道，可以实现不同系统之间的相互通信和交换数据，通常应用于连接数据库、查询第三方服务、获取数据等。使用时，调用方通过接口调用系统或服务中的现有数据，对这些数据进行查询、修改、删除等操作，然后将结果返回给调用方。作为示例而非限定，此处的查询接口可以是HTTP接口、API接口等等，也可以是其他可以实现同种功能的接口。

同步服务端是指根据客户端的请求提供同步用户号码服务的计算机设备或服务器。作为示例而非限定，此处的同步服务端可以是一个能够实现从互联网上获取支持接收AIM消息的用户号码并实时发送到查询接口的功能的服务器。

在一种实现方式中，查询接口通过互联网实时地从同步服务端获取支持接收AIM消息的用户号码的信息，并自动保存到本地的文件系统中。当需要向用户终端发送AIM消息时，网关会向查询接口发送查询请求指令，查询接口接收根据该查询请求指令判断用户号码能否在文件系统中找到相对应的用户号码(即进行用户号码的查找比对)，并将判断结果反馈给网关。最后根据判断结果即可判断出某一用户号码是否支持AIM消息。

也可以理解为，如果在文件系统可以查询到对应的用户号码，说明该号码支持AIM消息；如果在文件系统中查询不到对应的用户号码，说明该号码不支持AIM消息。

结合上述场景，可以理解采用传统的存储号码和查询号码的方式，不仅会导致内存空间占用严重的问题，查询结果的反馈速度也较慢，难以满足市场需求。

针对上述问题，本申请提出了一种号码处理方法，能够在节省存储空间的同时提高查询用户号码的效率。

为了进一步说明本申请的技术方案，下面通过具体实施例来说明。

图2是本申请实施例提供的一种号码存储的流程示意图。

如图2所示，上述号码存储方法包括以下步骤S201～S207。

S201、获取具备接收智能短信功能的待存储用户号码信息。

待存储用户号码信息包括待存储第一号段信息和待存储第二号段信息。其中，待存储第一号段信息是每一个待存储用户号码信息的通用信息，待存储第二号段信息是每一个待存储用户号码信息的专用信息。

也可以理解为，待存储第一号段信息是每一个待存储用户号码信息都具有的信息，该信息不能用来区分不同的待存储用户号码；而待存储第二号段信息能够表示每一个待存储用户号码信息之间的区别，用以区分不同的待存储用户号码。

作为示例而非限定，按照国内手机号码的编号规则，一个待存储用户号码可以是“10000000001”，另一个待存储用户号码可以是“10000000002”，将上述11位手机号码区分为两个号段，其中，待存储第一号段选择为“1”，待存储第二号段选择为“0000000001”或“0000000002”，可以明显看出待存储第一号段是每一个手机号码的通用号段，而待存储第二号段是每一个手机号码的专属号段。因此，可以利用待存储第二号段将支持接收AIM消息的手机用户区分开来。

可以理解，此处所说的待存储第一号段还可以有其他形式。

在一种实现方式中，可以根据待存储用户号码信息的数值区间来确定待存储第一号段和待存储第二号段。

例如，假设待存储用户号码的分布区间是“18800000001”～“18800009999”，此时的待存储第一号段就是“1880000”，待存储第二号段可以根据实际情况从“0001”～“9999”中具体选择。

再例如，假设待存储用户号码的分布区间是“10011111111”～“11000000999”。此时，可以将这一批号码分为两类，第一类是“10011111111”～“10999999999”区间段，第二类是“1100000000”～“11000000999”区间段。其中，第一类的待存储第一号段是“10”，待存储第二号段可以根据实际情况从“011111111”～“999999999”中具体选择。第二类的待存储第一号段是“11000000”，待存储第二号段可以根据实际情况从“000”～“999”中具体选择。

也就是说，在存储的时候，可以事先将待存储用户号码进行大小排序，然后再根据实际情况分别确定出待存储用户号码中的哪些号段是通用号段、哪些号段是专用号段，也即确定出待存储第一号段和待存储第二号段。

在一种实现方式中，可以从保存在本地的文件系统中获取具备接收智能短信功能的待存储用户号码信息，也可以利用互联网从其他计算机设备或服务器中实时获取具备接收智能短信功能的待存储用户号码信息，对于待存储用户号码信息的获取来源此处不做限定，可以根据实际情况来具体选择。

S202、删除待存储第一号段信息。

结合上述内容可以理解，待存储第一号段信息(如上文中提到的“1”)没有区分不同用户的功能，因此，该信息可以删除，并不是必须存储的信息。

作为示例而非限定，在存储“10000000001”时，可以把“1”删除，只存储“0000000001”。

S203、根据待存储第二号段信息的数值的大小顺序把待存储用户号码信息依次存储在预设数组中。

可以理解，待存储第二号段信息(如上文中提到的“0000000001”等)具有数值上的大小顺序。在存储时，可以按照从小到大或者从大到小的顺序来存储。因为“0000000002”在数值上比“0000000001”大，所以存储的时候，先存储“0000000001”，再存储“0000000002”。

在一种实现方式中，可以将待存储第二号段信息作为数组下标存储在预设数组中。

作为示例而非限定，在存储的时候可以用下述格式来表示各个数组，例如，数组[0](Array[0])表示存储的用户号码为10000000000，可以用下面的数组来表示：

Array[0]＝Data of 10000000000。

同理可得：

Array[1]＝Data of 10000000001；

……

Array[3588888888]＝Data of 13588888888；

Array[9999999999]＝Data of 19999999999。

结合上述内容可知，当需要存储“10000000001”和“10000000002”这两个用户号码时，先把“1”删除，然后在预设数组中将“0000000001”存储为数组下标，再按照同样的方式继续存储“0000000002”，可以明显看出，相较于直接存储“10000000001”，此种存储方式节省了10倍的内存空间。

采用此种存储方式，在批量存储，尤其是大批量地存储用户号码信息时，通过删除待存储第一号段信息再进行存储剩余的待存储第二号段信息，既可以节省大量内存空间，又可以提升存储速度，同时在后续的查询过程中，也可以减少查询内容，有利于提升查询速度。

当需要确定一个用户号码是否可以接收AIM消息时，可以通过在预设数组中查找对应的号码进而确定。

下面介绍本申请实施例提供的一种号码查询方法。该方法包括以下步骤S204～S207。

S204、获取待查询用户号码信息。

待查询用户号码信息包括待查询第一号段信息和待查询第二号段信息。

在一种实现方式中，可以接收HTTP请求来获取待查询用户信息，通过进一步解析其中的HTTP请求包来获取具体的待查询用户号码。

HTTP请求是指客户端向服务器发送的请求，用于获取某个资源或执行某个操作。它是一种应用层协议，定义了客户端和服务器之间的通信规范。

一般来说，HTTP请求包括请求方法、请求头、请求体、请求参数等。常见的请求方法有GET、POST、PUT、DELETE等，其中，GET可以理解为获取操作，POST可以理解为创建操作，PUT可以理解为更新操作，DELETE可以理解为删除操作。

请求头包含了一些关于请求和客户端信息的元数据，如用户代理(User-Agent，UA)等。

请求体根据请求方法的不同而有所不同，例如POST方法中的请求体一般用于传输表单数据、JSON数据等。

在一种实现方式中，查询接口可以采用HTTP+JSON协议交互方式。此种方式可以方便大部分编程语言接入，降低接入门槛，从而拓宽了查询接口的应用范围，降低开发成本。

S205、删除待查询第一号段信息。

同上文中的待存储第一号段信息的原理类似，将待查询用户号码信息中的待查询第一号段信息删除。

例如，在查询用户号码“10000000001”时，可以把“1”删除。

S206、将待查询第二号段信息的数值作为查询索引在预设数组中进行查询。

同上文中的待存储第二号段信息的原理类似，在查询用户号码“10000000001”时，把“1”删除，保留“0000000001”，将“0000000001”作为查询索引在预设数组中进行查询。

S207、当从预设数组中查找到查询索引对应的数组时，认定待查询用户号码信息对应的用户号码具备接收智能短信功能。

结合上文，可以理解，在预设数组中存储的都是具备接收智能短信功能的用户号码，如果能够在预设数组中查询到对应的数组，即表明该号码可以接收智能短信。

作为示例而非限定，在预设数组中存储有一个数组Array[1]，该数组表示用户号码“10000000001”。假设此时获取到的待查询号码为“10000000001”，去掉“1”之后，将“0000000001”(即数值1)作为查询索引在预设数组中进行查询，通过查询之后，找到了“Array[1]”。此时，说明待查询号码“10000000001”可以接收AIM消息。

反之，如果获取到的待查询号码为“10000000002”，去掉“1”之后，将“0000000002”(即数值2)作为查询索引在预设数组中进行查询，通过查询之后，找不到对应的数组“Array[2]”，说明待查询号码“10000000002”不能接收AIM消息。

通过将待查询号码的专用信息作为查询索引来进行查询，可以快速定位到具体的存储位置，同时也可以避免查找通用的信息，减少了查找的内容，提升了查询速度。

图3是本申请实施例提供的另一种号码存储方法的流程示意图。如图3所示，图3包括以下步骤S301～S304。

S301、获取待存储用户号码信息对应的用户终端的厂商名称信息和软件开发工具包的版本号信息。

通常，在存储用户号码的同时，也会相应地保存该用户号码对应的用户终端的厂商ID和SDK(Software Development Kit)版本号。

此处的厂商ID指的是用户终端对应的制造厂商的ID编号，通常用3位数字表示。例如：某用户终端品牌对应的厂商ID为001。

此处的SDK版本号是指号码在终端设备上标识的SDK版本号，跟AIM消息的展示相关。例如，可以采用5位SDK版本号形式，此处可以根据实际情况来选择，不做限定。

S302、将厂商名称信息和软件开发工具包的版本号信息合并存储为待存储用户号码信息对应的数组数值。

厂商名称信息和软件开发工具包的版本号信息可以用于判断待查询用户号码信息对应的用户号码是否能接收智能短信。将厂商名称信息和软件开发工具包的版本号信息合并存储为待存储用户号码信息对应的数组数值可以在查询的时候通过查询数组的数值来确定用户号码是否能接收智能短信。

下面结合图4来具体说明。

图4是本申请实施例提供的一种号码存储的结构示意图。其中，图4中的A部分是本申请中的存储结构示意图，B部分是传统方案中的存储结构示意图。

结合图4中的A部分，假设，某一用户号码为10000000001，在存储的时候可以把“1”去掉，将剩余数字作为数组下标，再按照数值大小顺序依次存储在内存中，相应地，该用户号码的所在的用户终端的厂商ID和SDK版本号即为该用户号码对应的数组的数值。

作为示例而非限定，已知Array[3588888888]＝Data of 13588888888，则Data of13588888888＝3bits for Vendor ID+5bits forSDK Version。可以理解，“Array[3588888888]”表示查询号码13588888888的数值，查询结果为该用户号码对应的3位厂商ID和5位SDK版本号。

结合图4中的B部分，B部分是传统的存储结构示意图，从图4中可以看出传统的存储结构是1字节为手机号码、1字节为厂商ID、1字节为SDK版本号。这种存储结构，占用内存大，且查询速度慢，对于大批量的号码而言，需要很大的存储空间，且不能满足号码的快速查询，并且在增删号码时，此种存储方式的内存占用量摆动较大，不稳定。

与传统的存储结构相比，通过上文中的压缩存储结构来存储用户号码，比直接把用户号码存储到内存中节省了10倍的内存空间，提升了存储性能。同时通过号码本身定位索引找到对应的存储结果，提升了查询速度。与此同时，只需要1字节即可存储号码，这种压缩存储号码的结构，在号码增删时内存稳定实现低延迟更新。

S303、当数组数值不等于0时，则认定该数组对应的用户号码信息对应的用户号码可以接收智能短信。

作为示例而非限定，当待查询用户号码为“13588888888”时，先把待查询第一号段“1”删除，将待查询第二号段“3588888888”作为查询索引在预设数组中查询，找到数组“Array[3588888888]”，然后得到数组数值为“3bits for Vendor ID+5bits for SDKVersion”，此时，“3bits for Vendor ID+5bits for SDK Version”的数值不等于0，说明该数组对应的用户号码信息对应的用户号码可以接收智能短信，即手机号码“13588888888”可以接收智能短信。

S304、当数组数值等于0时，则认定该数组对应的用户号码信息对应的用户号码不可以接收智能短信。

作为示例而非限定，当待查询用户号码为“13588888888”时，先把待查询第一号段“1”删除，将待查询第二号段“3588888888”作为查询索引在预设数组中查询，找到数组“Array[3588888888]”，然后得到数组数值为“3bits for Vendor ID+5bits for SDKVersion”，此时，“3bits for Vendor ID+5bits for SDK Version”的数值等于0，说明该数组对应的用户号码信息对应的用户号码不能接收智能短信，即手机号码“13588888888”不能接收智能短信。

在获取待查询用户号码信息时，通常需要先通过鉴权认证。下面结合图5来具体解释。

图5是本申请实施例提供的一种号码查询方法的流程示意图。如图5所示，包括以下步骤S501～S504。

S501、获取待查询用户号码信息对应的请求包。

请求包中包括请求头和请求体，请求头中包括鉴权认证信息，请求体中包括至少一个待鉴定用户号码信息。

在一种实现方式中，编码格式采用UTF-8(Unicode Transformation Format8-bit)。该编码格式是一种可变宽度的编码格式，用1～4个字节表示一个Unicode字符编码。

在一种实现方式中，该请求包的请求方式为POST。POST请求可以向服务器端发送数据，可以创建新的内容。

在一种实现方式中，协议类型为：

Content-Type:application/json；charset＝UTF-8。

下面结合表1来具体说明请求头的部分内容。

如表1所示，请求头中的必填参数包括：account、pwd、timestamp，数据类型为String，其中，account表示接入用户账号、pwd表示接入用户明文密码，按规则加密后的字符串，timestamp表示动态时间。

表1

参数	类型	是否必填	说明
				account	String	必填	接入用户账号
pwd	String	必填	接入用户明文密码，按规则加密后的字符串
				timestamp	String	必填	动态时间

下面结合表2来说明请求体的部分格式。

如表2所示，请求体中的必填参数包括参数名称即参数对象集合，参数即用户手机号码，数据类型为List<Object>，并且是必填项，表示请求体中可以接收0～10000个手机号码。

表2

从表2中可以看出，该请求体的请求参数支持批量号码查询，可以一次性传输多个用户号码，提升性能。

S502、根据鉴权认证信息判断是否在预设数组中查询待鉴定用户号码信息。

接收HTTP请求包时，可以利用鉴权认证信息对请求包的包头进行鉴权认证，如果鉴权认证通过则继续执行后续的查询步骤，如果鉴权认证不通过，则不会执行后续的查询步骤。

作为示例而非限定，上述鉴权认证方式可以是基本认证(BasicAuthentication)、摘要认证(Digest Authentication)等等。

基本认证是在请求头中添加Authorization字段，可以理解的是，Authorization是一个HTTP安全请求首部，包含了客户端提供给服务器便于对其自身进行认证的数据。此处该Authorization字段的值是将用户名和密码进行Base64编码后的数值。通过解码该Authorization字段，并与存储的用户名和密码进行比对即可得出鉴权认证结果。

摘要认证是请求头中添加Authorization字段，该Authorization字段的值包括：用户名、服务器领域(一般是一个字符串)、服务器生成的随机字符串以及客户端生成的响应摘要等等，可以通过摘要算法验证的前述响应摘要的正确性进而确定鉴权认证是否通过。

具体的鉴权认证方式可以根据安全性等要求来具体选择适用，此处只是举例并不做限定。

S503、当鉴权认证信息通过时，解析请求包，获取请求体中的待鉴定用户号码信息，并在预设数组中查询待鉴定用户号码信息。

作为示例而非限定，假设采用基本认证方式来进行鉴权认证，通过解码Authorization字段，获取对应的Basic base64的值，将该Basic base64的值与存储的用户名和密码进行比对，如果用户名和用户密码一致，则鉴权认证信息通过。

结合上述内容，当鉴权认证信息通过时，进一步解析请求包，获取请求体中的待鉴定用户号码信息，并在预设数组中查询待鉴定用户号码信息，具体查询过程参照上文示例，此处不再赘述。

S504、当鉴权认证信息未通过时，不解析对应的请求包，并判断下一个请求包的鉴权认证信息是否通过，直至鉴权认证信息通过。

为示例而非限定，假设采用基本认证方式来进行鉴权认证，通过解码Authorization字段，获取对应的Basic base64的值，将该Basic base64的值与存储的用户名和密码进行比对，如果用户名和用户密码不一致，则鉴权认证信息不通过。此时不会解析对应的请求包，直接转去判断下一个请求包的鉴权认证信息是否通过，直至鉴权认证信息通过才进行解析过程。通过此种方式进行解析数据可以避免解析不符合要求的数据，提升解析效率。

与将鉴权认证信息放在包体里相比，通过上述对请求包的包头进行鉴权认证的方式不需要解析请求体(HTTP BODY)，更容易实现信息分流，缩短查询时间。

图6是本申请实施例提供的另一种号码存储方法的流程示意图。如图5所示，包括以下步骤S601～S602。

S601、在预设数组中新增和/或删除待存储用户号码信息时，把对应的变更指令追写入AOF文件中，并将所有的待存储用户号码信息保存到本地。

AOF(Append-Only File)文件是一种用于持久化存储数据库操作日志的文件格式。它记录了数据库执行的写操作命令，以及这些命令所携带的参数和数据。

AOF文件的实现方式可以是追加模式(即Append-Only Mode)。在追加模式下，每次执行写操作命令时，可以利用远程字典服务器(Remote Dictionary Server，Redis)将该命令以文本的形式追加到AOF文件的末尾。

在一种实现方式中，每一次在预设数组中新增和/或删除待存储用户号码信息时，把对应的新增和/或删除指令追加到AOF文件中，并且在每天晚上的0点把预设数组中的所有待存储用户号码信息保存在本地的文件系统中，例如，可以保存在本地磁盘。

S602、当待存储用户号码信息丢失时，根据AOF文件恢复数据。

在一种实现方式中，当待存储用户号码信息丢失时，可以重启计算机设备，先加载保存在本地的待存储用户号码信息对应的文件，再加载所述AOF文件。

利用AOF文件可以防止断电或宕机情况下存储在计算机设备中的用户号码数据丢失。当重启计算机设备时，先加载待存储用户号码文件再加载AOF文件，即可恢复数据。

上文主要结合附图对本申请实施例的一种号码处理方法进行了介绍。应理解，虽然如上所述的各实施例所涉及的流程图中的各个步骤依次显示，但是这些步骤并不是必然按照图中所示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。下面结合附图对本申请实施例的一种的装置进行介绍。为了简洁，在下文介绍装置时，会进行适当省略，相关内容可以参照上文的方法中的相关描述，不再重复介绍。

图7申请实施例提供的一种号码处理装置的结构示意图。

如图7所示，该号码处理装置1000包括以下单元。

获取单元1001，用于获取具备接收智能短信功能的待存储用户号码信息，待存储用户号码信息包括待存储第一号段信息和待存储第二号段信息，待存储第一号段信息是每一个用户号码信息的通用信息，待存储第二号段信息是每一个用户号码信息的专用信息。

处理单元1002，用于删除待存储第一号段信息。

存储单元1003，用于根据待存储第二号段信息的数值的大小顺序把待存储用户号码信息依次存储在预设数组中。

在一种实现方式中，上述获取单元1001还可以用于执行上述步骤S204、S301以及S501中的方法。

在一种实现方式中，上述处理单元1002还可以用于执行上述步骤S205～S207、S302～S304、S502～S504以及S601～S602中的方法。

需要说明的是，上述单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

图8是本申请实施例提供的计算机设备的结构示意图。如图8所示，该实施例的计算机设备3000包括：至少一个处理器3100(图8仅示出一个)处理器、存储器3200以及存储在存储器3200中并可在至少一个处理器3100上运行的计算机程序3210，处理器3100执行计算机程序3210时，使得所述计算机设备实现上述实施例中的步骤。

处理器3100可以是中央处理单元(Central Processing Unit，CPU)，该处理器3100还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器3200在一些实施例中可以是计算机设备3000的内部存储单元，例如计算机设备3000的硬盘或内存。存储器3200在另一些实施例中也可以是计算机设备3000的外部存储设备，例如计算机设备3000上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。进一步地，存储器3200还可以既包括计算机设备3000的内部存储单元也包括外部存储设备。存储器3200用于存储操作系统、应用程序、引导装载程序(Boot Loader)数据以及其他程序等，例如计算机程序的程序代码等。存储器3200还可以用于暂时地存储已经输出或者将要输出的数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被计算机设备执行时，使得计算机设备实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在计算机设备上运行时，使得计算机设备能够实现上述各个方法。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，使得计算机设备可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质至少可以包括：能够将计算机程序代码携带到拍照装置/终端设备的任何实体或装置、记录介质、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。在描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

另外，在本申请说明书和所附权利要求书的描述中，术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

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

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

Claims (10)

1.一种号码处理方法，其特征在于，包括：

获取具备接收智能短信功能的待存储用户号码信息，所述待存储用户号码信息包括待存储第一号段信息和待存储第二号段信息，所述待存储第一号段信息是每一个所述待存储用户号码信息的通用信息，所述待存储第二号段信息是每一个所述待存储用户号码信息的专用信息；

删除所述待存储第一号段信息；

根据所述待存储第二号段信息的数值的大小顺序把所述待存储用户号码信息依次存储在预设数组中。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取待查询用户号码信息，所述待查询用户号码信息包括待查询第一号段信息和待查询第二号段信息；

删除所述待查询第一号段信息；

将所述待查询第二号段信息的数值作为查询索引在所述预设数组中进行查询；

当从所述预设数组中查找到所述查询索引对应的数组时，认定所述待查询用户号码信息对应的用户号码具备接收智能短信功能。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

获取所述待存储用户号码信息对应的用户终端的厂商名称信息和软件开发工具包的版本号信息；

将所述厂商名称信息和所述软件开发工具包的版本号信息合并存储为所述待存储用户号码信息对应的数组数值，所述厂商名称信息和所述软件开发工具包的版本号信息用于判断所述待查询用户号码信息对应的用户号码是否具备接收智能短信的功能。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

当所述数组数值不等于0时，则认定该数组对应的所述用户号码信息对应的用户号码可以接收智能短信；

当所述数组数值等于0时，则认定该数组对应的所述用户号码信息对应的用户号码不可以接收智能短信。

5.根据权利要求2所述的方法，其特征在于，所述获取待查询用户号码信息，包括：

获取待查询用户号码信息对应的请求包，所述请求包中包括请求头和请求体，所述请求头中包括鉴权认证信息，所述请求体中包括至少一个待鉴定用户号码信息；

根据所述鉴权认证信息判断是否在所述预设数组中查询所述待鉴定用户号码信息。

6.根据权利要求5所述的方法，其特征在于，所述根据所述鉴权认证信息判断是否在所述预设数组中查询所述待鉴定用户号码信息，包括：

当所述鉴权认证信息通过时，解析请求包，获取请求体中的待鉴定用户号码信息，并在所述预设数组中查询所述待鉴定用户号码信息；

当所述鉴权认证信息没有通过时，不解析对应的请求包，并判断下一个所述请求包的所述鉴权认证信息是否通过，直至所述鉴权认证信息通过。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述预设数组中新增和/或删除所述待存储用户号码信息时，把对应的变更指令追写入AOF文件中，并将所有的所述待存储用户号码信息保存到本地；

当所述待存储用户号码信息丢失时，根据所述AOF文件恢复数据。

8.根据权利要求7所述的方法，其特征在于，在根据所述AOF文件恢复数据之前，所述方法还包括：

重启后，加载保存在本地的所述待存储用户号码信息对应的文件，加载所述AOF文件。

9.一种计算机设备，其特征在于，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时，使得所述计算机设备实现如权利要求1至8中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被计算机设备执行时实现如权利要求1-8中任一项所述的方法。