一种文档同步方法及系统、文档同步客户端与流程

本发明涉及一种文档同步的技术领域，特别是涉及一种文档同步方法及系统、文档同步客户端。

背景技术：

电子文档管理的核心在于同步和对历史版本管理。对于个人网盘产品，由于没有太多的共享需求，所以可以采用直接扫描本地目录变化，来实现文档实时全同步。但是对于企业级应用场景，电子文档管理服务端上存在上TB甚至是PB级别的海量数据。此时若依旧采用全同步方式则存在以下缺陷：

1)终端用户客户机的磁盘空间一直处于占用满状态；

2)整个网络中一直传输着文档同步数据，导致带宽资源被无效占用着。

因此，针对企业级海量文件应用场景，基于Hook机制的按需触发下载机制能够很好的解决文档全同步以及网络带宽占用的问题。因为在该方式下，当用户需要访问某个文档时，才自动触发该文件内容的下载，默认仅同步该层面目录下的空目录名称以及文件名称。

对于采用Hook机制的同步客户端而言，需要拦截打开、关闭、读取、写入等文档操作，并且做出正确的响应。但是Hook并不能拦截到应用程序对于文件的所有访问。

另外，基于Hook机制的同步方式也存在明显的缺陷，即应用程序对文件的读写被迫延迟到文档下载完成之后。假如是几百MB或者上GB文件，这种延迟将会非常明显，导致用户体验较差。

技术实现要素：

鉴于以上所述现有技术的缺点，本发明的目的在于提供一种文档同步方法及系统、文档同步客户端，通过虚拟磁盘机制拦截所有对文件的访问，使得文档同步客户端能够在应用程序读取文档内容的时候，边从服务端下载数据，边向应用程序反馈数据，且文档打开的延迟仅受限于网络带宽，从而极大地提升了用户体验。

为实现上述目的及其他相关目的，本发明提供一种文档同步方法，包括以下步骤：将文档同步客户端虚拟为一个网络文件系统的服务器，所述文档同步客户端设置在本地计算机上，为文档同步服务器在本地计算机上的映射；将文档同步客户端挂载到本地计算机文件系统中的一个卷；当本地计算机上的应用程序打开卷上的目录和文件时，虚拟文件系统根据文档同步客户端的挂载信息将应用程序的文档操作请求投射到文档同步客户端的网络文件系统；文档同步客户端将对网络文件系统的请求转换为对文档的操作请求。

于本发明一实施例中，将所述文档同步客户端虚拟为一个单用户单挂载的网络文件系统的服务器。

于本发明一实施例中，还包括：在文档关闭时触发上传机制，将文档同步客户端上的文档上传至文档同步服务器。

于本发明一实施例中，还包括：设定同步周期，每间隔同步周期将文档同步客户端上的文档上传至文档同步服务器。

同时，本发明还提供一种文档同步系统，包括虚拟模块、挂载模块、投射模块和转换模块；

所述虚拟模块用于将文档同步客户端虚拟为一个网络文件系统的服务器，文档同步客户端设置在本地计算机上，为文档同步服务器在本地计算机上的映射；

所述挂载模块用于将文档同步客户端挂载到本地计算机文件系统中的一个卷；

所述投射模块用于在本地计算机上的应用程序打开卷上的目录和文件时，通过虚拟文件系统根据文档同步客户端的挂载信息将应用程序的文档操作请求投射到文档同步客户端的网络文件系统；

所述转换模块用于通过文档同步客户端将对网络文件系统的请求转化为对文档的操作请求。

于本发明一实施例中，所述虚拟模块将所述文档同步客户端虚拟为一个单用户单挂载的网络文件系统的服务器。

于本发明一实施例中，还包括上传模块，所述上传模块用于在文档关闭时触发上传机制，将所述文档同步客户端上的文档上传至所述文档同步服务器。

于本发明一实施例中，还包括周期上传模块，所述周期上传模块用于每间隔同步周期将所述文档同步客户端上的文档上传至所述文档同步服务器。

同时，本发明还提供一种文档同步客户端，所述文档同步客户端设置在本地计算机上，为文档同步服务器在本地计算机上的映射；

