CN101160903B - 一种实现数据同步的方法、系统、客户端及服务器 - Google Patents

Abstract

本发明公开了一种实现数据同步的方法，应用于客户端和服务器之间，该方法包括：客户端和服务器中的任一端发送第一同步命令至二者中的另一端；该方法还包括：在发送第一同步命令之前，客户端和服务器确定待同步节点；所述第一同步命令的接收端在收到第一同步命令之后，按接收到的第一同步命令，对所确定的待同步节点进行数据同步。本发明还公开了一种实现数据同步的系统、客户端及服务器，使用本发明方法，采用本发明能实现任意节点级的数据同步。

Description

一种实现数据同步的方法、系统、客户端及服务器

技术领域

本发明涉及开放移动联盟定义的同步标签语言(SyncML，Synchronization Marker-up Language)数据同步规范技术领域，特别是指在SyncML协议实现数据同步的方法、系统、客户端及服务器。 

发明背景 

为了制订可以在多个平台及网络之间实现个人信息及企业内数据同步的标准规格，开放移动联盟(OMA)提出了SyncML数据同步规范。开发SyncML的目的在于，使终端用户、设备开发商、基础构件开发商、数据提供商等协同工作，真正实现使用任何终端设备均可随时随地访问任何网络的数据。SyncML数据同步的典型应用是移动设备或应用服务器、与网络服务器之间的数据同步。除此之外，SyncML还可用于对等的数据同步，如两台PC之间的数据同步。 

图1为基于SyncML规范实现同步的示意图。客户端与服务器经过同步初始化阶段的参数协商以后，互相发送同步命令携带各自发生改变的数据，以保证双方数据的同步。 

同步客户端(DS Client，Data Synchronization Client)通常指PC软件、手机或PDA等智能终端。DS Client中设置有客户端数据库(ClientDatabase)，用来存储用户所需的数据，这些数据包括：通讯录、日程、便笺、短信、电子邮件等。这些数据均有标准规范定义其格式，同步客户端可以将数据转换成标准的格式发送给同步服务器，同步服务器处理后就可将数据保存入自己的数据库中。 

同步服务器(DS Server)，可接收来自DS Client的数据同步消息和 同步命令，并能向同步客户端发送同步消息。该设备可以为网络服务器或PC。DS Server中设置有服务器数据库(Server Database)，用来存放该同步服务器的数据。 

同步客户端和同步服务器都存储有数据标识，其中，同步客户端使用本地唯一标识(LUID，Local Unique Identifier)作为数据标识，而同步服务器使用全球唯一标识(GUID，Global Unique Identifier)作为数据标识。 

图2为同步客户端和同步服务器的数据存储示意图。参见图2，在同步客户端，只需维护各个LUID与数据之间的对应关系，在同步服务器端，则不仅要维护各个GUID与数据之间的对应关系，还要维护各个GUID与LUID之间的对应关系。其中，数据同步的类型有多种，具体参见表1。 

表1 

另外，SyncML规范中规定的同步流程通常分为三个阶段： 

1、同步初始化阶段，主要完成身份鉴权、要同步的数据库之间的协 商、同步能力的协商(包括：支持同步哪些数据、支持哪些同步类型等)，该协商过程可能需要持续多次才能完成。 

2、同步阶段，主要包括：客户端和服务器中的一端，根据数据的修改状态将发生改变的数据以操作命令的方式发送到另一端，由另一端使用发生改变的数据、执行该操作命令(如：更新、删除、增加等操作命令)对自身数据进行更新，以达到数据同步的目的。 

3、同步完成阶段，主要包括：客户端和服务器互相确认同步完成。 

现有技术中，为数据定义了文件夹(Folder)和文件(File)的存储方式，该存储方式模拟了PC机的基于文件夹和文件的树状目录结构。对于逻辑上或物理上存在层级(hierarchy)关系的数据而言，其可被描述为一种由一个或多个节点构成的树形结构，该树形结构中的每一节点可以为一个目录节点(也可称为目录项目)或为一个条目(也可称为数据项目)，但是，现有技术还不能够按照需要同步该树形结构中的某个特定节点以及节点下的内容。另外，现有技术中对于电话本按照群组进行同步的实现方式是根据vCard中的Group字段，使用过滤技术实现的，这种方法的缺点在于同步协议依赖与同步数据，不通用，而且并不能真正实现按照需要同步该树形结构中的某个特定节点以及节点下的内容。 

但是，目前存在大量需要同步的以逻辑上的层级关系或者物理上的目录结构存储的数据。例如，用户手机内存储通讯录、短信、电子邮件等几个以逻辑或物理方式存在的目录结构；日程、邮件当中外部存储的附件。按现有技术，用户只能同步短信这一整个数据库，而不能将已存储的短信分为“笑话”和“祝福”两个逻辑类进行同步，更不能只同步“笑话”这一逻辑类。对于日程、邮件外部存储附件的，现有技术无法对附件进行同步，无法描述附件和日程及邮件之间的层级关系；同时也不支持一个数据项同时存在于两个分类中，例如对于用户通讯簿，张三既属于 “同事组”，又属于“朋友组”的需求无法实现。 

可见，现有的数据同步技术还不能满足实际的需求，尤其不能支持层级数据的描述和层级结构中基于任意节点级别的数据同步。 

发明内容

有鉴于此，本发明的主要目的在于提供实现数据同步的方法，以实现基于任意节点级的数据同步。 

本发明的另一主要目的在于提供一种实现数据同步的系统、客户端及服务器，能够对灵活实现基于任意节点级的数据同步。 

为达到上述目的，本发明的技术方案是这样实现的： 

本发明公开了一种实现数据同步的方法，用于在客户端和服务器之间同步由一个或多个节点构成的层级结构的数据，该方法包括：客户端和服务器中的任一端发送第一同步命令至二者中的另一端；该方法还包括：在发送第一同步命令之前，客户端和服务器确定该层级结构的数据中的待同步节点，其中，所述客户端和服务器确定待同步节点的方法为：所述客户端和服务器中的任一端发送携带待同步节点地址的第二同步命令至另一端，该另一端按第二同步命令中的待同步节点地址确定当前待同步的节点；所述第一同步命令的接收端在收到第一同步命令之后，按接收到的第一同步命令，对所确定的待同步节点进行数据同步。 

其中，所述客户端和服务器中的任一端发送第二同步命令至另一端之前，包括：该第二同步命令的发送端确定待同步节点的源地址，然后将所确定的源地址作为该待同步节点的目的地址携带在第二同步命令中；或者，该第二同步命令发送端确定该待同步节点的目的地址并携带在第二同步命令中。 

其中，所述第二同步命令的发送端确定该待同步节点的目的地址的 方法为：由该另一端将待同步节点在本端的地址发送至该第二同步命令的发送端；或者，该第二同步命令的发送端从另一端获取该另一端的层级结构，并按所获取的层级结构确定待同步节点的目的地址；或者，该第二同步命令的发送端按用户输入的信息确定待同步节点的目的地址；或者，第二同步命令发送端指定待同步节点的目的地址，如果该目的地址在该另一端上不存在，则该另一端在第二同步命令发送端指定的目的地址上创建该待同步节点；或者，客户端和服务器预先设定待同步节点的地址。 

其中，所述第二同步命令为新增同步命令；或者现有协议的同步命令，且采用该现有协议的同步命令的属性或用于指明目标数据库地址的子元素来携带待同步节点的地址，该用于指明目标数据库地址的元素被扩展为能够指示节点级地址的元素。 

其中，所述待同步节点有多个，每一节点对应各自的同步类型；所述客户端和服务器通过发送第二同步命令协商得到待同步节点时，进一步包括：在客户端和服务器通过发送第二同步命令协商得到待同步节点时，该第二同步命令中进一步携带各个待同步节点所对应的同步类型协商参数以及各节点与同步类型之间的对应关系，按该第二同步命令携带的同步类型协商参数以及各节点与同步类型之间的对应关系确定每一待同步节点对应的同步类型。 

其中，所述第二同步命令为现有协议的同步命令，且采用该现有协议的同步命令的属性或新增的用于携带节点级过滤条件的元素来承载待同步节点地址。 

其中，所述第一同步命令携带操作类型；所述按接收到的第一同步命令对所确定的待同步节点进行数据同步的方法为：按第一同步命令携带的操作类型，对所确定的待同步节点中的数据作该操作类型指定的同 步操作。 

其中，该第一同步命令进一步携带待同步节点地址；所述按接收到的第一同步命令对所确定的待同步节点进行数据同步的方法进一步包括：确定该第一同步命令中携带的待同步节点地址，在所确定的待同步节点地址下进行同步操作。 

其中，该第一同步命令进一步携带该数据内容；所述按接收到的第一同步命令对所确定的待同步节点进行数据同步的方法进一步包括：确定该第一同步命令中携带的数据内容，将该数据内容保存在该待同步节点地址下。 

其中，该方法进一步包括：增设以服务器和客户端合并处理Win-Win为机制的仲裁结果；当服务器端和客户端的数据操作发生冲突时，客户端根据服务器的数据操作执行同步操作，并且，服务器根据客户端的数据操作执行同步操作；所述数据操作包括：新增操作、更新操作、移动操作、删除操作、复制操作或此五者的任意组合。 

本发明还公开了一种实现数据同步的系统，该系统包括：客户端和服务器，且二者之间通过交互同步命令来实现通信；所述客户端和服务器中的任一端发送携带待同步节点地址的第二同步命令至另一端，该另一端按第二同步命令中的待同步节点地址确定当前待同步的节点，并对所确定的待同步节点进行数据同步。 

