本发明涉及数据同步技术，特别涉及一种检测与解决数据同步冲突的实现方法。

为了制订可以在多个平台及网络之间实现个人信息与企业内数据同步的标准规格，于2000年2月份创建了业界团体SyncML iniative。后来SyncML规范移交到了OMA DS工作组(Open Mobile Alliance，Data Synchronization WorkGroup)。开发SyncML的目的在于，使终端用户、设备开发商、基础构件开发商、数据提供商、应用软件开发商以及服务提供商协同工作，真正实现使用任何终端设备均可随时随地访问任何网络数据。
SyncML的典型应用是在移动设备和网络服务之间的数据同步。除此之外，SyncML还可用于对等的数据同步，如两台PC之间。也就是说，两台PC中的任何一台既可以作为客户端，也可以作为服务器，客户端可以主动向服务器发起同步，而服务器也可以主动向客户端发起同步。
客户端和服务器之间进行数据同步的流程为：经过同步初始化阶段的参数协商以后，客户端和服务器互相发送各自改变的数据，以保证双方数据的同步。
现有技术中，客户端和服务器进行数据同步的类型有很多，同步类型如表一所示：
表一现有技术中，同步一般分为三个阶段：同步初始化阶段、同步阶段和同步完成阶段。下面仅以双向同步来说明数据同步的过程。
图1是现有技术中双向同步的消息流示意图。
同步初始化阶段，如图1中标出的Pkg#1和Pkg#2。
在同步初始化阶段系统主要完成身份鉴权、需要同步的数据库的协商、同步能力的协商，例如支持同步哪些数据、支持哪些同步类型等。
现有技术中使用消息包的原因是：这种交互过程可能需要持续多次才能完成，但是在逻辑上只有一来一回两种消息。
同步阶段，如图1所表示出的Pkg#3和Pkg#4。客户端和服务器根据数据的状态如新增Add、更新Relpace、删除Delete、移动Move等命令将发生改变的数据通过上述操作命令的方式发送到服务器，服务器按照这些命令进行相同的操作来达到同步的目的；同时服务器也将其发生改变的数据通过操作命令的方式发送给客户端。同步完成阶段如图1标出的Pkg#5和Pkg#6所示，客户端和服务器端互相确认同步完成。
现有技术中的系统包括：数据同步客户端，它通常是一个PC软件、手机或PDA等智能终端。数据同步客户端(Data Synchronization Client)包含一个客户端数据库，用来存储用户所需的数据。这些数据包括：通讯录、日程、便笺、短信、电子邮件等。这些数据均有标准规范定义其格式，各种数据具体的格式如表二所示。客户端可以将数据转换成标准的格式发送给服务器，服务器处理后可保存入自己的数据库中。
表二同步服务器可接收来自Data Sync Client的数据同步消息和同步命令，并能向同步客户端发送同步消息。这个设备可以是一个网络服务器或是一个个人计算机。数据同步服务器(Data Synchronization Server)包含了一个服务器端数据库(Server Database)，用来存放服务器上的数据。
现有技术中的客户端和服务器端数据存储如表三和表四所示。
表三
表四客户端使用LUID(Local Unique Identifier)来唯一标识一条数据，这个LUID可以是针对一种类型数据唯一，例如通讯簿内，也可以是在终端上唯一。服务器端使用GUID(Global Unique Identifer)来唯一表示一条数据，其唯一性与LUID相同。由于终端能力受限，LUID长度可能比较短，服务器端GUID长度则比较长，所以，在服务器端需要维护一个LUID和GUID之间的映射关系表。客户端和服务器端双方进行的操作都会导致相应记录条目状态的变更，双方根据条目状态来确定发送什么操作命令。所述的LUID-GUID的映射关系表如表五所示：
表五现有技术中的客户端发送给服务器的具体操作包括：
增加操作(<Add>)，客户端将生成的LUID以及数据发送给服务器端，服务器完成处理后为其生成GUID，并保存<LUID-GUID>的映射关系；更新操作(<Replace>)，将LUID和数据发送给服务器进行更新；删除操作(<Delete>)，只需要将LUID发送给服务器，服务器根据映射关系找到GUID对应数据进行更新；移动(<Move>)，客户端指明被移动的条目的LUID，以及目的地的LUID，服务器进行相应处理。
现有技术中的服务器端发送给客户端的具体操作包括：增加操作(<Add>)，服务器将生成的GUID以及数据发送给服务器端，客户端完成处理后返回LUID给服务器，有服务器保存<LUID-GUID>的映射关系；更新操作(<Replace>)，将LUID和数据发送给客户端进行更新；删除操作(<Delete>)，只需要将LUID发送给客户端。
移动(<Move>)，服务器指明被移动的条目的LUID，以及目的地的LUID，客户端进行相应处理。
其中，操作命令的交互，是在同步阶段；映射关系的发送是在同步完成阶段。
在现有技术数据同步冲突和解决有机制中，如果客户端和服务器端数据库对同一个条目进行了不同的修改，称为冲突。例如，客户端和服务器端对同一个vCard数据条目进行了修改。现有协议中，缺少完善的冲突检测机制和冲突解决策略：(1)同步阶段客户端将会等待同步的数据全部发送到服务器端，而客户端的这些修改，可能和服务器端的修改产生冲突，如果最终的结果是服务器端的修改生效，则服务器端会将其数据下发给客户端，此时客户端发送的数据则增加了网络流量，延长了同步时间；特别是在同步大对象时这种缺点尤其明显，比如客户端需要发送多个较大的音乐文件。
(2)现有技术中，无法做到字段级别的冲突检测与解决。例如，客户端和服务器端修改了同一条vCard中的“国家”字段；
(3)现有技术中，冲突检测机制不完善，例如，客户端修改了vCard中的“国家”字段，服务器端修改了“街道”字段，这种其实不冲突的，同步时可以将双方的结果合并，但是现有协议中认为是冲突的。现有技术中仅根据修改状态来判断双方是冲突的，最终无法将客户端和服务器的修改合并，仅修改一个字段也要传递所有vCard数据，增加了网络流量。

