技术领域

本申请涉及压缩技术， 尤其涉及一种压缩方法及设备。 背景技术

GZIP压缩技术主要包括两部分处理方式， 一部分处理方式为 LZ77压缩 方式， 另一部分处理方式为霍夫曼（Huffman )编码方式。 其中， LZ77压缩 方式是一种短语式压缩算法， 当一个文本文件中某个字符串之前存在一段与 其完全重复的字符串时，可以利用{重复长度� �二者之间的距离}这种较短的二 元组来代替前者， 以实现数据压缩的目的； 若一个文本文件中某个字符串之 前不存在与其完全重复的字符串时， 则不作处理。 霍夫曼编码方式是一种能 压缩数据的编码方式， 可以基于文本文件中不同的字符出现的频率差 异， 利 用较短的码字来代替出现频率较高的字符， 利用较长的码字来代替出现频率 较低的字符， 以实现数据压缩的目的。 霍夫曼编码方式可以包括静态霍夫曼 ( Fixed Huffman )编码方式和动态霍夫曼 ( Dynamic Huffman )编码方式。 其中， 静态霍夫曼编码方式是按协议规定的固定码表 对字符进行编码， 其压 缩效果有限； 动态霍夫曼编码方式是通过对待压缩的文本文 件中字符的出现 频率进行统计， 根据统计结果生成编码码表， 其压缩效果较为明显， 但需要 消耗资源和时间去统计字符的出现频率和生成 编码码表， 另外输出的比特流 中也需要携带额外的编码码表信息， 增加了输出的数据量。

可以釆用硬件设备实现 GZIP 压缩技术。 比如处理器即中央处理单元 ( Central Processing Unit, CPU )可以对每个压缩引擎输出的比特流进行合 并， 以获得压缩之后的文本文件。 现有技术中， 处理器在对每个压缩引擎输 出的比特流进行合并时， 需要进行移位拼接操作， 才能够获得长度为该处理 器所能够处理的最小数据单位的整数倍的比特 流。 发明内容

本申请的多个方面提供一种压缩方法及设备， 用以节省处理器的处理资 源。

本申请的一方面， 提供一种压缩方法， 包括：

获取待压缩的文本文件， 所述文本文件包括第一部分和第二部分； 利用压缩处理方式和 /或非压缩处理方式， 对所述第一部分进行处理， 以 生成第一比特流；

根据所述第一比特流的长度， 利用非压缩处理方式对所述第二部分进行 处理， 以生成第二比特流， 所述第一比特流的长度与所述第二比特流的长 度 之和为处理器能够处理的最小数据单位的整数 倍；

输出所述第一比特流和所述第二比特流， 以供所述处理器进行处理。 如上所述的方面和任一可能的实现方式， 进一步提供一种实现方式， 所述压缩处理方式包括 GZIP压缩技术中的静态霍夫曼编码方式和动态 霍夫曼编码方式；

所述非压缩处理方式包括所述 GZIP压缩技术中的非压缩编码方式。 如上所述的方面和任一可能的实现方式， 进一步提供一种实现方式， 所述压缩处理方式还包括所述 GZIP压缩技术中的 LZ77压缩方式。

如上所述的方面和任一可能的实现方式， 进一步提供一种实现方式， 所述第二部分包括所述文本文件的结尾的至少 一个字节。

如上所述的方面和任一可能的实现方式， 进一步提供一种实现方式， 所述最 d、数据单位包括字节。

本申请的另一方面， 提供一种压缩设备， 包括：

接收单元， 用于获取待压缩的文本文件， 以及将所述文本文件传输给处 理单元， 所述文本文件包括第一部分和第二部分；

所述处理单元， 用于利用压缩处理方式和 /或非压缩处理方式， 对所述第 一部分进行处理， 以生成第一比特流， 以及将所述第一比特流传输给输出单 元； 以及根据所述第一比特流的长度， 利用非压缩处理方式对所述第二部分 进行处理， 以生成第二比特流， 以及将所述第二比特流传输给所述输出单元， 所述第一比特流的长度与所述第二比特流的长 度之和为处理器能够处理的最 小数据单位的整数倍；

