CN104796312A - 联系人信息处理方法、装置及系统 - Google Patents

Abstract

本发明涉及一种联系人信息处理方法、装置及系统，其方法包括：接收用户客户端发起的合并重复联系人名片请求；根据合并重复联系人名片请求，拉取用户联系人名片数据；基于用户联系人名片数据，对用户联系人名片进行比较，根据比较结果以预定策略对用户联系人名片进行处理。本发明提高了重复联系人的合并准确性，节省了存储空间。

Description

联系人信息处理方法、装置及系统

技术领域

本发明涉及移动互联网技术领域，尤其涉及一种合并联系人的方法、装置及系统。

背景技术

目前，在移动终端或者PC终端上设置有同步联系人信息的功能，可以将不同移动终端上的联系人信息备份到服务器端，确保联系人信息的安全，并可实现联系人信息的共享。

服务器端在同步联系人信息时，对于出现重复的联系人，需要进行合并处理，以减少对服务器端存储空间的浪费。但是，现有的同步联系人方案中，在将不同移动终端的联系人信息备份到服务器端时，对于备份的两个联系人名片，只有当两者所包含的联系人信息完全相同时，才被检查出来进行合并。但是，一种可能的情形是，对于同一个联系人，在不同终端上备注的信息可能不完全相同，由此，在进行联系人信息合并时，会产生重复的联系人。

如表1所示，联系人名片A、B、C、D、E均为同一个联系人，联系人名片A和联系人名片B的各项联系人信息都相同，联系人名片A和联系人名片C的名字不一样，联系人名片A和联系人名片D的邮箱地址不一样，联系人名片A和联系人名片E的手机号码不一样，若采用现有的合并方案，则只会检查到联系人名片A和联系人名片B出现重复，需要进行合并。而联系人名片A和联系人名片C由于名字不一样，联系人名片A和联系人名片D由于邮箱地址不一样，联系人名片A和联系人名片E由于手机号码不一样，则不能被检查到重复，因此不会进行合并处理，由此降低了重复联系人的合并准确性，同时浪费了服务器端的存储空间。

联系人名片	姓名	手机号码	邮箱地址
				A	小明	12345678901	1234qq.com
B	小明	12345678901	1234qq.com
				C	小白	12345678901	1234qq.com

D	小明	12345678901	123qq.com
				E	小明	12345678902	1234qq.com

表1联系人名片信息

发明内容

本发明实施例提供一种联系人信息处理方法、装置及系统，旨在提高重复联系人的合并准确性，节省存储空间。

本发明实施例提出一种联系人信息处理方法，包括：

接收用户客户端发起的合并重复联系人名片请求；

根据所述合并重复联系人名片请求，拉取用户联系人名片数据；

基于所述用户联系人名片数据，对用户联系人名片进行比较；

根据比较结果，以预定策略对用户联系人名片进行处理。

本发明实施例还提出一种联系人信息处理装置，包括：

接收模块，用于接收用户客户端发起的合并重复联系人名片请求；

拉取模块，用于根据所述合并重复联系人名片请求，拉取用户联系人名片数据；

比较模块，用于基于所述用户联系人名片数据，对用户联系人名片进行比较；

处理模块，用于根据比较结果，以预定策略对用户联系人名片进行处理。

本发明实施例还提出一种联系人信息处理系统，包括：用户客户端及服务器，其中：

所述用户客户端，用于向所述服务器发起合并重复联系人名片请求；

所述服务器包括如上所述的装置。

本发明实施例提出的一种联系人信息处理方法、装置及系统，在接收到用户客户端发起的合并重复联系人名片请求时，根据合并重复联系人名片请求，拉取用户联系人名片数据，基于用户联系人名片数据，对用户联系人名片进行比较，根据比较结果，以预定策略对用户联系人名片进行处理，由此提高了重复联系人的合并准确性，节省了服务器或终端等的存储空间。

附图说明

图1是本发明实施例涉及的硬件环境架构图；

图2是本发明合并联系人的方法第一实施例的流程示意图；

图3是本发明实施例中基于所述用户联系人名片数据，对用户联系人名片进行比较，根据比较结果，以预定策略对用户联系人名片进行处理的一种流程示意图；

图4是本发明合并联系人的方法第二实施例的流程示意图；

图5是本发明合并联系人的方法第三实施例的流程示意图；

图6是本发明合并联系人的装置第一实施例的功能模块示意图；

图7是本发明合并联系人的装置第二实施例的功能模块示意图；

图8是本发明合并联系人的装置第三实施例的功能模块示意图；

图9是本发明合并联系人的系统较佳实施例的结构示意图。

为了使本发明的技术方案更加清楚、明了，下面将结合附图作进一步详述。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

