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

技术领域

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

背景技术

随着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

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

如表2所示，请求体中的必填参数包括参数名称即参数对象集合，参数即用户手机号码，数据类型为List