所述输出单元， 用于输出所述第一比特流和所述第二比特流， 以供所述 处理器进行处理。 如上所述的方面和任一可能的实现方式， 进一步提供一种实现方式， 所述压缩处理方式包括 GZIP压缩技术中的静态霍夫曼编码方式和动态 霍夫曼编码方式；

所述非压缩处理方式包括所述 GZIP压缩技术中的非压缩编码方式。 如上所述的方面和任一可能的实现方式， 进一步提供一种实现方式， 所述压缩处理方式还包括所述 GZIP压缩技术中的 LZ77压缩方式。

如上所述的方面和任一可能的实现方式， 进一步提供一种实现方式， 所述第二部分包括所述文本文件的结尾的至少 一个字节。

如上所述的方面和任一可能的实现方式， 进一步提供一种实现方式， 所述最 d、数据单位包括字节。

本申请的另一方面， 提供一种压缩设备， 包括：

接收器， 用于获取待压缩的文本文件， 以及将所述文本文件传输给处理 器， 所述文本文件包括第一部分和第二部分；

所述处理器， 用于利用压缩处理方式和 /或非压缩处理方式， 对所述第一 部分进行处理， 以生成第一比特流， 以及将所述第一比特流传输给发送器； 以及根据所述第一比特流的长度， 利用非压缩处理方式对所述第二部分进行 处理， 以生成第二比特流， 以及将所述第二比特流传输给所述发送器， 所述 第一比特流的长度与所述第二比特流的长度之 和为处理器能够处理的最小数 据单位的整数倍；

所述发送器， 用于输出所述第一比特流和所述第二比特流， 以供所述处 理器进行处理。

如上所述的方面和任一可能的实现方式， 进一步提供一种实现方式， 所述压缩处理方式包括 GZIP压缩技术中的静态霍夫曼编码方式和动态 霍夫曼编码方式；

所述非压缩处理方式包括所述 GZIP压缩技术中的非压缩编码方式。 如上所述的方面和任一可能的实现方式， 进一步提供一种实现方式， 所述压缩处理方式还包括所述 GZIP压缩技术中的 LZ77压缩方式。

如上所述的方面和任一可能的实现方式， 进一步提供一种实现方式， 所述第二部分包括所述文本文件的结尾的至少 一个字节。

如上所述的方面和任一可能的实现方式， 进一步提供一种实现方式， 所述最 d、数据单位包括字节。

由上述技术方案可知， 本申请实施例通过对待压缩的文本文件的第二 部 分釆用非压缩处理方式， 例如， 所述 GZIP 压缩技术中的非压缩 ( Uncompressed或 Stored )编码方式， 进行处理以生成第二比特流， 可以 使得输出的完整的比特流的长度即第一比特流 与第二比特流的长度之和为处 理器能够处理的最小数据单位例如， 字节 （Byte ) 的整数倍， 使得处理器在 对每个压缩引擎输出的比特流进行合并时不再 需要进行移位拼接操作， 从而 节省了处理器的处理资源。 附图说明 为了更清楚地说明本申请实施例或现有技术中 的技术方案， 下面将对实 施例或现有技术描述中所需要使用的附图作一 简单地介绍， 显而易见地， 下 面描述中的附图是本申请的一些实施例， 对于本领域普通技术人员来讲， 在 不付出创造性劳动性的前提下， 还可以根据这些附图获得其他的附图。

图 1 A为本申请一实施例提供的压缩方法的流程示� �图；

图 1 B为图 1A对应的实施例中待压缩的文本文件所包括的� ��一部分和第 二部分所釆用的处理方式的示意图；

图 1 C为图 1A对应的实施例中待压缩的文本文件中所包括� ��第二部分经 过处理之后的数据流示意图；

图 1 D为图 1A对应的实施例中待压缩的文本文件中所包括� ��第一部分和 第二部分经过处理之后的数据流示意图；