本发明还公开了一种实现数据同步的客户端，该客户端包括：第一节点地址处理模块，用于确定待同步节点的地址并输出至第一数据同步模块；从第一数据同步模块接收待同步节点的地址并按此地址确定当前待同步节点，提供待同步节点下的客户端与服务器之间的数据同步处理；第一数据同步模块，用于从第一节点地址处理模块接收待同步节点的地址，构造携带该待同步节点地址的同步命令并输出至服务器；从服务器接收同步命令并从中解析得到待同步节点地址输出至第一节点地址处理模块。 

本发明又公开了一种实现数据同步的服务器，该服务器包括：第二节点地址处理模块，用于确定待同步节点的地址并输出至第二数据同步模块；从第二数据同步模块接收待同步节点的地址并按此地址确定当前待同步节点，提供待同步节点下的客户端与服务器之间的数据同步处理；第二数据同步模块，用于从第二节点地址处理模块接收待同步节点的地址，构造携带该待同步节点地址的同步命令并输出至客户端；从客户端接收同步命令并从中解析得到待同步节点地址输出至第二节点地址处理模块。 

因此，采用本发明能够灵活实现针对某一层级的数据同步，在数据同步时不必在客户端和服务器之间传递整个数据库的数据，从而能提高数据同步效率并节约系统资源。 

附图简要说明 

图1所示为实现同步的示意图。 

图2所示为客户端和服务器端的数据存储示意。 

图3a所示为应用本发明实施例一的用户定义的数据结构示意图。 

图3b所示为应用本发明实施例一的客户端的数据存储示意图。 

图4a所示为应用本发明实施例二的用户定义的数据结构示意图。 

图4b所示为应用本发明实施例二的客户端的数据存储示意图。 

图5a所示为应用本发明实施例三的用户定义的数据结构示意图。 

图5b所示为应用本发明实施例三的客户端的数据存储示意图。 

图6a所示为应用本发明实施例四的用户定义的数据结构示意图。 

图6b所示为应用本发明实施例四的客户端的数据存储示意图。 

图7a所示为应用本发明实施例五的用户定义的数据结构示意图。 

图7b所示为应用本发明实施例五的客户端的数据存储示意图。 

图8a所示为应用本发明实施例六的用户定义的数据结构示意图。 

图8b所示为应用本发明实施例六的客户端的数据存储示意图。 

图9所示为应用本发明实施例的实现数据同步的系统结构示意图。 

实施本发明的方式 

下面结合附图及具体实施例，对本发明再做进一步地详细说明。 

本发明公开了一种实现数据同步的方法，其主要处理思想为：客户端和服务器中的任一端发送第一同步命令至二者中的另一端；在发送第一同步命令之前，客户端和服务器确定待同步节点地址；该第一同步命令的接收端在收到第一同步命令之后，按接收到的第一同步命令对所确定的待同步节点进行数据同步。这里待同步节点可以是树状的层级结构上的任一节点，例如整个数据库、逻辑或者物理目录或者数据条目。 

众所周知，按SyncML协议，同步的实现分为三个阶段：同步初始化阶段、同步阶段和同步完成阶段。在本发明中同步完成阶段的处理与现有方式相同，因此，以下仅就同步初始化阶段和同步阶段进行描述。 

在同步初始化阶段，指明待同步节点地址(包括该节点的源地址和目的地址)，其中源节点和目的地址可以是数据库地址、逻辑或者物理目录标识或者数据条目标识，客户端和服务器可通过发送第二同步命令协商得到待同步节点。其中，客户端和服务器中的任一端发送携带待同步节点地址的第二同步命令至另一端，该另一端按第二同步命令中的待同步节点地址确定当前待同步的节点。所述的待同步节点可以包括一个或多个节点；当待同步节点包括多个节点时，针对待同步节点中包括的所有地址，所述客户端和服务器中的任一端发送一个第二同步命令至另 一端，该第二同步命令中携带所有节点的地址；该另一端按第二同步命令中的所有节点的地址确定当前待同步节点中包括的所有节点；或者，针对待同步节点中包括的每一节点，所述客户端和服务器中的任一端发送一个携带该节点地址的第二同步命令至另一端；该另一端按每一第二同步命令中的节点地址一一确定当前待同步节点中包括的每一节点。另外，也可在客户端和服务器中预先配置待同步节点的地址，从而不必在同步初始化阶段通过第二同步命令来协商得到待同步节点。本文讨论的待同步节点可以包括数据库、目录、条目、或若干目录和条目的组合，为简明阐述本发明原理，以下仅就待同步节点包括一个或多个目录的情况对本发明的实施方式加以详述，对该待同步节点可能的其它组成情况不再加以详述，但仍在本发明的保护范围之内。 

上述实现第二同步命令携带待同步节点地址的方式有以下两种(在待同步节点包括一个或多个目录的情况下，该待同步节点地址就是待同步目录地址)： 

方式一：扩展现有协议中用于指明目标数据库的元素(又可被称为用于携带待同步数据地址的元素)来指明待同步目录，使其从能够指示数据库级别地址的元素扩展为能够指示任一级别目录地址的元素。具体实现过程可以为：对统一资源标识符(URI，Uniform Resource Identifier)的格式作预定义，预先指定哪一级URI标识数据库地址，哪一级URI标识目录的地址，通过URI的标识指明待同步目录，比如：指定“/files”为数据库级的地址，指定“/files/folder1ID”为数据库下的名为folder1的目录的地址，其中，files为数据库的名称，folder1ID为目录的标识。为了更精确的指定待同步目录的地址，可以在URI的标识中采用数据库或目录的编号来表示。比如：指定/4980为待同步数据库级的地址，指定/4980/4560为数据库4980下的编号为4560的子目录的地址。如果数据 库下有更多的分级，可采用多级结构，例如：/4560/4980/556等。还可以采用编号和目录名相结合的表示方法，例如：/files/4890。当然，如果需要同步多个目录，可同时给出多个URI予以指明。另外，在一个层级结构中，一个目录节点之下可以有子目录节点和/或条目节点，则一个待同步节点的地址可由目录标识及条目标识组合而成，如节点地址“/Macy/03/05”，其中“03”为目录“Macy”下的一个条目的标识，“05”为“03”的父节点的子条目(如附件)的标识。 

方式二：扩展现有协议中用于指明过滤条件的元素来指明待同步目录。具体实现过程可以为：扩展现有的过滤条件(如Filter命令)用于指明待同步目录。当然，如果需要同步多个目录，可同时指出多个目录。 

下面对这两种指明待同步目录的方式作详细说明。 

一、方式一为通过扩展现有协议中用于指明目标数据库的元素来实现协商待同步目录的一种方案，所述待同步数据地址通常指URI。 

本发明中，客户端和服务器通过发送第二同步命令协商得到待同步目录时，可进一步协商当前同步类型协商参数。客户端和服务器通过发送第二同步命令协商得到待同步目录时，该第二同步命令中可以进一步携带同步类型协商参数，按该第二同步命令中的同步类型协商参数确定当前同步类型。该第二同步命令可采用同步标签语言协议的警报(Alert)元素来实现，所述用于携带待同步数据地址的元素可以为Alert元素的子元素(如项目(Item)元素)，所述用于携带同步类型协商参数的元素可以为Alert元素的子元素(如数据(Data)元素)。该采用Alert元素实现的第二同步命令又可被称为Alert同步命令。其中，作为第二同步命令的Alert元素中，也可采用其它子元素，如代码(Code)等，来携带同步类型协商参数和待同步目录地址，也可采用Alert元素的属性来携带同步类型协商参数和待同步目录地址，这些情况下的命令结构本文 就不一一示出，但均在本发明的保护范围之内。未来规范中可能会改变这些元素、子元素或者属性的名称和结构，这些改变不应该理解为对本发明的限制。 

为了实现多个目录的同步，可以进一步扩充Alert命令，使其可以用于指定一个或多个目录的待同步目录。以下给出实现该功能的方案： 

同步初始化阶段，假定由客户端向服务器发起待同步目录的协商。 

客户端向服务器发送Alert命令，其中携带待同步目录的地址，该地址可为待同步目录的URI。之后，服务器可以向客户端返回响应。以下给出该Alert命令的一个举例。例如，客户端指定要同步的是名称为folder1的目录，客户端向服务器发送Alert命令，其中携带要建立的同步类型以及待同步目录的地址(如：/files/folder1ID)。其中，如果客户端与服务器端的目录结构相同(在待同步节点仅包括目录的情况下，该目录结构就是指数据的层级结构)，则客户端可以按自身的目录结构直接确定服务器上该待同步目录的地址。如果客户端与服务器端的目录结构不同，则客户端要先确定该待同步目录在服务器上的目录地址，具体确定方法可包括以下几种：1、事先，客户端从服务器端获取服务器的目录结构，并按服务器的目录结构确定当前待同步目录在服务器上的地址，2、由服务器向客户端发送待同步目录的地址，3、客户端直接指定该待同步目录在服务器端的地址，如果该目录地址在服务器上不存在，则服务器根据客户端的要求直接在该客户端指定的地址上创建该待同步目录，4、按用户输入的信息确定待同步目录地址，即由用户指定待同步目录地址，5、客户端与服务器预先设定待同步的目录地址。例如，双方约定，如果进行备份同步，则使用服务器端数据库中名字为备份(backup)的目录。上述的目录结构可以是生成后保存在服务器端，或是不保存，当客户端需要时，由服务器端为指定的数据库实时生成的。 其中，客户端在向服务器发送Alert命令以发起同步时，该Alert命令中携带的待同步目录地址包括：客户端的待同步目录地址(即源地址)和服务器端的待同步目录地址(即目的地址)，二者可能相同或不同；对于作为同步发起方的客户端而言，其可通过多种方式得到待同步目录的本端地址(即源地址)，比如：预先配置源地址，或者由用户指定源地址，或者由服务器将源地址下发给客户端等等，而待同步目录的在服务器端的地址(即目的地址)则需要客户端发起同步时向服务器指明，本文仅就作为同步发起方的客户端向服务器指明目的地址的方式进行说明，对于客户端确定源地址的方式不作讨论。 