如图1所示，图1是本发明实施例方法涉及的硬件环境架构图。本发明实施例方法涉及的硬件运行环境包括用户客户端，以及服务器或者本地终端（比如PC，或者手机等移动终端），本实施例以服务器20进行举例，其中，用户客户端可以为PC终端10、移动终端30等具有触发合并重复联系人功能的终端，客户端与服务器20可以通过无线网络或者有线网络进行通信，客户端10上安装有应用程序，并提供用户操作界面，供用户点击合并重复联系人选择项，客户端根据用户操作指令，向服务器20请求合并重复联系人，服务器20在接收到用户客户端发起的合并重复联系人名片请求时，根据合并重复联系人名片请求，拉取用户联系人名片数据，基于用户联系人名片数据，对用户联系人名片进行比较，根据比较结果，以预定策略对用户联系人名片进行处理，由此提高重复联系人的合并准确性，节省服务器端的存储空间。

由于联系人的名字、手机号码（具有全局唯一性，每个人的电话不会重复）、邮箱地址（具有全局唯一性，每个人的邮箱地址不会重复）等具有一定的唯一性，只要联系人名片其中的一个字段出现相同，则基本上可以判定两个联系人名片是重复的。基于这些考虑，本发明实施例方案对联系人名片通用化成标准的vcard形式，然后根据比较算法进行比较，把比较结果设定为：相等、相似（主要字段相同，主要字段可以指姓名、手机号码、家庭电话、办公电话等）和不相等三种情况，然后对不同的比较结果进行相应的处理。

具体地，基于上述图1所示的硬件架构，提出以下实施例中合并联系人的方法。

如图2所示，本发明第一实施例提出一种联系人信息处理方法，包括：

步骤S101，接收用户客户端发起的合并重复联系人名片请求；

本实施例方法的执行主体可以为服务器，也可以为本地终端，比如本地计算机或者手机等移动终端，本实施例以服务器进行举例。

其中，用户客户端可以为PC终端、移动终端等具有触发合并重复联系人功能的终端，终端界面上提供有供用户点击操作的合并重复联系人选择项。比如，用户可以在手机端或者PC web端入口，点击合并重复联系人选择项，客户端会根据用户操作指令，向服务器请求合并重复联系人名片。

该合并重复联系人名片请求中可以携带用户的ID信息等；该请求可以以http方式发送至服务器端。

其中，联系人名片以一个或多个字段记录有用户的联系人信息，比如联系人的姓名、手机号码、家庭电话、办公电话等。

步骤S102，根据所述合并重复联系人名片请求，拉取用户联系人名片数据；

服务器在接收到客户端发起的合并重复联系人名片请求后，从后台拉取对应该用户的用户联系人名片数据。

步骤S103，基于所述用户联系人名片数据，对用户联系人名片进行比较，根据比较结果，以预定策略对用户联系人名片进行处理。

服务器在拉取到用户联系人名片数据后，对各用户联系人名片数据进行分析，比较各用户联系人名片是否相同，以便根据比较结果进行相应的删除、合并处理或者不做处理。

本实施例考虑到：由于联系人的名字、手机号码（具有全局唯一性，每个人的电话不会重复）、邮箱地址（具有全局唯一性，每个人的邮箱地址不会重复）等具有一定的唯一性，只要联系人名片其中的一个字段出现相同，则基本上可以判定两个联系人名片是重复的。

因此，基于上述考虑，本实施例根据比较算法对联系人名片进行比较，把比较结果设定为：联系人信息相等、相似和不相等三种情况，然后对不同的比较结果进行相应的处理。

其中，联系人信息相等条件是指用户联系人名片中各项联系人信息均相同。其中，各项联系人信息均相同可以包括用户联系人名片中各项联系人信息完全相同的情形，也可以包括用户联系人名片中各项联系人信息实质相同的情形，对于联系人信息实质相同的判断，可以根据实际情况设定，或者通过一定的算法视为相同，比如相同的电话号码，在用户联系人名片中可以带本地区号，也可以不带本地区号，又比如，对于中国号码，在号码前加国别号86与不加86，实质为同一个电话号码；还比如，联系人信息中有头像与无头像不影响是否为同一联系人的判断，也可以认为实质上属于同一联系人信息。

联系人信息相似条件是指用户联系人名片中设定的一项或多项字段的联系人信息相同。比如：主要字段相同，主要字段可以指姓名、手机号码、家庭电话、办公电话等。

联系人信息不相等条件是指用户联系人名片中各项联系人信息均不相同，或者用户联系人名片中主要字段的联系人信息不相同。

具体处理过程可以设定如下：