有鉴于此，本发明的主要目的在于提供一种检测与解决数据同步冲突的实现方法方法，可以在数据同步之前检测出冲突，并根据仲裁策略解决冲突，达到节省同步时间，降低了网络流量的目的。
为了达到上述目的，本发明提出的技术方案为：一种检测与解决数据同步冲突的实现方法，包括以下步骤：A、客户端与服务器端检测数据同步的冲突，并根据检测的冲突检测数据获得冲突仲裁结果；B、客户端与服务器端根据获得的冲突仲裁结果进行数据同步。
较佳地，所述步骤A包括：A1、客户端向服务器端发送冲突检测数据；A2、服务器端根据接收到的冲突检测数据进行冲突检测，并根据预先配置的冲突仲裁策略获得冲突仲裁结果。
较佳地，所述步骤A2和步骤B之间进一步包括：A3、服务器端向客户端发送获得的冲突仲裁结果。
较佳地，所述冲突检测数据包括客户端条目的条目标识，步骤A2所述服务器端根据接收到的冲突检测数据进行冲突检测的方法为：AX1、服务器端接收冲突检测数据，并提取出条目标识；AX2、服务器端根据提取出的条目标识查询自身数据库，确定与所述条目标识对应的服务器端的条目，再根据确定的服务器端条目的修改状态信息检测出冲突。
较佳地，所述冲突检测数据还包括客户端条目的条目修改状态信息，所述步骤AX1进一步包括：服务器端从冲突检测数据中提取出条目修改状态信息；步骤AX2所述根据条目的修改状态信息检测出冲突的方法为：服务器端将提取的条目修改状态信息与自身相应条目的修改状态信息进行对比，检测出冲突。
较佳地，所述冲突检测数据包括客户端条目的条目标识和修改字段标识，步骤A2所述服务器端根据接收到的冲突检测数据进行冲突检测的方法为：AY1、服务器端接收冲突检测数据，提取出条目标识和修改字段标识；AY2、服务器端根据提取出的条目标识和修改字段标识在自身数据库中确定服务器端的字段，然后根据服务器端字段的字段修改状态信息检测出冲突。
较佳地，所述冲突检测数据还包括客户端条目的修改字段状态信息或字段校验和，所述步骤AY1进一步包括：服务器端从冲突检测数据中提取修改字段状态信息或字段校验和；步骤AY2所述根据服务器端字段的字段修改状态信息检测出冲突的方法为：服务器端将提取的修改字段状态信息和自身相应字段的修改状态信息进行对比，检测出冲突；或者，服务器端将提取的字段校验和与自身相应字段的字段校验和进行对比，检测出冲突。
较佳地，所述冲突检测数据包括客户端的条目标识和条目指纹，步骤A2所述服务器端根据接收到的冲突检测数据进行冲突检测的方法为：AZ1、服务器端接收冲突检测数据，并提取出条目标识和条目指纹；AZ2、服务器端根据提取出的条目标识在自身数据库中确定与所述条目标识对应的条目，再将提取的条目指纹与自身相应条目的条目指纹进行对比，检测出冲突。
较佳地，所述条目指纹为：条目的时间戳、摘要值、锚值或版本号。
较佳地，所述客户端向服务器端发送冲突检测数据的方法为：客户端通过新增的同步命令或扩充的同步命令将冲突检测数据发送给服务器。
较佳地，所述服务器端向客户端发送冲突仲裁结果的方法为：服务器端通过新增的同步命令或扩充的同步命令将冲突仲裁结果发送给客户端。
较佳地，如果客户端与服务器端修改了同一条目的不同字段，则该方法进一步包括：所述服务器端在冲突检测时将判定为不冲突，并在数据同步之后将服务器端修改的条目与客户端修改的条目进行合并。
较佳地，所述步骤A之前进一步包括：客户端与服务器端协商是否进行冲突检测。
较佳地，在数据同步协议中增加先解决冲突的同步类型状态码，或增加服务器通知的同步类型状态码，所述客户端与所述服务器端协商的方法为：X1、所述客户端向所述服务器发送初始化请求；X2、所述服务器端判断是否同意所述初始化请求中指示的同步类型，如果不同意，则所述客户端与所述服务器端根据配置的同步类型的冲突解决策略，确定同步类型并进入步骤X3；如果同意，则转步骤X3；X3、所述服务器端判断所述同步类型是否是现有的同步类型，如果是，则按现有的同步流程进行同步，再退出本流程；否则，转步骤A。
较佳地，所述先解决冲突的同步类型状态码为：先解决冲突且后续同步为双向同步的同步类型状态码；或者为先解决冲突且后续同步为慢同步的同步类型状态码；或者为先解决冲突且后续同步为所述客户端的单向同步的同步类型状态码；或者为先解决冲突且后续同步为客户端的刷新同步的同步类型状态码；
或者为先解决冲突且后续同步为服务器端的单向同步的同步类型状态码；或者为，增加先解决冲突，且后续同步为服务器端的刷新同步的同步类型状态码。
较佳地，所述服务器通知的同步类型状态码为：服务器端通知，先解决冲突且后续同步为双向同步的同步类型状态码；或者为服务器端通知，先解决冲突且后续同步为慢同步的同步类型状态码；或者为服务器端通知，先解决冲突且后续同步为客户端的单向同步的同步类型状态码；或者为服务器端通知，先解决冲突且后续同步为客户端的刷新同步的同步类型状态码；或者为服务器端通知，先解决冲突且后续同步为服务器端的单向同步的同步类型状态码；或者为服务器端通知，先解决冲突且后续同步为服务器端的刷新同步的同步类型状态码；所述步骤X1之前进一步包括：服务器端向客户端发送协商通知消息。
较佳地，配置一个先解决冲突的参数，所述客户端与所述服务器端协商的方法为：Y1、客户端向服务器端发送初始化请求；Y2、所述服务器端判断所述初始化请求中是否包含所述先解决冲突的参数，若没有，则按现有的同步流程进行同步，再退出本流程；否则转步骤Y3；Y3、所述服务器端判断是否同意所述初始化请求中的同步类型以及所述先解决冲突的参数，若同意，则转步骤A；否则转步骤Y4；Y4、同步双方协商，确定进行同步的同步类型以及同步流程，并按照新确定的同步流程进行同步，再退出本流程。
较佳地，所述客户端与所述服务器端协商的方法为：客户端向服务器端发送初始化请求，服务器端根据事先配置的协商原则或冲突仲裁原则判断是否进行冲突检测，并向客户端返回协商结果；客户端根据协商结果确定是否进行冲突检测，如果是，则执行步骤A；否则，退出本流程。
较佳地，所述初始化请求包括请求冲突检测的信息。
较佳地，所述客户端与所述服务器端协商的方法为：服务器端向客户端发送协商通知命令，客户端根据协商通知命令确定是否进行冲突检测，如果是，则执行步骤A；否则，退出本流程。
较佳地，所述客户端与所述服务器端协商的方法为：服务器将仲裁原则发送给客户端，客户端直接根据仲裁原则确定是否进行冲突检测，如果是，则执行步骤A；否则，退出本流程。
较佳地，所述预先配置的仲裁策略为：服务器端赢的仲裁策略、客户端赢的仲裁策略、互相忽略的仲裁策略、用户需求的仲裁策略或时间戳仲裁策略。
综上所述，本发明提出一种检测与解决数据同步冲突的实现方法，由于在数据同步之前，客户端和服务器端对需要进行同步的数据进行了冲突检测，如果有冲突，则用冲突仲裁原则对冲突进行仲裁，可以准确地判断出哪些数据需要传输，哪些数据不需要传输，从而可以节省同步时间，降低了网络流量。
另外，由于可以在数据同步冲突检测之前增加一个客户端和服务器端之间协商是否进行冲突检测的步骤，从而可以增加客户端和服务器端选择是否进行冲突检测的灵活性。
附图说明
图1是现有技术的双向数据同步流程的示意图；
图2是本发明方案的流程图；图3是应用本发明方案的实施例一的流程图；图4是应用本发明方案的实施例二的流程图；图5是应用本发明方案的实施例三的流程图；图6是应用本发明方案的实施例四的流程图。

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图及具体实施例对本发明作进一步地详细描述。
本发明提供的是一种检测与解决数据同步冲突的实现方法，能够最大限度的满足用户需要，缩短了数据同步的时间，降低了网络流量。
本发明的核心思想是：客户端与所述服务器端预先进行数据同步冲突的检测，再对冲突进行仲裁，获得仲裁结果，然后根据仲裁结果进行数据同步。
图2是本发明的流程图。如图2所示，本发明检测和解决数据同步冲突的实现方法的步骤包括：步骤201：客户端与服务器端检测数据同步的冲突，并根据冲突检测数据获得冲突仲裁结果。
本发明中，客户端与服务器端检测数据同步的冲突，并获得冲突仲裁结果的方法为：客户端向服务器端发送冲突检测数据；服务器端根据接收到的冲突检测数据进行冲突检测，并根据预先配置的冲突仲裁策略获得冲突仲裁结果。
这里所述的服务器端进行冲突检测的方法有很多，比如：如果冲突检测数据包括条目标识，则冲突检测的方法为：服务器端接收冲突检测数据，并提取出条目标识；服务器端根据提取出的条目标识查询自身数据库，确定与所述条目标识对应的服务器端的条目，再根据确定的服务器端条目的修改状态信息检测出冲突。
在上述方法中，如果客户端修改了某条目，则服务器只要在自身数据库中确定相应的条目也被修改过，就可以直接判断为发生了冲突。
如果冲突检测数据包括条目标识和条目修改状态信息，则冲突检测的方法为：服务器端接收冲突检测数据，提取出条目标识和条目修改状态信息；服务器端根据提取出的条目标识查询自身数据库，确定与所述条目标识对应的服务器端的条目；服务器端再将提取的条目修改状态信息与自身相应条目的修改状态信息进行对比，检测出冲突。
在上述方法中，如果客户端修改了某条目，并用条目修改状态信息标识修改的类型，如“删除”、“更新”等，则服务器端可以将客户端修改的状态信息与自身的修改状态进行比较，判断是否发生了冲突。在这种情况下，可以事先为服务器配置一个冲突检测的原则。比如：客户端和服务器端都对某条目进行了更新，则判断为发生了冲突。又比如：客户端和服务器端都对某条目进行了删除，则判断为不冲突。当然，这里所述的冲突检测原则可以由应用本发明方案的用户自行确定，此处不再赘述。
如果冲突检测数据包括条目标识和修改字段标识，则冲突检测的方法为：服务器端接收冲突检测数据，提取出条目标识和修改字段标识；服务器端根据提取出的条目标识和修改字段标识在自身数据库中确定服务器端的字段，然后根据服务器端字段的字段修改状态信息检测出冲突。
在上述方法中，如果客户端修改了某条目的某字段，则服务器只要在自身数据库中确定相应条目的字段也被修改过，就可以直接判断为发生了冲突。
如果冲突检测数据包括条目标识、修改字段标识和修改字段状态信息，则冲突检测的方法为：服务器端接收冲突检测数据，提取出条目标识、修改字段标识和修改字段状态信息；服务器端根据提取出的条目标识和修改字段标识在自身数据库中确定服务器端的字段；服务器端将提取的修改字段状态信息和自身相应字段的修改状态信息进行对比，检测出冲突。
在上述方法中，如果客户端修改了某条目中某字段，并用字段修改状态信息标识修改的类型，如“删除”、“更新”等，则服务器端可以将客户端修改的状态信息与自身的修改状态进行比较，判断是否发生了冲突。在这种情况下，也可以事先为服务器配置一个冲突检测的原则。比如：客户端和服务器端都对某条目中同一个字段进行了更新，则判断为发生了冲突。又比如：客户端和服务器端对某条目中不同字段进行了修改，则判断不冲突。
如果冲突检测数据包括条目标识、修改字段标识和字段校验和，则冲突检测的方法为：服务器端接收冲突检测数据，提取出条目标识、修改字段标识和字段校验和；服务器端根据提取出的条目标识和修改字段标识在自身数据库中确定服务器端的字段；服务器端将提取的字段校验和与自身相应字段的字段校验和进行对比，检测出冲突。
上述方案中，需要事先为每一个字段的设置一个字段校验和，该字段校验和可以通过Hash算法获得，并可以作为该字段唯一的标识。当字段被修改后，该字段的字段校验和也会相应的变化。所以，服务器端可以直接通过字段校验和来确定是否发生了修改，并且其修改是否相同。如果字段校验和相同，则判断为不冲突；否则，判断为冲突。
如果冲突检测数据包括条目标识和条目指纹，则冲突检测的方法为：服务器端接收冲突检测数据，提取出条目标识和条目指纹；服务器端根据提取出的条目标识在自身数据库中确定与所述条目标识对应的条目，再将提取的条目指纹与自身相应条目的条目指纹进行对比，检测出冲突。
上述方案中，所述的条目指纹是条目的唯一标识，可以为条目的时间戳、摘要值、锚值或版本号，其中锚值即现有技术中的Anchor值。服务器端可以直接比较条目指纹是否相同，如果相同，则判断为不冲突；否则，判断为冲突。
实际应用中，冲突检测数据还可以包括条目标识与条目修改状态信息、字段标识、字段修改状态信息、条目指纹等的组合，至于组合的方式可以由应用本发明方案的用户自行确定，此处不再一一列举。
实际应用中，如果客户端和服务器端是对等关系，服务器端也可以向客户端发送冲突检测数据，由客户端对冲突检测数据进行冲突检测，并根据冲突检测数据获得冲突仲裁结果。此时，客户端充当的是服务器端的角色，而服务器端则充当客户端的角色。
步骤202：客户端与服务器端根据冲突仲裁结果进行数据同步。
本发明中，步骤201与步骤202之间还可以增加由服务器端将冲突仲裁结果返回给客户端的步骤，也可以没有服务器端将冲突仲裁结果返回给客户端的步骤。比如：如果客户端和服务器端之间采用服务器到客户端的单向同步的方式进行数据同步，则当服务器端获得冲突仲裁结果之后，可以由服务器端直接根据冲突仲裁结果将需要同步的数据发送给客户端，实现数据同步。如果客户端和服务器端之间采用双向同步的方式进行数据同步，则当服务器端获得冲突仲裁结果之后，服务器端还需要将冲突仲裁结果返回给客户端，之后，客户端和服务器再根据冲突仲裁结果各自将需要同步的数据发送给对方。
实际应用中，当服务器端确定存在冲突时，需要根据预先配置的仲裁策略对冲突进行仲裁。这里所述的仲裁策略可以由应用本发明方案的用户自行确定。比如：可配置服务器端赢的仲裁策略、客户端赢的仲裁策略、互相忽略的仲裁策略、用户需求的仲裁策略或时间戳仲裁策略。也可以根据实际应用引入其他的仲裁策略，仲裁策略的改变不应理解为对本发明的限制；如果采用服务器端赢的仲裁策略，一旦确定发生冲突，客户端不必将条目或字段上传给服务器，只需服务器端将自身数据库中该条目或字段同步给客户端即可，可以降低网络流量。
如果采用客户端赢的仲裁策略，一旦确定发生冲突，客户端将把自身数据库中条目或字段上传给服务器端，服务器端无需将该条目或字段下传给客户端，同样可以降低网络流量。
如果采用互相忽略的仲裁策略，一旦确定发生冲突，客户端和服务器都不需要向对方发送数据，同样可以降低网络流量。
如果用户需求的仲裁策略，一旦确定发生冲突，可以由用户自行确定以服务器端还是以客户端的数据为标准进行数据同步。
如果采用时间戳仲裁策略，一旦确定某数据对象冲突，可以由修改数据的时间戳确定以服务器端还是以客户端的数据对象为标准进行数据同步。
实际应用中，本发明中客户端和服务器端检测数据同步的冲突可以在同步初始化阶段内完成，也可以在初始化阶段和同步阶段之间完成，也就是说，只要在进行同步阶段之前完成即可。
为了更好地说明本发明方案，下面用一个较佳实施例说明检测与解决数据同步冲突地实现方法。
实施例一本实施例中，客户端数据库的存储状态如表六所示：
表六服务器端数据库的存储状态如表七所示：
表七而此时服务器端存储的映射表如下：
表八客户端修改LUID＝12条目的First Name，并且删除了LUID＝13的条目，同时把LUID＝15的数据条目从根目录移动到“好友”目录，还修改了LUID＝16的数据条目的Last Name。修改之后的数据库如表九所示：
表九服务器端删除了GUID＝1012的条目，并且修改了GUID＝1013的条目的Last Name，同时把GUID＝1015的条目从根目录移动到“同事”目录。修改之后，如表十所示：
表十另外，本实施例中，服务器可以根据预先设置的冲突原则判断是否发生冲突。
这里所述的冲突原则可以如表十一所示。
表十一实际应用中，还可能存在其它检测冲突的原则，此时不再一一列举。
图3是本实施例的流程图。如图3所示，本实施例实现检测与解决数据同步冲突的实现方法包括以下步骤：步骤301：客户端向服务器端发送所述冲突检测数据。
本实施例中，客户端对条目标识LUID＝12的条目、LUID＝13的条目、LUID＝15，LUID＝16的条目分别进行了修改，需要将相应的条目标识和条目修改状态信息作为冲突检测数据发送给服务器端。
实际应用中，客户端向服务器端发送冲突检测数据的方式很多，比如：可以通过新增的同步命令或扩充的同步命令将冲突检测数据发送给服务器。
如果通过新增的同步命令，该命令可以表示为XML格式。例如可给该命令命名为<ConflictDetect>，该命令中携带的冲突检测数据至少包含数据对象的标识和数据对象的修改状态，还可进一步还包括时间戳、修改字段名称、修改字段状态与对修改数据生成的校验和之中的一个或几个的组合。上述的冲突检测数据可以包含在冲突检测命令的一个标签中，或包含在多个标签中。以下给出新增的同步命令的XML格式的几个实施例。
例如上述的同步命令可以采用以下的格式组织，即将数据对象标识根据它们的修改状态的不同包含在不同的元素中，如下所示：<ConflictDetect>
<命令编号>5</命令编号>
<修改数据的标识>11，13，14</修改数据的标识>
<删除数据的标识>15，16</删除数据的标识>
</ConflictDetect>
上述的命令也可以以以下的格式来组织，即数据对象标识和数据修改状态统一包含在一个元素中，如下所示：<ConflictDetect>
<命令编号>5</命令编号>
<数据项>
<数据的标识>11</修改数据的标识>
<修改状态>删除</修改状态>
</数据项>
<数据项>
<数据的标识>12</修改数据的标识>
<修改状态>更新</修改状态>
</数据项>
</ConflictDetect>
或也可以采用以下的形式组织，即将数据对象标识根据它们的修改状态的不同包含在不同的元素中，一个标识包含在一个元素中，如下所示：<ConflictDetect>
<命令编号>5</命令编号>
<修改数据的标识>
<标识>11</标识>
<标识>12</标识>
</修改数据的标识>
</ConflictDetect>
无论上述的命令以何种格式组织，均在本发明保护范围内。
所述客户端向所述服务器发送冲突检测数据，也可以通过扩充现有的同步命令的含义来实现，例如扩充现有的<Alert>命令，或<Add>命令，或其他命令的含义，如：Replace命令等。
以下给出一种扩充<Alert>命令的含义来实现客户端发送冲突检测数据的实现方案。如果客户端在同步初始化阶段将冲突检测数据发送给服务器端，可以在初始化阶段中的<Alert>命令中携带冲突检测数据，其命令的形式可以为：<Alert>
<命令编号>5</命令编号>
……<修改数据的标识>
<标识>11</标识>
<标识>12</标识>
</修改数据的标识>
</Alert>
实际应用中，还可以在同步过程中定义一新的标签来实现，例如定义<ConflictDetect>用来表示冲突检测数据，定义该标签的DTD如下：(CmdID，Cmd，Source，SoureParent？，Target，TargetParent？，Cred？，Data*)其中加星号“*”，表示该标签可以出现0次或是多次，加“？”表示该标签可出现0次或是1次。
所述客户端发送<ConflictDetect>标签给所述服务器端，所述服务器端对比自己的修改，按照配置的策略解决冲突，并向所述客户端返回冲突解决的结果。例如：所述客户端对数据库中LUID＝15的数据项的FN(First Name)和LN(Last Name)字段进行了修改，则所述客户端发送给所述服务器的冲突检测数据为：
<Conflict>
<CmdID>5</CmdID>
<Cmd>指示进行的操作为修改(Replace)</Cmd>
<Source><LocURI>指示被修改的数据项的LUID＝15</LocURI></Source>
<Data>指示修改的字段为FN和LN</Data>
</Conflict>
其中，可以在<Data>标签中，利用现有规范中定义的CGI语法携带修改的字段。规范中的CGI语法是采用逻辑运算符来表示数据间的逻辑关系，例如“&AND；”表示的是逻辑与，“&OR；”表示逻辑或，其余的运算符如“&EQ；”，“&iEQ；”，“&NE；”，“&iNE；”，“&CON；”，“&iCON；”等等。
例如上述的修改，在<Data>标签中可用CGI语法表示为：<Data>FN & AND；LN</Data>
服务器端对该命令返回的同步命令如下：<Status>
<CmdID>4</CmdID>
<MsgRef>2<MsgRef><CmdRef>5</CmdRef><Cmd>Conflict</Cmd>
<Data>服务器对上述的Conflict标签返回状态码</Data>
</Status>
实际应用中，也可以扩充现有的标签定义，来表示冲突检测数据。
现有的SyncML中，所述客户端与所述服务器端通过<Status>标签对对方同步命令返回执行状态码。现有的<Status>标签的DTD为：(CmdID，MsgRef，CmdRef，Cmd，TargetRef*，SourceRef*，Cred？，Chal？，Data，Item*)为了实现“先解决冲突后同步”的思想，可以扩充规范中的<Status>的含义，在规范中对<Status>增添了一些可选元件，包括：(Source，SourceParent，Target，TargetParent)，使现有的<Status>不但可以对对方的命令返回状态码，同时可以携带冲突检测数据。对<Status>命令的DTD的修改如下所示：
(CmdID，MsgRef*，CmdRef*，Cmd，Source？，SoureParent？，Target？，TargetParent？，TargetRef*，SourceRef*，Cred？，Chal？，Data*，Item*)无论上述的命令以何种格式组织，均在本发明保护范围内。
步骤302：服务器端接收到冲突检测数据，提取出冲突检测数据中的条目标识和条目修改状态信息。
本实施例中，服务器端将接收到客户端的LUID＝12、LUID＝13、LUID＝15、LUID＝16四个条目的条目标识和条目修改状态信息，所述的条目修改状态信息依次为“更新”、“删除”、“移动”和“更新”；服务器端还会接收到LUID＝12条目的First Name字段标识和字段修改状态信息，LUID＝16的条目的Last Name字段标识和字段修改状态信息。
实际应用中，客户端还可以只向服务器端发送条目标识，或发送条目标识和字段标识等。至于客户端向服务器发送的冲突检测数据的内容与服务器端进行冲突检测的方法决定，并可以由应用本发明方案的用户自行确定，此处不再详细叙述。
另外，本实施例中，当服务器端根据接收到的客户端的条目标识查询自身数据库时，还需要通过表八中客户端条目标识和服务器端条目标识的映射关系来查询自身数据库。实际应用中，客户端条目标识和服务器端条目标识还可以直接对应，无需通过表八来进行映射。现有技术中的LUID和GUID的映射机制可能会改变，但是客户端和服务器端之间的数据仍然会存在对应关系，客户端和服务器需要根据标识找到对应的数据，映射机制的改变不应该理解为对本发明的限制。
步骤303：服务器端对比自身相应条目的修改状态信息，检测出冲突。
本实施例中，服务器端可以根据表十一所示的冲突原则对接收的来自客户端的冲突检测数据进行冲突检测。显然，冲突检测之后，服务器端将确定，LUID＝12的条目不冲突，LUID＝13和LUID＝15的条目发生了冲突，需要进行冲突仲裁。
步骤304：服务器端按照预先配置的仲裁策略对冲突进行仲裁，获得冲突仲裁结果。
实际应用中，可以预先在服务器端配置仲裁策略，所述的仲裁策略可以为服务器端赢的仲裁策略、客户端赢的仲裁策略、互相忽略的仲裁策略、用户需求的仲裁策略或时间戳仲裁策略等。当然，如果采用时间戳仲裁策略，还需要为每一个条目或每一个条目的字段设置时间戳，记录最后一次修改的时间，并通过步骤301发送给服务器端。
不管服务器端配置的是哪种仲裁策略，服务器端都可以为检测出的冲突确定一个仲裁结果，从而可以确定哪些条目需要由客户端上传给服务器端，哪些条目需要由服务器端发送给客户端。
比如：本实施例中，如果预先配置服务器端赢的仲裁策略，并且客户端和服务器采用双向同步方式，则服务器端的仲裁结果是：客户端无需上传条目标识LUID＝1013和LUID＝1015的条目的相关数据，只需由服务器将条目标识LUID＝1013和LUID＝1015的条目的相关数据发送给客户端即可。
步骤305：服务器端向客户端发送冲突仲裁结果。
本实施例中，服务器端可以通过新增的同步命令或扩充的同步命令将冲突仲裁结果发送给客户端，其方法与步骤301相似，比如：服务器向客户端下发冲突仲裁结果通过新增的同步命令实现，该命令可以表示成XML语言，例如可命名为<ConflictResult>。所述客户端与所述的服务器可以约定该命令中仅携带需要客户端上传的数据的标识，或仅携带不需要客户端删除的数据项的标识，或返回所有进行冲突检测的数据的标识及其冲突仲裁结果等。以下给出几种<ConflictResult>命令的组织形式，无论该命令以何种形式组织，均在本发明的保护范围里。
在<ConflictResult>中仅返回需客户端上传的数据项的标识，该标识可以统一放在一个元素中或一个标识对应一个元素，如下所示：<ConflictResult>
<命令编号>8</命令编号>
<需要上传的数据项标识>11，13，24</需要上传的数据项标识>
</ConflictResult>
也可在<ConflictResult>中返回返回所有进行冲突检测的数据的标识及其冲突仲裁结果，数据项的标识可以根据冲突仲裁的结果包含在不同的元素中，如下所示：<ConflictResult>
<命令编号>8</命令编号>
<需要上传的数据项标识>11，12，13</需要上传的数据项的标识>
<不需要上传的数据项标识>14，15，16</需要上传的数据项的标识>
<合并的数据项标识>17</合并的数据项标识>
</ConflictResult>
所述的所述服务器向所述客户端发送冲突仲裁结果，也可以通过扩充现有的同步命令的含义来实现，例如扩充<Status>的含义，在现有的<Status>命令中携带上述的冲突仲裁结果。所述客户端与所述的服务器可以约定该命令中仅携带需要客户端上传的数据的标识，或仅携带不需要客户端删除的数据项的标识，或返回所有进行冲突检测的数据的标识及其冲突仲裁结果等。
以下给出一种扩充<Status>命令含义来携带冲突仲裁结果的实施方案，其中，<Status>命令是对携带冲突检测数据的命令进行的回复，如下所示：<Status>
<命令编号>8</命令编号>
<回复命令的编号>7</回复命令的编号>
<回复命令的名称>携带冲突检测数据的命令</回复命令的名称>
……<需上传的数据的标识>11，12，13</需上传的数据的标识>
</Status>
又比如：可以扩充现有的<Status>，其扩充方法如下所示：<Status>
<命令编号>8</命令编号>
<回复命令的编号>7</回复命令的编号>
<回复命令的名称>Alert(携带冲突检测数据的命令)</回复命令的名称>
......
<需上传的数据的标识>11</需上传的数据的标识>
</Status>
实际应用中，服务器端通过冲突仲裁结果通知客户端需要发送哪些条目，不需要发送哪些条目。如果某条目并未发生冲突，但仍然需要由客户端发送给服务器时，也可以通过冲突仲裁结果来通知客户端。比如：本实施例中，LUID＝16未发生冲突，但为了达到双向同步的目的，仍然需要通知客户端上传LUID＝16的条目的相关数据。
步骤306：客户端与服务器端根据冲突仲裁结果进行数据同步。
实际应用中，客户端和服务器端将根据事先在同步初始化阶段指定的方式进行数据同步，比如：双向同步方式、服务器单向同步方式、客户端单向同步方式等。
另外，实际应用中，本实施例中的步骤301～步骤305为可以在同步初始化阶段中进行，也可以在同步初始化阶段和同步阶段之间进行。如果在初始化阶段中进行，可以采用新增的同步命令实现步骤301和步骤305，也可以采用扩充现有的同步命令来实现步骤301和步骤305。如：可以通过初始化阶段中的<Alert>命令来发送冲突检测数据，通过<Status>返回冲突仲裁结果。
应用本实施例方案，可以在数据同步之前，先对需要同步的数据进行冲突检测，并进行冲突仲裁，再根据冲突仲裁结果进行数据同步，可以准确判断真正需要传输的数据，从而缩短同步时间，降低了网络流量。
实施例二本实施例中，客户端数据库如表十二所示，服务器端数据库如表十三所示。
表十二
表十三本实施例中，客户端的条目标识和服务器端的条目标识是相同的，可以直接对应，无需用映射表进行映射。客户端修改UID＝11的条目的First Name，UID＝12的条目的First Name，删除了UID＝13的条目，把UID＝15的数据条目从根目录移动到“好友”目录，并新增了UID＝17的数据条目。修改之后，如表十四所示：
表十四服务器端修改了UID＝12的条目的Last Name，修改了UID＝13的条目的LastName，把UID＝15的条目从根目录移动到“同事”目录，修改了UID＝16的条目的Last Name，修改之后如表十五所示：
表十五本实施例中，不为条目中的字段设置字段标识和字段修改状态信息，只为条目本身设置条目标识和条目状态信息。
服务器可以根据预先设置的冲突原则判断是否发生冲突。这里所述的冲突原则可以如表十六所示。
表十六图4是本实施例的流程图。如图4所示，本实施例实现检测与解决数据同步冲突的方法包括以下步骤：步骤401：客户端和服务器端之间协商是否进行数据冲突检测，如果是，则继续执行步骤402；否则，退出本流程。
进行协商的目的在于，某些情况下是没有必要进行冲突检测的，避免不必要数据的发送。例如：如果服务器端仲裁策略为“客户端赢”，则对于冲突的情况，客户端数据是一定要发送给服务器覆盖服务器端数据的，那么发送冲突检测数据显得没有意义；另外，如果服务器端数据未进行过任何修改，则不会产生冲突，则也没有必要进行冲突检测。
实际应用中，客户端和服务器端进行协商的方法很多。比如，首先在初始化请求中配置一个先解决冲突的参数，再采用以下方法进行协商：X1、客户端向服务器端发送初始化请求；X2、服务器端判断初始化请求中是否包含先解决冲突的参数，若没有，则按现有的同步流程进行同步，再退出本流程；否则转步骤X3；X3、服务器端判断是否同意初始化请求中的同步类型以及先解决冲突的参数，若同意，则转步骤402；否则转步骤X4；X4、同步双方协商，确定进行同步的同步类型以及同步流程，并按照新确定的同步流程进行同步，再退出本流程。
可以在<Alert>命令中增加一个元素<GotoConflictDetect>来指明客户端请求进入冲突检测和仲裁阶段；<Alert>
……<GotoConflictDetect/>
</Alert>
或者可以在<Alert>命令中增加一个属性“GotoConflictDetect”来指明客户端请求进入冲突检测和仲裁阶段；<Alert GotoConflictDetect＝true........>
</Alert>
如果协商先解决冲突与协商同步类型是在同一个<Alert>里面，则可能的情况如表十七所示：
表十七采用这种方案，需新增上述的4个状态码，由服务器通过<Status>命令携带这些状态码来表明协商结果；如果服务器不同意同步类型，双方可以重新协商同步类型。
如果先协商同步类型，后再通过一个新的<Alert>命令进一步的协商是否先解决冲突，则可能的情况有两种，如表十八所示：
表十八实际应用中，状态码的增加可能不同，但也在本发明的保护范围内；实际应用中，客户端和服务器端还可以在数据同步协议中增加先解决冲突的同步类型状态码，或增加服务器通知的同步类型状态码，再采用以下的方法进行协商：Y1、客户端向服务器发送初始化请求；Y2、服务器端判断是否同意初始化请求中指示的同步类型，如果不同意，则客户端与所述服务器端根据配置的同步类型的冲突解决策略，确定同步类型并进入步骤Y3；如果同意，则转步骤Y3；Y3、服务器端判断所述同步类型是否是现有的同步类型，如果是，则按现有的同步流程进行同步，再退出本流程；否则，转步骤402。
这里，所述的先解决冲突的同步类型状态码为：先解决冲突且后续为双向同步的同步类型状态码；或者为先解决冲突且后续为慢同步的同步类型状态码；或者为先解决冲突且后续同步为所述客户端的单向同步的同步类型状态码；或者为先解决冲突且后续同步为所述客户端的刷新同步的同步类型状态码；或者为先解决冲突且后续同步为所述服务器端的单向同步的同步类型状态码；或者为，增加先解决冲突，且后续同步为所述服务器端的刷新同步的同步类型状态码。
所述服务器通知的同步类型状态码为：服务器端通知，先解决冲突且后续的为双向同步的同步类型状态码；或者为服务器端通知，先解决冲突且后续的为慢同步的同步类型状态码；或者为服务器端通知，先解决冲突且后续同步为所述客户端的单向同步的同步类型状态码；或者为服务器端通知，先解决冲突且后续同步为所述客户端的刷新同步的同步类型状态码；或者为服务器端通知，先解决冲突且后续同步为所述服务器端的单向同步的同步类型状态码；或者为服务器端通知，先解决冲突且后续同步为所述服务器端的刷新同步的同步类型状态码。实际应用中，如果客户端和服务器端采用服务器通知的同步类型状态码进行协商，还需要在步骤Y1之前增加一个由服务器端向客户端发送协商通知消息的步骤。
实际应用中，客户端和服务器端进行协商的方法还可以为：客户端向服务器端发送初始化请求，服务器端根据事先配置的协商原则或冲突仲裁原则判断是否进行冲突检测，并向客户端返回协商结果。当然，如果确定无需进行冲突检测，则可以按照现有技术进行同步处理过程；否则，执行步骤402。这里所述的初始化请求可以包括客户端请求进行冲突检测的信息，也可以不包括客户端请求进行冲突检测的信息。所述的协商原则可以由应用本发明方案的用户自行确定。比如：可以在服务器端将协商原则设置为无需进行冲突检测。另外，服务器端也可以根据仲裁原则来判断是否进行冲突检测，比如：服务器端配置的是服务器端赢的仲裁原则，则无需再进行冲突检测。
实际应用中，客户端和服务器端进行协商的方法还可以为：服务器端向客户端发送协商通知命令，如果该协商通知命令通知无需进行冲突检测，则可以按照现有技术进行同步处理过程；否则，执行步骤402。这里，邮件通知可以由所述邮件服务器通过其它引擎下发，例如短消息、无线信息推送WAP Push、会话初始化协议信息SIP Message、多媒体短消息MMS等，或由所述服务器通过数据同步协议定义的通知下发，例如通过数据同步协议定义的通知命令<Alert>下发邮件通知。
实际应用中，客户端和服务器端进行协商的方法还可以为：服务器将冲突仲裁原则发送给客户端，客户端直接根据冲突仲裁原则确定是否进行冲突检测。例如，如果配置的冲突仲裁原则是所述客户端赢的原则，即双方按照所述客户端的需求进行同步，那么将判定本次无需进行冲突检测，客户端需将数据上传到服务器端。这是因为服务器端将接收客户端的任何修改，如果发生冲突，服务器端也将按照客户端的需求进行修改。
所述服务器可以通过扩充现有的同步来向所述客户端返回是否进行冲突检测的结果或返回配置的冲突仲裁原则。例如在现有的<Status>命令增加一个标识，指示所述客户端需要进行冲突检测，或通过在<Status>标签中增加一个元素携带配置的冲突仲裁原则或标识冲突仲裁原则的状态码，由客户端判定是否进行冲突检测。
实际应用中，客户端和服务器端可以进行协商，也可以不进行协商。如果不进行协商时，可以省略步骤401，其流程与实施一就基本相似。
另外，实际应用中，步骤401可以在初始化阶段完成，也可以在初始化之后才开始执行。
步骤402～步骤405与实施例一中的步骤301～步骤304相似，此处不再赘述。
步骤406与步骤306相同，此处不再赘述。
应用本实施例方案，客户端和服务器端可以事先协商是否需要进行冲突检测，如果需要，则执行冲突检测以及后继操作；否则，直接按照现有技术进行数据同步。这样，可以为数据冲突检测提供更加灵活的选择。
实施例三本实施例中，客户端修改条目标识LUID＝11的名为“资料”的文件，该文件的大小为2M，其修改的时间为2005年11月26日17点02分；服务器端上该文件的时间戳为2005年11月26日18点30分。本实施例中，服务器端预先配置的仲裁原则为时间戳原则，并规定发生冲突时，按照修改时间在后的条目进行数据同步。
图5显示了本实施例的流程图。如图5所示，本实施例实现检测与解决同步冲突方法包括以下步骤：步骤501～步骤503与步骤301～步骤303相似，只是本实施例中，当客户端向服务器发送的冲突检测数据包括表示修改时间的时间戳，但不包括条目的修改状态信息。当服务器端从冲突检测数据中提取出条目标识和时间戳之后，可以在利用条目标识查询到对应的条目之后，然后直接根据该条目的条目修改状态信息确定是否发生了冲突。比如：如果自身数据库中的条目进行了修改，不管是什么修改，都可以确认为发生了冲突。
其中，该文件的修改信息可以表示为冲突检测数据格式：<ConflictDetect>
<CmdID>4</CmdID>
<Cmd>文件的状态为Replace<Cmd>
<Source><LocURI>文件的LUID＝11</LocURI></Source>
<Data>指示文件的修改时间(例如：modified&EQ；20051126T170200)<Data>
</ConflictDetect>
步骤504：服务器端按照时间戳仲裁原则对冲突进行仲裁，并确定仲裁结果为按照服务器端的条目进行数据同步。
步骤505和步骤506与实施一的步骤305和步骤306相似，此处不再赘述。
应用本实施例方案，当服务器端接收到包括时间戳信息的冲突检测数据后，提取出其中的条目标识和时间戳信息，根据条目标识查询数据库并确定相应的条目，再直接根据该条目的条目修改状态信息确定是否发生了冲突。比如：如果自身数据库中的条目进行了修改，不管是什么修改，都可以确认为发生了冲突。然后，将冲突检测数据中的时间戳与自身条目的时间戳进行对比，按照时间戳原则确定时间戳为2005年11月26日18点30分的文件修改时间较后，获得仲裁结果，即客户端不需上传数据，而只需由服务器端下发该数据即可；然后，服务器端将自身的文件下发给客户端进行数据同步。
可见，采用本发明所提供的方法，可以减少同步数据的传输量，缩短同步时间，同时降低了网络流量。
实施例四本实施例中，客户端数据库如表十九所示，服务器端的数据库如表二十所示。
表十九
表二十本实施例中，客户端将LUID＝2中的Name字段修改为“Be”，将Fingerprint字段修改为“Fb1”；将LUID＝4中的Name字段修改为“De”，将Fingerprint字段修改为“Fd1”；并且删除了LUID＝5的条目；增加了LUID＝7的条目，其中，Name字段为“H”，Fingerprint字段为“Fh”。同时，服务器端将GUID＝1003中的Name字段修改为“Cs”，将Fingerprint字段修改为“Fc1”；将GUID＝1004中的Name字段修改为“Ds”，将Fingerprint字段为“Fd1”；删除了GUID＝1006的条目；增加了GUID＝1008的条目。
图6为本实施例的流程图。如图6所示，本实施例中实现检测和解决冲突的方法包括以下步骤：
步骤601：客户端向服务器端发送智能同步数据请求消息；这里所述的智能同步的核心思想为：为客户端和服务器各自数据库中的各个数据都设定条目指纹，在同步数据过程中，首先验证条目指纹，即通过对比客户端和服务器各自数据库所存储的数据设定的条目指纹来区分需要同步的数据和垃圾数据，从而在后续数据同步阶段只传输需要同步的数据，避免垃圾数据的传送。
步骤602：服务器端向客户端返回确认消息；步骤603：客户端将自身数据库中待同步数据条目的条目标识和条目指纹作为冲突检测数据发送给服务器端；步骤604：服务器端从接收到的冲突检测数据中提取条目标识和条目指纹，并根据提取的条目标识查询自身数据库，确定与提取的条目标识对应的条目；步骤605：服务器端根据提取的条目指纹和自身相应条目的条目指纹进行对比，检测出冲突。
本实施例中，当服务器端确定提取的条目指纹与自身条目的条目指纹不相同时，就可以判断为发生了冲突。即：只有LUID＝1的条目不冲突，LUID＝2～LUID＝6的条目都发生了冲突，而LUID＝7和GUID＝1008由于是增加的，判断为不冲突。
步骤606：服务器端根据事先配置的冲突仲裁策略获得冲突仲裁结果。
本实施例中，服务器端可以配置服务器端赢的仲裁策略。实际应用中，还可以配置客户端赢等其它仲裁策略。
步骤607：客户端和服务器端根据冲突仲裁结果进行数据同步。
本实施例中，如果指定客户端和服务器端为双向同步，则服务器端需要将GUID＝1002～GUID＝1005的条目的数据发送给客户端，并通知客户端删除LUID＝6的条目。另外，还需要通知客户端上传LUID＝7的条目，并同时把GUID＝1008的条目下发给客户端。
实际应用中，如果规定条目指纹由客户端统一计算，则客户端在不同阶段获得GUID＝1008条目后，可以先计算出该条目的指纹，并为该条目分配条目标识。之后，再将该条目的条目标识和条目指纹在同步完成阶段返回给服务器端。
而如果规定服务器端可以计算条目指纹，则服务器端可以直接将GUID＝1008的条目指纹计算出以后下发给客户端，客户端只需在同步完成阶段向服务器端返回为该条目分配的条目标识即可。
另外，实际应用中，条目指纹可以为条目的摘要值、时间戳、锚值或版本号等。
应用本实施例方案，可以直接根据条目的条目指纹检测冲突，如果发生冲突，再根据冲突仲裁策略获得冲突仲裁结果，确定需要传输哪些数据，不需要传输哪些数据，从而可以节约同步时间、降低了网络流量。
综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。