其中，客户端获取服务器的目录结构，可以通过独立的同步会话实现，在Alert命令中扩展或定义新的子元素、或者属性携带同步类型协商参数，定义新的同步类型仅用于获取数据库的目录结构，而并不进行数据库中数据的同步。当然，也可以使用其他数据同步类型，先获取目录结构，然后继续进行数据同步；以下提供了一种获取目录结构的实现方案，其流程如下： 

1、客户端向服务器发送建立同步会话的命令，在发送确定同步目录地址的Alert命令之前，客户端向服务器发送用于请求获取指定数据库的目录结构的同步命令，为与前述两种同步命令相区别，该同步命令可被称为第三同步命令。该第三同步命令可采用Get元素来实现，如下例中所示的提取(Get)命令实例。为了实现请求获取数据库的目录结构，必须扩充现有的Get命令的含义，在其中增加一个表示请求获取数据库的目录结构的标识。 

<Get>...... 

<Target><LocURI>/contacts？List＝struct</LocURI></Target>...... 

</Get> 

其中，在Target标签中，“/contacts”为指定的数据库的URI， “？List＝struct”为表示请求获取数据库的目录结构的标识，服务器接收到该Get命令，根据数据库的URI找到对应的数据库。 

2、服务器将指定数据库的目录结构通过Get命令的响应，结果(Results)命令，返回给客户端。设定服务器的数据库的目录结构为：在根目录(即第一级目录节点)，“/contacts”，之下，有A、B、C和D四个子节点，即第二级节点；在第二级目录节点A之下还有A1和A2两个子节点，即第三级节点。此时，返回的Results命令可有以下的几种组织方式： 

(1)对目录结构中的每一个节点用一个Item元素来指示其URI。客户端接收到此Results命令，可以根据每个Item中的URI来构建服务器端的目录结构。该Results命令格式如下： 

<Results>...... 

<Item>...... 

<Source><LocURI>/A</LocURI></Source>...... 

</Item> 

<Item>...... 

<Source><LocURI>/A/A1</LocURI></Source>...... 

</Item> 

</Results> 

(2)将所有目录结构数据封装在一个元素中，例如，可以将目录结构数据封装在Results元素中Item子元素的Data元素中，该Data元素携带的目录结构数据可以以文件的形式存在，此种情况下的Results命令格式如下所示： 

<Results>...... 

<Item>...... 

<Data>目录结构数据</Data> 

</Item> 

</Results> 

其中，上述作为第三同步命令的Get元素和作为其响应命令的 Results元素中，均可采用其它子元素或属性来指示请求获取目录结构，这些情况下的命令结构本文就不一一示出，无论上述Get和Results命令以何种方式组合，均在本发明的保护范围内。同样，也可以扩展Add命令或Replace命令使其能够携带层级结构数据，其扩展方式与Results相同，也在本发明的保护范围之内。 

客户端确定服务器端待同步目录的地址也可以是服务器主动向客户端发送待同步目录的地址，该方案可以通过服务器向客户端发送通知来实现，该通知可采用数据同步协议中的通知格式，也可以由服务器通过其它引擎下发，例如：短消息业务(SMS)、无线应用协议推送业务(WAP Push)、会话初始化协议消息(SIP Message)、多媒体消息业务(MMS)等。客户端可从所述通知中提取出待同步任意层级URI。 

在客户端确定待同步目录的地址后，客户端可进一步发送Alert命令，其中携带了同步类型协商参数和待同步目录地址，所述待同步目录地址对可以使用Item元素携带，其命令格式如下： 

<Alert>...... 

<同步类型>双向同步</同步类型> 

<Item> 

<Target><LocURI>/files/folder1(服务器上待同步目录folder1的URI)</LocURI></Target> 

<Source><LocURI>/files/folder1(客户端上待同步目录folder1的URI)</LocURI></Source>...... 

</Item>                 ...... 

</Alert> 

如果待同步目录包括多个目录，则可以在一个Alert命令中携带一个同步类型以及多个Item元素，其中每一个Item元素用于携带一个目录的地址，此时待同步目录中包括的各个目录的同步类型相同。 

服务器接收到客户端发送的Alert命令，会向客户端返回响应，该 响应携带待同步目录协商结果，以确认待同步目录是否可以进行同步。该响应可以为现有协议中用于返回状态码的状态(Status)命令。 

如果待同步目录包括多个目录，则服务器返回响应给客户端的方法可以为：针对待同步目录中包括的所有目录，服务器返回一个响应，该响应携带所有目录的协商结果；或者，针对待同步目录中包括的每一目录，服务器返回一个响应；每一响应携带一个目录的协商结果。当针对待同步目录中包括的每一目录，服务器返回一个响应，且每一响应携带一个目录的协商结果时，可以用多个Status命令针对相应的目录返回协商结果(也可称为状态码)。 

另外，客户端也可以用多个Alert命令来指定多个待同步的目录，且每一Alert命令对应一个待同步的目录。这时，服务器也可以用对应于上述的Alert命令的协商结果返回响应，该Alert命令的响应采用状态状态(Status)命令来实现。 

为实现对不同的节点采用不同的同步类型，可采用以下几种方案： 

1、针对待同步目录中包括的所有目录，客户端发送一个Alert命令至服务器，该Alert命令中携带所有目录的地址以及每一目录对应的同步类型协商参数；该服务器按Alert命令中的所有目录的地址确定当前待同步目录中包括的所有目录以及每一目录对应的同步类型。此时，该Alert命令携带多个用于指明目标数据库地址的元素(如：Item元素)；且每一用于携带用于指明目标数据库地址的元素被扩展为能够指示目录级别地址和一种同步类型的元素，并承载一个待同步目录的地址及其对应的同步类型。 

2、针对待同步目录中包括的每一目录，客户端发送一个携带该目录地址及其对应的同步类型协商参数的Alert命令至服务器；该服务器按每一Alert命令中的目录地址和同步类型协商参数一一确定当前待同步 目录中包括的每一目录及其当前同步类型。此时，该Alert命令携带用于指明目标数据库地址的元素和用于携带同步类型的元素；且该用于指明目标数据库地址的元素被扩展为能够指示目录级别地址的元素，并承载一个待同步目录的地址；所述用于携带同步类型的元素承载一种同步类型协商参数。 

然而，当待同步目录包括多个目录、且各个目录的同步类型相同时，针对待同步目录中包括的所有目录，客户端发送一个Alert命令至服务器，该Alert命令中携带所有目录的地址以及这些目录对应的同一同步类型协商参数；服务器按Alert命令中的所有目录的地址确定当前待同步目录中包括的所有目录以及当前同步类型。此时，该Alert命令携带多个用于指明目标数据库地址的元素(如：Item元素)和一个用于携带同步类型的元素(如：Data元素)；且每一用于指明目标数据库地址的元素被扩展为能够指示目录级别地址的元素，并承载一个待同步目录的地址；所述用于携带同步类型的元素承载一种同步类型协商参数。其中，作为第二同步命令的Alert元素也可采用其它子元素或属性来携带同步类型协商参数、待同步目录地址等，本文就不再一一示出各种情况下的命令格式，但均在本发明的保护范围之内。 

二、方式二为采用过滤机制来指定待同步目录地址的一种方式。 

现有的过滤机制只可以实现域级别和数据项级别的过滤，且主要基于同步数据的格式，本发明可将现有的过滤机制扩充到节点级别(这里就是指目录级别)，且可以适用于所有同步数据格式，其扩充可以通过在现有协议的过滤(Filter)元素中新增用于携带节点级别过滤条件的子元素，例如，该元素可以命名为节点级别(NodeLevel)，在该元素中可采用通用网关接口(CGI，Common Gateway Interface)语法或其他语法来指定待同步的目录。其中，也可采用Filter元素的属性或新增的其它 子元素来携带节点过滤条件，此种情况下的命令结构本文不再示出，但均在本发明的保护范围之内。 

以下给出待同步目录为编号112和113的目录的Filter命令格式： 

  <Filter>...... 

    <NodeLevel> 

    <Item> 

    <Meta><Type>syncml:filtertype-cgi</Type></Meta> 

    <Data>&LUID&EQ；112&AND；&LUID &EQ；113(采用filter的CGI语法指定同步的目 

录为编号是112和113的目录)</Data> 

    </Item> 

    </NodeLevel>...... 

  </Filter> 

在同步阶段，可通过发送第一同步命令来指明基于任意节点同步的操作类型，或进一步指明待同步目录地址，或进一步携带数据内容。 