若比较结果为相等，则将对比较结果相等的一组联系人名片进行自动化处理，保留联系人名片组其中一个用户联系人名片，将用户联系人名片组中其它相同的用户联系人名片删除，该操作可以不用提示用户，处理的结果采用最新备份到服务器的联系人名片时间为准。

若比较结果为相似（主要字段相同，主要字段比如可以指姓名、手机号码、家庭电话、办公电话等），则对比较结果相似的一组联系人名片提示用户，让用户根据自己的需要进行手动合并。

其中，提示用户的内容可以包括：满足联系人信息相似条件的联系人名片组，并显示各联系人名片的各个字段信息；同时提示用户是否对其中的两个或多个联系人名片进行合并处理。

上述对满足联系人信息相似条件的联系人名片组的合并处理可以是指：对两个或多个联系人名片中的各个字段信息进行组合，由此合并形成一个新的联系人名片；也可以是由用户选择其中一个联系人名片作为当前联系人的信息，而将满足联系人信息相似条件的联系人名片组中的其他联系人名片删除。

用户可以根据实际情况判断是否对符合联系人信息相似条件的用户联系人名片进行相应的合并处理，若需要，则可以在客户端手动操作进行字段选择合并，或者相应的删除处理，服务器根据用户客户端的操作结果，对符合联系人信息相似条件的用户联系人名片组进行相应的合并处理。

若比较结果为不相等，则可以将比较结果不显示给用户，即可以不做任何处理，或者向用户客户端反馈相应的执行结果信息，比如反馈合并操作结束、已无重复联系人名片需要合并等信息。

本实施例通过上述方案，服务器端在接收到用户客户端发起的合并重复联系人名片请求时，根据合并重复联系人名片请求，拉取用户联系人名片数据，基于用户联系人名片数据，对用户联系人名片进行比较，根据比较结果，以预定策略对用户联系人名片进行相应处理，由此提高了重复联系人的合并准确性，节省了服务器端的存储空间。

更为具体地，如图3所示，上述步骤S103可以包括：

步骤S1031，基于用户联系人名片数据，对用户联系人名片进行比较；当比较结果符合设定的联系人信息相等条件时，进入步骤S1032；当比较结果符合设定的联系人信息相似条件时，进入步骤S1033；当比较结果符合设定的联系人信息不相等条件时，进入步骤S1035；

步骤S1032，对于符合联系人信息相等条件的用户联系人名片组，保留其中一用户联系人名片，将用户联系人名片组中其它用户联系人名片删除。

步骤S1033，将符合联系人信息相似条件的用户联系人名片组返回给用户客户端，由用户判断是否对所述符合联系人信息相似条件的用户联系人名片进行合并处理；

步骤S1034，当用户请求对所述符合联系人信息相似条件的用户联系人名片进行合并处理时，所述服务器对符合联系人信息相似条件的用户联系人名片组进行相应的合并处理。

步骤S1035，不作任何处理，或者向用户客户端反馈相应的执行结果信息。

具体地，作为一种实现方式，首先，服务器基于用户联系人名片数据，对用户联系人名片进行比较，判断各用户联系人名片是否符合联系人信息相等条件。

当比较结果符合设定的联系人信息相等条件时，对于符合联系人信息相等条件的用户联系人名片组进行相应处理，比如保留联系人名片组其中一个用户联系人名片，将用户联系人名片组中其它相同的用户联系人名片删除。

对于不符合联系人信息相等条件的用户联系人名片，判断所述用户联系人名片是否符合联系人信息相似条件。

当比较结果符合设定的联系人信息相似条件时，将符合联系人信息相似条件的用户联系人名片组返回给用户客户端。

用户可以根据实际情况判断是否对所述符合联系人信息相似条件的用户联系人名片进行合并处理，若需要，则可以在客户端手动操作进行字段选择合并，或者相应的删除处理，服务器根据用户客户端的操作结果，对符合联系人信息相似条件的用户联系人名片组进行相应的合并处理。

对于不符合联系人信息相等条件的用户联系人名片，若其比较结果符合设定的联系人信息不相等条件时，可以不作任何处理，或者向用户客户端反馈相应的执行结果信息。

由此通过上述方案，让用户相同的联系人名片得到合并，同时相似的联系人名片分组让用户进行字段选择合并，更加智能化地合并用户由于各种原因导致的服务器端联系人名片重复，解决了用户重复联系人名片的问题，不仅提高了重复联系人的合并准确性，节省了服务器端的存储空间，而且给用户带来较好的体验。

如图4所示，本发明第二实施例提出一种合并联系人的方法，在上述图2所示的第一实施例的基础上，在上述步骤S102：根据合并重复联系人名片请求，拉取用户联系人名片数据之后还包括：

步骤S104，对所述用户联系人名片数据进行通用化处理。