所述文档同步客户端包括协议转换模块、临时文件缓存模块、客户端主逻辑模块、元数据库和客户端缓存模块；

所述协议转换模块用于将对网络文件系统的请求转化为对文档的操作；

所述临时文件缓存模块用于在将对网络文件系统的请求转化为对文档的操作时，提供临时目录和文件的缓存；

所述客户端主逻辑模块用于接收对网络文件系统的操作请求；

所述元数据库用于保存文档同步客户端当前登录用户所能访问的文档和目录的元数据；

所述客户端缓存模块用于缓存文档同步客户端的文档，控制缓存方式、加密缓存内容、保护缓存目录的安全。

于本发明一实施例中，所述客户端缓存模块中设定缓存文件为固定大小的块，所述文档同步客户端按照块的大小从文档同步服务器下载数据。

如上所述，本发明的文档同步方法及系统、文档同步客户端，具有以下有益效果：

(1)通过虚拟磁盘机制拦截所有对文件的访问，能够同步文档下载和应用程序对文档的访问；

(2)文档打开的延迟仅受限于网络带宽，极大地提升了用户体验；

(3)采用虚拟磁盘方式，使得本地无持久缓存，能够有效地避免缓存文件无限增长；

(4)基于虚拟磁盘机制，可以隐藏本地缓存目录，从而增加系统安全性与可靠性；

(5)访问大型文档时无需等待整个文档缓存至本地，仅需要缓存部分头文件即可，实现边访问边下载数据。

附图说明

图1显示为本发明的文档同步方法的流程图；

图2显示为本发明的文档同步系统的结构示意图。

元件标号说明

1 虚拟模块

2 挂载模块

3 投射模块

4 转换模块

具体实施方式

以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。

需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

虚拟磁盘就是在本地电脑里面虚拟出一个远程电脑里面的磁盘。例如，客户端可以通过局域网连接服务器上的iSCSI Cake服务器，在本地虚拟出一块硬盘，以达到通过网络共享服务器硬盘的效果。

本发明的文档同步方法及系统、文档同步客户端通过虚拟磁盘机制拦截所有对文件的访问，使文档同步客户端能够做到在应用程序读取文档内容的时候，边从服务端下载数据，边向应用程序反馈数据，从而提升用户体验。

具体地，本发明的文档同步方法及系统中，将文档同步客户端虚拟为一个单用户单挂载的网络文件系统的服务器，并挂载到计算机文件系统中的一个卷上。应用程序通过应用程序编程接口(Application Programming Interface，API)打开卷上的目录和文件以进行文件读写。虚拟文件系统(virtual File System，VFS)接收API的调用，并根据文档同步客户端的挂载信息，将应用程序的操作投射到文档同步客户端对应的网络文件系统，比如EXT4、NTFS、NFS等。但是直接开发一个基于文档管理系统的文件系统比较困难，特别在windows环境下需要进行内核开发。因此，必须借助一些额外的技术来简化开发。目前，有以下两种可选的技术方式：

(1)用户空间文件系统(FileSystem in usespace，FUSE)

这是一种允许用户空间的程序实现一个文件系统的技术。在windows环境下有Docken/DockenX。

(2)网络文件系统

将文件管理客户端实现成一个网络文件服务器，如NFS、SMB、CIFS等，其运行在客户计算机中。客户计算机向这个本地网络文件服务器挂载卷，同样达到文件系统的功能。在本发明中，即将文档同步客户端虚拟为一个网络文件系统的服务器。

参照图1，本发明的文档同步方法，包括以下步骤：

步骤S1、将文档同步客户端虚拟为一个网络文件系统的服务器，文档同步客户端设置在本地计算机上，用于管理文档同步服务器上的文档。

例如，文档同步服务器可以为百度网盘、360云盘等等，向用户提供文件的存储、访问、备份、共享等文件管理等功能。相应地，文档同步客户端为百度云盘客户端、360网盘客户端。

优选地，将文档同步客户端虚拟为一个单用户单挂载的网络文件系统的服务器。

步骤S2、将文档同步客户端挂载到本地计算机文件系统中的一个卷。

具体地，基于虚拟磁盘机制，将文档同步客户端挂载到本地计算机文件系统中的一个卷，从而可在本地计算机上获取文档同步服务器上的存储空间。