当该第一同步命令携带待同步目录地址时，可扩充现有的同步(Sync)命令中用于携带待同步数据地址的元素，如：目标(Target)元素，从而可将同步的粒度从数据库级别扩充到任意节点级别。比如：可以在Sync命令中携带能够指示任意节点地址(如：待同步目录的URI)的Target元素。现有的Sync命令只能携带的Target元素只能指示整个数据库的地址。本发明中Sync命令中携带的数据就可以仅为属于同步目的地址范围内的数据，而不需要是整个数据库的数据。 

其中，一个Sync命令可携带一个待同步目录的地址，如果有多个目录需要同步，则可以通过多个Sync命令来携带多个目录的地址。比如：由两个Sync命令分别携带两个待同步目录folder1和folder2的地址。另外，上述作为第一同步命令的Sync元素中，也可采用其它子元素或属性来携带待同步目录地址，这些情况下的命令结构本文就不一一示出，但均在本发明的保护范围之内。 

当第一同步命令(比如：Sync命令)携带操作类型时，具体携带操 作类型的方式与现有技术相同，使用新增(Add)、更新(Replace)、删除(Delete)、移动(Move)等元素。比如：在Sync命令中携带用于携带操作类型的子元素，如：指示新增操作的增加(Add)元素，指示更新操作的更新(Replace)元素。这样，接收第一同步命令的一端可按第一同步命令携带的操作类型，对所确定的待同步目录作该操作类型指定的同步操作。这样，Sync命令可按实际情况，选择携带Add元素、Replace元素、Delete元素或Move元素来指示各种操作类型。 

上述本发明的各种第一、第二和第三同步命令携带的各种信息，如：待同步节点数据、节点级别地址过滤条件、同步类型、层级结构数据等，并不限于携带在文中所示各个命令格式中的子元素或属性之中，还可采用其它子元素或属性来携带这些信息，鉴于命令格式的组合情况较多，本文就不再将这些命令格式一一示出，但均在本发明的保护范围之内。 

下面结合具体实施例对同步阶段进行说明。由于客户端发起同步与服务器端发起同步的处理流程相类似，下面仅以客户端发起同步，服务器端执行数据同步操作为例进行说明。以下实例中，所述第一同步命令采用SyncML协议的Sync元素来实现；其可以携带的操作类型包括：新增(Add)、更新(Replace)、删除(Delete)、移动(Move)等。 

为了实现能够使用户按照自己的意愿创建物理或逻辑分类目录，并指定任意一分类目录进行递归同步或非递归同步，需要在客户端和服务器端分别设置以下三个数据表： 

1、数据条目表(Data Item Table)：该表用于保存所有的数据项目信息，其包括数据项目编号与具体的数据内容(Data)的对应关系；所述数据项目编号在客户端和服务器端分别以Item LUID和Item GUID表示 

2、目录表(Folder Table)：该表用于保存所有的目录项信息，其包括目录项编号、目录名(Name)、该目录项所属的父目录(Parent Source)、 该目录项状态(Folder Status)以及这四者之间的对应关系。其中的目录项状态主要包括如下状态：现存未修改(Existing)(可用E来标识)、新增(New)(可用N来标识)、更新(Update)(可用U来标识)、删除(Delete)(可用D来标识)、移动(Move)(可用M来标识)以及复制(Copy)(可用C来标识)；其中，Delete可以分为永久删除(Deletepermanently)(可用P-D来标识)和非永久删除(Delete non-permanently)(可用P-ND来标识)两种状态；所述目录项编号在客户端以Folder LUID表示，在服务器端以Folder GUID表示。 

3、数据条目-目录的对应关系索引表(Index Table)：该表用于保存数据项目的归属关系，其包括：数据项目编号、父目录(Parent Source)以及数据项目状态(Data Status)的对应关系；其中所述数据项目编号在客户端以Item LUID表示，在服务器端以Item GUID表示。 

再有，在服务器端还需保存数据在客户端内的编号与服务器内的编号的对应关系列表，即GUID与LUID之间的对应关系。 

实施例一：用户在短信的根目录(如：/sms)下增加了一个新的目录“bless”，并且，在“bless”目录下又增加了两个子目录分别为“SpringFestival”和“Mid-autumn Festival”，同时，在每个目录下分别增加了一个数据，比如：在“bless”目录下增加了数据N1，在“Spring Festival”目录下增加了数据N2，在“Mid-autumn Festival”目录下增加了数据N3。 

参见图3a和图3b，图3a所示为应用本发明实施例一的用户定义的数据结构示意图，其中，方框表示目录(Folder)，圆圈表示数据条目(dataItem)；实线表示的状态为Existing，虚线表示的状态为New。图3b所示为应用本发明实施例一的客户端的数据存储示意图。在客户端保存有数据条目表Data Item Table、目录表Folder Table和“数据条目-目录”对应关系索引表Index Table。各个列表所增加数据的状态在图3b都有相应 的反映。 

当用户要求同步“bless”目录时，客户端顺序生成以下同步命令： 

首先，客户端根据接收到的来自用户的同步bless目录的命令并确定同步数据是一个目录项后，从Folder Table中确定该bless的状态为N，之后，构建表示增加目录的同步命令，比如：在Sync命令中增加Add子元素，以构成Add同步命令，该Add同步命令也可称为Sync命令的子命令。并且，在该所构建的Add命令中，使用Meta字段指明数据类型为目录项(Folder)，该数据类型为根据Folder Table所确定的，使用LUID字段指明待同步数据的编号为1006，使用Data字段指明具体的数据为bless，使用SourceParent字段指明其所属父目录为根目录。 

之后，客户端确定bless目录下数据项目状态，由于在Index Table中，数据项目2001所对应的状态为N，因此，构建Add同步命令；并且当从Data Item Table中确定数据项目2001所对应的具体数据内容为N1后，在该所构建的Add同步命令中，使用Meta字段指明数据类型为数据项目(Item)，使用LUID字段指明待同步数据的编号为2001，使用Data字段指明具体的数据为N1，使用SourceParent字段指明其所属父目录为1006。 

当客户端确定bless目录下没有新增加的数据项目后，索引该bless目录下子目录的状态，其具体方法与确定bless目录的方法相同，此处不再赘述。其确定的结果是构建两个Add同步命令，其中一个Add命令中，Meta字段指明数据类型为目录项Folder，LUID字段指明待同步数据的编号1007，Data字段指明具体的数据为春节(Spring Festival)，SourceParent字段指明其所属父目录为1006；而另一个Add命令中的Meta字段指明数据类型为目录项(Folder)，LUID字段指明待同步数据的编号为1008，Data字段指明具体的数据为中秋节(Mid-autumn Festival)，SourceParent字段指明其所属父目录为1006。 

当客户端确定bless目录下没有新增加的子目录后，再确定SpringFestival目录和Mid-autumn Festival目录下的数据项目的状态，其具体方法与确定N1的方法相同，即客户端会分别再构造两条Add同步命令，在此不再赘述。 

以此类推，直到针对所有增加的数据均发出Add同步命令为止，这样也就实现了递归同步。而非递归同步指的是：1、只同步某一目录项，而不再同步该目录项下的数据项，比如：修改目录项的名称；2、只同步某一目录项及该目录项下的数据项目，而不再同步该目录项下的子目录项。 

最后，将所构造的Add同步命令全部发送给服务器。如果Add命令的数据量较少，则可在一个消息中包含多个Add命令，一次性交互即可；如果Add命令的数据量较大，则需要多次交互。在实际应用中，还可以只发送一个Add同步命令，并在该Add命令中包含多个目录和数据项目，其逻辑上仍然可看作是多个Add命令。 

下面说明服务器端接收到上述Add命令后，执行同步操作的过程。该过程所涉及的表格与图3b所示表格类似，这里不再将此表格示出。 

当服务器端接收到增加bless目录项的同步命令后，通过接收到的同步命令中的Meta字段确定待同步数据的类型为目录项，根据LUID字段确定该待同步数据在客户端的编号为1006，根据Data字段确定其名称为bless，根据SourceParent字段确定其父目录为根目录。之后，为该待同步数据分配服务器本地编号(Folder GUID)，如100006。然后，在本地已设置的目录表中增加相应条目，即增加条目：100006、bless、根目录、该bless数据项当前状态，以及这四者的对应关系。并且，在自身已设置的客户端内编号与服务器内编号的对应关系列表中保存该同 步数据的客户端内编号(即LUID)、该同步数据在服务器端内编号(即GUID)以及二者对应关系，即保存1006、100006以及二者之间的对应关系。 

当服务器端接收到增加N1数据项目的同步命令后，通过接收到的同步命令中的Meta字段确定待同步数据的类型为数据项目，根据LUID字段确定该待同步数据在客户端内的编号为2001，根据Data字段确定其具体的数据内容为N1，根据SourceParent字段确定其父目录为1006。之后，在本地数据库中保存该N1数据，然后为该待同步数据分配服务器本地编号(Folder GUID)，如200001，并在本地已设置的数据条目表Data Item Table中增加相应条目，即增加条目：200001、N1以及二者的对应关系；在Index Table中增加相应条目，即增加条目：200001、100006、该N1数据当前状态、以及这三者的对应关系，在自身已设置的客户端内编号与服务器内编号的对应关系列表中保存该同步数据在客户端内的编号、该同步数据在服务器端内的编号以及二者的对应关系，即保存2001、200001以及二者之间的对应关系。 

服务器端增加Spring Festival目录项和Mid-autumn Festival目录项的方式与增加bless目录项的方式相同，增加N2和N3数据项目的方法与增加N1数据项目的方式相同，在此不再赘述。 