图 2为本申请另一实施例提供的压缩设备的结构� �意图；

图 3为本申请另一实施例提供的压缩设备的结构� �意图。 具体实施方式 为使本申请实施例的目的、 技术方案和优点更加清楚， 下面将结合本申 请实施例中的附图， 对本申请实施例中的技术方案进行清楚、 完整地描述， 显然， 所描述的实施例是本申请一部分实施例， 而不是全部的实施例。 基于 本申请中的实施例， 本领域普通技术人员在没有作出创造性劳动前 提下所获 得的所有其他实施例， 都属于本申请保护的范围。

另外， 本文中术语"和 /或"， 仅仅是一种描述关联对象的关联关系， 表示 可以存在三种关系， 例如， A和 /或 B, 可以表示： 单独存在 A , 同时存在 A 和 B, 单独存在 B这三种情况。 另外， 本文中字符' 7", —般表示前后关联对 象是一种"或"的关系。 在某些情况下， 一些文本文件经过 LZ77压缩方式和霍夫曼编码方式进 行处理之后， 压缩效果不明显， 甚至处理之后的文件可能比原始的文本文件 更大。 因此， GZIP 压缩技术还可以进一步包括另一部分处理方式 即非压缩 ( Uncompressed或 Stored )编码方式， 即不进行 LZ77压缩和霍夫曼编码， 直接对原始的文本文件添加标志位之后， 输出。 图 1A为本申请一实施例提供的压缩方法的流程示� ��图， 如图 1A所示。

101、 获取待压缩的文本文件， 所述文本文件包括第一部分和第二部分。

102、 利用压缩处理方式和 /或非压缩处理方式， 对所述第一部分进行处 理， 以生成第一比特流。

选择哪一种处理方式对第一部分进行处理， 具体可以根据预先设置的处 理策略进行选择， 例如， 可以选择压缩率最高的处理方式处理。

103、根据所述第一比特流的长度，利用非压缩 处理方式对所述第二部分 进行处理， 以生成第二比特流， 所述第一比特流的长度与所述第二比特流的 长度之和为处理器能够处理的最小数据单位的 整数倍。

104、输出所述第一比特流和所述第二比特流， 以供所述处理器进行处理。 需要说明的是， 101~104的执行主体可以为一硬件设备中的至少� �个压 缩引擎中的每个压缩引擎。

需要说明的是， 每个压缩引擎所获取的待压缩的文本文件， 可以为处理 器根据每个压缩引擎的处理能力， 对原始文本文件进行分割获得的。 原始文 本文件和待压缩的文本文件均是以处理器能够 处理的最小数据单位例如， 字 节 （Byte ) 为单位的。

可选的， 本实施例的一个可能的实现方式中， 所述压缩处理方式可以包 括 GZIP压缩技术中的静态霍夫曼（Fixed Huffman )编码方式和动态霍夫曼 ( Dynamic Huffman )编码方式； 所述非压缩处理方式可以包括所述 GZIP 压缩技术中的非压缩（ Uncompressed或 Stored )编码方式， 如图 1 B所示。 其中，所述 GZIP压缩技术中的静态霍夫曼（Fixed Huffman )编码方式、 动态霍夫曼 ( Dynamic Huffman ) 编码方式， 以及非压缩 ( Uncompressed 或 Stored )编码方式的详细描述具体可以参见现有技术� �的相关内容， 此处 不再赘述。

可选的， 本实施例的一个可能的实现方式中， 所述压缩处理方式还可以 进一步包括所述 GZIP压缩技术中的 LZ77压缩方式。 具体地， 可以先利用 LZ77压缩方式，对所述第一部分进行处理， 然后，再利用静态霍夫曼（Fixed Huffman )编码方式或动态霍夫曼（Dynamic Huffman )编码方式， 对经过 LZ77压缩方式处理的所述第一部分进行处理。

可选的， 本实施例的一个可能的实现方式中， 所述第二部分可以包括所 述文本文件的结尾的至少一个字节。