本实施例与上述第一实施例的区别在于，本实施例服务器在拉取到用户联系人名片数据后，还需要对用户联系人名片数据进行通用化处理，以提高联系人名片的可对比性，方便服务器对不同的用户联系人名片进行比较。

其中，对用户联系人名片数据进行通用化处理可以是：对用户联系人名片中的各字段按一定规律进行编排处理，比如，对表1中的各用户联系人名片，可以按照用户联系人名片中的字段：编号、姓名、手机号码、邮箱地址等顺序统一编排，由此，方便服务器对不同字段进行比较，提高服务器对不同的用户联系人名片进行比较时的操作效率。

如图5所示，本发明第三实施例提出一种合并联系人的方法，在上述图3所示的第二实施例的基础上，在上述步骤S101：服务器接收用户客户端发起的合并重复联系人名片请求之后还包括：

步骤S105，对所述合并重复联系人名片请求进行合法性验证，当验证通过之后，执行步骤S102，否则，进入步骤S106。

步骤S106，向用户客户端提示验证失败信息。

本实施例与上述图3所示的第二实施例的区别在于，本实施例在服务器接收到用户客户端发起的合并重复联系人名片请求后，服务器还需要对用户的身份进行合法性验证，以提高联系人名片合并操作的安全性。

具体地，服务器在接收到用户客户端发起的合并重复联系人名片请求之后，对合并重复联系人名片请求进行合法性验证，比如，对用户请求中携带的用户ID进行匹配，若匹配成功，则验证通过，表明用户身份合法；若匹配失败，则验证未通过，表明用户身份不合法。

当验证通过之后，服务器根据合并重复联系人名片请求，拉取用户联系人名片数据；并基于所述用户联系人名片数据，对用户联系人名片进行比较，根据比较结果，以预定策略对用户联系人名片进行合并处理。

当验证未通过时，向用户客户端提示验证失败信息。

本实施例通过上述方案，服务器端在接收到用户客户端发起的合并重复联系人名片请求时，对合并重复联系人名片请求进行合法性验证，当验证通过后，根据合并重复联系人名片请求，拉取用户联系人名片数据，对用户联系人名片数据进行通用化处理，基于用户联系人名片数据，对用户联系人名片进行比较，根据比较结果，以预定策略对用户联系人名片进行相应处理，不仅提高了重复联系人的合并准确性，节省了服务器端的存储空间，而且提高了联系人名片合并操作的安全性和效率。

如图6所示，本发明第一实施例提出一种联系人信息处理装置，包括：接收模块201、拉取模块202、比较模块203以及处理模块204，其中：

接收模块201，用于接收用户客户端发起的合并重复联系人名片请求；

拉取模块202，用于根据所述合并重复联系人名片请求，拉取用户联系人名片数据；

比较模块203，用于基于所述用户联系人名片数据，对用户联系人名片进行比较；

处理模块204，用于根据比较结果，以预定策略对用户联系人名片进行处理。

本实施例装置可以设置在服务器上，也可以设置在本地终端，比如本地计算机或者手机等移动终端，本实施例以服务器进行举例。

其中，用户客户端可以为PC终端、移动终端等具有触发合并重复联系人功能的终端，终端界面上提供有供用户点击操作的合并重复联系人选择项。比如，用户可以在手机端或者PC web端入口，点击合并重复联系人选择项，客户端会根据用户操作指令，向服务器请求合并重复联系人名片。

该合并重复联系人名片请求中可以携带用户的ID信息等；该请求可以以http方式发送至服务器端。

其中，联系人名片以一个或多个字段记录有用户的联系人信息，比如联系人的姓名、手机号码、家庭电话、办公电话等。

服务器在接收到客户端发起的合并重复联系人名片请求后，从后台拉取对应该用户的用户联系人名片数据。

服务器在拉取到用户联系人名片数据后，对各用户联系人名片数据进行分析，比较各用户联系人名片是否相同，以便根据比较结果进行相应的删除、合并处理或者不做处理。

本实施例考虑到：由于联系人的名字、手机号码（具有全局唯一性，每个人的电话不会重复）、邮箱地址（具有全局唯一性，每个人的邮箱地址不会重复）等具有一定的唯一性，只要联系人名片其中的一个字段出现相同，则基本上可以判定两个联系人名片是重复的。

因此，基于上述考虑，本实施例根据比较算法对联系人名片进行比较，把比较结果设定为：联系人信息相等、相似和不相等三种情况，然后对不同的比较结果进行相应的处理。