另外，有一点需要说明的是：如果是服务器端发起同步请求，由客户端执行同步操作，则服务器端发送给客户端的同步请求中包含待同步数据在服务器端的编号，客户端执行完同步操作后，将给服务器端返回该数据客户端内编号与服务器内编号的对应关系即LUID与GUID的对应关系，由服务器端将接收到的对应关系保存在本地已设置的客户端内编号与服务器内编号的对应关系列表内。 

至此，实现了增加数据的同步操作，而且该数据可以是一个具体的 数据项目，也可以是根据用户的意愿而创建的目录项，且该目录项不受系统的数据物理结构的限制。可见，应用本发明的好处是：相同的数据只需传递一份，而且，执行同步操作的一端，对相同数据也只需保存一份，大大节省了网络资源和设备本身的资源。例如，假设N1同时属于bless、Spring Festival和Mid-autumn Festival目录下，那么在服务器端的同步操作过程中，只需在Index Table中再增加两条相应条目，即增加条目1：200001、100007、该N1数据当前状态以及这三者对应关系，和条目2：200001、100008、该N1数据当前状态以及这三者的对应关系即可。 

实施例二：用户在短信的根目录(/sms)下更新了目录“bless”的属性，并更新了“bless”目录下数据项U1，仅更新了“Spring Festival”目录下的数据项U2。本实施例中，U2同时属于Spring Festival和Mid-autumnFestival两个目录下。 

参见图4a和图4b，图4a所示为应用本发明实施例二的用户定义的数据结构示意图，其中，方框表示Folder，圆圈表示data Item；实线表示的状态为Existing，点画线表示的状态为Update。图4b所示为应用本发明实施例二的客户端的数据存储示意图。在客户端保存有数据条目表(Data Item Table)、目录表(Folder Table)和数据条目-目录对应关系索引表(Index Table)。各个数据表中数据的状态在图4b中都有相应的反映。 

当用户要求同步“bless”目录时，客户端顺序生成以下同步命令： 

首先，客户端根据接收到的来自用户的同步bless目录的命令并确定同步数据是目录项之后，从Folder Table中确定该bless目录的状态为U，之后，构建指示更新的Sync命令，比如：更新(Replace)同步命令，该Replace同步命令可称为是Sync命令的子命令。并且，使用该所构建 的Replace命令中的Meta字段指明数据类型为目录项(Folder)，该数据类型可根据Folder Table确定；使用LUID字段指明待同步数据的编号为1006，使用Data字段指明具体的数据为bless，使用SourceParent字段指明该bless目录所属父目录为根目录。 

之后，客户端确定bless目录下数据项目的状态，由于在Index Table中，1006所对应的数据项目为2001，且其状态为U，因此，构建Replace同步命令，并且当从Data Item Table中确定2001所对应的具体数据内容为U1后，使用该所构建的Replace同步命令中的Meta字段指明数据类型为数据项目(Item)，使用LUID字段指明待同步数据的编号为2001，使用Data字段指明具体的数据为U1，使用SourceParent字段指明该数据项目所属父目录为1006。 

然后，当客户端确定bless目录下没有更新的数据项目后，索引该bless目录下子目录的状态，其具体方法与确定bless目录的方法相同，本例中，该bless目录下子目录的状态未发生变化，因此不做处理。 

最后，当客户端确定bless目录下没有更新的子目录后，再确定子目录Spring Festival下的数据项目的状态，其具体方法与确定U1的方法相同。即：最终的结果是构建Replace同步命令，并且在从Data Item Table中确定2002所对应的具体数据内容为U2之后，使用该所构建的Replace同步命令中的Meta字段指明数据类型为数据项目(Item)，使用LUID字段指明待同步数据的编号为2002，使用Data字段指明具体的数据为U2，使用SourceParent字段指明其所属父目录为1007。 

以此类推，直到针对所有更新的数据均发出Replace同步命令为止，这样也就实现了递归同步。当然，也可能实现的是非递归同步，具体实现原理与递归同步类似，这里就不再进一步描述。其中，可在同步初始化阶段协商待同步目录时确定当前同步是否为递归同步，这样，本发明 的第二同步命令中进一步携带递归同步标志，当携带有效的递归同步标志时，说明当前待同步目录进行的是递归同步，该待同步目录的根节点以及所有子节点均要进行数据同步，当携带无效的递归同步标志时，说明当前待同步目录进行的是非递归同步，只有该待同步目录的根节点要进行数据同步。当在同步初始化阶段确定当前待同步目录要进行递归同步之后，同步阶段中客户端或服务器发送的第一同步命令中携带的数据内容包括：当前待同步目录的根节点以及各个子节点的数据内容；此时，第一同步命令的接收端按第一同步命令中携带的根节点以及各子节点的数据内容，依次同步该待同步目录的根节点以及各个子节点的数据内容。当在同步初始化阶段确定当前待同步目录要进行非递归同步之后，同步节点中客户端或服务器发送的第一同步命令中携带的数据内容包括：当前待同步目录根节点的数据内容；此时，该第一同步命令的接收端仅同步该待同步目录的根节点的数据内容。这里，本文所述的数据内容指待同步目录中根节点或子节点的目录项和数据项的内容，如：目录项的名称(Name)、数据项的数据(Data)。 

此后，将所构造的Replace同步命令全部发送给服务器，具体发送方式与发送Add同步命令的方式相同，在此不再赘述。 

下面说明服务器端接收到上述Replace命令后，执行同步操作的过程。该过程所涉及的表格与图4b所示表格类似，因此这里并未示出该表格。 

当服务器端接收到更新bless目录项的同步命令后，通过接收到的同步命令中的Meta字段确定待同步数据的类型为目录项，根据LUID字段确定该待同步数据在客户端的编号为1006，根据Data字段确定其名称为bless，根据SourceParent字段确定其父目录为根目录。之后，在已设置的客户端内编号与服务器内编号的对应关系列表中获取该更新的 待同步数据在服务器本地的编号，如100006。然后，在本地已设置的目录表中更新相应条目，即更新条目中的bless的属性信息，该条目中包括：100006、bless、根目录、该bless数据当前状态以及这四者的对应关系。 

当服务器端接收到更新U1数据项目的同步命令后，通过接收到的同步命令中的Meta字段确定待同步数据的类型为数据项目，根据LUID字段确定该待同步数据在客户端的编号为2001，根据Data字段确定其具体的数据内容为U1，根据SourceParent字段确定其父目录为1006。之后，在已设置的客户端内编号与服务器内编号的对应关系列表中获取该更新的待同步数据在服务器本地的编号，如200001，在本地已设置的数据条目表中更新待同步数据的本地编号所对应的条目，即更新200001和U1及其对应关系条目中的U1的信息。 

服务器端更新U2的方法与更新U1的方法相同，在此不再赘述。 

此处需要说明一点，本例中，U2既属于Spring Festival目录又属Mid-autumn Festival目录，但更新U2时只需发送一次Replace命令，服务器端也只需更新一次U2，就可以使两个目录下的U2都得到更新。这是因为，在服务器端实际只保存了一份数据，该数据的隶属关系是通过Index Table表来体现的。可见，采用本发明的方法可最大限度地减少冗余数据的存在，进而最大限度地节省有限的资源。 

实施例三：用户将“music”目录下的数据项目“M1”移动到“favorite”目录下；将“mp3”整个目录移动到“favorite”下。 

参见图5a和图5b，图5a所示为应用本发明实施例三的用户定义的数据结构示意图，其中，方框表示Folder，圆圈表示data Item；实线表示的状态为Existing，双点画线表示的状态为Move。图5b所示为应用本发明实施例三的客户端的数据存储示意图。在客户端保存有数据条目 表(Data Item Table)、目录表(Folder Table)和数据条目-目录对应关系索引表(Index Table)。各个数据表中数据的状态在图5b都有相应的反映。 

当用户要求同步根目录时，客户端顺序生成以下同步命令： 

首先，客户端根据接收到的来自用户的同步根目录的命令后，索引该根目录下的所有子目录的状态，本例中，该根目录下所有子目录的状态未发生变化，因而不做处理。然后，客户端索引该根目录下的数据项目的状态是否发生变化，本例中，该根目录下的数据项目的状态也未发生变化，因此不做处理。 

之后，客户端依次索引每个子目录中的子目录状态是否发生变化，本例中，客户端确定music目录下的“mp3”子目录的状态为M，之后，构建移动(Move)同步命令，该Move同步命令也称为是一种Sync命令的子命令，用于携带移动数据。并且，使用该所构建的Move命令中的Meta字段指明数据类型为目录项(Folder)，该数据类型根据FolderTable确定，使用LUID字段指明待同步数据的编号为1006，使用SourceParent字段指明该目录移动后所属父目录为1004。 

然后，客户端确定music目录下数据项目的状态，由于在Index Table中，1006所对应的数据项目为2001，且其状态为M，因此构建Move同步命令，并且，使用该构建的命令中的Meta字段指明数据类型为数据项目(Item)，使用LUID字段指明待同步数据的编号为2001，使用SourceParent字段指明其移动后所属的父目录为1004。 

以此类推，本例中没有其他发生移动的数据，因此不再处理。 

之后，将所构造的Move同步命令全部发送给服务器，具体发送方式与发送Add同步命令的方式相同，在此不再赘述。 

下面说明服务器端接收到上述Move命令后，执行同步操作的过程。 该过程所涉及的表格与图5b所示表格类似，因此图未示。 