具体地， 所述第二比特流可以包括 3个比特（Bit )的标志位 "xOO" 、 m 个比特的 0、 1个字节的长度码（LEN ) 、 1个字节的长度码反码 ( NLEN ) 和所述第二部分所包含的数据， 如图 1 C所示。 其中， 所述第一比特流的长 度、 3个比特、 m个比特、 1个字节、 1个字节和所述第二部分所包含的数据 的长度之和为处理器能够处理的最小数据单位 例如， 字节（Byte )的整数倍。 其中， 若所述第二部分为所述待压缩的文本文件的最 后一个数据块， 则 X取 值为 "1 " ； 若所述第二部分不为所述待压缩的文本文件的 最后一个数据块， 则 X取值为 "0" 。 其中， 所述待压缩的文本文件可以被分成若干个数据 块 ( block ) , 作为静态霍夫曼 （ Fixed Huffman ) 编码方式或动态霍夫曼 ( Dynamic Huffman )编码方式的基本单位， 每个数据块大小通常为 4k~32k 字节。

为使得本申请实施例提供的方法更加清楚， 下面将以 100个字节的待压 缩的文本文件作为举例。 其中， 该 100个字节的待压缩的文本文件可以包括 第一部分即前面的 96个字节和第二部分即后面的 4个字节。假设所述第一部 分所包含的数据， 经过压缩处理方式和 /或非压缩处理方式进行处理之后， 生 成的第一比特流的长度为 207个比特。 所述第一比特流、 3个比特的标志位 "100" 、 1个字节的 LEN、 1个字节的 NLEN和所述第二部分所包含的数据 的长度之和为 （207+3+8+8+32 )个比特， 即 258个比特。 此时， 258个比 特以 8个比特为一组划分之后， 余下 2个比特， 因此， 为了使得所述第一比 特流的长度、 3个比特、 m个比特、 1个字节、 1个字节和所述第二部分所包 含的数据的长度之和为字节的整数倍， 可以得到 m的取值为 6个比特， 如图 1 D所示。

本实施例中， 通过对待压缩的文本文件的最后一个部分（即 第二部分） 釆用非压缩处理方式，例如，所述 GZIP压缩技术中的非压缩（ Uncompressed 或 Stored )编码方式， 进行处理以生成第二比特流， 可以使得输出的完整的 比特流的长度即第一比特流与第二比特流的长 度之和为处理器能够处理的最 小数据单位例如， 字节 （Byte ) 的整数倍， 使得处理器在对每个压缩引擎输 出的比特流进行合并时不再需要进行移位拼接 操作， 从而节省了处理器的处 理资源。

需要说明的是， 对于前述的各方法实施例， 为了简单描述， 故将其都表 述为一系列的动作组合， 但是本领域技术人员应该知悉， 本申请并不受所描 述的动作顺序的限制， 因为依据本申请， 某些步骤可以釆用其他顺序或者同 时进行。 其次， 本领域技术人员也应该知悉， 说明书中所描述的实施例均属 于优选实施例， 所涉及的动作和模块并不一定是本申请所必须 的。

在上述实施例中， 对各个实施例的描述都各有侧重， 某个实施例中没有 详述的部分， 可以参见其他实施例的相关描述。

图 2为本申请另一实施例提供的压缩设备的结构� �意图， 如图 2所示， 本实施例的压缩设备可以包括接收单元 21、 处理单元 22和输出单元 23。 其 中， 接收单元 21 , 用于获取待压缩的文本文件， 以及将所述文本文件传输给 处理单元 22, 所述文本文件包括第一部分和第二部分； 所述处理单元 22, 用于利用压缩处理方式和 /或非压缩处理方式， 对所述第一部分进行处理， 以 生成第一比特流， 以及将所述第一比特流传输给输出单元 23; 以及根据所述 第一比特流的长度， 利用非压缩处理方式对所述第二部分进行处理 ， 以生成 第二比特流， 以及将所述第二比特流传输给所述输出单元 23, 所述第一比特 流的长度与所述第二比特流的长度之和为处理 器能够处理的最小数据单位的 整数倍； 所述输出单元 23, 用于输出所述第一比特流和所述第二比特流， 以 供所述处理器进行处理。