其中，联系人信息相等条件是指用户联系人名片中各项联系人信息均相同。其中，各项联系人信息均相同可以包括用户联系人名片中各项联系人信息完全相同的情形，也可以包括用户联系人名片中各项联系人信息实质相同的情形，对于联系人信息实质相同的判断，可以根据实际情况设定，或者通过一定的算法视为相同，比如相同的电话号码，在用户联系人名片中可以带本地区号，也可以不带本地区号，又比如，对于中国号码，在号码前加国别号86与不加86，实质为同一个电话号码；还比如，联系人信息中有头像与无头像不影响是否为同一联系人的判断，也可以认为实质上属于同一联系人信息。

联系人信息相似条件是指用户联系人名片中设定的一项或多项字段的联系人信息相同。比如：主要字段相同，主要字段可以指姓名、手机号码、家庭电话、办公电话等。

联系人信息完全不相等条件是指用户联系人名片中各项联系人信息均不相同，或者用户联系人名片中主要字段的联系人信息不相同。

具体处理过程可以设定如下：

若比较结果为相等，则将对比较结果相等的一组联系人名片进行自动化处理，保留联系人名片组其中一个用户联系人名片，将用户联系人名片组中其它相同的用户联系人名片删除，该操作可以不用提示用户，处理的结果采用最新备份到服务器的联系人名片时间为准。

若比较结果为相似（主要字段相同，主要字段比如可以指姓名、手机号码、家庭电话、办公电话等），则对比较结果相似的一组联系人名片提示用户，让用户根据自己的需要进行手动合并。

其中，提示用户的内容可以包括：满足联系人信息相似条件的联系人名片组，并显示各联系人名片的各个字段信息；同时提示用户是否对其中的两个或多个联系人名片进行合并处理。

上述对满足联系人信息相似条件的联系人名片组的合并处理可以是指：对两个或多个联系人名片中的各个字段信息进行组合，由此合并形成一个新的联系人名片；也可以是由用户选择其中一个联系人名片作为当前联系人的信息，而将满足联系人信息相似条件的联系人名片组中的其他联系人名片删除。

用户可以根据实际情况判断是否对符合联系人信息相似条件的用户联系人名片进行相应的合并处理，若需要，则可以在客户端手动操作进行字段选择合并，或者相应的删除处理，服务器根据用户客户端的操作结果，对符合联系人信息相似条件的用户联系人名片组进行相应的合并处理。

若比较结果为不相等，则可以将比较结果不显示给用户，即可以不做任何处理，或者向用户客户端反馈相应的执行结果信息，比如反馈合并操作结束、已无重复联系人名片需要合并等信息。

本实施例通过上述方案，服务器端在接收到用户客户端发起的合并重复联系人名片请求时，根据合并重复联系人名片请求，拉取用户联系人名片数据，基于用户联系人名片数据，对用户联系人名片进行比较，根据比较结果，以预定策略对用户联系人名片进行相应处理，由此提高了重复联系人的合并准确性，节省了服务器端的存储空间。

更为具体地，所述合并处理模块203，还用于基于用户联系人名片数据，对用户联系人名片进行比较；当比较结果符合设定的联系人信息相等条件时，对于符合联系人信息相等条件的用户联系人名片组进行相应处理，比如保留联系人名片组其中一个用户联系人名片，将用户联系人名片组中其它相同的用户联系人名片删除。

所述合并处理模块203，还用于当比较结果符合设定的联系人信息相似条件时，将符合联系人信息相似条件的用户联系人名片组返回给用户客户端，由用户判断是否对所述符合联系人信息相似条件的用户联系人名片进行合并处理；当用户请求对所述符合联系人信息相似条件的用户联系人名片进行合并处理时，对符合联系人信息相似条件的用户联系人名片组进行相应的合并处理。

所述合并处理模块203，还用于当比较结果符合设定的联系人信息不相等条件时，不做任何处理，或者向用户客户端反馈相应的执行结果信息。

由此通过上述方案，让用户相同的联系人名片得到合并，同时相似的联系人名片分组让用户进行字段选择合并，更加智能化地合并用户由于各种原因导致的服务器端联系人名片重复，解决了用户重复联系人名片的问题，不仅提高了重复联系人的合并准确性，节省了服务器端的存储空间，而且给用户带来较好的体验。

如图7所示，本发明第二实施例提出一种合并联系人的服务器，在上述图6所示的第一实施例的基础上，还包括：

通用化处理模块205，用于对所述用户联系人名片数据进行通用化处理。

本实施例与上述第一实施例的区别在于，本实施例服务器在拉取到用户联系人名片数据后，还需要对用户联系人名片数据进行通用化处理，以提高联系人名片的可对比性，方便服务器对不同的用户联系人名片进行比较。

其中，对用户联系人名片数据进行通用化处理可以是：对用户联系人名片中的各字段按一定规律进行编排处理，比如，对表1中的各用户联系人名片，可以按照用户联系人名片中的字段：编号、姓名、手机号码、邮箱地址等顺序统一编排，由此，方便服务器对不同字段进行比较，提高服务器对不同的用户联系人名片进行比较时的操作效率。