当服务器端接收到指示移动mp3目录项的Move同步命令后，通过接收到的Move同步命令中的Meta字段确定待同步数据的类型为目录项，根据LUID字段确定该待同步数据在客户端内的编号为1006，根据SourceParent字段确定该mp3目录项移动后所属父目录为1004，之后，在已设置的客户端内编号与服务器内编号的对应关系列表中获取该待移动数据在服务器本地的编号，如100006，在本地已设置的Folder Table中该待同步数据的本地编号所对应的条目中，将所属父目录更改为接收到的Move同步命令中的父目录，即将该表中的100006所对应的父目录由1005改为1004。 

当服务器端接收到指示移动M1数据项目的Move同步命令后，通过接收到的Move同步命令中的Meta字段确定待同步数据的类型为Item，根据LUID字段确定该待同步数据在客户端的编号为2001，根据SourceParent字段确定其移动后所属父目录为1004，之后，从已设置的客户端内编号与服务器内编号的对应关系列表获取该更新的待同步数据在服务器本地的编号，如200001，在本地已设置的Index Table中该待同步数据的本地编号所对应的条目中，将所属父目录更改为接收到的同步命令中的父目录，即将该表中的200001所对应的父目录由1005改为1004。 

可见，采用本发明的方法进行移动的同步操作时，仅需修改相应数据表中的对应关系，不需要对实际数据进行移动，从而最大限度节省了有限的资源。 

另外需要说明一点：在移动某个目录及其下的子目录和数据项目时，比如移动mp3目录项时，只需针对mp3目录项只发送一条Move命令，而不需再针对mp3目录下的子目录和数据项目发送Move命令， 因为其下的子目录和数据项目所属的父目录是未发生任何变化的。 

当第一同步命令携带的操作类型为删除，且要同步的是待同步目录下的数据项时，进一步包括：判断当前待同步目录的数据项的数据内容是否仅存于该待同步目录下，如果是，则在该第一同步命令中进一步携带有效的永久删除标志；否则在该第一同步命令中进一步携带无效的永久删除标志；此时，该第一同步命令的接收端对待同步目录所进行的数据同步操作包括：判断该第一同步命令中是否携带有效的永久删除标志，如果是，则删除该待同步目录下数据项的数据内容；否则取消该数据项与该待同步目录之间的对应关系。 

实施例四：用户删除了“bless”目录下的“D1”数据项目，对“SpringFestival”目录下的数据“U2”选择了永久删除，“D3”选择了非永久删除。本例中，仅是对删除数据项目的描述。 

参见图6a和图6b，图6a所示为应用本发明实施例四的用户定义的数据结构示意图，其中，方框表示Folder，圆圈表示data Item；实线表示的状态为Existing，点线表示的状态为Delete。图6b所示为应用本发明实施例四的客户端的数据存储示意图。在客户端保存有数据条目表(Data Item Table)、目录表(Folder Table)和数据条目-目录对应关系索引表(Index Table)。各个列表中数据的状态在图6b都有相应的反映。 

当用户要求同步“bless”目录时，客户端顺序生成以下同步命令： 

客户端确定bless目录下数据项目的状态，由于在Index Table中，数据项目为2001的状态为永久删除(P-D)，因此，构建删除(Delete)同步命令，该Delete同步命令也为一种Sync命令的子命令，用于携带删除某数据；并且，使用该所构建的Delete同步命令中的Meta字段指明数据类型为数据项目(Item)，使用LUID字段指明待同步数据的编号为2001，并且该Delete同步命令中还需包括指明永久删除的标识。 

之后，当客户端确定bless目录下没有删除的数据项目后，索引该bless目录下子目录的状态，本例中，该bless目录下子目录的状态未发生变化，因此不做处理。 

当客户端确定bless目录下没有删除的子目录后，再确定子目录Spring Festival下的数据项目的状态，其具体方法与确定D1的方法相同。即：最终的结果是构建两条Delete同步命令，其中一条Delete同步命令中，使用Meta字段指明数据类型为数据项目(Item)，使用LUID字段指明待同步数据的编号为2002，并且该命令中还需包括指明永久删除的标识，如P-D。而另一条Delete同步命令中，使用Meta字段指明数据类型为数据项目(Item)，LUID字段指明待同步数据的编号为2003，并且在该命令中还需包括指明非永久删除的标识，如NP-D。 

所构建的Delete同步命令中，不需要包含要删除的数据，只需指明要删除数据的类型、编号、以及是永久删除还是非永久删除即可。以上是Delete命令的一种实现方式，即该命令中包含类型、编号、以及用于携带永久删除或非永久删除的标志位这三种信息；当然，还可以有其他的实现方式，比如，将Delete分为两种命令，一种永久删除P-Delete命令，另一种是非永久删除NP-Delete命令，这样，每种删除命令中只需包含待删除数据的类型、编号即可。 

最后，将所构造的用于携带删除的同步命令全部发送给服务器。 

下面说明服务器端接收到上述Delete命令后，执行同步操作的过程。 

当服务器端接收到删除D1数据项目的同步命令后，通过接收到的同步命令中的Meta字段确定待同步数据的类型为数据项目Item，根据LUID字段确定该待同步数据在客户端的编号为2001，并确定此次删除为永久删除，之后，在已设置的客户端内编号与服务器内编号的对应关系列表中获取该待删除数据在服务器本地的编号，如200001，从本地的 数据条目表和数据条目-目录对应关系表中，分别删除待同步数据本地编号所对应的条目，即删除编号为200001的整个条目。同时，在本地数据库中删除数据D1。 

当服务器端接收到用于携带删除D2数据项目的Delete同步命令后，即删除相应数据表中的整个条目，其删除D2的方法与删除D1的方法相同，在此不再赘述。 

当服务器端接收到用于携带删除D3数据项目的Delete同步命令后，通过接收到的Delete同步命令中的Meta字段确定待同步数据的类型为数据项目Item，根据LUID字段确定该待同步数据在客户端的编号为2003，并确定此次删除为非永久删除，之后，在已设置的客户端内编号与服务器内编号的对应关系列表中获取该待删除数据在服务器本地的编号，如200003，并只在本地的数据条目-目录对应关系表中删除该待同步数据的本地编号所对应的条目，即删除该表中编号为200003的整个条目，而在本地数据库内不删除D3数据。 

可见，采用本发明的方法进行删除的同步操作时，仅需在客户端与服务器端之间传递标识，不需要传输具体的数据内容，最大限度节省了有限的资源。 

实施例五：用户删除了整个“bless”目录。这相当于同时删除了其下的所有子目录以及其下的所有数据项目。本例中，D1和D2仅存在于bless目录下，D3存在于bless和joke目录下，且本例仅是对删除目录项的描述。 

参见图7a和图7b，图7a所示为应用本发明实施例五的用户定义的数据结构示意图，其中，方框表示Folder，圆圈表示data Item；实线表示的状态为Existing，点线表示的状态为Delete。图7b所示为应用本发明实施例五的客户端的数据存储示意图。在客户端保存有数据条目表 (Data Item Table)、目录表(Folder Table)和数据条目-目录对应关系索引表(Index Table)。各个数据表中数据的状态在图7b都有相应的反映。 

当用户要求同步根目录时，客户端顺序生成以下同步命令： 

首先，客户端根据接收到的来自用户的同步根目录的命令后，索引该根目录下的所有子目录的状态，本例中，从Folder Table表中确定bless的状态为D，则客户端还要进一步执行如下步骤：判断该待删除目录下的数据项目以及该目录的子目录下的数据项目是否仅存在于该待删除目录下，如果是，则构建一条Delete同步命令，且该Delete同步命令中包含指示永久删除的信息；否则，针对每个数据项目和目录项分别构建一条Delete同步命令，并且，仅存在于该待删除目录下的数据项目或目录项所对应的Delete同步命令中将包含指示永久删除的信息，而并非仅存在于该待删除目录下的数据项目或目录项所对应的Delete同步命令中则包含指示非永久删除的信息。也就是说，如果某个数据项目或目录项，还存在于其他目录下(这里的其他目录不包括bless子目录)，则在这样的数据所对应的Delete同步命令中包含非永久删除信息，如果不是这样的数据，则其所对应的Delete同步命令中包含永久删除信息。之后，将所构建的所有Delete同步命令均发送给服务器。这里，针对每个数据项目和目录项分别构建一条删除命令，实际就是一种递归的同步。 

下面说明服务器端接收到上述Delete同步命令后，执行同步操作的过程。 

如果服务器接收到的是针对数据项目的Delete同步命令，则与实施例四中所述的处理方式相同，不再赘述。 

如果服务器接收到的是针对目录项的Delete同步命令，则在已设置的客户端内编号与服务器内编号的对应关系列表中获取该待删除数据在服务器本地的编号，然后，无论是永久删除还是非永久删除，都要从 本地已设置的目录表中删除该待同步数据的本地编号所对应的条目。 

对于目录删除操作还有一点需要说明：作为同步发起方的客户端，在删除某个目录项时，如删除bless目录项，其可以针对该目录项只构建一条Delete同步命令，而其所执行的其他操作，如“判断该待删除目录下的数据项目以及该目录的子目录下的数据项目是否仅存在于该待删除目录下”等，均由服务器来执行，这样可以简化客户端的操作。当然，反之也适用。 

在实际应用中，实施例四、五通常会结合起来同时使用。 

另外，对于删除操作，在服务器端完成同步操作后，客户端也会将自身相应数据表中的条目删除。 

实施例六：用户将“music”目录下的数据项目“M1”复制到“favorite”目录下；将“mp3”目录复制到“favorite”目录下。 