需要说明的是， 本实施例提供的压缩设备可以为一硬件设备中 的至少两 个压缩引擎中的任一压缩引擎。

需要说明的是，接收单元 21所获取的待压缩的文本文件， 可以为处理器 根据每个压缩引擎的处理能力， 对原始文本文件进行分割获得的。 原始文本 文件和待压缩的文本文件均是以处理器能够处 理的最小数据单位例如， 字节 ( Byte ) 为单位的。

可选的， 本实施例的一个可能的实现方式中， 所述压缩处理方式可以包 括 GZIP压缩技术中的静态霍夫曼（Fixed Huffman )编码方式和动态霍夫曼 ( Dynamic Huffman )编码方式； 所述非压缩处理方式可以包括所述 GZIP 压缩技术中的非压缩（ Uncompressed或 Stored )编码方式， 如图 1 B所示。

其中，所述 GZIP压缩技术中的静态霍夫曼（Fixed Huffman )编码方式、 动态霍夫曼 ( Dynamic Huffman ) 编码方式， 以及非压缩 ( Uncompressed 或 Stored )编码方式， 的详细描述具体可以参见现有技术中的相关内 容， 此 处不再赘述。

可选的， 本实施例的一个可能的实现方式中， 所述压缩处理方式还可以 进一步包括所述 GZIP压缩技术中的 LZ77压缩方式。 具体地， 处理单元 22 可以先利用 LZ77压缩方式， 对所述第一部分进行处理， 然后， 再利用静态 霍夫曼（ Fixed Huffman )编码方式或动态霍夫曼（ Dynamic Huffman )编码 方式， 对经过 LZ77压缩方式处理的所述第一部分进行处理。

可选的， 本实施例的一个可能的实现方式中， 所述第二部分可以包括所 述文本文件的结尾的至少一个字节。

具体地， 所述第二比特流可以包括 3个比特的标志位 "xOO" 、 m个比 特的 0、 1个字节的长度码（LEN ) 、 1个字节的长度码反码 ( NLEN )和所 述第二部分所包含的数据， 如图 1 C所示。 其中， 所述第一比特流的长度、 3 个比特、 m个比特、 1个字节、 1个字节和所述第二部分所包含的数据的长度 之和为处理器能够处理的最小数据单位例如， 字节（Byte )的整数倍。 其中， 若所述第二部分为所述待压缩的文本文件的最 后一个数据块， 则 X取值为 "1 " ； 若所述第二部分不为所述待压缩的文本文件的 最后一个数据块， 则 X 取值为 "0" 。

为使得本申请实施例提供的方法更加清楚， 下面将以 100个字节的待压 缩的文本文件作为举例。 其中， 该 100个字节的待压缩的文本文件可以包括 第一部分即前面的 96个字节和第二部分即后面的 4个字节。假设所述第一部 分所包含的数据， 经过压缩处理方式和 /或非压缩处理方式进行处理之后， 生 成的第一比特流的长度为 207个比特。 所述第一比特流、 3个比特的标志位 "100" 、 1个字节的 LEN、 1个字节的 NLEN和所述第二部分所包含的数据 的长度之和为 （207+3+8+8+32 )个比特， 即 258个比特。 此时， 258个比 特以 8个比特为一组划分之后， 余下 2个比特， 因此， 为了使得所述第一比 特流的长度、 3个比特、 m个比特、 1个字节、 1个字节和所述第二部分所包 含的数据的长度之和为字节的整数倍， 可以得到 m的取值为 6个比特， 如图 1 D所示。

本实施例提供的压缩设备用于对应执行如图 1A所示实施例的方法， 对 于图 1A所示实施例已经描述的细节， 此处不再赘述。