如图8所示，本发明第三实施例提出一种合并联系人的服务器，在上述图7所示的第二实施例的基础上，还包括：

验证模块206，用于对所述合并重复联系人名片请求进行合法性验证，当验证通过之后，由所述拉取模块根据所述合并重复联系人名片请求，拉取用户联系人名片数据。

本实施例与上述图7所示的第二实施例的区别在于，本实施例在服务器接收到用户客户端发起的合并重复联系人名片请求后，服务器还需要对用户的身份进行合法性验证，以提高联系人名片合并操作的安全性。

具体地，服务器在接收到用户客户端发起的合并重复联系人名片请求之后，对合并重复联系人名片请求进行合法性验证，比如，对用户请求中携带的用户ID进行匹配，若匹配成功，则验证通过，表明用户身份合法；若匹配失败，则验证未通过，表明用户身份不合法。

当验证通过之后，服务器根据合并重复联系人名片请求，拉取用户联系人名片数据；并基于所述用户联系人名片数据，对用户联系人名片进行比较，根据比较结果，以预定策略对用户联系人名片进行合并处理。

当验证未通过时，向用户客户端提示验证失败信息。

本实施例通过上述方案，服务器端在接收到用户客户端发起的合并重复联系人名片请求时，对合并重复联系人名片请求进行合法性验证，当验证通过后，根据合并重复联系人名片请求，拉取用户联系人名片数据，对用户联系人名片数据进行通用化处理，基于用户联系人名片数据，对用户联系人名片进行比较，根据比较结果，以预定策略对用户联系人名片进行合并处理，不仅提高了重复联系人的合并准确性，节省了服务器端的存储空间，而且提高了联系人名片合并操作的安全性和效率。

如图9所示，本发明较佳实施例提出一种合并联系人的系统，包括：用户客户端301及服务器302，其中：

所述用户客户端301，用于向所述服务器302发起合并重复联系人名片请求；

所述服务器302可以包括上述实施例所述的装置。

优选地，所述用户客户端301，还用于当比较结果符合设定的联系人信息相似条件时，接收所述服务器302返回的符合联系人信息相似条件的用户联系人名片组，判断是否对所述符合联系人信息相似条件的用户联系人名片进行合并处理；若是，则向所述服务器302请求对所述符合联系人信息相似条件的用户联系人名片进行合并处理。

具体地，可以参照图1所示，本实施例中，用户客户端301可以为PC终端、移动终端等具有触发合并重复联系人功能的终端，终端界面上提供有供用户点击操作的合并重复联系人选择项。比如，用户可以在手机端或者PC web端入口，点击合并重复联系人选择项，客户端会根据用户操作指令，向服务器302请求合并重复联系人名片。

该合并重复联系人名片请求中可以携带用户的ID信息等；该请求可以以http方式发送至服务器302端。

其中，联系人名片以一个或多个字段记录有用户的联系人信息，比如联系人的姓名、手机号码、家庭电话、办公电话等。

服务器302在接收到客户端发起的合并重复联系人名片请求后，从后台拉取对应该用户的用户联系人名片数据。

服务器302在拉取到用户联系人名片数据后，对各用户联系人名片数据进行分析，比较各用户联系人名片是否相同，以便根据比较结果进行相应的合并处理或者不做处理。

本实施例考虑到：由于联系人的名字、手机号码（具有全局唯一性，每个人的电话不会重复）、邮箱地址（具有全局唯一性，每个人的邮箱地址不会重复）等具有一定的唯一性，只要联系人名片其中的一个字段出现相同，则基本上可以判定两个联系人名片是重复的。

因此，基于上述考虑，本实施例根据比较算法对联系人名片进行比较，把比较结果设定为：联系人信息完全相等、相似和不相等三种情况，然后对不同的比较结果进行相应的处理。

其中，联系人信息相等条件是指用户联系人名片中各项联系人信息均相同，其中，各项联系人信息均相同可以包括用户联系人名片中各项联系人信息完全相同的情形，也可以包括用户联系人名片中各项联系人信息实质相同的情形，对于联系人信息实质相同的判断，可以根据实际情况设定，或者通过一定的算法视为相同，比如相同的电话号码，在用户联系人名片中可以带本地区号，也可以不带本地区号，又比如，对于中国号码，在号码前加国别号86与不加86，实质为同一个电话号码；还比如，联系人信息中有头像与无头像不影响是否为同一联系人的判断，也可以认为实质上属于同一联系人信息。。

联系人信息相似条件是指用户联系人名片中设定的一项或多项字段的联系人信息相同。比如：主要字段相同，主要字段可以指姓名、手机号码、家庭电话、办公电话等。