步骤S3、当本地计算机上的应用程序打开卷上的目录和文件时，虚拟文件系统根据文档同步客户端的挂载信息将应用程序的文档操作请求投射到文档同步客户端的网络文件系统。

其中，应用程序通过API打开卷上的目录和文件。虚拟文件系统接收API的调用，并根据文档同步客户端的挂载信息将应用程序的文档操作请求投射到文档同步客户端的网络文件系统。

虚拟文件系统(VFS)是由Sun microsystems公司在定义网络文件系统(NFS)时创造的。它是一种用于网络环境的分布式文件系统，是允许和操作系统使用不同的文件系统实现的接口。虚拟文件系统(VFS)是物理文件系统与服务之间的一个接口层，它对Linux的每个文件系统的所有细节进行抽象，使得不同的文件系统在Linux核心以及系统中运行的其他进程看来，都是相同的。严格说来，VFS并不是一种实际的文件系统。它只存在于内存中，不存在于任何外存空间。VFS在系统启动时建立，在系统关闭时消亡。

步骤S4、文档同步客户端将对网络文件系统的请求转换为对文档的操作请求。

至此，本地计算机的应用程序即可实现对文档同步客户端中文档的操作，同时文档同步客户端能够在应用程序读取文档内容的时候，边从文档同步服务器下载数据，边向应用程序反馈数据。待应用程序完成了对文档的读写等操作，也同时完成了文档同步服务器上文档数据的同步。

优选地，还包括：在文档关闭时，触发上传机制，将文档同步客户端上的文档上传至文档同步服务器，从而实现了文档同步客户端与文档同步服务器之间的文档同步。

优选地，还包括：设定同步周期，每间隔同步周期将文档同步客户端上的文档上传至文档同步服务器，确保文档长时间打开情况下数据可靠性。

参照图2，本发明的文档同步系统包括虚拟模块1、挂载模块2、投射模块3和转换模块4。

虚拟模块1用于将文档同步客户端虚拟为一个网络文件系统的服务器，文档同步客户端设置在本地计算机上，为文档同步服务器在本地计算机上的映射。

例如，文档同步服务器可以为百度网盘、360云盘等等，向用户提供文件的存储、访问、备份、共享等文件管理等功能。相应地，文档同步客户端为百度云盘客户端、360网盘客户端。

优选地，将文档同步客户端虚拟为一个单用户单挂载的网络文件系统的服务器。

挂载模块2用于将文档同步客户端挂载到本地计算机文件系统中的一个卷。

具体地，基于虚拟磁盘机制，将文档同步客户端挂载到本地计算机文件系统中的一个卷，从而可在本地计算机上获取文档同步服务器上的存储空间。

投射模块3与虚拟模块1和挂载模块2相连，用于在本地计算机上的应用程序打开卷上的目录和文件时，通过虚拟文件系统根据文档同步客户端的挂载信息将应用程序的文档操作请求投射到文档同步客户端的网络文件系统。

其中，应用程序通过API打开卷上的目录和文件。虚拟文件系统接收API的调用，并根据文档同步客户端的挂载信息将应用程序的文档操作请求投射到文档同步客户端的网络文件系统。

虚拟文件系统(VFS)是由Sun microsystems公司在定义网络文件系统(NFS)时创造的。它是一种用于网络环境的分布式文件系统，是允许和操作系统使用不同的文件系统实现的接口。虚拟文件系统(VFS)是物理文件系统与服务之间的一个接口层，它对Linux的每个文件系统的所有细节进行抽象，使得不同的文件系统在Linux核心以及系统中运行的其他进程看来，都是相同的。严格说来，VFS并不是一种实际的文件系统。它只存在于内存中，不存在于任何外存空间。VFS在系统启动时建立，在系统关闭时消亡。

转换模块4与投射模块3相连，用于通过文档同步客户端将对网络文件系统的请求转化为对文档的操作请求。

至此，本地计算机的应用程序即可实现对文档同步客户端中文档的操作，同时文档同步客户端能够在应用程序读取文档内容的时候，边从文档同步服务器下载数据，边向应用程序反馈数据。待应用程序完成了对文档的读写等操作，也同时完成了文档同步服务器上文档数据的同步。