本实施例中， 通过处理单元对待压缩的文本文件的最后一个 部分（即第 二部分） 釆用非压缩处理方式， 例如， 所述 GZIP 压缩技术中的非压缩 ( Uncompressed或 Stored )编码方式， 进行处理以生成第二比特流， 可以 使得输出单元输出的完整的比特流的长度即第 一比特流与第二比特流的长度 之和为处理器能够处理的最小数据单位例如， 字节 （Byte ) 的整数倍， 使得 处理器在对每个压缩引擎输出的比特流进行合 并时不再需要进行移位拼接操 作， 从而节省了处理器的处理资源。

图 3为本申请另一实施例提供的压缩设备的结构� �意图， 如图 3所示， 本实施例的压缩设备可以包括接收器 31、 处理器 32和发送器 33。 其中， 接 收器 31 ,用于获取待压缩的文本文件，以及将所述文� �文件传输给处理器 32, 所述文本文件包括第一部分和第二部分； 所述处理器 32, 用于利用压缩处理 方式和 /或非压缩处理方式， 对所述第一部分进行处理， 以生成第一比特流， 以及将所述第一比特流传输给发送器 33; 以及根据所述第一比特流的长度， 利用非压缩处理方式对所述第二部分进行处理 ， 以生成第二比特流， 以及将 所述第二比特流传输给所述发送器 33, 所述第一比特流的长度与所述第二比 特流的长度之和为处理器能够处理的最小数据 单位的整数倍； 所述发送器 33, 用于输出所述第一比特流和所述第二比特流， 以供所述处理器进行处理。

需要说明的是， 本实施例提供的压缩设备可以为一硬件设备中 的至少两 个压缩引擎中的任一压缩引擎。 需要说明的是，接收器 31所获取的待压缩的文本文件，可以为处理器� �� 据每个压缩引擎的处理能力， 对原始文本文件进行分割获得的。 原始文本文 件和待压缩的文本文件均是以处理器能够处理 的最小数据单位例如， 字节 ( Byte ) 为单位的。

可选的， 本实施例的一个可能的实现方式中， 所述压缩处理方式可以包 括 GZIP压缩技术中的静态霍夫曼（Fixed Huffman )编码方式和动态霍夫曼 ( Dynamic Huffman )编码方式； 所述非压缩处理方式可以包括所述 GZIP 压缩技术中的非压缩（ Uncompressed或 Stored )编码方式， 如图 1 B所示。

其中，所述 GZIP压缩技术中的静态霍夫曼（Fixed Huffman )编码方式、 动态霍夫曼（Dynamic Huffman ) 编码方式， 以及非压缩 （Uncompressed 或 Stored )编码方式， 的详细描述具体可以参见现有技术中的相关内 容， 此 处不再赘述。

可选的， 本实施例的一个可能的实现方式中， 所述压缩处理方式还可以 进一步包括所述 GZIP压缩技术中的 LZ77压缩方式。 具体地， 处理器 32可 以先利用 LZ77压缩方式， 对所述第一部分进行处理， 然后， 再利用静态霍 夫曼 ( Fixed Huffman )编码方式或动态霍夫曼 ( Dynamic Huffman )编码方 式， 对经过 LZ77压缩方式处理的所述第一部分进行处理。

可选的， 本实施例的一个可能的实现方式中， 所述第二部分可以包括所 述文本文件的结尾的至少一个字节。

具体地， 所述第二比特流可以包括 3个比特的标志位 "xOO" 、 m个比 特的 0、 1个字节的长度码（LEN ) 、 1个字节的长度码反码 ( NLEN )和所 述第二部分所包含的数据， 如图 1 C所示。 其中， 所述第一比特流的长度、 3 个比特、 m个比特、 1个字节、 1个字节和所述第二部分所包含的数据的长度 之和为处理器能够处理的最小数据单位例如， 字节（Byte )的整数倍。 其中， 若所述第二部分为所述待压缩的文本文件的最 后一个数据块， 则 X取值为 "1 " ； 若所述第二部分不为所述待压缩的文本文件的 最后一个数据块， 则 X 取值为 "0" 。