参见图8a和图8b，图8a所示为应用本发明实施例六的用户定义的数据结构示意图，其中，方框表示Folder，圆圈表示data Item；实线表示的状态为Existing，粗实线表示的状态为Copy。图8b所示为应用本发明实施例六的客户端的数据存储示意图。在客户端保存有数据条目表(Data Item Table)、目录表(Folder Table)和数据条目-目录对应关系索引表(Index Table)。各个列表所增加数据的状态在图3b都有相应的反映。 

需要说明的是，上述实施例中，服务器中设置有客户端内编号与服务器内编号之间的对应关系列表，比如：LUID与GUID的对应关系表，此表的设置是考虑到目前还存在一些服务器与客户端的编号支持能力不同的问题。而在服务器与客户端的编号支持能力相同的情况下，对于同一数据而言，客户端和服务器使用相同的目录项编号和数据项编号，那么就不需要先进行从客户端内编号到服务器内编号的映射就可直接 使用客户端内编号进行处理，因此，此种情况下，本发明方法的实施并未受到限制。 

当用户要求同步根目录时，客户端与服务器端的操作与实施例一的操作基本一致。所不同之处在于，在实施例一中，客户端要针对每一个数据项目和目录项都发送一次Add同步命令，而在本例中，如果客户端对某一目录项发出Copy同步命令(该Copy同步命令也为一种Sync命令的子命令，用于携带复制数据)，则不需对该目录项下的子目录项和数据项目再发Copy同步命令，从而进一步减少数据量的传输，节约网络资源。而本例中服务器端的处理过程与实施例一中的处理过程是相同的，其也是针对每一个目录项和数据项目逐一地进行处理。 

再有，在执行Copy同步时，用户可根据需要决定是否在再指令复制一份实际数据，如果是，则执行同步操作的一方的数据同步操作进一步包括：在本地数据库内在复制一份数据，并在本地已设置的数据目录表中增加相应条目。 

如果客户端和服务器端的修改操作存在冲突，如在被移动的目录中增加、更新或者删除了一些条目，本发明可通过扩展现有的冲突机制来确保客户端和服务器端的数据完全同步。具体实现为：将现有的以客户端为主(Client-Win)和以服务器端为主(Server-Win)的仲裁结果加以扩展，增加一种以服务器端和客户端合并处理(Win-Win)的仲裁结果，通过双赢的方式来确保客户端和服务器端的数据完全一致。当服务器端和客户端的数据操作发生冲突时，客户端根据服务器的数据操作执行同步操作，并且，服务器根据客户端的数据操作执行同步操作；所述数据操作包括：新增操作、更新操作、移动操作、删除操作、复制操作或此五者的任意组合。例如，用户在客户端上移动A目录使其成为B目录的子目录，而服务器端是在A目录中增加了一个条目，此时，服务器端将 移动A目录使其成为B目录的子目录，并且，客户端在A目录中也增加一个条目，从而确保客户端和服务器端的数据完全一致。 

基于上述本发明方法，本发明还提供了一种实现数据同步的系统，该系统包括：客户端和服务器，二者之间通过交互同步命令来实现通信。其中，客户端和服务器进一步用于确定待同步节点，并对所确定的待同步节点进行数据同步。 

图9为所示为应用本发明实施例的实现数据同步的系统结构示意图。如图9所示，客户端包括：第一节点地址处理模块和第一数据同步模块，服务器包括：第二节点地址处理模块和第二数据同步模块。 

客户端中，第一节点地址处理模块用于确定待同步节点的地址并输出至第一数据同步模块；从第一数据同步模块接收待同步节点的地址并按此地址确定当前待同步节点，提供待同步节点下的客户端与服务器之间的数据同步处理；第一数据同步模块用于从第一节点地址处理模块接收待同步节点的地址，构造携带该待同步节点地址的同步命令并输出至服务器；从服务器接收同步命令并从中解析得到待同步节点地址输出至第一节点地址处理模块。其中，第一节点地址处理模块可进一步用于从接收用户通过配置命令输入的待同步节点的地址，以使用户能在客户端上设定待同步节点地址。 

服务器中，第二节点地址处理模块用于确定待同步节点的地址并输出至第二数据同步模块；从第二数据同步模块接收待同步节点的地址并按此地址确定当前待同步节点，提供待同步节点下的客户端与服务器之间的数据同步处理；第二数据同步模块用于从第二节点地址处理模块接收待同步节点的地址，构造携带该待同步节点地址的同步命令并输出至客户端；从客户端接收同步命令并从中解析得到待同步节点地址输出至第二节点地址处理模块。 

基于上述实现数据同步的系统可见，本发明还公开了一种实现数据同步的客户端和一种实现数据同步的服务器，该客户端和服务器的实现原理与前述系统中的客户端和服务器相同，这里就不再对其工作原理及内部构造做详细说明，但均在本发明保护范围之内。 

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。 

Claims (35)

1.一种实现数据同步的方法，用于在客户端和服务器之间同步由一个或多个节点构成的层级结构的数据，该方法包括：客户端和服务器中的任一端发送第一同步命令至二者中的另一端；其特征在于，该方法还包括：

在发送第一同步命令之前，客户端和服务器确定该层级结构的数据中的待同步节点，其中，所述客户端和服务器确定待同步节点的方法为：所述客户端和服务器中的任一端发送携带待同步节点地址的第二同步命令至另一端，该另一端按第二同步命令中的待同步节点地址确定当前待同步的节点；

所述第一同步命令的接收端在收到第一同步命令之后，按接收到的第一同步命令，对所确定的待同步节点进行数据同步。

2.根据权利要求1所述的方法，其特征在于，待同步节点有多个时，所述客户端和服务器通过发送第二同步命令协商得到待同步节点的方法为：

针对所有待同步节点，所述客户端和服务器中的任一端发送一个第二同步命令至另一端，该第二同步命令中携带所有节点的地址；该另一端按第二同步命令中的所有节点的地址确定所有待同步的节点；或者，

针对每一待同步节点，所述客户端和服务器中的任一端发送一个携带该节点地址的第二同步命令至另一端；该另一端按每一第二同步命令中的节点地址一一确定每一待同步节点。

3.根据权利要求1所述的方法，其特征在于，所述客户端和服务器中的任一端发送第二同步命令至另一端之前，包括：该第二同步命令的发送端确定待同步节点的源地址，然后将所确定的源地址作为该待同步节点的目的地址携带在第二同步命令中。

4.根据权利要求1所述的方法，其特征在于，所述客户端和服务器中的任一端发送第二同步命令至另一端之前，包括：该第二同步命令发送端确定该待同步节点的目的地址并携带在第二同步命令中。

5.根据权利要求4所述的方法，其特征在于，所述第二同步命令的发送端确定该待同步节点的目的地址的方法为：

由该另一端将待同步节点在本端的地址发送至该第二同步命令的发送端。

6.根据权利要求5所述的方法，其特征在于，所述另一端将待同步节点在本端的地址发送至该第二同步命令的发送端的方法为：通过发携带该节点地址的通知来发送。

7.根据权利要求4所述的方法，其特征在于，所述第二同步命令发送端确定该待同步节点的目的地址的方法为：

该第二同步命令的发送端从另一端获取该另一端的层级结构，并按所获取的层级结构确定待同步节点的目的地址。

8.根据权利要求7所述的方法，其特征在于，所述第二同步命令的发送端从另一端获取该另一端的层级结构的方法为：

该第二同步命令的发送端发送第三同步命令至另一端，该第三同步命令指示请求获取指定数据库的层级结构；

该另一端在该第三同步命令的响应中携带本端指定数据库的层级结构并返回给该第二同步命令的发送端。

9.根据权利要求8所述的方法，其特征在于，所述在第三同步命令的响应中携带指定数据库的层级结构的方法为：使用一个该第三同步命令的子元素来封装整个层级结构的数据。

10.根据权利要求8所述的方法，其特征在于，所述第三同步命令采用同步标签语言SyncML协议的提取Get元素来实现；采用Get元素的子元素或属性来携带指定数据库的地址并指示请求获取该指定数据库的层级结构；或者，所述第三同步命令采用SyncML协议的警报Alert元素来实现，该Alert元素携带指定数据库的地址，并采用Alert元素的属性或子元素来指示请求获取该指定数据库的层级结构。

11.根据权利要求8所述的方法，其特征在于，所述第三同步命令的响应采用SyncML协议的结果Results元素、新增Add或更新Replace元素来实现，并采用至少一个Results元素、Add元素或Replace元素的子元素或属性来携带节点的地址，其中，每一子元素或属性携带一个节点的地址。

12.根据权利要求9所述的方法，其特征在于，所述第三同步命令的响应采用SyncML协议的Results元素、Add元素或Replace元素来实现，并采用一个Results元素、Add元素或Replace元素的子元素来封装整个层级结构的数据。

13.根据权利要求4所述的方法，其特征在于，所述第二同步命令发送端确定该待同步节点的目的地址的方法为：

该第二同步命令的发送端按用户输入的信息确定待同步节点的目的地址；或者，

第二同步命令发送端指定待同步节点的目的地址，如果该目的地址在该另一端上不存在，则该另一端在第二同步命令发送端指定的目的地址上创建该待同步节点；或者，

客户端和服务器预先设定待同步节点的地址。

14.根据权利要求1所述的方法，其特征在于，所述第二同步命令为新增同步命令；或者现有协议的同步命令，且采用该现有协议的同步命令的属性或用于指明目标数据库地址的子元素来携带待同步节点的地址，该用于指明目标数据库地址的元素被扩展为能够指示层级地址的元素。