优选地，还包括上传模块，该上传模块用于在文档关闭时，触发上传机制，将文档同步客户端上的文档上传至文档同步服务器，从而实现了文档同步客户端与文档同步服务器之间的文档同步。

优选地，还包括周期上传模块，该周期上传模块用于每间隔同步周期将文档同步客户端上的文档上传至文档同步服务器，确保文档长时间打开情况下数据可靠性。

本发明的文档同步客户端模块包括协议转换模块、临时文件缓存模块、客户端主逻辑模块、元数据库和客户端缓存模块。

协议转换模块用于将对网络文件系统的请求转化为对文档的操作，从而解决应用程序产生的文档操作与文档同步客户端文档操作的适配问题。在文档管理系统中，所有对于文档的操作都是对应到某一个具体的使用者。但是应用程序对于一个文档的逻辑操作，比如创建、保存、删除等，可能是对应到一系列的文件操作。因此，文档同步客户端所接收到的都是来自应用程序的文件操作，与文档同步客户端的文档操作并不对应。因此需要通过协议转换模块进行整合与转换。

具体地，协议转换模块执行以下操作：

1)应用程序临时文件处理

应用程序在编辑一个文档时可能产生一系列的临时文件或者临时目录，用于存放自动保存的结果、中间文档、辅助数据等。这些并非文档持久化所需要的文件，不需要也不应当同步至文档同步服务器。因此，需要对这些文档做额外处理，即被文档同步客户端过滤掉，仅限本地保存。

2)应用程序特殊文档操作行为

应用程序有一些特殊的文档操作行为，如Finder复制大文件时，会分多次打开文件写入文档内容。这些操作实际为一次文档写入操作。因此需要将这一系列文件打开和写入操作合并为一个文档写入操作。这个合并操作即时协议转换模块的任务。

3)目录真实删除

真实删除一个目录在很多应用程序，例如Explorer、Finder等时，需遍历整个目录树，挨个删除所包含的文件和子孙目录。这样的操作投射到文档同步服务器上将会造成大量的文件被移入回收站，而不是被删除目录本身。因此需要由协议转换模块将这一系列删除操作还原为最初的目录删除操作；

临时文件缓存模块用于在将对网络文件系统的请求转化为对文档的操作时，提供临时目录和文件的缓存。

临时文件会排除在文档缓存之外，不会同步至文档同步服务器。必要时也需要进行加密和保护。

客户端主逻辑模块用于接收对网络文件系统的操作请求。

具体地，接收来自FUSE、NFS Client等模块的文件系统操作请求，如打开文件、列举目录、写入/读取文件内容。

元数据库用于保存文档同步客户端当前登录用户所能访问的文档和目录的元数据。用户在文档同步客户端中的文档、目录结构、访问权限等信息都来自元数据。文档同步客户端与文档同步服务器之间定期同步元数据。当文档同步客户端进行文档和目录的创建、写入、删除等操作时，会向文档同步服务器请求相应的操作。如果操作获得允许，那么相应的操作也会写入文档同步客户端的元数据中。如果操作未被允许，则反馈此次操作无效。如果操作失败，如网络终端、超时、客户端离线等，则尝试在文档同步客户端元数据中写入响应操作。文档同步客户端元数据根据所缓存的权限信息决定是否允许此次操作。文档同步客户端一旦恢复通信，则自动将离线时本地发生的修改同步到文档同步服务器。文档同步服务器根据融合规则合并文件发生的变化。例如发生冲突，则需要遵循冲突处理逻辑进行处理。对于文档和目录的非读写操作，比如重命名、删除、打开和创建目录、获取文档属信息等，都需要用到元数据模块处理。

客户端缓存模块用于缓存文档同步客户端的文档，控制缓存方式、加密缓存内容、保护缓存目录的安全。当应用程序打开一个文件时，相应的会打开缓存模块里的缓存文件，后续的读写操作也会落到这个缓存文件上。缓存文件和目录的组织结构与文档的逻辑组织结构不一样，其命名应当由缓存目录自行生成，并且无意义，全局唯一。为了防止缓存目录堆积过多无效缓存文件，影响读写性能，需要将缓存文件分散到多个目录中。缓存文件还可以根据设定进行加密，以保护缓存数据。