为使得本申请实施例提供的方法和装置更加清 楚， 下面将以 100个字节 的待压缩的文本文件作为举例。 其中， 该 100个字节的待压缩的文本文件可 以包括第一部分即前面的 96个字节和第二部分即后面的 4个字节。假设所述 第一部分所包含的数据， 经过压缩处理方式和 /或非压缩处理方式进行处理之 后， 生成的第一比特流的长度为 207个比特。 所述第一比特流、 3个比特的 标志位 "100" 、 1个字节的 LEN、 1个字节的 NLEN和所述第二部分所包含 的数据的长度之和为（207+3+8+8+32 )个比特， 即 258个比特。 此时， 258 个比特以 8个比特为一组划分之后， 余下 2个比特， 因此， 为了使得所述第 一比特流的长度、 3个比特、 m个比特、 1个字节、 1个字节和所述第二部分 所包含的数据的长度之和为字节的整数倍， 可以得到 m的取值为 6个比特， 如图 1 D所示。

本实施例提供的压缩设备用于对应执行如图 1A所示实施例的方法， 对 于图 1A所示实施例已经描述的细节， 此处不再赘述。

本实施例中， 通过处理器对待压缩的文本文件的最后一个部 分（即第二 部分） 釆用非压缩处理方式， 例如， 所述 GZIP 压缩技术中的非压缩 ( Uncompressed或 Stored )编码方式， 进行处理以生成第二比特流， 可以 使得发送器输出的完整的比特流的长度即第一 比特流与第二比特流的长度之 和为处理器能够处理的最小数据单位例如， 字节 （Byte ) 的整数倍， 使得处 理器在对每个压缩引擎输出的比特流进行合并 时不再需要进行移位拼接操 作， 从而节省了处理器的处理资源。

所属领域的技术人员可以清楚地了解到， 为描述的方便和简洁， 上述描 述的系统， 装置和单元的具体工作过程， 可以参考前述方法实施例中的对应 过程， 在此不再赘述。

在本申请所提供的几个实施例中， 应该理解到， 所揭露的系统， 装置和 方法， 可以通过其它的方式实现。 例如， 以上所描述的装置实施例仅仅是示 意性的， 例如， 所述单元的划分， 仅仅为一种逻辑功能划分， 实际实现时可 以有另外的划分方式， 例如多个单元或组件可以结合或者可以集成到 另一个 系统， 或一些特征可以忽略， 或不执行。 另一点， 所显示或讨论的相互之间 的耦合或直接耦合或通信连接可以是通过一些 接口， 装置或单元的间接耦合 或通信连接， 可以是电性， 机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可 以不是物理上分开的， 作 为单元显示的部件可以是或者也可以不是物理 单元， 即可以位于一个地方， 或者也可以分布到多个网络单元上。 可以根据实际的需要选择其中的部分或 者全部单元来实现本实施例方案的目的。

另夕卜，在本申请各个实施例中的各功能单元 可以集成在一个处理单元中， 也可以是各个单元单独物理存在， 也可以两个或两个以上单元集成在一个单 元中。 上述集成的单元既可以釆用硬件的形式实现， 也可以釆用硬件加软件 功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元 ， 可以存储在一个计算机 可读取存储介质中。 上述软件功能单元存储在一个存储介质中， 包括若干指 令用以使得一台计算机设备（可以是个人计算 机， 服务器， 或者网络设备等） 或处理器（processor )执行本申请各个实施例所述方法的部分步骤� � 而前述 的存储介质包括： U盘、移动硬盘、只读存储器（ Read-Only Memory, ROM ) , 随机存取存储器（ Random Access Memory, RAM ) 、 磁碟或者光盘等各种 可以存储程序代码的介质。

最后应说明的是： 以上实施例仅用以说明本申请的技术方案， 而非对其 限制； 尽管参照前述实施例对本申请进行了详细的说 明， 本领域的普通技术 人员应当理解： 其依然可以对前述各实施例所记载的技术方案 进行修改， 或 者对其中部分技术特征进行等同替换； 而这些修改或者替换， 并不使相应技 术方案的本质脱离本申请各实施例技术方案的 精神和范围。