联系人信息不相等条件是指用户联系人名片中各项联系人信息均不相同，或者用户联系人名片中主要字段的联系人信息不相同。

具体处理过程可以设定如下：

若比较结果为相等，则将对比较结果相等的一组联系人名片进行自动化处理，保留联系人名片组其中一个用户联系人名片，将用户联系人名片组中其它相同的用户联系人名片删除，该操作可以不用提示用户，处理的结果采用最新备份到服务器的联系人名片时间为准。

若比较结果为相似（主要字段相同，主要字段比如可以指姓名、手机号码、家庭电话、办公电话等），则对比较结果相似的一组联系人名片提示用户，让用户根据自己的需要进行手动合并。

其中，提示用户的内容可以包括：满足联系人信息相似条件的联系人名片组，并显示各联系人名片的各个字段信息；同时提示用户是否对其中的两个或多个联系人名片进行合并处理。

上述对满足联系人信息相似条件的联系人名片组的合并处理可以是指：对两个或多个联系人名片中的各个字段信息进行组合，由此合并形成一个新的联系人名片；也可以是由用户选择其中一个联系人名片作为当前联系人的信息，而将满足联系人信息相似条件的联系人名片组中的其他联系人名片删除。

用户可以根据实际情况判断是否对符合联系人信息相似条件的用户联系人名片进行相应的合并处理，若需要，则可以在客户端手动操作进行字段选择合并，或者相应的删除处理，服务器根据用户客户端的操作结果，对符合联系人信息相似条件的用户联系人名片组进行相应的合并处理。

若比较结果为不相等，则可以将比较结果不显示给用户，即可以不做任何处理，或者向用户客户端301反馈相应的执行结果信息，比如反馈合并操作结束、已无重复联系人名片需要合并等信息。

本实施例通过上述方案，服务器302端在接收到用户客户端301发起的合并重复联系人名片请求时，根据合并重复联系人名片请求，拉取用户联系人名片数据，基于用户联系人名片数据，对用户联系人名片进行比较，根据比较结果，以预定策略对用户联系人名片进行相应处理，由此提高了重复联系人的合并准确性，节省了服务器302端的存储空间。

而且本实施例让用户完全相同的联系人名片得到合并，同时相似的联系人名片分组让用户进行字段选择合并，更加智能化地合并用户由于各种原因导致的服务器302端联系人名片重复，解决了用户重复联系人名片的问题，而且给用户带来较好的体验。

进一步地，服务器302在拉取到用户联系人名片数据后，还需要对用户联系人名片数据进行通用化处理，以提高联系人名片的可对比性，方便服务器302对不同的用户联系人名片进行比较。

其中，对用户联系人名片数据进行通用化处理可以是：对用户联系人名片中的各字段按一定规律进行编排处理，比如，对表1中的各用户联系人名片，可以按照用户联系人名片中的字段：编号、姓名、手机号码、邮箱地址等顺序统一编排，由此，方便服务器302对不同字段进行比较，提高服务器302对不同的用户联系人名片进行比较时的操作效率。

进一步地，在服务器302接收到用户客户端301发起的合并重复联系人名片请求后，服务器302还需要对用户的身份进行合法性验证，以提高联系人名片合并操作的安全性。

具体地，服务器302在接收到用户客户端301发起的合并重复联系人名片请求之后，对合并重复联系人名片请求进行合法性验证，比如，对用户请求中携带的用户ID进行匹配，若匹配成功，则验证通过，表明用户身份合法；若匹配失败，则验证未通过，表明用户身份不合法。

当验证通过之后，服务器302根据合并重复联系人名片请求，拉取用户联系人名片数据；并基于所述用户联系人名片数据，对用户联系人名片进行比较，根据比较结果，以预定策略对用户联系人名片进行合并处理。

当验证未通过时，向用户客户端301提示验证失败信息。

由此通过上述方案，服务器302端在接收到用户客户端301发起的合并重复联系人名片请求时，对合并重复联系人名片请求进行合法性验证，当验证通过后，根据合并重复联系人名片请求，拉取用户联系人名片数据，对用户联系人名片数据进行通用化处理，基于用户联系人名片数据，对用户联系人名片进行比较，根据比较结果，以预定策略对用户联系人名片进行相应处理，不仅提高了重复联系人的合并准确性，节省了服务器302端的存储空间，而且提高了联系人名片合并操作的安全性和效率。

还需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质（如ROM/RAM、磁碟、光盘）中，包括若干指令用以使得一台终端设备（可以是手机，计算机，服务器，或者网络设备等）执行本发明各个实施例所述的方法。

以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (16)

1.一种联系人信息处理方法，其特征在于，包括：

