CN103210590A

CN103210590A - 压缩方法及设备

Info

Publication number: CN103210590A
Application number: CN2012800027802A
Authority: CN
Inventors: 覃祥菊
Original assignee: Huawei Technologies Co Ltd
Current assignee: XFusion Digital Technologies Co Ltd
Priority date: 2012-08-21
Filing date: 2012-08-21
Publication date: 2013-07-17
Anticipated expiration: 2032-08-21
Also published as: WO2014029081A1; CN103210590B

Abstract

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

Description

压缩方法及设备

技术领域

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

背景技术

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

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

发明内容

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

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

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

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

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

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

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，

所述压缩处理方式包括GZIP压缩技术中的静态霍夫曼编码方式和动态霍夫曼编码方式；

所述非压缩处理方式包括所述GZIP压缩技术中的非压缩编码方式。

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

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

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

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

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

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

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

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

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

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

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

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

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

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

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

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

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

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

图3为本申请另一实施例提供的压缩设备的结构示意图。

具体实施方式

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

另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

在某些情况下，一些文本文件经过LZ77压缩方式和霍夫曼编码方式进行处理之后，压缩效果不明显，甚至处理之后的文件可能比原始的文本文件更大。因此，GZIP压缩技术还可以进一步包括另一部分处理方式即非压缩(Uncompressed或Stored)编码方式，即不进行LZ77压缩和霍夫曼编码，直接对原始的文本文件添加标志位之后，输出。

图1A为本申请一实施例提供的压缩方法的流程示意图，如图1A所示。

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

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

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

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

104、输出所述第一比特流和所述第二比特流，以供所述处理器进行处理。

需要说明的是，101～104的执行主体可以为一硬件设备中的至少两个压缩引擎中的每个压缩引擎。

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

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

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

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

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

具体地，所述第二比特流可以包括3个比特(Bit)的标志位“x00”、m个比特的0、1个字节的长度码(LEN)、1个字节的长度码反码(NLEN)和所述第二部分所包含的数据，如图1C所示。其中，所述第一比特流的长度、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个比特，如图1D所示。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

为使得本申请实施例提供的方法和装置更加清楚，下面将以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个比特，如图1D所示。

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

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

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

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

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

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

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

Claims

1.一种压缩方法，其特征在于，包括：

2.根据权利要求1所述的方法，其特征在于，所述压缩处理方式包括GZIP压缩技术中的静态霍夫曼编码方式和动态霍夫曼编码方式；所述非压缩处理方式包括所述GZIP压缩技术中的非压缩编码方式。

3.根据权利要求2所述的方法，其特征在于，所述压缩处理方式还包括所述GZIP压缩技术中的LZ77压缩方式。

4.根据权利要求1～3任一权利要求所述的方法，其特征在于，所述第二部分包括所述文本文件的结尾的至少一个字节。

5.根据权利要求1～4任一权利要求所述的方法，其特征在于，所述最小数据单位包括字节。

6.一种压缩设备，其特征在于，包括：

7.根据权利要求6所述的设备，其特征在于，所述压缩处理方式包括GZIP压缩技术中的静态霍夫曼编码方式和动态霍夫曼编码方式；所述非压缩处理方式包括所述GZIP压缩技术中的非压缩编码方式。

8.根据权利要求7所述的设备，其特征在于，所述压缩处理方式还包括所述GZIP压缩技术中的LZ77压缩方式。

9.根据权利要求6～8任一权利要求所述的设备，其特征在于，所述第二部分包括所述文本文件的结尾的至少一个字节。

10.根据权利要求6～9任一权利要求所述的设备，其特征在于，所述最小数据单位包括字节。

11.一种压缩设备，其特征在于，包括：

12.根据权利要求11所述的设备，其特征在于，所述压缩处理方式包括GZIP压缩技术中的静态霍夫曼编码方式和动态霍夫曼编码方式；所述非压缩处理方式包括所述GZIP压缩技术中的非压缩编码方式。

13.根据权利要求12所述的设备，其特征在于，所述压缩处理方式还包括所述GZIP压缩技术中的LZ77压缩方式。

14.根据权利要求11～13任一权利要求所述的设备，其特征在于，所述第二部分包括所述文本文件的结尾的至少一个字节。

15.根据权利要求11～14任一权利要求所述的设备，其特征在于，所述最小数据单位包括字节。