在本发明的文档同步方法及系统、文档同步客户端中，打开文档是针对打开一个已存在的文档。对于未存在的文档，则报告该文档不存在。因此，文档存在是相对于该用户而言，文档可见。

应用程序打开文件的操作流程，包括以下步骤：

1)应用程序调用Open()系统调用，访问本地客户端同步卷中的文档。该调用通常会携带一些用于说明打开方式的参数，比如只读/读写/append等等。这些参数对于后续文档的处理行为有很大影响。

2)本地客户端同步卷将open()调用传递给本地文档同步客户端。

3)本地文档同步客户端访问客户端元数据模块，获取文档的相关属性信息，判断文档的存在性、访问权限、访问方式与访问权限的匹配性等参数，以决定如何进行后续操作。文档的打开都依据本地的文档元数据记录。本地元数据会与文档同步服务器定期同步，或者由用户执行强制同步。对于以可写方式打开文档，并且当前用户对文档也具备写入权限，文档同步客户端则向文档同步服务器发起请求文档锁：

a)如果该文件不存在，则反馈该应用程序文档不存在；

b)如果该用户对于文档只有预览权限，则文档同步客户端打开预览界面，显示预览内容，并且反馈应用程序访问权限不足；

c)如果用户对于该文档没有写入权限，并且应用程序试图以读写方式打开，则向应用程序反馈该文档只读；

d)如果用户对于该文档有可写权限，并且应用程序试图以可写方式打开，则文档同步客户端向文档同步服务器请求获取文件锁；如果没有获得文件锁(通常由于其他用户已经占据该文档的锁)，则反馈该文档只读；否则就继续打开流程。

4)文档同步客户端向客户端缓存请求打开该文档指定版本的本地缓存。客户端缓存判断文档版本是否已经缓存。若文档版本的缓存已经存在，则直接打开缓存文件，若没有缓存，则进行如下操作：

a)创建空缓存文件；

b)向文档同步核心模块(Core模块)发起下载请求；

c)文档的同步Core模块执行存在验证、权限验证等。若验证通过则反馈打包后的http请求；

d)文档同步客户端缓存记录下该下载请求，以备后续缓存使用。此时客户端缓存并不发起正式的文档版本下载。正式的下载等到应用程序读写文档时才进行。

5)客户端缓存向文档同步客户端反馈缓存文件的句柄。

6)文档同步客户端记录下被打开文件等相关信息，保存缓存文件的句柄，生成文档句柄，建立文档句柄与被打开文档信息的关联。

7)文档同步客户端向本地客户端同步反馈文档句柄。

8)文档同步客户端向应用程序反馈文档句柄。

文档读取用于应用程序从一个已打开的文档上读取数据。在本发明的文档同步方法及系统、文档同步客户端中，应用程序读取文件的操作流程，包括以下步骤：

1)应用程序通过read()等系统函数向本地客户端同步卷读取某一指定位置的文档。此时，该文档已被应用程序打开，持有该文档的FD，并结合所需读取的offset和size调用read()。

2)本地客户端同步卷通过FUSE、NFS或CIFS将read()调用传递给文档同步客户端。

3)文档同步客户端见FD转换成文档的缓存ID。文档在打开时，文档同步客户端缓存已经建立了缓存项，并且生成缓存ID提交给文档同步客户端。文档同步客户端建立和保存FD到缓存ID的映射。

4)文档同步客户端以缓存ID向客户端缓存读取该文件的数据。

5)如果该文档尚未缓存文档数据，文档同步客户端缓存会向对象存储请求数据下载。文档的缓存有很多种模式，包括一次性完全缓存、按需缓存、区块缓存等。

6)客户端缓存读取缓存文件指定位置的数据。

7)客户端缓存向文档同步客户端反馈读取到的数据。

8)文档同步客户端向本地客户端同步卷反馈读取到的数据。

9)本地客户端同步卷向应用程序反馈读取到的数据。

文档写入用于向一个打开的文档写入数据。在本发明的文档同步方法及系统、文档同步客户端中，基于虚拟磁盘机制写入文档的操作流程，包括以下步骤：