15.根据权利要求1所述的方法，其特征在于，所述待同步节点有多个，每一节点对应各自的同步类型；所述客户端和服务器通过发送第二同步命令协商得到待同步节点时，进一步包括：

在客户端和服务器通过发送第二同步命令协商得到待同步节点时，该第二同步命令中进一步携带各个待同步节点所对应的同步类型协商参数以及各节点与同步类型之间的对应关系，按该第二同步命令携带的同步类型协商参数以及各节点与同步类型之间的对应关系确定每一待同步节点对应的同步类型。

16.根据权利要求15所述的方法，其特征在于，所述所有待同步节点对应同一同步类型，所述通过发送第二同步命令协商得到待同步节点和同步类型的方法为：

针对所有待同步节点，发送一个第二同步命令，该第二同步命令中携带所有节点的地址以及这些节点对应的同一同步类型协商参数；该第二同步命令的接收端按第二同步命令中的所有节点的地址确定所有待同步节点以及当前同步类型。

17.根据权利要求15所述的方法，其特征在于，所述通过发送第二同步命令协商得到待同步节点和同步类型的方法为：

针对所有待同步节点，发送一个第二同步命令，该第二同步命令中携带各个节点的地址及其对应的同步类型协商参数；该第二同步命令的接收端按第二同步命令携带的各个节点的地址及其对应的同步类型协商参数确定所有待同步节点以及每一节点的同步类型；或者，

针对每一待同步节点，发送一个携带该节点地址及其对应的同步类型协商参数的第二同步命令；该同步命令的接收端按每一第二同步命令携带的节点地址和同步类型协商参数一一确定每一待同步节点及其同步类型。

18.根据权利要求16或17所述的方法，其特征在于，所述第二同步命令为现有协议的同步命令；针对该第二同步命令携带的每一节点地址采用一个元素或属性来携带该节点地址，针对该第二同步命令携带的每一同步类型协商参数采用一个元素或属性来携带该同步类型协商参数；或者，针对该第二同步命令携带的每一节点地址及其对应的同步类型协商参数采用一个元素或属性来携带该节点地址及其对应的同步类型协商参数。

19.根据权利要求18所述的方法，其特征在于，所述第二同步命令采用同步标签语言SyncML协议的警报Alert元素来实现，并采用Alert元素的子元素或属性来携带节点地址和同步类型协商参数。

20.根据权利要求1所述的方法，其特征在于，所述第二同步命令为现有协议的同步命令，且采用该现有协议的同步命令的属性或新增的用于携带节点级过滤条件的元素来承载待同步节点地址。

21.根据权利要求20所述的方法，其特征在于，所述第二同步命令采用SyncML协议的过滤Filter元素来实现，并采用Filter元素的属性或子元素来携带节点级过滤条件。

22.根据权利要求1所述的方法，其特征在于，所述第一同步命令携带操作类型；所述按接收到的第一同步命令对所确定的待同步节点进行数据同步的方法为：按第一同步命令携带的操作类型，对所确定的待同步节点中的数据作该操作类型指定的同步操作。

23.根据权利要求22所述的方法，其特征在于，该第一同步命令进一步携带待同步节点地址；

所述按接收到的第一同步命令对所确定的待同步节点进行数据同步的方法进一步包括：确定该第一同步命令中携带的待同步节点地址，在所确定的待同步节点地址下进行同步操作。

24.根据权利要求22所述的方法，其特征在于，该第一同步命令进一步携带该数据内容；

所述按接收到的第一同步命令对所确定的待同步节点进行数据同步的方法进一步包括：确定该第一同步命令中携带的数据内容，将该数据内容保存在该待同步节点地址下。

25.根据权利要求23或24所述的方法，其特征在于，所述第一同步命令为现有协议的同步命令，采用该现有协议的同步命令的属性或用于指明目标数据库地址的子元素来携带所述待同步节点地址，该用于指明目标数据库地址的元素被扩展为能够指示节点级地址的元素。

26.根据权利要求25所述的方法，其特征在于，所述第一同步命令采用SyncML协议的同步Sync元素来实现，并采用Sync元素的子元素或属性来携带待同步数据地址。

27.根据权利要求1所述的方法，其特征在于，所述第二同步命令中进一步携带递归同步标志；所述按第二同步命令中的待同步节点地址确定当前待同步的节点时，进一步包括：判断该第二同步命令是否携带有效的递归同步标志，如果是，确定当前待同步节点要进行递归同步；否则确定当前待同步节点要进行非递归同步；

当确定当前待同步节点要进行递归同步时，所述第一同步命令中携带的数据内容包括：当前待同步节点的根节点以及各个子节点的数据内容，该第一同步命令的接收端按第一同步命令中携带的根节点以及各子节点的数据内容，依次同步该待同步节点的根节点以及各个子节点的数据内容；

当确定当前待同步节点要进行非递归同步时，所述第一同步命令中携带的数据内容包括：当前待同步节点的根节点的数据内容，该第一同步命令的接收端仅同步该待同步节点的根节点的数据内容。

28.根据权利要求22或23所述的方法，其特征在于，当第一同步命令携带的操作类型为删除、且要同步待同步节点下的数据项时，进一步包括：判断当前待同步节点的数据项的数据内容是否仅存于该待同步节点下，如果是，则在该第一同步命令中进一步携带有效的永久删除标志；否则在该第一同步命令中进一步携带无效的永久删除标志；

该第一同步命令的接收端对待同步节点所进行的数据同步操作包括：判断该第一同步命令中是否携带有效的永久删除标志，如果是，则删除该待同步节点下数据项的数据内容；否则取消该数据项与该待同步节点之间的对应关系。

29.根据权利要求1所述的方法，其特征在于，在确定待同步节点之后进一步包括：判断当前待同步节点是否发生变化，如果发生变化，则按当前待同步节点的变化状态构造第一同步命令并发送。

30.根据权利要求1所述的方法，其特征在于，该方法进一步包括：增设以服务器和客户端合并处理Win-Win为机制的仲裁结果；

当服务器端和客户端的数据操作发生冲突时，客户端根据服务器的数据操作执行同步操作，并且，服务器根据客户端的数据操作执行同步操作；所述数据操作包括：新增操作、更新操作、移动操作、删除操作、复制操作或此五者的任意组合。

31.一种实现数据同步的系统，该系统包括：客户端和服务器，且二者之间通过交互同步命令来实现通信；其特征在于，

所述客户端和服务器中的任一端发送携带待同步节点地址的第二同步命令至另一端，该另一端按第二同步命令中的待同步节点地址确定当前待同步的节点，并对所确定的待同步节点进行数据同步，所述数据同步为在客户端和服务器之间同步由一个或多个节点构成的层级结构的数据，所述待同步节点为同步层级结构的数据中的待同步节点；

所述客户端包括：

第一节点地址处理模块，用于确定待同步节点的地址并输出至第一数据同步模块；从第一数据同步模块接收待同步节点的地址并按此地址确定当前待同步节点，提供待同步节点下的客户端与服务器之间的数据同步处理；

第一数据同步模块，用于从第一节点地址处理模块接收待同步节点的地址，构造携带该待同步节点地址的同步命令并输出至服务器；从服务器接收同步命令并从中解析得到待同步节点地址输出至第一节点地址处理模块；

所述服务器包括：

第二节点地址处理模块，用于确定待同步节点的地址并输出至第二数据同步模块；从第二数据同步模块接收待同步节点的地址并按此地址确定当前待同步节点，提供待同步节点下的客户端与服务器之间的数据同步处理；

第二数据同步模块，用于从第二节点地址处理模块接收待同步节点的地址，构造携带该待同步节点地址的同步命令并输出至客户端；从客户端接收同步命令并从中解析得到待同步节点地址输出至第二节点地址处理模块。

32.根据权利要求31所述的系统，其特征在于，所述第一节点地址处理模块进一步用于从接收用户输入的待同步节点的地址。

33.一种实现数据同步的客户端，其特征在于，该客户端包括：

第一节点地址处理模块，用于确定待同步节点的地址并输出至第一数据同步模块；从第一数据同步模块接收待同步节点的地址并按此地址确定当前待同步节点，提供待同步节点下的客户端与服务器之间的数据同步处理，所述数据同步为在客户端和服务器之间同步由一个或多个节点构成的层级结构的数据，所述待同步节点为同步层级结构的数据中的待同步节点；

第一数据同步模块，用于从第一节点地址处理模块接收待同步节点的地址，构造携带该待同步节点地址的同步命令并输出至服务器；从服务器接收同步命令并从中解析得到待同步节点地址输出至第一节点地址处理模块。

34.根据权利要求33所述的客户端，其特征在于，所述第一节点地址处理模块进一步用于从接收用户通过配置命令输入的待同步节点的地址。

35.一种实现数据同步的服务器，其特征在于，该服务器包括：

第二节点地址处理模块，用于确定待同步节点的地址并输出至第二数据同步模块；从第二数据同步模块接收待同步节点的地址并按此地址确定当前待同步节点，提供待同步节点下的客户端与服务器之间的数据同步处理，所述数据同步为在客户端和服务器之间同步由一个或多个节点构成的层级结构的数据，所述待同步节点为同步层级结构的数据中的待同步节点；

第二数据同步模块，用于从第二节点地址处理模块接收待同步节点的地址，构造携带该待同步节点地址的同步命令并输出至客户端；从客户端接收同步命令并从中解析得到待同步节点地址输出至第二节点地址处理模块。

Images