接收用户客户端发起的合并重复联系人名片请求；

根据所述合并重复联系人名片请求，拉取用户联系人名片数据；

基于所述用户联系人名片数据，对用户联系人名片进行比较；

根据比较结果，以预定策略对用户联系人名片进行处理。

2.根据权利要求1所述的方法，其特征在于，所述根据合并重复联系人名片请求，拉取用户联系人名片数据的步骤之后还包括：

对所述用户联系人名片数据进行通用化处理。

3.根据权利要求1或2所述的方法，其特征在于，所述根据比较结果，以预定策略对用户联系人名片进行处理的步骤包括：

当比较结果符合设定的联系人信息相等条件时，对于符合联系人信息相等条件的用户联系人名片组，保留其中一用户联系人名片，将用户联系人名片组中其它用户联系人名片删除。

4.根据权利要求1或2所述的方法，其特征在于，所述根据比较结果，以预定策略对用户联系人名片进行处理的步骤之后包括：

当比较结果符合设定的联系人信息相似条件时，将符合联系人信息相似条件的用户联系人名片组返回给用户客户端，由用户判断是否对所述符合联系人信息相似条件的用户联系人名片进行合并处理；

当用户请求对所述符合联系人信息相似条件的用户联系人名片进行合并处理时，对符合联系人信息相似条件的用户联系人名片组进行相应的合并处理。

5.根据权利要求1或2所述的方法，其特征在于，所述根据比较结果，以预定策略对用户联系人名片进行处理的步骤之后还包括：

当比较结果符合设定的联系人信息不相等条件时，向用户客户端反馈相应的执行结果信息。

6.根据权利要求3所述的方法，其特征在于，所述联系人信息相等条件是指用户联系人名片中各项联系人信息均相同。

7.根据权利要求3所述的方法，其特征在于，所述联系人信息相似条件是指用户联系人名片中设定的一项或多项字段的联系人信息相同；所述联系人信息不相等条件是指用户联系人名片中设定的所有项字段的联系人信息均不相同。

8.根据权利要求1或2所述的方法，其特征在于，所述接收用户客户端发起的合并重复联系人名片请求的步骤之后还包括：

对所述合并重复联系人名片请求进行合法性验证，当验证通过之后，执行步骤根据所述合并重复联系人名片请求，拉取用户联系人名片数据。

9.一种联系人信息处理装置，其特征在于，包括：

接收模块，用于接收用户客户端发起的合并重复联系人名片请求；

拉取模块，用于根据所述合并重复联系人名片请求，拉取用户联系人名片数据；

比较模块，用于基于所述用户联系人名片数据，对用户联系人名片进行比较；

处理模块，用于根据比较结果，以预定策略对用户联系人名片进行处理。

10.根据权利要求9所述的置，其特征在于，还包括：

通用化处理模块，用于对所述用户联系人名片数据进行通用化处理。

11.根据权利要求9或10所述的装置，其特征在于，

所述处理模块，还用于当比较结果符合设定的联系人信息相等条件时，对于符合联系人信息相等条件的用户联系人名片组，保留其中一用户联系人名片，将用户联系人名片组中其它用户联系人名片删除。

12.根据权利要求9或10所述的装置，其特征在于，

所述处理模块，还用于当比较结果符合设定的联系人信息相似条件时，将符合联系人信息相似条件的用户联系人名片组返回给用户客户端，由用户端判断是否对所述符合联系人信息相似条件的用户联系人名片进行合并处理；当用户请求对所述符合联系人信息相似条件的用户联系人名片进行合并处理时，对符合联系人信息相似条件的用户联系人名片组进行相应的合并处理。

13.根据权利要求9或10所述的装置，其特征在于，

所述处理模块，还用于当比较结果符合设定的联系人信息不相等条件时，向用户客户端反馈相应的执行结果信息。

14.根据权利要求11所述的装置，其特征在于，还包括：

验证模块，用于对所述合并重复联系人名片请求进行合法性验证，当验证通过之后，由所述拉取模块根据所述合并重复联系人名片请求，拉取用户联系人名片数据。

15.一种联系人信息处理系统，其特征在于，包括：用户客户端及服务器，其中：

所述用户客户端，用于向所述服务器发起合并重复联系人名片请求；

所述服务器包括权利要求9-14中任一项所述的装置。

16.根据权利要求15所述的系统，其特征在于，

所述用户客户端，还用于当比较结果符合设定的联系人信息相似条件时，接收所述服务器返回的符合联系人信息相似条件的用户联系人名片组，判断是否对所述符合联系人信息相似条件的用户联系人名片进行合并处理；若是，则向所述服务器请求对所述符合联系人信息相似条件的用户联系人名片进行合并处理。