1)应用程序通过系统调用向一个本地客户端同步卷写入数据。

2)本地客户端同步卷将写入请求转发给文档同步客户端。

3)文档同步客户端判断被打开文档是可写性。如果不可写，则通过文档同步客户端向应用程序反馈无权限写入错误。

4)如果被打开文档可写，则文档同步客户端判断是否首次写入；如果是首次写入，则文档同步客户端创建新的版本，并且指令客户端缓存创建新的版本缓存；如果不是首次写入，则将FD转化成缓存ID。

5)文档同步客户端向客户端缓存发送写入操作，客户端缓存则将数据写入缓存文件。

在本发明的文档同步方法及系统、文档同步客户端中，文档同步客户端同时采用两种缓存策略，分别用于元数据和文档数据。

元数据采用read-back和wire-through。即当文档同步客户端接收到需要读取元数据的操作时，从本地的元数据库读取；当文档同步客户端接收到需要写入元数据的操作时，则需要先向文档同步服务器发起相应的请求，获取相应的访问授权和可执行判别。得到正确的反馈之后，再在文档同步客户端本地记录元数据信息。文档同步客户端周期性向文档同步服务器获取元数据，保存在本地元数据库。

文档数据采用read-back和write-back。即文档同步客户端接收到需要读取的文档版本的操作时，从本地文档缓存读取文档数据。文档版本如果没有缓存，则文档同步客户端从文档同步服务器下载文档，缓存到本地。写入文档的话，也是先写入本地缓存，在文档关闭时触发上传机制。在安全性要求较高的情况下，可以引入定期同步机制，确保文档长时间打开情况下数据可靠性。

在本发明中，文档同步客户端的缓存隐藏在本地同步客户内部，因此缓存策略得以隐藏。文档同步客户端可以长期隐藏缓存文档，可以临时缓存。可以在读取时缓存，也可以在打开时缓存，甚至可以指定个别文档和目录采用不同的缓存策略。文档缓存可以进一步限制容量，采用LRU等淘汰策略，防止缓存空间过大。

单个文件的大小范围很广，从几个字节到上TB。对于大型的等文档，等待其完全缓存完毕再向应用程序反馈数据，会产生很多的时间延迟，严重影响客户体验。比较恰当的做法是，当应用读取一个文档时，仅反馈它所请求的那部分数据。比如应用读取16KB的数据，那么文档同步客户端就从文档同步服务器下载这16KB的数据，然后反馈给应用程序。但是，这种按需读取的方式同样存在问题。应用程序连续以小块读取文档数据，每块数据都需要到文档同步服务器获取。这种跨域网络的请求相对于本地磁盘来说具有很大的延时性。造成文档读取的延迟增加。解决这个问题最简单的是文档打开的同时，文档同步客户端便开始下载文档。但是当应用程序试图读取文档的数据时候，可能会读取到尚未下载的部分，应用程序的读取请求就必须等待所读取的部分下载文笔，才能反馈。比如osx下的Finder会随机的读取一个文档，用于预览。因此，本发明将缓存文件划分固定大小的块，比如64K，或者256K。每次应用程序读取无论多少大小，都按照块的大小向文档同步服务器下载数据。当应用程序下载读取已缓存的其他数据时，就会如同本地文件读取那样响应。由于跨越网络的下载请求有一部分延迟是固定大小，不随下载数据量变化。所以选择合适的块大小，便可以优化应用程序读取未下载文档的响应。更进一步地，可采取一些预下载的策略，提前下载一些应用程序读取概率最高的缓存块。

综上所述，本发明的文档同步方法及系统、文档同步客户端通过虚拟磁盘机制拦截所有对文件的访问，能够同步文档下载和应用程序对文档的访问；文档打开的延迟仅受限于网络带宽，极大地提升了用户体验；采用虚拟磁盘方式，使得本地无持久缓存，能够有效地避免缓存文件无限增长；基于虚拟磁盘机制，可以隐藏本地缓存目录，从而增加系统安全性与可靠性；访问大型文档时无需等待整个文档缓存至本地，仅需要缓存部分头文件即可，实现边访问边下载数据。所以，本发明有效克服了现有技术中的种种缺点而具高度产业利用价值。

上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。