JP2863065B2 - マッチングストリング探索およびハフマン符号化を用いたデータ圧縮装置および方法ならびにデータ伸長装置および方法 - Google Patents
マッチングストリング探索およびハフマン符号化を用いたデータ圧縮装置および方法ならびにデータ伸長装置および方法Info
- Publication number
- JP2863065B2 JP2863065B2 JP5198670A JP19867093A JP2863065B2 JP 2863065 B2 JP2863065 B2 JP 2863065B2 JP 5198670 A JP5198670 A JP 5198670A JP 19867093 A JP19867093 A JP 19867093A JP 2863065 B2 JP2863065 B2 JP 2863065B2
- Authority
- JP
- Japan
- Prior art keywords
- code
- length
- string
- bin
- offset
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T9/00—Image coding
- G06T9/005—Statistical coding, e.g. Huffman, run length coding
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
- H03M7/3084—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method
- H03M7/3086—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method employing a sliding window, e.g. LZ77
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
- H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
- H03M7/42—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code using table look-up for the coding or decoding process, e.g. using read-only memory
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
- H03M7/46—Conversion to or from run-length codes, i.e. by representing the number of consecutive digits, or groups of digits, of the same kind by a code word and a digit indicative of that kind
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Multimedia (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
Description
【０００１】
【産業上の利用分野】本発明は、一般的にはデータ格納
及び伝送システムに関し、詳細には、データ格納及び伝
送の能力を改善する、データ圧縮システム及び方法に関
する。
及び伝送システムに関し、詳細には、データ格納及び伝
送の能力を改善する、データ圧縮システム及び方法に関
する。
【０００２】
【従来の技術】データ格納システムとデータ伝送システ
ムとの間のデータ圧縮の重要でない違いによって、デー
タ格納システムのみが、特に、このようなシステムに格
納されたデータファイルに言及される。しかし、全ての
データ格納システムは、データ伝送システム及び他のア
プリケーションをカバーするように、容易に拡張され得
る。ファイルはバイト又はキャラクタの連続するストリ
ームであると考えられ、そこではバイトは幾つかの固定
された数のビットから成り、圧縮システムはこの入力バ
イトのストリームを、「圧縮された」バイトの出力スト
リームに変換し、これから伸張ユニットによって、オリ
ジナルファイルの内容が再構築され得る。
ムとの間のデータ圧縮の重要でない違いによって、デー
タ格納システムのみが、特に、このようなシステムに格
納されたデータファイルに言及される。しかし、全ての
データ格納システムは、データ伝送システム及び他のア
プリケーションをカバーするように、容易に拡張され得
る。ファイルはバイト又はキャラクタの連続するストリ
ームであると考えられ、そこではバイトは幾つかの固定
された数のビットから成り、圧縮システムはこの入力バ
イトのストリームを、「圧縮された」バイトの出力スト
リームに変換し、これから伸張ユニットによって、オリ
ジナルファイルの内容が再構築され得る。
【０００３】コンピュータデータファイルが典型的に膨
大な量の冗長性を含むということは、定着している。こ
れらのファイルがディスク又はテープ記憶媒体上でより
小さいスペースを占めるように、又は１２００ボーのモ
デムラインのような伝送チャネルに於いてより短い時間
で移送され得るように、これらのファイルを「圧縮」す
るために多くの技術が長年用いられてきた。例えば、パ
ーソナルコンピュータに使用される幾つかの広く用いら
れている市販のプログラムがある（例えば、Systems En
hancement Associates, Inc., Wayne, NJ, 1985のＡＲ
Ｃソフトウェア）。このプログラムはファイル上で圧縮
及び伸張の機能を果たす。減少量はファイルの内容に大
きく依存して変化するが、このようなプログラムにとっ
て、与えられたファイルの大きさを２：１の比（又はそ
れ以上）に減少させることは一般的ではない。
大な量の冗長性を含むということは、定着している。こ
れらのファイルがディスク又はテープ記憶媒体上でより
小さいスペースを占めるように、又は１２００ボーのモ
デムラインのような伝送チャネルに於いてより短い時間
で移送され得るように、これらのファイルを「圧縮」す
るために多くの技術が長年用いられてきた。例えば、パ
ーソナルコンピュータに使用される幾つかの広く用いら
れている市販のプログラムがある（例えば、Systems En
hancement Associates, Inc., Wayne, NJ, 1985のＡＲ
Ｃソフトウェア）。このプログラムはファイル上で圧縮
及び伸張の機能を果たす。減少量はファイルの内容に大
きく依存して変化するが、このようなプログラムにとっ
て、与えられたファイルの大きさを２：１の比（又はそ
れ以上）に減少させることは一般的ではない。
【０００４】データ圧縮のための従来技術における多く
のアプローチがなされている。これらのアプローチの幾
つかは、ファイル又はファイル内のデータの一定のタイ
プについて、暗黙の前提を作り出している。例えば、ス
キャナを用いて生成されたページのビットイメージは、
殆どが空白の画素であり、この傾向は、このようなファ
イルの大きさを大きく減少させる圧縮アルゴリズムによ
って利用される。同様に、ワードプロセッシングファイ
ルは、関係する言語（即ち、英語）に最もよく現れるキ
ャラクタ（又はワード）の知識を用いて容易に圧縮され
る、多くのアスキーキャラクタを含んでいる。他の圧縮
方法はファイルのタイプから独立しており、そのデータ
に「適応」するようにされている。一般に、特定のタイ
プ用の圧縮技術は、その技術が最適化されるファイル上
では、一般用のアルゴリズムよりも高い圧縮性能を供給
する。しかし、もしファイルモデルが正しくないと、そ
れらは非常に低い圧縮性能を有する傾向にある。例え
ば、英語のテキストに最適化された圧縮方法は、フラン
ス語のテキストを含むファイル上では、不完全にしか機
能しないかも知れない。
のアプローチがなされている。これらのアプローチの幾
つかは、ファイル又はファイル内のデータの一定のタイ
プについて、暗黙の前提を作り出している。例えば、ス
キャナを用いて生成されたページのビットイメージは、
殆どが空白の画素であり、この傾向は、このようなファ
イルの大きさを大きく減少させる圧縮アルゴリズムによ
って利用される。同様に、ワードプロセッシングファイ
ルは、関係する言語（即ち、英語）に最もよく現れるキ
ャラクタ（又はワード）の知識を用いて容易に圧縮され
る、多くのアスキーキャラクタを含んでいる。他の圧縮
方法はファイルのタイプから独立しており、そのデータ
に「適応」するようにされている。一般に、特定のタイ
プ用の圧縮技術は、その技術が最適化されるファイル上
では、一般用のアルゴリズムよりも高い圧縮性能を供給
する。しかし、もしファイルモデルが正しくないと、そ
れらは非常に低い圧縮性能を有する傾向にある。例え
ば、英語のテキストに最適化された圧縮方法は、フラン
ス語のテキストを含むファイル上では、不完全にしか機
能しないかも知れない。
【０００５】典型的には、格納システムはどんなタイプ
のデータがその中に格納されているかを知らない。従っ
て、特定のデータ用の圧縮技術は避けられ、又はそれら
は可能な技術の集合の一つとして用いられるのみであ
る。例えば、ＡＲＣは多くの方法を用い、そして各ファ
イルに最適のそれを選択する。しかし、このアプローチ
は単一の圧縮方法を用いるのに比べて、非常なコンピュ
ータのオーバーヘッドを必要とする。
のデータがその中に格納されているかを知らない。従っ
て、特定のデータ用の圧縮技術は避けられ、又はそれら
は可能な技術の集合の一つとして用いられるのみであ
る。例えば、ＡＲＣは多くの方法を用い、そして各ファ
イルに最適のそれを選択する。しかし、このアプローチ
は単一の圧縮方法を用いるのに比べて、非常なコンピュ
ータのオーバーヘッドを必要とする。
【０００６】圧縮方法の他の重要な見地は、ファイルが
処理される速度である。もし圧縮（又は伸張）の速度が
非常に遅く、システムの性能を著しく低下させる場合に
は、たとえそれが競合する方法よりも高い圧縮比を達成
し得ても、その圧縮方法は受け入れられない。例えば、
ストリームテープシステムでは、もしテープ駆動に必要
な速度でデータを供給するのに十分速くファイルが圧縮
されなければ、テープは流れの速度を落し、圧縮による
性能及び／又は容量利得は無駄になる。
処理される速度である。もし圧縮（又は伸張）の速度が
非常に遅く、システムの性能を著しく低下させる場合に
は、たとえそれが競合する方法よりも高い圧縮比を達成
し得ても、その圧縮方法は受け入れられない。例えば、
ストリームテープシステムでは、もしテープ駆動に必要
な速度でデータを供給するのに十分速くファイルが圧縮
されなければ、テープは流れの速度を落し、圧縮による
性能及び／又は容量利得は無駄になる。
【０００７】最も一般的な圧縮技術の一つは、ランレン
グスコード化として知られている。このアプローチは、
ゼロ又はスペースキャラクタのような同じバイト（キャ
ラクタ）が繰り返されたストリングを、ファイルがしば
しば有しているという事実を利用している。このような
ストリングは「エスケープ」キャラクタを用いてコード
化され、繰り返し数、繰り返されるキャラクタが続く。
ランの形式で現れなかった他の全てのキャラクタは、そ
れらを「普通テキスト」として出力ストリームに置くこ
とによってコード化される。エスケープキャラクタは滅
多に使用しないバイトとなるように選ばれ、入力ストリ
ームにおけるその出現は、キャラクタとしてのエスケー
プキャラクタそれ自身を有する長さ１のランとしてコー
ド化される。ランレングスコード化はあるタイプのファ
イル上ではよく機能するが、もしファイルが繰り返しの
キャラクタを有していなければ（又はファイルにエスケ
ープキャラクタがしばしば出現すれば）、低い圧縮比率
しか有し得ない。従って、一般に、エスケープキャラク
タの選択は、データ上で最も使用の少ないバイトを捜す
という余分な経路を必要とし、このようなシステムの効
率を低下させる。
グスコード化として知られている。このアプローチは、
ゼロ又はスペースキャラクタのような同じバイト（キャ
ラクタ）が繰り返されたストリングを、ファイルがしば
しば有しているという事実を利用している。このような
ストリングは「エスケープ」キャラクタを用いてコード
化され、繰り返し数、繰り返されるキャラクタが続く。
ランの形式で現れなかった他の全てのキャラクタは、そ
れらを「普通テキスト」として出力ストリームに置くこ
とによってコード化される。エスケープキャラクタは滅
多に使用しないバイトとなるように選ばれ、入力ストリ
ームにおけるその出現は、キャラクタとしてのエスケー
プキャラクタそれ自身を有する長さ１のランとしてコー
ド化される。ランレングスコード化はあるタイプのファ
イル上ではよく機能するが、もしファイルが繰り返しの
キャラクタを有していなければ（又はファイルにエスケ
ープキャラクタがしばしば出現すれば）、低い圧縮比率
しか有し得ない。従って、一般に、エスケープキャラク
タの選択は、データ上で最も使用の少ないバイトを捜す
という余分な経路を必要とし、このようなシステムの効
率を低下させる。
【０００８】最も洗練されたアプローチは、ハフマンコ
ードとして知られている（Huffman,David A., "A Metho
d for the Construction of Minimum Redundancy Code
s",Proceedings of the IRE, pp. 1098-1110, Septembe
r 1952を参照せよ）。この方法では、あるバイトはファ
イル内で他のバイトよりしばしば多く現れると仮定され
る。例えば英語のテキストでは、文字「ｔ」又は「Ｔ」
は文字「Ｑ」より多く存在する。各バイトはビットスト
リングに割り当てられ、その長さは、逆にファイル内に
おけるそのバイトの相対的な頻度に関係する。これらの
ビットストリングは、もし１ビットがある時に処理され
ると、唯一の結果しか生じないようにデコードされるよ
うに選択される。ハフマンはファイルに対する相対的頻
度の統計に基づく、ビットストリングの最適割当てのた
めのアルゴリズムを導いている。
ードとして知られている（Huffman,David A., "A Metho
d for the Construction of Minimum Redundancy Code
s",Proceedings of the IRE, pp. 1098-1110, Septembe
r 1952を参照せよ）。この方法では、あるバイトはファ
イル内で他のバイトよりしばしば多く現れると仮定され
る。例えば英語のテキストでは、文字「ｔ」又は「Ｔ」
は文字「Ｑ」より多く存在する。各バイトはビットスト
リングに割り当てられ、その長さは、逆にファイル内に
おけるそのバイトの相対的な頻度に関係する。これらの
ビットストリングは、もし１ビットがある時に処理され
ると、唯一の結果しか生じないようにデコードされるよ
うに選択される。ハフマンはファイルに対する相対的頻
度の統計に基づく、ビットストリングの最適割当てのた
めのアルゴリズムを導いている。
【０００９】ハフマンアルゴリズムは、達成される圧縮
が漸近的にファイルの「エントロピー」に近づくことを
保証し、それは以下のように正確に定義される。
が漸近的にファイルの「エントロピー」に近づくことを
保証し、それは以下のように正確に定義される。
【００１０】 Ｈ＝ＳＵＭ−［ｐ（ｉ）ｌｏｇ2（ｐ（ｉ））］ ここで、 ｐ（ｉ）＝ファイル内のキャラクタｉの確率 ＝（ｉの出現数）／（ファイル内のキャラクタの総数） Ｈの単位はビットであり、それはファイル内のキャラク
タを表現するのに（平均して）どれだけのビットが必要
であるかを測定する。例えば、もしエントロピーが８ビ
ットバイトを用いて４．０ビットであれば、ハフマン圧
縮システムはファイル上で２：１の圧縮をなし得る。エ
ントロピーが高いほど、データはより「乱雑」（従っ
て、あまり圧縮できない）である。
タを表現するのに（平均して）どれだけのビットが必要
であるかを測定する。例えば、もしエントロピーが８ビ
ットバイトを用いて４．０ビットであれば、ハフマン圧
縮システムはファイル上で２：１の圧縮をなし得る。エ
ントロピーが高いほど、データはより「乱雑」（従っ
て、あまり圧縮できない）である。
【００１１】ハフマンのコード化は多くのタイプのファ
イル上で非常によく機能する。しかし、ビットストリン
グのバイトへの割当ては、多くの実際的な困難を伴う。
例えば、予め設定されたコード化スキームが用いられる
場合（例えば、英語における文字の出現の頻度に基づい
て）、もしその予め設定されたスキームが、ファイル内
の実際に存在するものとかなり異なる頻度統計であると
仮定すると、ハフマンのコード化はファイルを大きく拡
張するかもしれない。これに加えて、ファイルの内容に
基づくコード化スキームの演算は、ハフマンアルゴリズ
ムを頻度統計に適応するのと同様に、データ上での２つ
のパスを必要とするのみならず（従って、システムの効
率を低下させる）、コード化テーブルがデータに沿って
格納されるということが必要とされ、これは圧縮率の上
での否定的な衝撃を有する。更に、バイトの相対的頻度
は、ファイル内で動的に容易に変えられ得る。そのた
め、どの点でも特定のコード化割当てはうまく機能しな
い。
イル上で非常によく機能する。しかし、ビットストリン
グのバイトへの割当ては、多くの実際的な困難を伴う。
例えば、予め設定されたコード化スキームが用いられる
場合（例えば、英語における文字の出現の頻度に基づい
て）、もしその予め設定されたスキームが、ファイル内
の実際に存在するものとかなり異なる頻度統計であると
仮定すると、ハフマンのコード化はファイルを大きく拡
張するかもしれない。これに加えて、ファイルの内容に
基づくコード化スキームの演算は、ハフマンアルゴリズ
ムを頻度統計に適応するのと同様に、データ上での２つ
のパスを必要とするのみならず（従って、システムの効
率を低下させる）、コード化テーブルがデータに沿って
格納されるということが必要とされ、これは圧縮率の上
での否定的な衝撃を有する。更に、バイトの相対的頻度
は、ファイル内で動的に容易に変えられ得る。そのた
め、どの点でも特定のコード化割当てはうまく機能しな
い。
【００１２】ハフマンアプローチの多くの変形があり
（例えば、Jones, Douglas W., "Application of Splay
Trees to Data Compression", Communications of the
ACM,pp. 996-1007, Vol. 31, No. 8, August 1988）、
通常、それらは処理された入力バイトの最新の履歴に基
づいた、動的コード割当てを含んでいる。このようなス
キームは上で議論した問題点を回避する。他のアプロー
チは同時に２バイトワード（バイグラム（bi-gram））
を見ることを含み、ハフマンのコード化をそのワード上
で行う。
（例えば、Jones, Douglas W., "Application of Splay
Trees to Data Compression", Communications of the
ACM,pp. 996-1007, Vol. 31, No. 8, August 1988）、
通常、それらは処理された入力バイトの最新の履歴に基
づいた、動的コード割当てを含んでいる。このようなス
キームは上で議論した問題点を回避する。他のアプロー
チは同時に２バイトワード（バイグラム（bi-gram））
を見ることを含み、ハフマンのコード化をそのワード上
で行う。
【００１３】近年のハフマンのコード化の変形は、MacC
riskenの米国特許第4,730,348号（及びその中で参照さ
れている他の特許）に現れている。MacCriskenの米国特
許では、ハフマンコードは先のバイトのコンテキストに
おけるバイトに割り当てられる。言い換えれば、複数の
コード化テーブルが用いられ、各テーブルは先のバイト
に従って選択される。このアプローチは、例えば、英語
では文字「ｕ」は頻繁には現れないが、「ｑ」の後には
殆ど常に現れるという観察に基づいている。従って、
「ｕ」に割り当てられるコードは、先の文字が「ｑ」
（又は「Ｑ」）であるかどうかに依存して異なるであろ
う。多数のテーブルと動的コード割当てとを用いる同様
のスキームについては、Jones, Douglas W., "Applicat
ion of SplayTrees to Data Compression"を参照された
い。
riskenの米国特許第4,730,348号（及びその中で参照さ
れている他の特許）に現れている。MacCriskenの米国特
許では、ハフマンコードは先のバイトのコンテキストに
おけるバイトに割り当てられる。言い換えれば、複数の
コード化テーブルが用いられ、各テーブルは先のバイト
に従って選択される。このアプローチは、例えば、英語
では文字「ｕ」は頻繁には現れないが、「ｑ」の後には
殆ど常に現れるという観察に基づいている。従って、
「ｕ」に割り当てられるコードは、先の文字が「ｑ」
（又は「Ｑ」）であるかどうかに依存して異なるであろ
う。多数のテーブルと動的コード割当てとを用いる同様
のスキームについては、Jones, Douglas W., "Applicat
ion of SplayTrees to Data Compression"を参照された
い。
【００１４】上述のハフマンタイプのアプローチは、コ
ンピュータによって強化される傾向にあり、例外的に高
い圧縮比率を達成するものではない。この観察に対する
一つの説明は、８ビットバイトに基づく純粋なハフマン
コードは最も良い場合には８：１の圧縮比率を達成し得
ること、そしてそれはファイルが同じバイトの繰り返し
（即ち、エントロピー＝０）から成る最善の状況でのみ
達成され得ることである。同じ状況では、単純なランレ
ングスコード化スキームは５０：１以上の圧縮率を達成
し得る。平均の性能は最善及び最悪の場合の数の同じ組
み合わせであろう。そして、最善の場合の限度は、その
平均をも制限する。ハフマンのコード化の公知の限度
は、確率が厳密に２の累乗でなければ、理論的な限度の
１ビットの範囲内となることは保証されるが、エントロ
ピーを達成し得ないことである。これは、全てのハフマ
ンコードが長さにおける正確なビット数であるという事
実のためである。一方、全ての場合においてエントロピ
ーを達成するためには、断片的なビット長が必要であ
る。言い換えると、ハフマンのアルゴリズムはまるめの
問題を有している。一般に、高い確率でトークンがある
場合に問題は悪化する。なぜなら、「エラー」のビット
の断片が、割り当てられたコードのサイズの大きなパー
センテージを占めるからである。
ンピュータによって強化される傾向にあり、例外的に高
い圧縮比率を達成するものではない。この観察に対する
一つの説明は、８ビットバイトに基づく純粋なハフマン
コードは最も良い場合には８：１の圧縮比率を達成し得
ること、そしてそれはファイルが同じバイトの繰り返し
（即ち、エントロピー＝０）から成る最善の状況でのみ
達成され得ることである。同じ状況では、単純なランレ
ングスコード化スキームは５０：１以上の圧縮率を達成
し得る。平均の性能は最善及び最悪の場合の数の同じ組
み合わせであろう。そして、最善の場合の限度は、その
平均をも制限する。ハフマンのコード化の公知の限度
は、確率が厳密に２の累乗でなければ、理論的な限度の
１ビットの範囲内となることは保証されるが、エントロ
ピーを達成し得ないことである。これは、全てのハフマ
ンコードが長さにおける正確なビット数であるという事
実のためである。一方、全ての場合においてエントロピ
ーを達成するためには、断片的なビット長が必要であ
る。言い換えると、ハフマンのアルゴリズムはまるめの
問題を有している。一般に、高い確率でトークンがある
場合に問題は悪化する。なぜなら、「エラー」のビット
の断片が、割り当てられたコードのサイズの大きなパー
センテージを占めるからである。
【００１５】数学的コード化は、まるめの問題を実際に
克服することのできる公知の技術である。しかしなが
ら、数学的コード化に必要なテーブルは、ハフマンのテ
ーブルのように圧縮可能ではなく、またテーブルサイズ
の問題を克服するために数学的アルゴリズムを動的に行
うことは、可能ではあるが、計算上非常に集中的であ
る。最終的な結果として、数学的コード化を用いて実際
に達成される利得は、理論的見地から望まれるほど大き
くはない。
克服することのできる公知の技術である。しかしなが
ら、数学的コード化に必要なテーブルは、ハフマンのテ
ーブルのように圧縮可能ではなく、またテーブルサイズ
の問題を克服するために数学的アルゴリズムを動的に行
うことは、可能ではあるが、計算上非常に集中的であ
る。最終的な結果として、数学的コード化を用いて実際
に達成される利得は、理論的見地から望まれるほど大き
くはない。
【００１６】圧縮のための全体的に異なるアプローチ
が、Lempel及びZivによって開発され（Ziv, J.及びLemp
el, A., "Compression of Individual Sequences via V
ariable-Rate Coding", IEEE Transactions on Informa
tion Theory, Vol. IT-24, pp. 530-536, September 19
78を参照せよ）、Welchによって改良されている（Welc
h, Terry A., "A Technique for High-Performance Dat
a Compression", IEEE Computer, pp. 8-19, June 1984
を参照せよ）。可変長のコードを固定された大きさのバ
イトに割り当てる代わりに、Lempel-Zivアルゴリズム
（「ＬＺ」）は、固定長のコードを可変の大きさのスト
リングに割り当てる。ファイルからの入力バイトが処理
されるにつれて、ストリングのテーブルが作成され、各
バイト又はバイトのストリングは、テーブル内のストリ
ングのインデックスのみを出力することにより、圧縮さ
れる。典型的にはこのインデックスは１１〜１４ビット
の範囲であり、１２ビットが一般的である。なぜならこ
れは単純な手法に向いているからである。テーブルは先
にコード化されたバイトのみを用いて作成されるので、
圧縮及び伸張のシステムの両方は、テーブル情報を移送
するのに必要な余分なオーバーヘッド無しに、同じテー
ブルを維持することができる。ハッシングアルゴリズム
がマッチするストリングを効率的に捜すのに用いられ
る。ファイルの初めでは、テーブルはアルファベットの
各キャラクタに対して一つのストリングが初期化され
る。従って、たとえそのストリングが長さ１のみを有し
ていても、全てのバイトは少なくとも一つのストリング
に見いだされるということを確実にする。
が、Lempel及びZivによって開発され（Ziv, J.及びLemp
el, A., "Compression of Individual Sequences via V
ariable-Rate Coding", IEEE Transactions on Informa
tion Theory, Vol. IT-24, pp. 530-536, September 19
78を参照せよ）、Welchによって改良されている（Welc
h, Terry A., "A Technique for High-Performance Dat
a Compression", IEEE Computer, pp. 8-19, June 1984
を参照せよ）。可変長のコードを固定された大きさのバ
イトに割り当てる代わりに、Lempel-Zivアルゴリズム
（「ＬＺ」）は、固定長のコードを可変の大きさのスト
リングに割り当てる。ファイルからの入力バイトが処理
されるにつれて、ストリングのテーブルが作成され、各
バイト又はバイトのストリングは、テーブル内のストリ
ングのインデックスのみを出力することにより、圧縮さ
れる。典型的にはこのインデックスは１１〜１４ビット
の範囲であり、１２ビットが一般的である。なぜならこ
れは単純な手法に向いているからである。テーブルは先
にコード化されたバイトのみを用いて作成されるので、
圧縮及び伸張のシステムの両方は、テーブル情報を移送
するのに必要な余分なオーバーヘッド無しに、同じテー
ブルを維持することができる。ハッシングアルゴリズム
がマッチするストリングを効率的に捜すのに用いられ
る。ファイルの初めでは、テーブルはアルファベットの
各キャラクタに対して一つのストリングが初期化され
る。従って、たとえそのストリングが長さ１のみを有し
ていても、全てのバイトは少なくとも一つのストリング
に見いだされるということを確実にする。
【００１７】Lempel-Zivアルゴリズムは、それ自身をデ
ータに適合させ、ファイルの内容に根拠を置く予め設定
されたテーブルを必要としないので、魅力がある。更
に、ストリングを極端に長くし得るので、最適の場合の
圧縮比率は非常に高く、実際のＬＺ出力は、ほとんどの
タイプのファイルでハフマンスキームに匹敵する。ま
た、それは装置にとっても非常に単純であり、この単純
さが高い効率に現れている。
ータに適合させ、ファイルの内容に根拠を置く予め設定
されたテーブルを必要としないので、魅力がある。更
に、ストリングを極端に長くし得るので、最適の場合の
圧縮比率は非常に高く、実際のＬＺ出力は、ほとんどの
タイプのファイルでハフマンスキームに匹敵する。ま
た、それは装置にとっても非常に単純であり、この単純
さが高い効率に現れている。
【００１８】しかし、幾つかの障害もまた、ＬＺ圧縮法
に存在する。ＬＺストリング探索は「どん欲な」アルゴ
リズムである。例えば、次のストリングを考える。
に存在する。ＬＺストリング探索は「どん欲な」アルゴ
リズムである。例えば、次のストリングを考える。
【００１９】ＡＢＣＤＥＦＢＣＤＥＦ ここで、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆは異なったバイトであ
る。ＬＺストリング探索は、ＡＢ、ＢＣ、ＣＤ、ＤＥ、
ＥＦ、ＢＣＤ、ＤＥＦのストリングをストリングテーブ
ルに付け加え、このアルゴリズムを用いて出力され得る
長さ２又はそれ以上のストリングは、上で示した時点で
はＢＣ及びＤＥのみであることに注意しなければならな
い。実際にはストリングＢＣＤＥＦは既に入力に現れて
いる。従って、第２のＢＣＤＥＦストリングは最初のＢ
ＣＤＥＦに戻って参照されるのが理想であるが、実際に
はこれは行われない。
る。ＬＺストリング探索は、ＡＢ、ＢＣ、ＣＤ、ＤＥ、
ＥＦ、ＢＣＤ、ＤＥＦのストリングをストリングテーブ
ルに付け加え、このアルゴリズムを用いて出力され得る
長さ２又はそれ以上のストリングは、上で示した時点で
はＢＣ及びＤＥのみであることに注意しなければならな
い。実際にはストリングＢＣＤＥＦは既に入力に現れて
いる。従って、第２のＢＣＤＥＦストリングは最初のＢ
ＣＤＥＦに戻って参照されるのが理想であるが、実際に
はこれは行われない。
【００２０】ＬＺアプローチにとって重大な欠点は、圧
縮されたデータを保持するためのストリングテーブル
が、長いファイルを満たしてしまう傾向にあることであ
る。しかし、テーブルの大きさは増大されることがで
き、このアプローチはストリングを表すのにより多くの
ビットを必要とし、従って、効率が低下するであろう。
この欠点を扱うための一つのアプローチは、テーブルが
いっぱいになったときにそのテーブルの全部又は一部を
捨てることであろう。アルゴリズムの構造のために、最
新に見いだされたストリングが最初に捨てられる。なぜ
なら、それらは先のストリングに戻って参照するからで
ある。しかし、ローカルデータに動的に適合しているの
は、最新のストリングであり、それらを捨てるのもまた
効率的ではない。基本的にはＬＺストリングは無限の長
さのメモリを有しているので、ファイル内のデータのタ
イプの変更は、もしストリングテーブルがいっぱいであ
れば、非常なコード化の効率の悪さを引き起こし得る。
縮されたデータを保持するためのストリングテーブル
が、長いファイルを満たしてしまう傾向にあることであ
る。しかし、テーブルの大きさは増大されることがで
き、このアプローチはストリングを表すのにより多くの
ビットを必要とし、従って、効率が低下するであろう。
この欠点を扱うための一つのアプローチは、テーブルが
いっぱいになったときにそのテーブルの全部又は一部を
捨てることであろう。アルゴリズムの構造のために、最
新に見いだされたストリングが最初に捨てられる。なぜ
なら、それらは先のストリングに戻って参照するからで
ある。しかし、ローカルデータに動的に適合しているの
は、最新のストリングであり、それらを捨てるのもまた
効率的ではない。基本的にはＬＺストリングは無限の長
さのメモリを有しているので、ファイル内のデータのタ
イプの変更は、もしストリングテーブルがいっぱいであ
れば、非常なコード化の効率の悪さを引き起こし得る。
【００２１】同時に１より多くの方法を用いる圧縮シス
テムを設計することも可能である。このシステムは、フ
ァイル内でその方法が最も効率的になるように動的に後
ろ及び前にスイッチングする。装置の観点からは、この
ようなスキームは非常に高価であるかも知れないが（即
ち、遅く及び／又は高価である）、結果として得られる
圧縮比率を非常に高くすることができる。
テムを設計することも可能である。このシステムは、フ
ァイル内でその方法が最も効率的になるように動的に後
ろ及び前にスイッチングする。装置の観点からは、この
ようなスキームは非常に高価であるかも知れないが（即
ち、遅く及び／又は高価である）、結果として得られる
圧縮比率を非常に高くすることができる。
【００２２】動的に前後にスイッチするこのような一つ
の方法は、MacCriskenの特許に開示されている。上述の
ように、バイグラムハフマン法は主要な圧縮技術として
使用されている。典型的には、圧縮及び伸張システムは
予め定義された（即ち、統計的に）コードテーブルのセ
ットを用いてスタートする。おそらく、英語、フランス
語及びパスカルソースコードのためのこのようなテーブ
ルのセットがある。圧縮ユニット（送信機）は、使用さ
れるテーブルの短い記述を最初に移送又は格納する。伸
張ユニット（受信機）はこのコードを分析し、適切なテ
ーブルを選択する。圧縮の間に、もし現在のテーブルが
十分に機能しないことが決定されると、送信機は特別の
（「エスケープ」）ハフマンコードを移送する。このコ
ードは、他の特定の予め定義されたテーブルを選択する
か、又は伸張された先のデータに基づいて新たなテーブ
ルを計算するかどうかを受信機に伝える。送信機及び受
信機の両方は、同じアルゴリズムを用いてテーブルを計
算するので、テーブル全体を送る必要はないけれども計
算を行うのに幾らかの時間がかかる。ひとたび新たなテ
ーブルが計算されると、以前と同様に圧縮が行われる。
かなりのコンピュータのオーバーヘッドが存在するけれ
ども、この技術が更に動的ハフマンスキームに用いられ
得ないという理由は無いことに注意されなければならな
い。
の方法は、MacCriskenの特許に開示されている。上述の
ように、バイグラムハフマン法は主要な圧縮技術として
使用されている。典型的には、圧縮及び伸張システムは
予め定義された（即ち、統計的に）コードテーブルのセ
ットを用いてスタートする。おそらく、英語、フランス
語及びパスカルソースコードのためのこのようなテーブ
ルのセットがある。圧縮ユニット（送信機）は、使用さ
れるテーブルの短い記述を最初に移送又は格納する。伸
張ユニット（受信機）はこのコードを分析し、適切なテ
ーブルを選択する。圧縮の間に、もし現在のテーブルが
十分に機能しないことが決定されると、送信機は特別の
（「エスケープ」）ハフマンコードを移送する。このコ
ードは、他の特定の予め定義されたテーブルを選択する
か、又は伸張された先のデータに基づいて新たなテーブ
ルを計算するかどうかを受信機に伝える。送信機及び受
信機の両方は、同じアルゴリズムを用いてテーブルを計
算するので、テーブル全体を送る必要はないけれども計
算を行うのに幾らかの時間がかかる。ひとたび新たなテ
ーブルが計算されると、以前と同様に圧縮が行われる。
かなりのコンピュータのオーバーヘッドが存在するけれ
ども、この技術が更に動的ハフマンスキームに用いられ
得ないという理由は無いことに注意されなければならな
い。
【００２３】ハフマンのコード化に加えて、MacCrisken
は第２のストリングに基づく圧縮方法を用いている。送
信機及び受信機の両方が、最新の移送された入力バイト
の履歴バッファを保持する。それぞれの新たな入力バイ
ト（Ａ）に対してバイグラムハフマンコードが生成され
るが、ハッシングスキームを用いて履歴内の次の３つの
入力バイト（ＡＢＣ）によって表現されるストリングを
見つける試みもまた行われる。ハッシュが３バイトスト
リング上で行われ、ハッシュリスト内の古い入力の廃棄
を可能とするために、２重にリンクされたハッシュリス
トが維持される。もしストリングが見つかると、ストリ
ングが続くことを示すために特別のハフマンエスケープ
コードが生成され、履歴バッファ内のストリングの長さ
とオフセットが送られる。オフセットは１０ビットにコ
ードされ、長さは３〜１８バイトの長さを表現する４ビ
ットにコードされる。しかし、このようなストリングが
送られる前に、圧縮ユニットはストリング内の全てのバ
イトに対するハフマンコードを発生し、そのハフマンコ
ードの大きさをストリングビットの大きさと比較する。
典型的にはハフマンストリングエスケープコードは４ビ
ットであり、ストリングを表すのに１９ビットを要す
る。２つの量の小さい方が送られる。
は第２のストリングに基づく圧縮方法を用いている。送
信機及び受信機の両方が、最新の移送された入力バイト
の履歴バッファを保持する。それぞれの新たな入力バイ
ト（Ａ）に対してバイグラムハフマンコードが生成され
るが、ハッシングスキームを用いて履歴内の次の３つの
入力バイト（ＡＢＣ）によって表現されるストリングを
見つける試みもまた行われる。ハッシュが３バイトスト
リング上で行われ、ハッシュリスト内の古い入力の廃棄
を可能とするために、２重にリンクされたハッシュリス
トが維持される。もしストリングが見つかると、ストリ
ングが続くことを示すために特別のハフマンエスケープ
コードが生成され、履歴バッファ内のストリングの長さ
とオフセットが送られる。オフセットは１０ビットにコ
ードされ、長さは３〜１８バイトの長さを表現する４ビ
ットにコードされる。しかし、このようなストリングが
送られる前に、圧縮ユニットはストリング内の全てのバ
イトに対するハフマンコードを発生し、そのハフマンコ
ードの大きさをストリングビットの大きさと比較する。
典型的にはハフマンストリングエスケープコードは４ビ
ットであり、ストリングを表すのに１９ビットを要す
る。２つの量の小さい方が送られる。
【００２４】MacCriskenストリング法は、Lempel-Ziv法
のストリングテーブルは決していっぱいにならないとい
う問題点を避けているということに注意しなければなら
ない。なぜなら、古い入力はハッシュリストから除くこ
とによって廃棄されるからである。従って、最新の（１
キロバイト以内）のストリングのみがテーブルを占め
る。また、原理的には全てのマッチするストリングが見
いだされるので、それは「どん欲」ではない。実際に
は、ストリング探索の長さの制限が課されている。これ
に加えて、MacCrisken法は２つの圧縮アルゴリズムを同
時に効率的に行い、従って、コンピュータのオーバーヘ
ッドが非常に高くなるので、コンピュータで行うには非
効率的である。
のストリングテーブルは決していっぱいにならないとい
う問題点を避けているということに注意しなければなら
ない。なぜなら、古い入力はハッシュリストから除くこ
とによって廃棄されるからである。従って、最新の（１
キロバイト以内）のストリングのみがテーブルを占め
る。また、原理的には全てのマッチするストリングが見
いだされるので、それは「どん欲」ではない。実際に
は、ストリング探索の長さの制限が課されている。これ
に加えて、MacCrisken法は２つの圧縮アルゴリズムを同
時に効率的に行い、従って、コンピュータのオーバーヘ
ッドが非常に高くなるので、コンピュータで行うには非
効率的である。
【００２５】データの最新処理されたバイトの「スライ
ディングウインドウ」を維持し、マッするバイトのスト
リングに対するウインドウを走査するLempel-Ziv技術の
うちのMacCrisken法の変形を用いるアルゴリズムが他に
もいくつかある。ストリングが見いだされると、マッチ
するストリングの長さ及びウインドウ内のそのオフセッ
トが出力される。他の場合では、「生の」バイトが出力
される。圧縮エンジンのコード化部分は、ストリングと
生のバイトとの間の差異を示すタグを送り、ストリング
及び生のバイト自体は多くの方法でコード化され得る。
ディングウインドウ」を維持し、マッするバイトのスト
リングに対するウインドウを走査するLempel-Ziv技術の
うちのMacCrisken法の変形を用いるアルゴリズムが他に
もいくつかある。ストリングが見いだされると、マッチ
するストリングの長さ及びウインドウ内のそのオフセッ
トが出力される。他の場合では、「生の」バイトが出力
される。圧縮エンジンのコード化部分は、ストリングと
生のバイトとの間の差異を示すタグを送り、ストリング
及び生のバイト自体は多くの方法でコード化され得る。
【００２６】明らかに、データのタイプが異なると、ス
トリングの長さ及びオフセットの分布も異なるので、単
一の固定されたコード化が全ての可能なファイルに対し
て最適とはなり得ない。従って、見いだされたストリン
グに基づいてコード化を決定するための様々な技術が開
発されている。例えば、ハフマンコード化は、ストリン
グの長さ及びオフセットをコード化するために用いられ
ることができる。実際には、全ての長さ及びオフセット
が個々のハフマンコードを与えられるわけではない。そ
の代わりに、長さ及びオフセットの範囲が、単一のハフ
マンコードによって表されることができる。範囲内の値
を区別するために特別なビットがハフマンコードの後ろ
に続いている。これらの範囲、つまりビン（bin）は、
データにおいて典型的に観察される分布を近似するよう
に選択される。
トリングの長さ及びオフセットの分布も異なるので、単
一の固定されたコード化が全ての可能なファイルに対し
て最適とはなり得ない。従って、見いだされたストリン
グに基づいてコード化を決定するための様々な技術が開
発されている。例えば、ハフマンコード化は、ストリン
グの長さ及びオフセットをコード化するために用いられ
ることができる。実際には、全ての長さ及びオフセット
が個々のハフマンコードを与えられるわけではない。そ
の代わりに、長さ及びオフセットの範囲が、単一のハフ
マンコードによって表されることができる。範囲内の値
を区別するために特別なビットがハフマンコードの後ろ
に続いている。これらの範囲、つまりビン（bin）は、
データにおいて典型的に観察される分布を近似するよう
に選択される。
【００２７】そのようなアプローチの利点の一つは、選
択されるビンの制約内で、コード化が、圧縮されたイメ
ージのサイズを最小化するように処理されるているデー
タに対して最適化され得ることである。そのようなアプ
ローチの１つの欠点は、コード化フォーマットを記述す
るタイプのテーブルがデータと共に送られなければなら
ず、従って、可変コード化によって得られる余分な圧縮
をある程度打ち消すことになる。実際に、十分大きなデ
ータブロックに対して、このオーバーヘッドは、コード
化における利得によって補償されるよりも大きい。他の
欠点は、このタイプのアプローチは本質的に、ハードウ
エアであってもソフトウエアであっても、固定コード化
スキームよりも実行が困難であることである。ここで
も、補償率における利得が、複雑さの増大よりも重要と
なることがよくある。データの各バイトが処理される毎
にコード化を動的に修正してテーブルの必要性を除去す
ることはできるが、そのようなスキームは、さらに非常
に複雑であるので、典型的には、圧縮率の対応する劇的
利得を伴わずに圧縮及び伸張のスループットを劇的に低
速化させる。３番目の欠点は、多くの場合に重要ではな
いが、このタイプのアルゴリズムが本質的に２経路アプ
ローチであるので、いずれかのコード化トークンが出力
され得る前にストリング探索エンジンによって全てのデ
ータが処理されることが必要であることである。
択されるビンの制約内で、コード化が、圧縮されたイメ
ージのサイズを最小化するように処理されるているデー
タに対して最適化され得ることである。そのようなアプ
ローチの１つの欠点は、コード化フォーマットを記述す
るタイプのテーブルがデータと共に送られなければなら
ず、従って、可変コード化によって得られる余分な圧縮
をある程度打ち消すことになる。実際に、十分大きなデ
ータブロックに対して、このオーバーヘッドは、コード
化における利得によって補償されるよりも大きい。他の
欠点は、このタイプのアプローチは本質的に、ハードウ
エアであってもソフトウエアであっても、固定コード化
スキームよりも実行が困難であることである。ここで
も、補償率における利得が、複雑さの増大よりも重要と
なることがよくある。データの各バイトが処理される毎
にコード化を動的に修正してテーブルの必要性を除去す
ることはできるが、そのようなスキームは、さらに非常
に複雑であるので、典型的には、圧縮率の対応する劇的
利得を伴わずに圧縮及び伸張のスループットを劇的に低
速化させる。３番目の欠点は、多くの場合に重要ではな
いが、このタイプのアルゴリズムが本質的に２経路アプ
ローチであるので、いずれかのコード化トークンが出力
され得る前にストリング探索エンジンによって全てのデ
ータが処理されることが必要であることである。
【００２８】ストリングをコード化することに加えて、
生バイトもまたコード化され得る。スライディングウイ
ンドウ法を用いて、各アイテム出力はストリング又は生
バイトのいずれかであるので、生バイト及びストリング
が共にコード化され得る。例えば、単一ハフマンコード
が、生バイト又はある長さのストリングのいずれかを表
すことができる。コード化に生バイトを含ませること
は、用いられる特定のコード化を特定するテーブルのサ
イズをさらに大きくする傾向があるが、このテーブルサ
イズの増大は、得られる圧縮の利得によって典型的には
克服される。
生バイトもまたコード化され得る。スライディングウイ
ンドウ法を用いて、各アイテム出力はストリング又は生
バイトのいずれかであるので、生バイト及びストリング
が共にコード化され得る。例えば、単一ハフマンコード
が、生バイト又はある長さのストリングのいずれかを表
すことができる。コード化に生バイトを含ませること
は、用いられる特定のコード化を特定するテーブルのサ
イズをさらに大きくする傾向があるが、このテーブルサ
イズの増大は、得られる圧縮の利得によって典型的には
克服される。
【００２９】PKZIP version 2.0及びLHA version 2.13
は共通に、このタイプの圧縮方法を用いるＭＳ−ＤＯＳ
コンピュータに対して利用可能な圧縮ユーティリティで
ある。これらのプログラムによって用いられるストリン
グ探索技術は異なるが、得られる圧縮フォーマットは、
スタイルが極めて似ている。意外ではないが、非常に似
た圧縮率が得られる。各プログラムは、スライディング
ウインドウ及び最小のストリングの長さである３を用い
ており、圧縮データの一部として格納される２つのハフ
マンテーブルを発生させる。第１（及び大きい方）のハ
フマンテーブルは生バイト及びストリング長さをコード
化する。例えば、PKZIPは、各種サイズの２９レングス
ビンの合計を用いて、ハフマンコード０〜２５５に生バ
イトを割当て、ハフマンコード２５７〜２８５に３〜２
５８のストリング長を割当てる。
は共通に、このタイプの圧縮方法を用いるＭＳ−ＤＯＳ
コンピュータに対して利用可能な圧縮ユーティリティで
ある。これらのプログラムによって用いられるストリン
グ探索技術は異なるが、得られる圧縮フォーマットは、
スタイルが極めて似ている。意外ではないが、非常に似
た圧縮率が得られる。各プログラムは、スライディング
ウインドウ及び最小のストリングの長さである３を用い
ており、圧縮データの一部として格納される２つのハフ
マンテーブルを発生させる。第１（及び大きい方）のハ
フマンテーブルは生バイト及びストリング長さをコード
化する。例えば、PKZIPは、各種サイズの２９レングス
ビンの合計を用いて、ハフマンコード０〜２５５に生バ
イトを割当て、ハフマンコード２５７〜２８５に３〜２
５８のストリング長を割当てる。
【００３０】第２のハフマンテーブルは、PKZIP及びLHA
によって用いられて、ストリング長が特定されると、ス
トリングオフセットを表す。言い換えると、（生バイト
とは反対に）ストリング長に対応するハフマンコードの
後ろに、ストリングオフセットを特定するために異なる
ハフマンコードが用いられる。PKZIPは、１から３２７
６８の範囲の３０個のオフセットビンに対するハフマン
コードを有しているが、LHAは、１から８１９１の範囲
の１３個のオフセットビンを有している。これらのアル
ゴリズムは、サイズが８Ｋバイト又はそれ以上のデータ
のブロックを圧縮する際に最も効果的であるので、ブロ
ックサイズの一部であるテーブルオーバーヘッドは最小
となる。
によって用いられて、ストリング長が特定されると、ス
トリングオフセットを表す。言い換えると、（生バイト
とは反対に）ストリング長に対応するハフマンコードの
後ろに、ストリングオフセットを特定するために異なる
ハフマンコードが用いられる。PKZIPは、１から３２７
６８の範囲の３０個のオフセットビンに対するハフマン
コードを有しているが、LHAは、１から８１９１の範囲
の１３個のオフセットビンを有している。これらのアル
ゴリズムは、サイズが８Ｋバイト又はそれ以上のデータ
のブロックを圧縮する際に最も効果的であるので、ブロ
ックサイズの一部であるテーブルオーバーヘッドは最小
となる。
【００３１】これらの製品において、ハフマンのアルゴ
リズムによって発生されるコードの長さを与えるだけ
で、ハフマンコードの独特のセットを発生させて割り当
てることができるという公知の事実によって、ハフマン
テーブルは、それ自体が圧縮形態で格納されている。従
って、ハフマンコードの長さのみが格納される必要があ
るので、テーブルはコード自体よりもかなり小さくなる
（さらに圧縮可能である）。実際、ハフマン長はハフマ
ンコード化を用いて圧縮されるので、ハフマン長を引き
出すために用いられる初期の（未圧縮の）ハフマンテー
ブルが実際にあり、それはその後、データの圧縮及び伸
張において用いられるハフマンコードを発生させるため
に用いられる。
リズムによって発生されるコードの長さを与えるだけ
で、ハフマンコードの独特のセットを発生させて割り当
てることができるという公知の事実によって、ハフマン
テーブルは、それ自体が圧縮形態で格納されている。従
って、ハフマンコードの長さのみが格納される必要があ
るので、テーブルはコード自体よりもかなり小さくなる
（さらに圧縮可能である）。実際、ハフマン長はハフマ
ンコード化を用いて圧縮されるので、ハフマン長を引き
出すために用いられる初期の（未圧縮の）ハフマンテー
ブルが実際にあり、それはその後、データの圧縮及び伸
張において用いられるハフマンコードを発生させるため
に用いられる。
【００３２】典型的には、これらのアプローチは固定コ
ード化技術よりも１０〜１５％小さいサイズまでデータ
を圧縮することができる。データ圧縮に関する文献及び
研究の多くが、コード化技術よりもストリング探索方法
に注目しているが、コード化が行われる方法に厳密に傾
注することによって、大きな利得が（複雑さを犠牲にし
て）達成され得ることが経験的に明らかである。しかし
ながら、複雑さの局面を無視しても、固定コード化は、
テーブルが送られ得ない多くのアプリケーションに対し
てはやはり重要である。例えば、多くの伝送システムに
おいて、データの小さなパケット（多くの場合、１００
バイトよりも小さい）が圧縮されなくてはならない。テ
ーブルオーバーヘッドはこの場合重要である。同様に、
いくつかのアプリケーションにおいて、データは、テー
ブルが発生され得るように、受け取られる全ブロックを
待つことなく、データが受け取られるとすぐに圧縮され
移送されなくてはならない。
ード化技術よりも１０〜１５％小さいサイズまでデータ
を圧縮することができる。データ圧縮に関する文献及び
研究の多くが、コード化技術よりもストリング探索方法
に注目しているが、コード化が行われる方法に厳密に傾
注することによって、大きな利得が（複雑さを犠牲にし
て）達成され得ることが経験的に明らかである。しかし
ながら、複雑さの局面を無視しても、固定コード化は、
テーブルが送られ得ない多くのアプリケーションに対し
てはやはり重要である。例えば、多くの伝送システムに
おいて、データの小さなパケット（多くの場合、１００
バイトよりも小さい）が圧縮されなくてはならない。テ
ーブルオーバーヘッドはこの場合重要である。同様に、
いくつかのアプリケーションにおいて、データは、テー
ブルが発生され得るように、受け取られる全ブロックを
待つことなく、データが受け取られるとすぐに圧縮され
移送されなくてはならない。
【００３３】可変コード化スキームを用いる圧縮比率に
おける利得の主要な部分は、可変コード化自体から得ら
れるものであり、生バイト及びストリングの分布に適合
する。しかしながら、利得の他の重要な成分は、可変コ
ード化によって提供されるより大きなウインドウサイズ
（例えば、８Ｋバイト以上）に帰することができる。よ
り大きなウインドウによって、より多くのストリングが
見いだされることが可能となる。なぜなら、より大きな
履歴がストリング探索のために利用可能となるからであ
る。固定コード化スキームでは、残念なことに、オフセ
ットのコード化サイズの増大は、より多くのストリング
が見いだされるという事実を打ち消す傾向がある。一
方、可変コード化スキームでは、余分のストリングがオ
フセットコード化の適合性によって全体の圧縮比率を増
大させる。
おける利得の主要な部分は、可変コード化自体から得ら
れるものであり、生バイト及びストリングの分布に適合
する。しかしながら、利得の他の重要な成分は、可変コ
ード化によって提供されるより大きなウインドウサイズ
（例えば、８Ｋバイト以上）に帰することができる。よ
り大きなウインドウによって、より多くのストリングが
見いだされることが可能となる。なぜなら、より大きな
履歴がストリング探索のために利用可能となるからであ
る。固定コード化スキームでは、残念なことに、オフセ
ットのコード化サイズの増大は、より多くのストリング
が見いだされるという事実を打ち消す傾向がある。一
方、可変コード化スキームでは、余分のストリングがオ
フセットコード化の適合性によって全体の圧縮比率を増
大させる。
【００３４】
【発明が解決しようとする課題】実施する観点から、よ
り大きなウインドウサイズに伴う一つの問題は、全体の
圧縮及び伸張エンジンが単一の集積回路上に配置される
べきである場合には特に、必要なハードウエアのコスト
が非常に高いことである。同様に、ソフトウエアの実現
には通常、ウインドウサイズに比例するメモリサイズが
必要であり、これが多くの場合に許容され得ない。あら
ゆる場合において、通常は、圧縮アルゴリズムの互換性
のあるソフトウエア及びハードウエアのバージョンを有
することが望ましい。アルゴリズムによって達成され得
る圧縮比率と共に、ハードウエア及びソフトウエアの両
方のコスト及び速度が考慮されなくてはならない。
り大きなウインドウサイズに伴う一つの問題は、全体の
圧縮及び伸張エンジンが単一の集積回路上に配置される
べきである場合には特に、必要なハードウエアのコスト
が非常に高いことである。同様に、ソフトウエアの実現
には通常、ウインドウサイズに比例するメモリサイズが
必要であり、これが多くの場合に許容され得ない。あら
ゆる場合において、通常は、圧縮アルゴリズムの互換性
のあるソフトウエア及びハードウエアのバージョンを有
することが望ましい。アルゴリズムによって達成され得
る圧縮比率と共に、ハードウエア及びソフトウエアの両
方のコスト及び速度が考慮されなくてはならない。
【００３５】
【課題を解決するための手段】本発明のデータ圧縮方法
は、入力バイトのウインドウ内のマッチングストリング
に対する探索であって、生のバイトまたは一定の長さお
よび該ウインドウへ戻る一定のオフセットを有するマッ
チングストリングのいずれかを表現するトークンからな
るストリームを生成する探索を実行するステップと、該
トークンを予め定義されているビンに割り当てるステッ
プであって、該ビンのいくつかは、所定の長さおよび一
定のオフセット範囲内にあるマッチングストリングを有
するステップと、各ビンに割り当てられたトークンの発
生頻度に基づいて、可変長コードを各ビンに割り当てる
ステップと、生成された各トークンに対し、各トークン
が割り当てられた該ビンの該可変長コードを、出力デー
タストリームに出力するステップと、各可変長コードが
出力された後、必要であれば、該ビン内の該トークンを
正確に特定するために、余分なビットを出力するステッ
プとを包含する。
は、入力バイトのウインドウ内のマッチングストリング
に対する探索であって、生のバイトまたは一定の長さお
よび該ウインドウへ戻る一定のオフセットを有するマッ
チングストリングのいずれかを表現するトークンからな
るストリームを生成する探索を実行するステップと、該
トークンを予め定義されているビンに割り当てるステッ
プであって、該ビンのいくつかは、所定の長さおよび一
定のオフセット範囲内にあるマッチングストリングを有
するステップと、各ビンに割り当てられたトークンの発
生頻度に基づいて、可変長コードを各ビンに割り当てる
ステップと、生成された各トークンに対し、各トークン
が割り当てられた該ビンの該可変長コードを、出力デー
タストリームに出力するステップと、各可変長コードが
出力された後、必要であれば、該ビン内の該トークンを
正確に特定するために、余分なビットを出力するステッ
プとを包含する。
【００３６】前記方法は、前記可変長コードを割り当て
る前に、入力データストリームの全てのマッチングスト
リング探索を完了するステップと、該入力ストリーム全
体から各ビンにおけるトークン発生数をカウントするス
テップと、該発生カウントに基づいて前記可変長コード
を割り当てるステップと、各ビンに割り当てられた該可
変長コードを示すコーディングテーブルを生成するステ
ップと、いかなる符号化されたトークンを出力する前
に、該コーディングテーブルを前記出力データストリー
ムに出力するステップとをさらに包含することもでき
る。
る前に、入力データストリームの全てのマッチングスト
リング探索を完了するステップと、該入力ストリーム全
体から各ビンにおけるトークン発生数をカウントするス
テップと、該発生カウントに基づいて前記可変長コード
を割り当てるステップと、各ビンに割り当てられた該可
変長コードを示すコーディングテーブルを生成するステ
ップと、いかなる符号化されたトークンを出力する前
に、該コーディングテーブルを前記出力データストリー
ムに出力するステップとをさらに包含することもでき
る。
【００３７】前記可変長コードを割り当てるステップ
が、前記発生カウントに基づいてハフマンのアルゴリズ
ムを用いて該可変長コードを割り当てるステップをさら
に包含することもできる。
が、前記発生カウントに基づいてハフマンのアルゴリズ
ムを用いて該可変長コードを割り当てるステップをさら
に包含することもできる。
【００３８】前記コーディングテーブルを生成するステ
ップが、前記可変長コードの長さのみを有するコーディ
ングテーブルを生成するステップをさらに包含すること
もできる。
ップが、前記可変長コードの長さのみを有するコーディ
ングテーブルを生成するステップをさらに包含すること
もできる。
【００３９】前記方法は、ランレングス圧縮体系を用い
て前記コーディングテーブルを圧縮するステップをさら
に包含することもできる。
て前記コーディングテーブルを圧縮するステップをさら
に包含することもできる。
【００４０】前記方法は、ハフマンコーディングを用い
て、前記コーディングテーブルを圧縮するステップと、
該コーディングテーブル中の可変長に割り当てられたハ
フマンコードを特定するために使用される予備テーブル
を生成するステップとをさらに包含することもできる。
て、前記コーディングテーブルを圧縮するステップと、
該コーディングテーブル中の可変長に割り当てられたハ
フマンコードを特定するために使用される予備テーブル
を生成するステップとをさらに包含することもできる。
【００４１】前記方法は、圧縮された出力データの末端
部を示す特別なビンを割り当てるステップと、全ての他
のトークンが出力された後に、該圧縮された出力データ
ビンの該末端部のコードを出力するステップとをさらに
包含することもできる。
部を示す特別なビンを割り当てるステップと、全ての他
のトークンが出力された後に、該圧縮された出力データ
ビンの該末端部のコードを出力するステップとをさらに
包含することもできる。
【００４２】前記方法は、前記ビンを以下に示すように
割り当てるステップ
割り当てるステップ
【００４３】
【表９】
【００４４】をさらに包含することもできる。
【００４５】前記方法は、ビン２５６から３１８のコー
ドの後にストリングオフセットを特定する一定数の余分
なビットを以下に示すように続けるステップ
ドの後にストリングオフセットを特定する一定数の余分
なビットを以下に示すように続けるステップ
【００４６】
【表１０】
【００４７】をさらに包含することもできる。
【００４８】前記方法は、ビン３１９から３３４のコー
ドの後にストリングオフセットを特定する一定数の余分
なビットを以下に示すように続けるステップ
ドの後にストリングオフセットを特定する一定数の余分
なビットを以下に示すように続けるステップ
【００４９】
【表１１】
【００５０】をさらに包含することもできる。
【００５１】前記方法は、ビン３３４のコードおよびオ
フセットビットの後にストリング長を特定する余分なビ
ットを以下に示すように続けるステップ
フセットビットの後にストリング長を特定する余分なビ
ットを以下に示すように続けるステップ
【００５２】
【表１２】
【００５３】をさらに包含することもできる。
【００５４】他の局面によれば、本発明の圧縮された入
力データストリームを伸張するデータ伸張方法は、全て
のバイト出力の履歴アレイを維持するステップと、入力
データストリームが消耗するまで、または該圧縮された
入力データストリームの末端部を示すコードが見つかる
まで、以下のステップを繰り返すステップと、該圧縮さ
れた入力データストリームからビンコードを抜き出すス
テップと、該ビンコードに関連したトークンを正確に決
定するために必要とされる余分なビットを抜き出すステ
ップと、該トークンが生のバイトに相当する時、該生の
バイトを出力するステップと、該トークンがマッチング
ストリングに相当する時、該ストリングのオフセットを
用いて該履歴アレイにインデックスバックすることによ
り該ストリングの全てのバイトを出力するステップとを
包含する。
力データストリームを伸張するデータ伸張方法は、全て
のバイト出力の履歴アレイを維持するステップと、入力
データストリームが消耗するまで、または該圧縮された
入力データストリームの末端部を示すコードが見つかる
まで、以下のステップを繰り返すステップと、該圧縮さ
れた入力データストリームからビンコードを抜き出すス
テップと、該ビンコードに関連したトークンを正確に決
定するために必要とされる余分なビットを抜き出すステ
ップと、該トークンが生のバイトに相当する時、該生の
バイトを出力するステップと、該トークンがマッチング
ストリングに相当する時、該ストリングのオフセットを
用いて該履歴アレイにインデックスバックすることによ
り該ストリングの全てのバイトを出力するステップとを
包含する。
【００５５】前記方法は、前記圧縮された入力データス
トリームの開始部からコーディングテーブルを抜き出す
ステップと、該コーディングテーブルからカテゴリーに
対する可変長コードを抜き出すステップとをさらに包含
することもできる。
トリームの開始部からコーディングテーブルを抜き出す
ステップと、該コーディングテーブルからカテゴリーに
対する可変長コードを抜き出すステップとをさらに包含
することもできる。
【００５６】他の局面によれば、本発明のデータ圧縮装
置は、入力バイトのウインドウ内のマッチングストリン
グに対する探索であって、生のバイトまたは一定の長さ
および該ウインドウへ戻る一定のオフセットを有するマ
ッチングストリングのいずれかを表現するトークンから
なるストリームを生成する探索を実行する手段と、該ト
ークンを予め定義されているビンに割り当てる手段であ
って、該ビンのいくつかは、所定の長さおよび一定のオ
フセット範囲内にあるマッチングストリングを有する手
段と、各ビンに割り当てられたトークンの発生頻度に基
づいて、可変長コードを各ビンに割り当てる手段と、生
成された各トークンに対し、各トークンが割り当てられ
た該ビンの該可変長コードを、出力データストリームに
出力する手段と、各可変長コードが出力された後、必要
であれば、該ビン内の該トークンを正確に特定するため
に、余分なビットを出力する手段とを備えている。
置は、入力バイトのウインドウ内のマッチングストリン
グに対する探索であって、生のバイトまたは一定の長さ
および該ウインドウへ戻る一定のオフセットを有するマ
ッチングストリングのいずれかを表現するトークンから
なるストリームを生成する探索を実行する手段と、該ト
ークンを予め定義されているビンに割り当てる手段であ
って、該ビンのいくつかは、所定の長さおよび一定のオ
フセット範囲内にあるマッチングストリングを有する手
段と、各ビンに割り当てられたトークンの発生頻度に基
づいて、可変長コードを各ビンに割り当てる手段と、生
成された各トークンに対し、各トークンが割り当てられ
た該ビンの該可変長コードを、出力データストリームに
出力する手段と、各可変長コードが出力された後、必要
であれば、該ビン内の該トークンを正確に特定するため
に、余分なビットを出力する手段とを備えている。
【００５７】前記装置は、前記可変長コードを割り当て
る前に、入力データストリームの全てのマッチングスト
リング探索を完了する手段と、該入力ストリーム全体か
ら各ビンにおけるトークン発生数をカウントする手段
と、該発生カウントに基づいて前記可変長コードを割り
当てる手段と、各ビンに割り当てられた該可変長コード
を示すコーディングテーブルを生成する手段と、いかな
る符号化されたトークンを出力する前に、該コーディン
グテーブルを前記出力データストリームに出力する手段
とをさらに備えることもできる。
る前に、入力データストリームの全てのマッチングスト
リング探索を完了する手段と、該入力ストリーム全体か
ら各ビンにおけるトークン発生数をカウントする手段
と、該発生カウントに基づいて前記可変長コードを割り
当てる手段と、各ビンに割り当てられた該可変長コード
を示すコーディングテーブルを生成する手段と、いかな
る符号化されたトークンを出力する前に、該コーディン
グテーブルを前記出力データストリームに出力する手段
とをさらに備えることもできる。
【００５８】前記可変長コードを割り当てる手段が、前
記発生カウントに基づいてハフマンのアルゴリズムを用
いて該可変長コードを割り当てる手段をさらに備えるこ
ともできる。
記発生カウントに基づいてハフマンのアルゴリズムを用
いて該可変長コードを割り当てる手段をさらに備えるこ
ともできる。
【００５９】前記コーディングテーブルを生成する手段
が、前記可変長コードの長さのみを有するコーディング
テーブルを生成する手段をさらに備えることもできる。
が、前記可変長コードの長さのみを有するコーディング
テーブルを生成する手段をさらに備えることもできる。
【００６０】前記装置は、ランレングス圧縮体系を用い
て前記コーディングテーブルを圧縮する手段をさらに備
えることもできる。
て前記コーディングテーブルを圧縮する手段をさらに備
えることもできる。
【００６１】前記装置は、ハフマンコーディングを用い
て、前記コーディングテーブルを圧縮する手段と、該コ
ーディングテーブル中の可変長に割り当てられたハフマ
ンコードを特定するために使用される予備テーブルを生
成する手段とをさらに備えることもできる。
て、前記コーディングテーブルを圧縮する手段と、該コ
ーディングテーブル中の可変長に割り当てられたハフマ
ンコードを特定するために使用される予備テーブルを生
成する手段とをさらに備えることもできる。
【００６２】前記装置は、圧縮された出力データの末端
部を示す特別なビンを割り当てる手段と、全ての他のト
ークンが出力された後に、該圧縮された出力データビン
の該末端部のコードを出力する手段をさらに備えること
もできる。
部を示す特別なビンを割り当てる手段と、全ての他のト
ークンが出力された後に、該圧縮された出力データビン
の該末端部のコードを出力する手段をさらに備えること
もできる。
【００６３】前記装置は、前記ビンを以下に示すように
割り当てる手段
割り当てる手段
【００６４】
【表１３】
【００６５】をさらに備えることもできる。
【００６６】前記装置は、ビン２５６から３１８のコー
ドの後にストリングオフセットを特定する一定数の余分
なビットを以下に示すように続ける手段
ドの後にストリングオフセットを特定する一定数の余分
なビットを以下に示すように続ける手段
【００６７】
【表１４】
【００６８】をさらに備えることもできる。
【００６９】前記装置は、ビン３１９から３３４のコー
ドの後にストリングオフセットを特定する一定数の余分
なビットを以下に示すように続ける手段
ドの後にストリングオフセットを特定する一定数の余分
なビットを以下に示すように続ける手段
【００７０】
【表１５】
【００７１】をさらに備えることもできる。
【００７２】前記装置は、ビン３３４のコードおよびオ
フセットビットの後にストリング長を特定する余分なビ
ットを以下のように続ける手段
フセットビットの後にストリング長を特定する余分なビ
ットを以下のように続ける手段
【００７３】
【表１６】
【００７４】をさらに備えることもできる。
【００７５】他の局面によれば、本発明の圧縮された入
力データストリームを伸張するデータ伸張装置は、全て
のバイト出力の履歴アレイを維持する手段と、該圧縮さ
れた入力データストリームからビンコードを抜き出す手
段と、該ビンコードに関連したトークンを正確に決定す
るために必要とされる余分なビットを抜き出す手段と、
生のバイトを出力する手段と、マッチングストリングの
全てのバイトを、該ストリングのオフセットを用いて該
履歴アレイにインデックスバックすることにより出力す
る手段とを備えている。
力データストリームを伸張するデータ伸張装置は、全て
のバイト出力の履歴アレイを維持する手段と、該圧縮さ
れた入力データストリームからビンコードを抜き出す手
段と、該ビンコードに関連したトークンを正確に決定す
るために必要とされる余分なビットを抜き出す手段と、
生のバイトを出力する手段と、マッチングストリングの
全てのバイトを、該ストリングのオフセットを用いて該
履歴アレイにインデックスバックすることにより出力す
る手段とを備えている。
【００７６】前記装置は、前記圧縮された入力データス
トリームの開始部からコーディングテーブルを抜き出す
手段と、該コーディングテーブルから該カテゴリーに対
する可変長コードを抜き出す手段とをさらに備えること
もできる。
トリームの開始部からコーディングテーブルを抜き出す
手段と、該コーディングテーブルから該カテゴリーに対
する可変長コードを抜き出す手段とをさらに備えること
もできる。
【００７７】
【作用】本発明は、磁気ディスク又はテープ記憶装置の
ようなデジタル記憶装置の容量を増大させる、圧縮／伸
張システムである。圧縮方法は完全に適合性があり、予
め初期化されたコード化テーブルを必要とせずに、コン
ピュータファイルのようなバイトに適応したキャラクタ
ストリームを最適化する。それは従来技術に見られる多
くの困難を克服し、上述で議論した先行する技術の何れ
よりも、より少ないメモリ要件で、より速くより高い圧
縮率を達成する。
ようなデジタル記憶装置の容量を増大させる、圧縮／伸
張システムである。圧縮方法は完全に適合性があり、予
め初期化されたコード化テーブルを必要とせずに、コン
ピュータファイルのようなバイトに適応したキャラクタ
ストリームを最適化する。それは従来技術に見られる多
くの困難を克服し、上述で議論した先行する技術の何れ
よりも、より少ないメモリ要件で、より速くより高い圧
縮率を達成する。
【００７８】圧縮は、まず、以前のマッチするストリン
グ又はバイトに対して、入力データストリーム全体に探
索を行うことによって達成される。ストリング探索は、
以前に処理されたバイトの履歴アレイを維持することに
よって達成される。マッチするストリングが見いだされ
ると、マッチするストリングの長さ及び履歴アレイ内で
のマッチするストリングのオフセット（相対的位置）を
示す出力トークンが発生される。現在調べられているバ
イトを含むマッチするストリングが見いだされない場合
には、「生の」バイトであることを示す出力トークンが
発生される。
グ又はバイトに対して、入力データストリーム全体に探
索を行うことによって達成される。ストリング探索は、
以前に処理されたバイトの履歴アレイを維持することに
よって達成される。マッチするストリングが見いだされ
ると、マッチするストリングの長さ及び履歴アレイ内で
のマッチするストリングのオフセット（相対的位置）を
示す出力トークンが発生される。現在調べられているバ
イトを含むマッチするストリングが見いだされない場合
には、「生の」バイトであることを示す出力トークンが
発生される。
【００７９】圧縮プロセスは、マッチするストリング及
びストリング探索によって発生される生のバイトを表す
トークンのハフマンに基づくコード化を用いることによ
って完結する。単一のハフマンコード化ツリーが、生の
バイト及び多くの最も共通するストリング長／オフセッ
トの対に対して用いられる。ハフマンテーブル自体は、
データの圧縮イメージの一部として圧縮形態で格納され
る。
びストリング探索によって発生される生のバイトを表す
トークンのハフマンに基づくコード化を用いることによ
って完結する。単一のハフマンコード化ツリーが、生の
バイト及び多くの最も共通するストリング長／オフセッ
トの対に対して用いられる。ハフマンテーブル自体は、
データの圧縮イメージの一部として圧縮形態で格納され
る。
【００８０】本発明の好ましい実施例は、圧縮ユニット
から出力されるコード化データストリームを伸張するた
めの方法も包含している。伸張するための方法は、以下
のステップを包含している。第１に、コード化されたハ
フマン長テーブルが受け取られてデコードされる。各ハ
フマンビンに対するコードの長さが分かると、ハフマン
コードが各トークンビンに割り当てられる。トークンビ
ンに対してハフマンコードが与えられると、ハフマンツ
リーがトークンをデコードするために構築され、それが
圧縮入力データストリームから引き出される。ハフマン
ビンが生のバイトに対応する場合には、伸張ユニットが
生のバイトを出力する。ハフマンビンがストリングに対
応する場合には、ストリングオフセット及び長さを特定
するために必要な全ての余分なビットが、入力データス
トリームから引き出される。その後、ストリングが、同
時に１バイト出力される。好ましい実施例において、た
いていのスライディングウインドウ伸張スキームと同様
に、これは、最新のバイト出力の履歴アレイを維持し、
オフセットによって履歴アレイにインデックスし直すこ
とによって行われ、１バイトが引き出される。生バイト
又はストリングバイトのいずれか全てのバイト出力が履
歴アレイに加えられる。
から出力されるコード化データストリームを伸張するた
めの方法も包含している。伸張するための方法は、以下
のステップを包含している。第１に、コード化されたハ
フマン長テーブルが受け取られてデコードされる。各ハ
フマンビンに対するコードの長さが分かると、ハフマン
コードが各トークンビンに割り当てられる。トークンビ
ンに対してハフマンコードが与えられると、ハフマンツ
リーがトークンをデコードするために構築され、それが
圧縮入力データストリームから引き出される。ハフマン
ビンが生のバイトに対応する場合には、伸張ユニットが
生のバイトを出力する。ハフマンビンがストリングに対
応する場合には、ストリングオフセット及び長さを特定
するために必要な全ての余分なビットが、入力データス
トリームから引き出される。その後、ストリングが、同
時に１バイト出力される。好ましい実施例において、た
いていのスライディングウインドウ伸張スキームと同様
に、これは、最新のバイト出力の履歴アレイを維持し、
オフセットによって履歴アレイにインデックスし直すこ
とによって行われ、１バイトが引き出される。生バイト
又はストリングバイトのいずれか全てのバイト出力が履
歴アレイに加えられる。
【００８１】
【実施例】図１（ａ）及び図１（ｂ）において、本発明
による圧縮ユニット４及び伸張ユニット６のブロック図
が示される。ユニット４及び６の両方は、ハードウエア
モジュールであっても、ソフトウエアモジュールであっ
てもよい。しかし、好ましい実施例においては、圧縮ユ
ニット４及び伸張ユニット６は１個の集積回路に組み入
れられる（図１０）。この集積回路は、マイクロプロセ
ッサ５によって制御されるデータ記憶システム又はデー
タ伝送システムの一部として用いられる。図１（ａ）に
おいて、入力データストリーム８は、ホスト１０と称さ
れるデータ送信装置から圧縮ユニット４に入力される。
コード化され、圧縮されたデータストリーム１２は装置
１４と称されるデータ受信装置へ伝送される。
による圧縮ユニット４及び伸張ユニット６のブロック図
が示される。ユニット４及び６の両方は、ハードウエア
モジュールであっても、ソフトウエアモジュールであっ
てもよい。しかし、好ましい実施例においては、圧縮ユ
ニット４及び伸張ユニット６は１個の集積回路に組み入
れられる（図１０）。この集積回路は、マイクロプロセ
ッサ５によって制御されるデータ記憶システム又はデー
タ伝送システムの一部として用いられる。図１（ａ）に
おいて、入力データストリーム８は、ホスト１０と称さ
れるデータ送信装置から圧縮ユニット４に入力される。
コード化され、圧縮されたデータストリーム１２は装置
１４と称されるデータ受信装置へ伝送される。
【００８２】同様に、図１（ｂ）に於いて、伸張ユニッ
ト６は、装置１４（ここではデータ送信装置）から圧縮
されたデータストリーム１８を受け取り、元の圧縮され
ていないデータストリーム２０を再構成し、そのデータ
ストリームをホスト１０（ここではデータ受信装置）へ
出力する。好ましい実施例において、伸張及び圧縮は同
時には行われない。しかし、他の実施例に於いては伸張
及び圧縮は同時に行われ得る。
ト６は、装置１４（ここではデータ送信装置）から圧縮
されたデータストリーム１８を受け取り、元の圧縮され
ていないデータストリーム２０を再構成し、そのデータ
ストリームをホスト１０（ここではデータ受信装置）へ
出力する。好ましい実施例において、伸張及び圧縮は同
時には行われない。しかし、他の実施例に於いては伸張
及び圧縮は同時に行われ得る。
【００８３】図２では、本発明によって動作するように
構成された圧縮ユニット４のブロック図が示されてい
る。入力データ２２は、圧縮されるべき入力データスト
リームである。入力データ２２は、ＭＥＭＳＩＺＥバイ
トのウインドウサイズを用いて、ブロック２４に示され
るように、スライディングウインドウストリング探索ア
ルゴリズムを用いて処理される。多くの異なるストリン
グ探索アルゴリズムがブロック２４において用いられ得
る。スライディングウインドウアルゴリズムの出力は一
連のトークン２６である。
構成された圧縮ユニット４のブロック図が示されてい
る。入力データ２２は、圧縮されるべき入力データスト
リームである。入力データ２２は、ＭＥＭＳＩＺＥバイ
トのウインドウサイズを用いて、ブロック２４に示され
るように、スライディングウインドウストリング探索ア
ルゴリズムを用いて処理される。多くの異なるストリン
グ探索アルゴリズムがブロック２４において用いられ得
る。スライディングウインドウアルゴリズムの出力は一
連のトークン２６である。
【００８４】トークン２６のそれぞれは、生バイト又は
与えられた長さ及びオフセットを有するマッチするスト
リングである。すでに処理された以前のＭＥＭＳＩＺＥ
バイトにおいてマッチするストリングが見いだされない
場合に、生バイトトークンが生成される。ストリングト
ークンは、見いだされたストリングマッチの長さ及びス
ライディングウインドウからのそのオフセットを示す。
長さ及びオフセットは、伸張ユニット６が元のデータを
再構成し得るには十分である。
与えられた長さ及びオフセットを有するマッチするスト
リングである。すでに処理された以前のＭＥＭＳＩＺＥ
バイトにおいてマッチするストリングが見いだされない
場合に、生バイトトークンが生成される。ストリングト
ークンは、見いだされたストリングマッチの長さ及びス
ライディングウインドウからのそのオフセットを示す。
長さ及びオフセットは、伸張ユニット６が元のデータを
再構成し得るには十分である。
【００８５】出力トークンは、ハフマンコードがトーク
ンビンのそれぞれに割り当てられるまで中間バッファ２
８に一時的に格納される。この割当ては、入力データ２
２の全てがマッチするストリングを捜すために探索さ
れ、全てのトークンが生成されるまで起こらない。トー
クンが生成されて格納されると、それらは、異なるビン
又はカテゴリに割り当てられる。ビンは、生バイト、各
種ストリング長さ／オフセット対及び幾つかの個々のス
トリング長から成る。
ンビンのそれぞれに割り当てられるまで中間バッファ２
８に一時的に格納される。この割当ては、入力データ２
２の全てがマッチするストリングを捜すために探索さ
れ、全てのトークンが生成されるまで起こらない。トー
クンが生成されて格納されると、それらは、異なるビン
又はカテゴリに割り当てられる。ビンは、生バイト、各
種ストリング長さ／オフセット対及び幾つかの個々のス
トリング長から成る。
【００８６】トークンはまた、入力データ２２から生成
される全てのトークンに対して１ビン当たりのトークン
の数をカウントするビンカウンタ３０へ入力される。各
ビンに対するカウントは、初期的にはゼロに設定され、
ビンに対応するトークンが生成される毎に１ずつインク
リメントされる。他の実施例において、ビンカウント
は、中間バッファにおけるトークンを再処理することに
よってスライディングウインドウ探索が完了した後にの
み計算されて、カウントを累積する。他の実施例におい
て、中間トークンは、バイト配列された固定コード化を
用いて（ビット配列フォーマットではなく）格納され
る。バイト配列された固定コード化には、より大きな格
納空間が必要ではあるが、より効率的に処理され得る。
される全てのトークンに対して１ビン当たりのトークン
の数をカウントするビンカウンタ３０へ入力される。各
ビンに対するカウントは、初期的にはゼロに設定され、
ビンに対応するトークンが生成される毎に１ずつインク
リメントされる。他の実施例において、ビンカウント
は、中間バッファにおけるトークンを再処理することに
よってスライディングウインドウ探索が完了した後にの
み計算されて、カウントを累積する。他の実施例におい
て、中間トークンは、バイト配列された固定コード化を
用いて（ビット配列フォーマットではなく）格納され
る。バイト配列された固定コード化には、より大きな格
納空間が必要ではあるが、より効率的に処理され得る。
【００８７】全ての入力データがスライディングウイン
ドウ探索２４によって処理され、全ての出力トークンが
一時的に格納されてビンカウントが計算されると、ハフ
マンのアルゴリズムが用いられて、ハフマンコード３２
が各種ビンに割り当てられる。ハフマンコード３２は、
ビンカウンタ３０によって維持されるビンカウントから
生成される。各ビンに対するハフマンの確率は、ビンカ
ウントに比例するので、一般に、大きなカウントを有す
るビンほど短いコードを割り当てられ、小さなカウント
を有するビンほど長いコードを割り当てられる。
ドウ探索２４によって処理され、全ての出力トークンが
一時的に格納されてビンカウントが計算されると、ハフ
マンのアルゴリズムが用いられて、ハフマンコード３２
が各種ビンに割り当てられる。ハフマンコード３２は、
ビンカウンタ３０によって維持されるビンカウントから
生成される。各ビンに対するハフマンの確率は、ビンカ
ウントに比例するので、一般に、大きなカウントを有す
るビンほど短いコードを割り当てられ、小さなカウント
を有するビンほど長いコードを割り当てられる。
【００８８】単一のハフマンツリーを用いることによっ
て、データと共に格納されるテーブルのサイズが小さく
なる。より重要なことに、ストリング長さ／オフセット
対を単一ハフマンコードに組み合わせることは、所定の
長さ及びオフセットのビンからのストリングが、例えば
オフセットとは独立した所定の長さのストリングよりも
かなり確率が低くなることを意味している。従って、ハ
フマンコード化に付随するまるめの問題が最小化され、
高圧縮比率が小さなウインドウサイズでも達成され得
る。小さなウインドウサイズは、ハードウエア及びソフ
トウエア実現において、より許容可能なコストとなる。
て、データと共に格納されるテーブルのサイズが小さく
なる。より重要なことに、ストリング長さ／オフセット
対を単一ハフマンコードに組み合わせることは、所定の
長さ及びオフセットのビンからのストリングが、例えば
オフセットとは独立した所定の長さのストリングよりも
かなり確率が低くなることを意味している。従って、ハ
フマンコード化に付随するまるめの問題が最小化され、
高圧縮比率が小さなウインドウサイズでも達成され得
る。小さなウインドウサイズは、ハードウエア及びソフ
トウエア実現において、より許容可能なコストとなる。
【００８９】好ましい実施例において、ハフマンのアル
ゴリズムは、各ハフマンコードの長さを生成させるため
にのみ用いられており、ビットコードそのものを生成さ
せるためには用いられていない。各ビンに対してハフマ
ンコードの長さを与えると、実際のコードは、以下に説
明されるように、図１５において示されるアルゴリズム
を用いて一意的に生成される。ハフマンコードの長さの
みが圧縮データと共に格納され、伸縮ユニット６は図１
５の同様のアルゴリズムを用いてコードを割り当てる。
従って、圧縮及び伸縮の一致が保証される。
ゴリズムは、各ハフマンコードの長さを生成させるため
にのみ用いられており、ビットコードそのものを生成さ
せるためには用いられていない。各ビンに対してハフマ
ンコードの長さを与えると、実際のコードは、以下に説
明されるように、図１５において示されるアルゴリズム
を用いて一意的に生成される。ハフマンコードの長さの
みが圧縮データと共に格納され、伸縮ユニット６は図１
５の同様のアルゴリズムを用いてコードを割り当てる。
従って、圧縮及び伸縮の一致が保証される。
【００９０】中間バッファ２８からのトークン及びハフ
マンコード３２がいずれもハフマンエンコーダ３４へ入
力される。ハフマンエンコーダ３４は、圧縮された出力
データ３６の第１の部分として、各ビン対するハフマン
コードレングスを出力する。そのレングスは、ハフマン
ビン０から始まり、最後のハフマンビンまで出力され
る。好ましい実施例では１〜１５ビットの範囲であるコ
ードレングス自体は、空間を節約するために圧縮フォー
マットで出力される。レングスフィールドにおいてゼロ
であるということは、所定のビンが起こらないことを意
味している。好ましい実施例において、単一のランレン
グス圧縮フォーマットは、４ビットによって表される各
レングスを用いて、このレングステーブルをコード化す
るために用いられる。他の実施例において、そのレング
ス自身も、可変ハフマンコードを用いてコード化される
ことができ、ハフマン長のためのコード化を特定するた
めにデータの始めにさらに他のテーブルが置かれてい
る。このテーブルは、圧縮されずに含まれている。なぜ
なら、繰り返される連続レングス（つまり、ラン）がハ
フマンコードとしてどのように含まれているか（或いは
含まれているかどうか）に応じて、３２個よりも少ない
コードが典型的には含まれるからである。
マンコード３２がいずれもハフマンエンコーダ３４へ入
力される。ハフマンエンコーダ３４は、圧縮された出力
データ３６の第１の部分として、各ビン対するハフマン
コードレングスを出力する。そのレングスは、ハフマン
ビン０から始まり、最後のハフマンビンまで出力され
る。好ましい実施例では１〜１５ビットの範囲であるコ
ードレングス自体は、空間を節約するために圧縮フォー
マットで出力される。レングスフィールドにおいてゼロ
であるということは、所定のビンが起こらないことを意
味している。好ましい実施例において、単一のランレン
グス圧縮フォーマットは、４ビットによって表される各
レングスを用いて、このレングステーブルをコード化す
るために用いられる。他の実施例において、そのレング
ス自身も、可変ハフマンコードを用いてコード化される
ことができ、ハフマン長のためのコード化を特定するた
めにデータの始めにさらに他のテーブルが置かれてい
る。このテーブルは、圧縮されずに含まれている。なぜ
なら、繰り返される連続レングス（つまり、ラン）がハ
フマンコードとしてどのように含まれているか（或いは
含まれているかどうか）に応じて、３２個よりも少ない
コードが典型的には含まれるからである。
【００９１】割り当てられ出力されたハフマンコードと
共に、その後、ハフマンエンコーダは、中間バッファ２
８内のトークンを処理して、各トークンに対するハフマ
ンコードを圧縮された出力データストリーム３６へ出力
する。たいていのストリングトークンは、ハフマンコー
ドの後に添付される余分なビットを必要とする。先ず、
ストリングオフセットを特定するために必要な余分のビ
ットが出力される。好ましい実施例において、長さ６以
上のストリング（ハフマンビン３１９〜３３４）の後ろ
には、図１３に示されるように、ストリングオフセット
コード化が後続している。レングス３、４及び５（ハフ
マンビン２５６〜３１８）のストリングに対するコード
の後ろには、図１４に示されるように、特定された余分
のオフセットビットの数が後続している。次に、ストリ
ング長を十分に特定するために必要な余分のビットが出
力される。好ましい実施例において、図１４に示される
ように、ハフマンビン３３４のみが余分なレングスビッ
トを必要としている。他の実施例において、中間バッフ
ァに出力トークンを格納する代わりに、元の入力データ
が、スライディングウインドウ探索アルゴリズムによっ
て再び処理され、最初のスライディングウインドウ探索
後に生成されるハフマンコードに基づいて、トークンス
トリームが、２回目の生成されるようにコード化され
る。
共に、その後、ハフマンエンコーダは、中間バッファ２
８内のトークンを処理して、各トークンに対するハフマ
ンコードを圧縮された出力データストリーム３６へ出力
する。たいていのストリングトークンは、ハフマンコー
ドの後に添付される余分なビットを必要とする。先ず、
ストリングオフセットを特定するために必要な余分のビ
ットが出力される。好ましい実施例において、長さ６以
上のストリング（ハフマンビン３１９〜３３４）の後ろ
には、図１３に示されるように、ストリングオフセット
コード化が後続している。レングス３、４及び５（ハフ
マンビン２５６〜３１８）のストリングに対するコード
の後ろには、図１４に示されるように、特定された余分
のオフセットビットの数が後続している。次に、ストリ
ング長を十分に特定するために必要な余分のビットが出
力される。好ましい実施例において、図１４に示される
ように、ハフマンビン３３４のみが余分なレングスビッ
トを必要としている。他の実施例において、中間バッフ
ァに出力トークンを格納する代わりに、元の入力データ
が、スライディングウインドウ探索アルゴリズムによっ
て再び処理され、最初のスライディングウインドウ探索
後に生成されるハフマンコードに基づいて、トークンス
トリームが、２回目の生成されるようにコード化され
る。
【００９２】圧縮ユニット４の出力はビットストリーム
である。好ましい実施例において、ビットは、１６ビッ
トワードで出力され、第１のビットがワードの最上位ビ
ットであり、連続ビットがワードの最下位ビットまで満
たしている。ワードが満たされると、最下位バイトが最
初に出力され、再びワードの最上位ビットから始まる最
初のワードが蓄積される。全てのトークンがコード化さ
れて出力されると、特別のハフマンコード（好ましい実
施例においては３３５）が圧縮データの終了を示すため
に出力され、パッドビットが出力ワードの残りを埋める
ために出力される。最終コードは伸張ユニット６を停止
するために用いられる。他の実施例においては、ビット
が８ビットバイトで出力されることも可能であり、或い
は、ビットが最下位ビットを先頭として蓄積されること
もでき、或いは、ワードが最上位バイトを先頭として出
力されることもできる。
である。好ましい実施例において、ビットは、１６ビッ
トワードで出力され、第１のビットがワードの最上位ビ
ットであり、連続ビットがワードの最下位ビットまで満
たしている。ワードが満たされると、最下位バイトが最
初に出力され、再びワードの最上位ビットから始まる最
初のワードが蓄積される。全てのトークンがコード化さ
れて出力されると、特別のハフマンコード（好ましい実
施例においては３３５）が圧縮データの終了を示すため
に出力され、パッドビットが出力ワードの残りを埋める
ために出力される。最終コードは伸張ユニット６を停止
するために用いられる。他の実施例においては、ビット
が８ビットバイトで出力されることも可能であり、或い
は、ビットが最下位ビットを先頭として蓄積されること
もでき、或いは、ワードが最上位バイトを先頭として出
力されることもできる。
【００９３】図３は、スライディングウインドウ探索ブ
ロック２４によるトークン生成の一例を含む単純な結果
のテーブルを示している。テーブルは、２つの列に分け
られており、第１列５０は、入力データストリームを示
しており、第２列５２は、トークン及び生データの出力
ストリームを示している。トークンを生成させるために
必要な最小マッチストリング長は好ましい実施例におい
ては３である。なぜなら、それが、経験的に最良の結果
を与えるようであるからである。
ロック２４によるトークン生成の一例を含む単純な結果
のテーブルを示している。テーブルは、２つの列に分け
られており、第１列５０は、入力データストリームを示
しており、第２列５２は、トークン及び生データの出力
ストリームを示している。トークンを生成させるために
必要な最小マッチストリング長は好ましい実施例におい
ては３である。なぜなら、それが、経験的に最良の結果
を与えるようであるからである。
【００９４】第２列５２は、行６０〜７０によって参照
される。第１の入力バイトはキャラクタ「Ａ」であり、
これは以前には現れなかったもので、生のバイト「Ａ」
に対応する出力トークンを有している（行６０）。次の
入力バイトはキャラクタ「Ｂ」であり、これは同様に以
前には現れなかったもので（スライディングウインドウ
履歴は「Ａ」のみを有している）、従って、生のバイト
「Ｂ」に対応する出力トークンを有している（行６
２）。次の入力バイトはキャラクタ「Ａ」である。好ま
しい実施例において、３又はそれ以上を有するストリン
グのみがマッチするストリングとしてコード化されるの
で、キャラクタ「Ａ」は、生のバイト「Ａ」として出力
される（行６４）。しかしながら、次の「Ａ」キャラク
タが起こると、全ての「Ａ」キャラクタが処理された後
に、オフセット１でレングス５を有するマッチするスト
リングが見いだされる。従って、対応するトークン（行
６６）が生成される。次の入力バイトは「Ｃ」であり、
これは以前には現れなかったもので、従って、生のバイ
ト「Ｃ」に対応する出力トークンを有している（行６
８）。次の３つのバイト「ＡＢＡ」は、入力データスト
リームの先頭のストリングにマッチしている。従って、
オフセット９でのレングス３のストリングのマッチを示
すマッチするストリングのためのトークンが出力される
（行７０）。
される。第１の入力バイトはキャラクタ「Ａ」であり、
これは以前には現れなかったもので、生のバイト「Ａ」
に対応する出力トークンを有している（行６０）。次の
入力バイトはキャラクタ「Ｂ」であり、これは同様に以
前には現れなかったもので（スライディングウインドウ
履歴は「Ａ」のみを有している）、従って、生のバイト
「Ｂ」に対応する出力トークンを有している（行６
２）。次の入力バイトはキャラクタ「Ａ」である。好ま
しい実施例において、３又はそれ以上を有するストリン
グのみがマッチするストリングとしてコード化されるの
で、キャラクタ「Ａ」は、生のバイト「Ａ」として出力
される（行６４）。しかしながら、次の「Ａ」キャラク
タが起こると、全ての「Ａ」キャラクタが処理された後
に、オフセット１でレングス５を有するマッチするスト
リングが見いだされる。従って、対応するトークン（行
６６）が生成される。次の入力バイトは「Ｃ」であり、
これは以前には現れなかったもので、従って、生のバイ
ト「Ｃ」に対応する出力トークンを有している（行６
８）。次の３つのバイト「ＡＢＡ」は、入力データスト
リームの先頭のストリングにマッチしている。従って、
オフセット９でのレングス３のストリングのマッチを示
すマッチするストリングのためのトークンが出力される
（行７０）。
【００９５】全てのデータ構造（例えば、履歴アレイ１
０２、ハッシュテーブル１００、及びオフセットアレイ
１０４（図４））は、ＲＡＭ１６内に維持され、ＲＡＭ
１６は１つ又は多数のＲＡＭユニットを有していること
ができる。好ましい実施例において行われる好ましいデ
ータ構造のより詳細な説明は、それらを構築し維持する
圧縮ユニット４の説明の間に、以下に説明される。
０２、ハッシュテーブル１００、及びオフセットアレイ
１０４（図４））は、ＲＡＭ１６内に維持され、ＲＡＭ
１６は１つ又は多数のＲＡＭユニットを有していること
ができる。好ましい実施例において行われる好ましいデ
ータ構造のより詳細な説明は、それらを構築し維持する
圧縮ユニット４の説明の間に、以下に説明される。
【００９６】以下に論じられる全ての数値パラメータの
値（例えば、ＭＥＭＳＩＺＥ、１６ビットＨＰＴＲサイ
ズ等）が、本発明の圧縮伸張技術の背後にある基本概念
に影響を与えることなく修正され得ることを、当業者は
認識するであろう。
値（例えば、ＭＥＭＳＩＺＥ、１６ビットＨＰＴＲサイ
ズ等）が、本発明の圧縮伸張技術の背後にある基本概念
に影響を与えることなく修正され得ることを、当業者は
認識するであろう。
【００９７】上記実施例において、バイトがマッチしな
かった場合には、スライディングウインドウ探索２４
が、入力バイトストリームの履歴アレイを遡って現在の
入力バイトまでマッチし、現在の入力バイトを含むスト
リングを探索する。そのような新たなストリングが見い
だされた場合には、マッチの長さがインクリメントさ
れ、新たなマッチストリングの位置が定められて記憶さ
れる。このように、このストリングマッチが「拡張」さ
れている。そのような新たなストリングが見いだされな
い場合には、或いは、非常に多くの以前の入力バイトエ
ントリーが探索されなくてはならない場合には、現在の
マッチするストリングが最大のストリングであると見な
され、そのコード化トークンが出力される。コード化さ
れたトークンは、その長さ及び入力バイトストリームを
格納する履歴内の相対位置を含んでいる。オフセット
は、バッファ内のストリングの開始位置からマッチした
バイトまでのバイト数として算出される。このバイト数
は、好ましい実施例においては１からメモリサイズ（Ｍ
ＥＭＳＩＺＥ−１）の範囲である。
かった場合には、スライディングウインドウ探索２４
が、入力バイトストリームの履歴アレイを遡って現在の
入力バイトまでマッチし、現在の入力バイトを含むスト
リングを探索する。そのような新たなストリングが見い
だされた場合には、マッチの長さがインクリメントさ
れ、新たなマッチストリングの位置が定められて記憶さ
れる。このように、このストリングマッチが「拡張」さ
れている。そのような新たなストリングが見いだされな
い場合には、或いは、非常に多くの以前の入力バイトエ
ントリーが探索されなくてはならない場合には、現在の
マッチするストリングが最大のストリングであると見な
され、そのコード化トークンが出力される。コード化さ
れたトークンは、その長さ及び入力バイトストリームを
格納する履歴内の相対位置を含んでいる。オフセット
は、バッファ内のストリングの開始位置からマッチした
バイトまでのバイト数として算出される。このバイト数
は、好ましい実施例においては１からメモリサイズ（Ｍ
ＥＭＳＩＺＥ−１）の範囲である。
【００９８】ハッシング技術は、好ましい実施例におい
ては、効率的なストリング探索を行うために用いられ
る。入力バイトストリームに対するストリング探索操作
を行うために多くの実現方法があることを当業者は認識
するであろう。特に、マッチするストリングを見いだす
ために用いられ得る多くのハッシング技術及び探索方法
がある。各種のハッシング技術についての完全な背景に
関しては、KnuthのSorting and Searching, The Art of
Computer Programming (Vol. 3) pp. 506-549 (1973)
を参照されたい。この文献は参考として本明細書に援用
されている。以下は、好ましい実施例によって用いられ
る特定のハッシング構造の詳細な説明である。説明され
るデータ構造及びアプローチが選択された理由は、それ
らが、ストリング探索機能のために必要なＲＡＭサイク
ルの数を最小とし、システムのスループットを最大とす
るからである。
ては、効率的なストリング探索を行うために用いられ
る。入力バイトストリームに対するストリング探索操作
を行うために多くの実現方法があることを当業者は認識
するであろう。特に、マッチするストリングを見いだす
ために用いられ得る多くのハッシング技術及び探索方法
がある。各種のハッシング技術についての完全な背景に
関しては、KnuthのSorting and Searching, The Art of
Computer Programming (Vol. 3) pp. 506-549 (1973)
を参照されたい。この文献は参考として本明細書に援用
されている。以下は、好ましい実施例によって用いられ
る特定のハッシング構造の詳細な説明である。説明され
るデータ構造及びアプローチが選択された理由は、それ
らが、ストリング探索機能のために必要なＲＡＭサイク
ルの数を最小とし、システムのスループットを最大とす
るからである。
【００９９】図４を参照して、ハッシュ構造の好ましい
実施例が説明される。すでに処理された（圧縮された、
又は生データとして圧縮されなかった）入力データの最
後のＭＥＭＳＩＺＥ（好ましくは２０４８）のキャラク
タを包含する履歴アレイ１０２がＲＡＭ１６に格納され
ている（図１（ａ））。新たな入力データがスライディ
ングウインドウ探索２４によって受け取られると、本発
明は、先ず、新たな入力データ中の少なくとも２バイト
の「ストリング」が履歴アレイ１０２中のストリングと
マッチするかどうかをチェックする。マッチすれば、少
なくとも３バイト長のマッチするストリングを見いだす
ように探索が拡張される。少なくとも３バイト長のマッ
チするストリングが見いだされると、マッチするストリ
ングを表すトークンが出力される。少なくとも３バイト
長のマッチするストリングが見いだされない場合には、
現在処理されているバイトを表す生データトークンが出
力される。
実施例が説明される。すでに処理された（圧縮された、
又は生データとして圧縮されなかった）入力データの最
後のＭＥＭＳＩＺＥ（好ましくは２０４８）のキャラク
タを包含する履歴アレイ１０２がＲＡＭ１６に格納され
ている（図１（ａ））。新たな入力データがスライディ
ングウインドウ探索２４によって受け取られると、本発
明は、先ず、新たな入力データ中の少なくとも２バイト
の「ストリング」が履歴アレイ１０２中のストリングと
マッチするかどうかをチェックする。マッチすれば、少
なくとも３バイト長のマッチするストリングを見いだす
ように探索が拡張される。少なくとも３バイト長のマッ
チするストリングが見いだされると、マッチするストリ
ングを表すトークンが出力される。少なくとも３バイト
長のマッチするストリングが見いだされない場合には、
現在処理されているバイトを表す生データトークンが出
力される。
【０１００】ハッシュテーブル１００は、履歴アレイ１
０２中の特定のストリングを素早く見いだすために用い
られる。ハッシュテーブル１００は、履歴アレイ１０２
への履歴アレイポインタを含む一連のエントリで構成さ
れている。オフセットアレイ１０４と称されている他の
データ構造はハッシュリンクテーブルである。オフセッ
トアレイ１０４中の各リンクリストの第１の要素は、特
定のハッシュ値に対応する履歴アレイ中の前のエントリ
を指し示している。リンクリスト中の最後の要素（この
要素は無効なポインタであってもよい）はこのハッシュ
値に関連付けられた最も古いエントリを指し示してい
る。スライディングウインドウ探索２４は、各入力バイ
トが処理された後にインクリメントされる１６ビットの
履歴ポインタＨＰＴＲ１０８を維持している。ＨＰＴＲ
１０８は０に初期化される。好ましい実施例において、
圧縮操作は、６４Ｋサイズよりも大きなブロックに関し
ては行われない。従って、ＨＰＴＲ１０８は、６４Ｋバ
イトがスライディングウインドウ探索２４によって処理
された後に、０へ戻るように「ラップ」する必要はな
い。ＨＰＴＲ１０８がラップしないので、ＨＰＴＲ１０
８の「ラッピング」によって無効となったハッシュテー
ブルからの古いエントリを取り除く必要がない。オフセ
ットアレイ１０４は実際には単純リンクリストから構成
された２次ハッシュである。ある特定のオフセットがＭ
ＥＭＳＩＺＥ−ＭＡＸＳＴＲ（ここでＭＡＸＳＴＲは探
索されている最大のストリングである）よりも大きい
か、又はリストの最近のエントリからの全てのリンクの
合計がＭＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも大きい場合
には、特定のハッシュビン（値）中に有効なエントリは
もはや存在しない。このようにして、ＭＥＭＳＩＺＥ−
ＭＡＸＳＴＲよりも古いエントリは履歴アレイ１０２の
終わりから効果的に「離れ落ちる（fall off）」。本発
明のこの点により、オフセットアレイ１０４中の単純リ
ンクリストの使用を可能にする。単純リンクリストの維
持は、二重リンクリストに比べて半分以下のメモリアク
セスによって行うことができる。
０２中の特定のストリングを素早く見いだすために用い
られる。ハッシュテーブル１００は、履歴アレイ１０２
への履歴アレイポインタを含む一連のエントリで構成さ
れている。オフセットアレイ１０４と称されている他の
データ構造はハッシュリンクテーブルである。オフセッ
トアレイ１０４中の各リンクリストの第１の要素は、特
定のハッシュ値に対応する履歴アレイ中の前のエントリ
を指し示している。リンクリスト中の最後の要素（この
要素は無効なポインタであってもよい）はこのハッシュ
値に関連付けられた最も古いエントリを指し示してい
る。スライディングウインドウ探索２４は、各入力バイ
トが処理された後にインクリメントされる１６ビットの
履歴ポインタＨＰＴＲ１０８を維持している。ＨＰＴＲ
１０８は０に初期化される。好ましい実施例において、
圧縮操作は、６４Ｋサイズよりも大きなブロックに関し
ては行われない。従って、ＨＰＴＲ１０８は、６４Ｋバ
イトがスライディングウインドウ探索２４によって処理
された後に、０へ戻るように「ラップ」する必要はな
い。ＨＰＴＲ１０８がラップしないので、ＨＰＴＲ１０
８の「ラッピング」によって無効となったハッシュテー
ブルからの古いエントリを取り除く必要がない。オフセ
ットアレイ１０４は実際には単純リンクリストから構成
された２次ハッシュである。ある特定のオフセットがＭ
ＥＭＳＩＺＥ−ＭＡＸＳＴＲ（ここでＭＡＸＳＴＲは探
索されている最大のストリングである）よりも大きい
か、又はリストの最近のエントリからの全てのリンクの
合計がＭＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも大きい場合
には、特定のハッシュビン（値）中に有効なエントリは
もはや存在しない。このようにして、ＭＥＭＳＩＺＥ−
ＭＡＸＳＴＲよりも古いエントリは履歴アレイ１０２の
終わりから効果的に「離れ落ちる（fall off）」。本発
明のこの点により、オフセットアレイ１０４中の単純リ
ンクリストの使用を可能にする。単純リンクリストの維
持は、二重リンクリストに比べて半分以下のメモリアク
セスによって行うことができる。
【０１０１】図５〜図７及び図８を参照して、本発明の
スライディングウインドウ探索の詳細な流れ図が論じら
れる。流れ図（図５〜図７及び図８）の特定のデータ経
路を示すハード的に配線された版を図９に示す。
スライディングウインドウ探索の詳細な流れ図が論じら
れる。流れ図（図５〜図７及び図８）の特定のデータ経
路を示すハード的に配線された版を図９に示す。
【０１０２】より詳細には、図５〜図７において、スラ
イディングウインドウ探索ルーチンがブロック１０９で
スタートする。次に、ブロック１１０では、初期化ルー
チン（図８）が呼び出され、図４に示すハッシュ構造が
初期化される。この操作は、新たなウインドウ探索操作
のそれぞれの開始時に行われる。
イディングウインドウ探索ルーチンがブロック１０９で
スタートする。次に、ブロック１１０では、初期化ルー
チン（図８）が呼び出され、図４に示すハッシュ構造が
初期化される。この操作は、新たなウインドウ探索操作
のそれぞれの開始時に行われる。
【０１０３】図８において、ブロック１１２では、ハッ
シュポインタ１０８（ＨＰＴＲ）が０に設定される。ブ
ロック１１４（図８）では、現在コード化されているビ
ットストリングの現在の長さを追跡するためのマッチ長
変数（「ＭＡＴＣＨＬＥＮ」）が０に設定される。次
に、ブロック１２０の間に、ハッシュテーブル１００が
値ＨＰＴＲ−ＭＥＭＳＩＺＥで埋められる。このステッ
プにより、ハッシュテーブル１００の以前の有効な全て
の値が効果的に空にされる。
シュポインタ１０８（ＨＰＴＲ）が０に設定される。ブ
ロック１１４（図８）では、現在コード化されているビ
ットストリングの現在の長さを追跡するためのマッチ長
変数（「ＭＡＴＣＨＬＥＮ」）が０に設定される。次
に、ブロック１２０の間に、ハッシュテーブル１００が
値ＨＰＴＲ−ＭＥＭＳＩＺＥで埋められる。このステッ
プにより、ハッシュテーブル１００の以前の有効な全て
の値が効果的に空にされる。
【０１０４】図５〜図７を再び参照すると、初期化ルー
チン（図８）の終了後、入力されるデータストリームか
らのバイトを受け入れるためにスライディングウインド
ウ探索が始まり得る。ブロック１２８の間に、操作を初
期化するために、履歴アレイ１０２の最初の２つのバイ
トが入力データで埋められる。この２バイトは、レジス
タＩＮＲＥＧ０及びＩＮＲＥＧ１に保持される。新たな
１バイトが処理される度に、第１バイト及び次の入力バ
イトのハッシュ（「Ｈ」）が計算される。好ましい実施
例において、ＩＮＲＥＧ０を左に４ビットシフトたもの
とＩＮＲＥＧ１との排他的論理和を求めることによって
ハッシュが計算される。上述のように、Knuth（以前に
参照した）によって論じられるいずれのハッシュ関数も
適用可能である。新たな１個の入力バイトが処理される
度に、ＩＮＲＥＧ１の内容がＩＮＲＥＧ０へ移され、Ｉ
ＮＲＥＧ１には新たなバイト値がロードされる。
チン（図８）の終了後、入力されるデータストリームか
らのバイトを受け入れるためにスライディングウインド
ウ探索が始まり得る。ブロック１２８の間に、操作を初
期化するために、履歴アレイ１０２の最初の２つのバイ
トが入力データで埋められる。この２バイトは、レジス
タＩＮＲＥＧ０及びＩＮＲＥＧ１に保持される。新たな
１バイトが処理される度に、第１バイト及び次の入力バ
イトのハッシュ（「Ｈ」）が計算される。好ましい実施
例において、ＩＮＲＥＧ０を左に４ビットシフトたもの
とＩＮＲＥＧ１との排他的論理和を求めることによって
ハッシュが計算される。上述のように、Knuth（以前に
参照した）によって論じられるいずれのハッシュ関数も
適用可能である。新たな１個の入力バイトが処理される
度に、ＩＮＲＥＧ１の内容がＩＮＲＥＧ０へ移され、Ｉ
ＮＲＥＧ１には新たなバイト値がロードされる。
【０１０５】ブロック１２８で処理される各バイトに対
して、ハッシュ値Ｈ（「Ｈ」）が計算され、新たなハッ
シュ値に対応するハッシュリスト内の古いエントリが読
み出されてＮＥＸＴと称される変数に格納される。ま
た、ブロック１２８では、現在のハッシュ値に対応する
ハッシュテーブル中の古いエントリがＨＰＴＲの現在の
値で置換される。ブロック１４０では、ＨＰＴＲ−ＮＥ
ＸＴ＞＝ＭＥＭＳＩＺＥ−ＭＡＸＳＴＲであるかどうか
が判定される。変数ＭＡＸＳＴＲは、履歴アレイ１０２
中で見いだされるバイトのマッチするストリングが現在
処理されているバイトによって上書きされないことを保
証する、探索されている最大ストリングサイズの値であ
る。ＭＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも大きいか又は
等しい値にであると判定されると、処理はブロック１４
２へ進み、変数ＮＥＸＴはＨＰＴＲ−ＭＥＭＳＩＺＥに
等しく設定される。言い換えると、履歴の最後のＭＥＭ
ＳＩＺＥバイト中にマッチするストリングがなかったた
め、ハッシュビンが空にされる。
して、ハッシュ値Ｈ（「Ｈ」）が計算され、新たなハッ
シュ値に対応するハッシュリスト内の古いエントリが読
み出されてＮＥＸＴと称される変数に格納される。ま
た、ブロック１２８では、現在のハッシュ値に対応する
ハッシュテーブル中の古いエントリがＨＰＴＲの現在の
値で置換される。ブロック１４０では、ＨＰＴＲ−ＮＥ
ＸＴ＞＝ＭＥＭＳＩＺＥ−ＭＡＸＳＴＲであるかどうか
が判定される。変数ＭＡＸＳＴＲは、履歴アレイ１０２
中で見いだされるバイトのマッチするストリングが現在
処理されているバイトによって上書きされないことを保
証する、探索されている最大ストリングサイズの値であ
る。ＭＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも大きいか又は
等しい値にであると判定されると、処理はブロック１４
２へ進み、変数ＮＥＸＴはＨＰＴＲ−ＭＥＭＳＩＺＥに
等しく設定される。言い換えると、履歴の最後のＭＥＭ
ＳＩＺＥバイト中にマッチするストリングがなかったた
め、ハッシュビンが空にされる。
【０１０６】ＭＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも大き
いか又は等しい値となるかどうかの判定に拘らず、処理
はブロック１４４へ進む。ブロック１４４では、値ＨＰ
ＴＲ−ＮＥＸＴが対応するオフセットアレイ１０４のエ
ントリであるＯＦＦＳＥＴ（ＨＰＴＲ）に書き込まれ
る。同様に、ブロック１４４では、ＩＮＲＥＧ１の値が
履歴アレイ１０２のエントリであるＨＩＳＴＯＲＹ（Ｈ
ＰＴＲ）に置かれる。上記ブロック１２８、１４０、１
４２及び１４４で行われるステップにより、現在処理さ
れているバイトに必要なデータ構造の保守は完了し、こ
の時点で、履歴アレイ１０２の内容のストリング探索が
開始され得る。スライディングウインドウ探索がストリ
ングマッチを現在処理しているかどうかに拘らず、処理
される全ての入力バイトに対して上記ハウスキーピング
機能が行われることに注意されたい。他の実施例におい
て、ハウスキーピング機能の幾つかは、圧縮比率でのわ
ずかなコストでの操作のスループットを増大させるため
に、処理される入力バイトの幾つかに対してのみ行われ
る。
いか又は等しい値となるかどうかの判定に拘らず、処理
はブロック１４４へ進む。ブロック１４４では、値ＨＰ
ＴＲ−ＮＥＸＴが対応するオフセットアレイ１０４のエ
ントリであるＯＦＦＳＥＴ（ＨＰＴＲ）に書き込まれ
る。同様に、ブロック１４４では、ＩＮＲＥＧ１の値が
履歴アレイ１０２のエントリであるＨＩＳＴＯＲＹ（Ｈ
ＰＴＲ）に置かれる。上記ブロック１２８、１４０、１
４２及び１４４で行われるステップにより、現在処理さ
れているバイトに必要なデータ構造の保守は完了し、こ
の時点で、履歴アレイ１０２の内容のストリング探索が
開始され得る。スライディングウインドウ探索がストリ
ングマッチを現在処理しているかどうかに拘らず、処理
される全ての入力バイトに対して上記ハウスキーピング
機能が行われることに注意されたい。他の実施例におい
て、ハウスキーピング機能の幾つかは、圧縮比率でのわ
ずかなコストでの操作のスループットを増大させるため
に、処理される入力バイトの幾つかに対してのみ行われ
る。
【０１０７】ブロック１４６では、マッチ長変数ＭＡＴ
ＣＨＬＥＮが０に等しいかどうかが判定される。ブロッ
ク１１４の初期化ルーチン（図８）ではＭＡＴＣＨＬＥ
Ｎ変数が０に設定されたことを想起されたい。ＭＡＴＣ
ＨＬＥＮは、現在のストリングマッチ長を包含してお
り、操作の開始時には０である。ここで、圧縮操作の開
始時での処理を行っており、ＭＡＴＣＨＬＥＮが０であ
る場合には、内部ハッシュカウンタＨＡＳＨＣＮＴが０
に設定される。ＨＡＳＨＣＮＴは、いずれかの特定のス
トリング探索の反復を制限するために用いられる。次
に、ブロック１５０では、ＨＰＴＲ−ＮＥＸＴ＞＝ＭＥ
ＭＳＩＺＥ−ＭＡＸＳＴＲであるかどうかが判定され
る。得られる値がＭＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも
小さいと判定されると、処理はブロック１５２へ進む。
ブロック１５２の間に、変数ＩＮＲＥＧ１が履歴アレイ
のＨＩＳＴＯＲＹ（ＮＥＸＴ）の値に等しいかどうかが
判定される。このステップの目的は、履歴アレイ中の先
行するエントリに対して、ＩＮＲＥＧ０及びＩＮＲＥＧ
１における２バイトにマッチする２バイトストリングを
探索することである。ＩＮＲＥＧ１における値のみがＨ
ＩＳＴＯＲＹ（ＮＥＸＴ）の値と比較される。なぜな
ら、ハッシュ機能が、ＩＮＲＥＧ０に対して１対１の写
影が行われるように選択されるので、ハッシュリスト中
の各ストリングからの１バイトのみがＩＮＲＥＧ１と比
較される必要があるからである。このステップは、本実
施例の性能を高める。なぜなら、２バイト比較に代えて
１バイトの比較を行うだけでよいからである。ブロック
１５０においてＭＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも大
きい又は等しいと判定された場合には、処理はブロック
１５８へ進む。ブロック１５８では、ＩＮＲＥＧ０バイ
トを示す生のデータバイトトークンが出力され、処理が
ブロック１２５へ進む。ブロック１２５では、次の入力
バイトが得られ、処理全体が再び開始される。
ＣＨＬＥＮが０に等しいかどうかが判定される。ブロッ
ク１１４の初期化ルーチン（図８）ではＭＡＴＣＨＬＥ
Ｎ変数が０に設定されたことを想起されたい。ＭＡＴＣ
ＨＬＥＮは、現在のストリングマッチ長を包含してお
り、操作の開始時には０である。ここで、圧縮操作の開
始時での処理を行っており、ＭＡＴＣＨＬＥＮが０であ
る場合には、内部ハッシュカウンタＨＡＳＨＣＮＴが０
に設定される。ＨＡＳＨＣＮＴは、いずれかの特定のス
トリング探索の反復を制限するために用いられる。次
に、ブロック１５０では、ＨＰＴＲ−ＮＥＸＴ＞＝ＭＥ
ＭＳＩＺＥ−ＭＡＸＳＴＲであるかどうかが判定され
る。得られる値がＭＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも
小さいと判定されると、処理はブロック１５２へ進む。
ブロック１５２の間に、変数ＩＮＲＥＧ１が履歴アレイ
のＨＩＳＴＯＲＹ（ＮＥＸＴ）の値に等しいかどうかが
判定される。このステップの目的は、履歴アレイ中の先
行するエントリに対して、ＩＮＲＥＧ０及びＩＮＲＥＧ
１における２バイトにマッチする２バイトストリングを
探索することである。ＩＮＲＥＧ１における値のみがＨ
ＩＳＴＯＲＹ（ＮＥＸＴ）の値と比較される。なぜな
ら、ハッシュ機能が、ＩＮＲＥＧ０に対して１対１の写
影が行われるように選択されるので、ハッシュリスト中
の各ストリングからの１バイトのみがＩＮＲＥＧ１と比
較される必要があるからである。このステップは、本実
施例の性能を高める。なぜなら、２バイト比較に代えて
１バイトの比較を行うだけでよいからである。ブロック
１５０においてＭＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも大
きい又は等しいと判定された場合には、処理はブロック
１５８へ進む。ブロック１５８では、ＩＮＲＥＧ０バイ
トを示す生のデータバイトトークンが出力され、処理が
ブロック１２５へ進む。ブロック１２５では、次の入力
バイトが得られ、処理全体が再び開始される。
【０１０８】ブロック１５２においてマッチしていると
判定された場合には、処理はブロック１６０へ進み、変
数ＭＡＴＣＨＰＴＲが変数ＮＥＸＴの値に等しく設定さ
れる。加えて、変数ＭＡＴＣＨＬＥＮが２バイトマッチ
を示すように２に設定され、長さ２よりも大きなマッチ
するストリングが結局ない場合には、ＩＮＲＥＧ０の内
容が変数ＯＬＤＲＡＷに格納される。処理は、ブロック
１２５へ進み、そこで、次の入力バイトが得られる。し
かしながら、ＨＩＳＴＯＲＹ（ＮＥＸＴ）での値がマッ
チしない場合には、処理はブロック１５４へ進み、ＨＡ
ＳＨＣＮＴの値がインクリメントされ、変数ＮＥＸＴが
ＮＥＸＴ−ＯＦＦＳＥＴ（ＮＥＸＴ）に等しく設定され
る。このステップにより、オフセットアレイ１０４によ
ってリンクされている次のエントリが効果的に指し示さ
れる。処理はブロック１５６へ進み、ＨＡＳＨＣＮＴが
所定の最大カウント値ＭＡＸＨＣＮＴ（典型的には８）
に達しているかどうかが判定される。ＨＡＳＨＣＮＴが
ＭＡＸＨＣＮＴよりも大きい又は等しい場合には、処理
はブロック１５８へ進み、ＩＮＲＥＧ０に対する出力生
バイトトークンが出力され、処理はブロック１２５へ進
む。しかしながら、ＨＡＳＨＣＮＴがＭＡＸＨＣＮＴよ
りも大きくなく又は等しくもない場合には、ＨＡＳＨＣ
ＮＴがＭＡＸＨＣＮＴ（つまり、好ましい実施例では
８）に達するまで、又はハッシュリスト中にそれ以上有
効なエントリが存在しなくなるまで（ブロック１５０で
判定される）、又はマッチするストリングが見いだされ
るまで（ブロック１５２）、ブロック１５０、１５２、
１５４及び１５６の処理を継続する。
判定された場合には、処理はブロック１６０へ進み、変
数ＭＡＴＣＨＰＴＲが変数ＮＥＸＴの値に等しく設定さ
れる。加えて、変数ＭＡＴＣＨＬＥＮが２バイトマッチ
を示すように２に設定され、長さ２よりも大きなマッチ
するストリングが結局ない場合には、ＩＮＲＥＧ０の内
容が変数ＯＬＤＲＡＷに格納される。処理は、ブロック
１２５へ進み、そこで、次の入力バイトが得られる。し
かしながら、ＨＩＳＴＯＲＹ（ＮＥＸＴ）での値がマッ
チしない場合には、処理はブロック１５４へ進み、ＨＡ
ＳＨＣＮＴの値がインクリメントされ、変数ＮＥＸＴが
ＮＥＸＴ−ＯＦＦＳＥＴ（ＮＥＸＴ）に等しく設定され
る。このステップにより、オフセットアレイ１０４によ
ってリンクされている次のエントリが効果的に指し示さ
れる。処理はブロック１５６へ進み、ＨＡＳＨＣＮＴが
所定の最大カウント値ＭＡＸＨＣＮＴ（典型的には８）
に達しているかどうかが判定される。ＨＡＳＨＣＮＴが
ＭＡＸＨＣＮＴよりも大きい又は等しい場合には、処理
はブロック１５８へ進み、ＩＮＲＥＧ０に対する出力生
バイトトークンが出力され、処理はブロック１２５へ進
む。しかしながら、ＨＡＳＨＣＮＴがＭＡＸＨＣＮＴよ
りも大きくなく又は等しくもない場合には、ＨＡＳＨＣ
ＮＴがＭＡＸＨＣＮＴ（つまり、好ましい実施例では
８）に達するまで、又はハッシュリスト中にそれ以上有
効なエントリが存在しなくなるまで（ブロック１５０で
判定される）、又はマッチするストリングが見いだされ
るまで（ブロック１５２）、ブロック１５０、１５２、
１５４及び１５６の処理を継続する。
【０１０９】最終的に、処理はブロック１２５へ進み、
この時点で、スライディングウイントウ探索は、次の入
力データバイトを処理する準備ができている。ブロック
１２５では、ＨＰＴＲがインクリメントされる。ＭＡＴ
ＣＨＬＥＮがブロック１４６で０よりも大きいと判定さ
れるまで、ブロック１２８、１４０、１４２、１４４、
１４６、１４８、１５０、１５２、１５４、１５６、１
５８、１６０及び１２５の処理が継続される。ブロック
１４６では、ＭＡＴＣＨＬＥＮが０に等しくない場合に
は、処理がブロック１６２へ進むことに注意されたい。
ブロック１６２では、変数ＭＡＴＣＨＰＴＲが１だけイ
ンクリメントされる。このように、新たな値ＩＮＲＥＧ
１は、履歴アレイ１０２中のＭＡＴＣＨＰＴＲにおいて
見いだされるＭＡＴＣＨＬＥＮ＋１の長さのストリーム
における次のバイトと比較される。ブロック１６４で
は、バイトがマッチしているかどうかの判定がなされ
る。バイトがマッチする場合には、ブロック１８０でＭ
ＡＴＣＨＬＥＮがインクリメントされてストリングが拡
張され、処理はブロック１２５へ進む。しかしながら、
バイトがマッチしない場合には、処理はブロック１６６
へ進み、変数ＮＥＸＴがＭＡＴＣＨＰＴＲ−ＭＡＴＣＨ
ＬＥＮ＋１に等しく設定される。処理は、ブロック１６
８へ進み、変数ＮＥＸＴがＮＥＸＴ−ＯＦＦＳＥＴ（Ｎ
ＥＸＴ）に等しく設定される。加えて、ブロック１６８
では、変数ＨＡＳＨＣＮＴがインクリメントされる。ス
テップ１６６及び１６８は、ハッシュリストの残りの連
続するストリングエントリにおいた、マッチがとれる元
のストリングを探索するスライディングウインドウ探索
を効果的に引き起こす。ブロック１７０では、ＨＰＴＲ
−ＮＥＸＴ＞＝ＭＥＭＳＩＺＥ−ＭＡＸＳＴＲであるか
どうかが判定される。ＭＥＭＳＩＺＥ−ＭＡＸＳＴＲよ
りも大きいと判定された場合には、有効なエントリはそ
れ以上存在せず、処理はブロック１２４へ進む。ブロッ
ク１２４では、ＭＡＴＣＨＬＥＮが２よりも大きいかど
うかが判定される。大きくないと判定されると、処理は
ブロック１２６へ進み、変数ＯＬＤＲＡＷにおける生デ
ータバイトを表す出力トークンが出力される。その後、
ＮＥＸＴはＩＮＲＥＧ１及びＩＮＲＥＧ０の最新のハッ
シュ値に対応して、ハッシュリストで置換される。その
後、ＭＴＡＣＨＬＥＮが０にリセットされ、処理はブロ
ック１４８から再開される。
この時点で、スライディングウイントウ探索は、次の入
力データバイトを処理する準備ができている。ブロック
１２５では、ＨＰＴＲがインクリメントされる。ＭＡＴ
ＣＨＬＥＮがブロック１４６で０よりも大きいと判定さ
れるまで、ブロック１２８、１４０、１４２、１４４、
１４６、１４８、１５０、１５２、１５４、１５６、１
５８、１６０及び１２５の処理が継続される。ブロック
１４６では、ＭＡＴＣＨＬＥＮが０に等しくない場合に
は、処理がブロック１６２へ進むことに注意されたい。
ブロック１６２では、変数ＭＡＴＣＨＰＴＲが１だけイ
ンクリメントされる。このように、新たな値ＩＮＲＥＧ
１は、履歴アレイ１０２中のＭＡＴＣＨＰＴＲにおいて
見いだされるＭＡＴＣＨＬＥＮ＋１の長さのストリーム
における次のバイトと比較される。ブロック１６４で
は、バイトがマッチしているかどうかの判定がなされ
る。バイトがマッチする場合には、ブロック１８０でＭ
ＡＴＣＨＬＥＮがインクリメントされてストリングが拡
張され、処理はブロック１２５へ進む。しかしながら、
バイトがマッチしない場合には、処理はブロック１６６
へ進み、変数ＮＥＸＴがＭＡＴＣＨＰＴＲ−ＭＡＴＣＨ
ＬＥＮ＋１に等しく設定される。処理は、ブロック１６
８へ進み、変数ＮＥＸＴがＮＥＸＴ−ＯＦＦＳＥＴ（Ｎ
ＥＸＴ）に等しく設定される。加えて、ブロック１６８
では、変数ＨＡＳＨＣＮＴがインクリメントされる。ス
テップ１６６及び１６８は、ハッシュリストの残りの連
続するストリングエントリにおいた、マッチがとれる元
のストリングを探索するスライディングウインドウ探索
を効果的に引き起こす。ブロック１７０では、ＨＰＴＲ
−ＮＥＸＴ＞＝ＭＥＭＳＩＺＥ−ＭＡＸＳＴＲであるか
どうかが判定される。ＭＥＭＳＩＺＥ−ＭＡＸＳＴＲよ
りも大きいと判定された場合には、有効なエントリはそ
れ以上存在せず、処理はブロック１２４へ進む。ブロッ
ク１２４では、ＭＡＴＣＨＬＥＮが２よりも大きいかど
うかが判定される。大きくないと判定されると、処理は
ブロック１２６へ進み、変数ＯＬＤＲＡＷにおける生デ
ータバイトを表す出力トークンが出力される。その後、
ＮＥＸＴはＩＮＲＥＧ１及びＩＮＲＥＧ０の最新のハッ
シュ値に対応して、ハッシュリストで置換される。その
後、ＭＴＡＣＨＬＥＮが０にリセットされ、処理はブロ
ック１４８から再開される。
【０１１０】ブロック１２４でＭＡＴＣＨＬＥＮが２よ
りも大きいと判定された場合には、処理はブロック１８
２へ進み、スライディングウインドウ探索２４が、マッ
チするストリングの長さ（ＭＡＴＣＨＬＥＮ）及び履歴
アレイ１０２内でのそのオフセット（ＯＦＦＳＥＴ＝Ｈ
ＰＴＲ−ＭＡＴＣＨＰＴＲ）を表すトークンを出力す
る。処理はブロック１８４へ進み、ＭＡＴＣＨＬＥＮが
０に設定され、処理は、新たなバイトに対してブロック
１２５を開始する。
りも大きいと判定された場合には、処理はブロック１８
２へ進み、スライディングウインドウ探索２４が、マッ
チするストリングの長さ（ＭＡＴＣＨＬＥＮ）及び履歴
アレイ１０２内でのそのオフセット（ＯＦＦＳＥＴ＝Ｈ
ＰＴＲ−ＭＡＴＣＨＰＴＲ）を表すトークンを出力す
る。処理はブロック１８４へ進み、ＭＡＴＣＨＬＥＮが
０に設定され、処理は、新たなバイトに対してブロック
１２５を開始する。
【０１１１】しかしながら、ブロック１７０においてＭ
ＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも小さいと判定された
場合には、処理はブロック１７２へ進み、ＭＡＴＣＨＬ
ＥＮ＞＝ＭＡＸＳＴＲであるかどうかが判定される。Ｍ
ＡＴＣＨＬＥＮ＞＝ＭＡＸＳＴＲである場合には、探索
は限界に達し、処理はブロック１２４へ続く。しかしな
がら、ＭＡＴＣＨＬＥＮがＭＡＸＳＴＲよりも大きくな
く、等しくもないと判定される場合には、処理はブロッ
ク１７４へ進む。
ＥＭＳＩＺＥ−ＭＡＸＳＴＲよりも小さいと判定された
場合には、処理はブロック１７２へ進み、ＭＡＴＣＨＬ
ＥＮ＞＝ＭＡＸＳＴＲであるかどうかが判定される。Ｍ
ＡＴＣＨＬＥＮ＞＝ＭＡＸＳＴＲである場合には、探索
は限界に達し、処理はブロック１２４へ続く。しかしな
がら、ＭＡＴＣＨＬＥＮがＭＡＸＳＴＲよりも大きくな
く、等しくもないと判定される場合には、処理はブロッ
ク１７４へ進む。
【０１１２】ブロック１７４では、位置ＨＩＳＴＯＲＹ
（ＮＥＸＴ）におけるＭＡＴＣＨＬＥＮ＋１の現在のス
トリングが内部マッチバッファの内容に等しいかどうか
が判定される。内部マッチバッファは、現在のマッチし
ているストリングのＭＡＴＣＨＬＥＮ個の全てのバイト
を包含している。このバッファによって、このストリン
グをマッチさせる最初の試みが失敗しても、新たなスト
リングの探索が高速化される。マッチが行われる度にマ
ッチをとろうとするバイトを得るためにＲＡＭにアクセ
スする必要はなく、マッチをとろうとするバイトがチッ
プ内で即座に利用可能であるので効率的である。言い換
えると、マッチバッファは、処理を効率的に向上するた
めのルックアサイド（ｌｏｏｋ ａｓｉｄｅ）バッファ
として機能する。マッチバッファの長さは有限である
（好ましい実施例においてＭＡＸＳＴＲ＝８バイト）。
（ＮＥＸＴ）におけるＭＡＴＣＨＬＥＮ＋１の現在のス
トリングが内部マッチバッファの内容に等しいかどうか
が判定される。内部マッチバッファは、現在のマッチし
ているストリングのＭＡＴＣＨＬＥＮ個の全てのバイト
を包含している。このバッファによって、このストリン
グをマッチさせる最初の試みが失敗しても、新たなスト
リングの探索が高速化される。マッチが行われる度にマ
ッチをとろうとするバイトを得るためにＲＡＭにアクセ
スする必要はなく、マッチをとろうとするバイトがチッ
プ内で即座に利用可能であるので効率的である。言い換
えると、マッチバッファは、処理を効率的に向上するた
めのルックアサイド（ｌｏｏｋ ａｓｉｄｅ）バッファ
として機能する。マッチバッファの長さは有限である
（好ましい実施例においてＭＡＸＳＴＲ＝８バイト）。
【０１１３】ＨＩＳＴＯＲＹ（ＮＥＸＴ）におけるＭＡ
ＴＣＨＬＥＮ＋１のストリングがマッチバッファの内容
に等しい場合には、処理はブロック１７８へ進み、変数
ＭＡＴＣＨＰＴＲがＮＥＸＴ＋ＭＡＴＣＨＬＥＮに等し
く設定される。処理はブロック１８０へ進み、そこで、
ＭＡＴＣＨＬＥＮがインクリメントされ、処理はブロク
１２５へ進む。ブロック１２５では、入力データストリ
ームにおける次の新たなバイトが処理される。しかしな
がら、ＨＩＳＴＯＲＹ（ＮＥＸＴ）におけるストリング
がマッチバッファに等しくない場合には、処理がブロッ
ク１７６へ進み、変数ＨＡＳＨＣＮＴがＭＡＸＨＣＮＴ
よりも大きい又は等しいかどうかに関する判定がなされ
る。ＨＡＳＨＣＮＴがＭＡＸＨＣＮＴよりも大きい又は
等しい場合には、処理はブロック１８２及び１８４へ進
み、履歴アレイにおけるマッチの長さ及びオフセットを
含むマッチストリングトークンが出力され、変数ＭＡＴ
ＣＨＬＥＮが０に設定される。処理は、ブロック１２５
へ進み、次の新たな入力データバイトが処理される。し
かしながら、ブロック１７６においてＨＡＳＨＣＮＴが
ＭＡＸＨＣＮＴよりも大きくなく又は等しくもない場合
には、処理は、ＭＡＴＣＨＬＥＮ＋１の長さのマッチが
見いだされるまで、又はＨＡＳＨＣＮＴがＭＡＸＨＣＮ
Ｔに達するまで、又は有効なハッシュエントリがそれ以
上存在しなくなるまで（ＨＰＴＲ−ＮＥＸＴ＞＝ＭＥＭ
ＳＩＺＥ−ＭＡＸＳＴＲ）、ブロック１６８、１７０、
１７２、１７４及び１７６の処理を継続する。
ＴＣＨＬＥＮ＋１のストリングがマッチバッファの内容
に等しい場合には、処理はブロック１７８へ進み、変数
ＭＡＴＣＨＰＴＲがＮＥＸＴ＋ＭＡＴＣＨＬＥＮに等し
く設定される。処理はブロック１８０へ進み、そこで、
ＭＡＴＣＨＬＥＮがインクリメントされ、処理はブロク
１２５へ進む。ブロック１２５では、入力データストリ
ームにおける次の新たなバイトが処理される。しかしな
がら、ＨＩＳＴＯＲＹ（ＮＥＸＴ）におけるストリング
がマッチバッファに等しくない場合には、処理がブロッ
ク１７６へ進み、変数ＨＡＳＨＣＮＴがＭＡＸＨＣＮＴ
よりも大きい又は等しいかどうかに関する判定がなされ
る。ＨＡＳＨＣＮＴがＭＡＸＨＣＮＴよりも大きい又は
等しい場合には、処理はブロック１８２及び１８４へ進
み、履歴アレイにおけるマッチの長さ及びオフセットを
含むマッチストリングトークンが出力され、変数ＭＡＴ
ＣＨＬＥＮが０に設定される。処理は、ブロック１２５
へ進み、次の新たな入力データバイトが処理される。し
かしながら、ブロック１７６においてＨＡＳＨＣＮＴが
ＭＡＸＨＣＮＴよりも大きくなく又は等しくもない場合
には、処理は、ＭＡＴＣＨＬＥＮ＋１の長さのマッチが
見いだされるまで、又はＨＡＳＨＣＮＴがＭＡＸＨＣＮ
Ｔに達するまで、又は有効なハッシュエントリがそれ以
上存在しなくなるまで（ＨＰＴＲ−ＮＥＸＴ＞＝ＭＥＭ
ＳＩＺＥ−ＭＡＸＳＴＲ）、ブロック１６８、１７０、
１７２、１７４及び１７６の処理を継続する。
【０１１４】好ましい実施例において、上記操作は、Ｒ
ＡＭ１６（図１（ａ））が全てのクロックサイクルでも
使用中であることを保証するために、パイプライン化さ
れる。なぜなら、ＲＡＭサイクルカウントが性能を制限
する要因であるからである。
ＡＭ１６（図１（ａ））が全てのクロックサイクルでも
使用中であることを保証するために、パイプライン化さ
れる。なぜなら、ＲＡＭサイクルカウントが性能を制限
する要因であるからである。
【０１１５】典型的には、記憶システムにおいて、デー
タは、一定サイズのセクタ又はブロックへ分割されなく
てはならず、所定段階で圧縮が切り捨てられ、次に、残
りの入力ストリームに関する新たな処理が再スタートす
る。圧縮ユニット４はその後、後述される特別な「圧縮
データの終わり」トークンを出力する。
タは、一定サイズのセクタ又はブロックへ分割されなく
てはならず、所定段階で圧縮が切り捨てられ、次に、残
りの入力ストリームに関する新たな処理が再スタートす
る。圧縮ユニット４はその後、後述される特別な「圧縮
データの終わり」トークンを出力する。
【０１１６】本発明がなされる過程において、圧縮方法
の広範なソフトウエアシミュレーションが行われた。Ｍ
ＡＸＨＣＮＴ、ＨＡＳＨＳＩＺＥ、マッチバッファサイ
ズ及びＭＥＭＳＩＺＥを含む全てのパラメータの値が変
化させられて、スループット及び圧縮比に対するそれら
のパラメータの影響が調べられた。好ましい実施例の特
定の形式及びパラメータの組は、これらの性能上の論点
に対して受け入れ可能なトレードオフが得られるように
選択された。しかし、多くの類似のパラメータの組及び
コード化は実質的に同様の性能に帰着する。
の広範なソフトウエアシミュレーションが行われた。Ｍ
ＡＸＨＣＮＴ、ＨＡＳＨＳＩＺＥ、マッチバッファサイ
ズ及びＭＥＭＳＩＺＥを含む全てのパラメータの値が変
化させられて、スループット及び圧縮比に対するそれら
のパラメータの影響が調べられた。好ましい実施例の特
定の形式及びパラメータの組は、これらの性能上の論点
に対して受け入れ可能なトレードオフが得られるように
選択された。しかし、多くの類似のパラメータの組及び
コード化は実質的に同様の性能に帰着する。
【０１１７】図９に、好適な実施態様におけるスライデ
ィングウインドウ探索２４（図２）および出力トークン
の生成を含む回路図２２８を示す。回路２２８の要素は
デジタル論理によって実現される。回路２２８は、圧縮
コントローラ兼シーケンスユニット２３０によって制御
される。圧縮コントローラ兼シーケンスユニット２３０
は、回路２２８の要素のそれぞれに一連の制御ライン
（図示せず）によってリンクされている。好適な実施態
様では、毎秒数メガヘルツで作動する内部クロック（図
示せず）は、作動中の各クロックサイクルにおいて１個
以上の要素に働きかけるコントローラ兼シーケンスユニ
ット２３０の活性化レベルを定める。実際の作動および
それらのシーケンスは、すでに論じた図５〜図７および
図８に示されている。
ィングウインドウ探索２４（図２）および出力トークン
の生成を含む回路図２２８を示す。回路２２８の要素は
デジタル論理によって実現される。回路２２８は、圧縮
コントローラ兼シーケンスユニット２３０によって制御
される。圧縮コントローラ兼シーケンスユニット２３０
は、回路２２８の要素のそれぞれに一連の制御ライン
（図示せず）によってリンクされている。好適な実施態
様では、毎秒数メガヘルツで作動する内部クロック（図
示せず）は、作動中の各クロックサイクルにおいて１個
以上の要素に働きかけるコントローラ兼シーケンスユニ
ット２３０の活性化レベルを定める。実際の作動および
それらのシーケンスは、すでに論じた図５〜図７および
図８に示されている。
【０１１８】回路２２８におけるデータフローのより詳
細な説明を行う。入力バイトストリームの圧縮されてい
ないバイトは、圧縮ユニット４に入力され、ライン２４
４を介して入力ＦＩＦＯ２３２に与えられる。入力ＦＩ
ＦＯ２３２に格納されたバイトは、２個の拡張ＦＩＦＯ
レジスタＩＮＲＥＧ１（２３３）およびＩＮＲＥＧ０
（２３５）に転送される。より詳細には、ＦＩＦＯ２３
２からのデータはライン２４６を介してＩＮＲＥＧ１レ
ジスタ２３３に与えられる。ＩＮＲＥＧ１レジスタ２３
３に格納されたデータは、次にライン２４８および２５
０を介してＩＮＲＥＧ０レジスタ２３５に転送される。
ＩＮＲＥＧ１およびＩＮＲＥＧ０レジスタの目的はハッ
シュ関数２３７への入力を発生することにあることを想
起されたい。ハッシュ関数２３７の出力はライン２５５
を介してマルチプレクサ２５６へ伝送される。
細な説明を行う。入力バイトストリームの圧縮されてい
ないバイトは、圧縮ユニット４に入力され、ライン２４
４を介して入力ＦＩＦＯ２３２に与えられる。入力ＦＩ
ＦＯ２３２に格納されたバイトは、２個の拡張ＦＩＦＯ
レジスタＩＮＲＥＧ１（２３３）およびＩＮＲＥＧ０
（２３５）に転送される。より詳細には、ＦＩＦＯ２３
２からのデータはライン２４６を介してＩＮＲＥＧ１レ
ジスタ２３３に与えられる。ＩＮＲＥＧ１レジスタ２３
３に格納されたデータは、次にライン２４８および２５
０を介してＩＮＲＥＧ０レジスタ２３５に転送される。
ＩＮＲＥＧ１およびＩＮＲＥＧ０レジスタの目的はハッ
シュ関数２３７への入力を発生することにあることを想
起されたい。ハッシュ関数２３７の出力はライン２５５
を介してマルチプレクサ２５６へ伝送される。
【０１１９】ＩＮＲＥＧ１レジスタ２３３において、マ
ッチングストリングが見い出せない場合には、それはラ
イン２４８、２５４、および２５８を介して出力管理部
２６０へ送られる。出力管理部２６０の目的は、生のデ
ータバイトおよびマッチングストリングの出力トークン
を生成することにある。出力管理部２６０の出力は、ラ
イン２６２を介してビットバイト変換器２６４へ伝送さ
れる。次にこのデータはライン２６８を介して出力ＦＩ
ＦＯ２３４に入力される。出力トークンは、出力ＦＩＦ
Ｏ２３４からライン２７０を介して中間バッファ（図２
の２８）へ出力される。
ッチングストリングが見い出せない場合には、それはラ
イン２４８、２５４、および２５８を介して出力管理部
２６０へ送られる。出力管理部２６０の目的は、生のデ
ータバイトおよびマッチングストリングの出力トークン
を生成することにある。出力管理部２６０の出力は、ラ
イン２６２を介してビットバイト変換器２６４へ伝送さ
れる。次にこのデータはライン２６８を介して出力ＦＩ
ＦＯ２３４に入力される。出力トークンは、出力ＦＩＦ
Ｏ２３４からライン２７０を介して中間バッファ（図２
の２８）へ出力される。
【０１２０】ＩＮＲＥＧ１レジスタ２３３の内容はま
た、ライン２４８、２５４、および２７２を介して内部
マッチバッファ２７４へ送られる。内部マッチバッファ
２７４の目的は、マッチングプロセスの能力を効果的に
向上させるための「ルックアサイド（lookaside）」バ
ッファとして機能することにある。マッチバッファ２７
４の内容はバイト比較レジスタ２７６の内容と比較され
る。マッチバッファの内容は、ライン２７８上に多重化
されてバイト比較レジスタ２７６へ送られる。バイト比
較レジスタ２７６の内容は外部のＲＡＭ２３８内に格納
されている履歴アレイ１０２（図４）から得られる。履
歴アレイのエントリの内容は、ライン２８０を介してラ
ッチ２８２に入力され、次に、ライン２８４および２８
６を介してバイト比較レジスタ２７６へ送られる。ブロ
ック２７６によって実行されるバイト比較の結果は、ラ
イン２８８を介して圧縮コントローラ兼シーケンスユニ
ット２３０に伝達される。圧縮コントローラ兼シーケン
スユニット２３０は比較結果を評価し、制御ライン（図
示せず）を介して回路２２８の様々な要素に適切な制御
信号を送り出す。
た、ライン２４８、２５４、および２７２を介して内部
マッチバッファ２７４へ送られる。内部マッチバッファ
２７４の目的は、マッチングプロセスの能力を効果的に
向上させるための「ルックアサイド（lookaside）」バ
ッファとして機能することにある。マッチバッファ２７
４の内容はバイト比較レジスタ２７６の内容と比較され
る。マッチバッファの内容は、ライン２７８上に多重化
されてバイト比較レジスタ２７６へ送られる。バイト比
較レジスタ２７６の内容は外部のＲＡＭ２３８内に格納
されている履歴アレイ１０２（図４）から得られる。履
歴アレイのエントリの内容は、ライン２８０を介してラ
ッチ２８２に入力され、次に、ライン２８４および２８
６を介してバイト比較レジスタ２７６へ送られる。ブロ
ック２７６によって実行されるバイト比較の結果は、ラ
イン２８８を介して圧縮コントローラ兼シーケンスユニ
ット２３０に伝達される。圧縮コントローラ兼シーケン
スユニット２３０は比較結果を評価し、制御ライン（図
示せず）を介して回路２２８の様々な要素に適切な制御
信号を送り出す。
【０１２１】ＩＮＲＥＧ０レジスタ２３５の内容はま
た、ライン２５１および２９０を介してマルチプレクサ
２９２へ送られ得る。マルチプレクサ２９２は調停を行
い、ＩＮＲＥＧ０の内容をライン２９４を介してラッチ
２９６へ送る。ラッチ２９６の内容は、ライン２９８を
介してＲＡＭ２３８内のデータ構造の履歴アレイ１０２
（図４）へ出力される。
た、ライン２５１および２９０を介してマルチプレクサ
２９２へ送られ得る。マルチプレクサ２９２は調停を行
い、ＩＮＲＥＧ０の内容をライン２９４を介してラッチ
２９６へ送る。ラッチ２９６の内容は、ライン２９８を
介してＲＡＭ２３８内のデータ構造の履歴アレイ１０２
（図４）へ出力される。
【０１２２】ライン２８０を介してＲＡＭ２３８から入
力されるデータはまた、ラッチ２８２並びにライン２８
４、３００、および３０２を介してレジスタ３０４へ送
られる。このパス上のデータは、ＮＥＸＴと称される変
数に格納された古いハッシュポインタを含んでいる。レ
ジスタ３０４の内容は、ライン３０５、３０６、および
３０７を介してマルチプレクサ２５６へ出力される。レ
ジスタ３０４の出力はまた、ライン３０５および３０８
を介してオフセットレジスタ３１０に与えられる。オフ
セットレジスタ３１０の機能について簡単に説明する。
レジスタ３０４の内容はまた、ライン３０４、３０５、
３０６、および３１２を介してＭＡＴＣＨＰＴＲのため
の変数内容を含むレジスタ３１４へ送られる。レジスタ
３１４の出力（ＭＡＴＣＨＰＴＲ）は、ライン３１６を
介してマルチプレクサ２５６へ送られる。レジスタ３１
８の目的は、ポインタＨＰＴＲをインクリメントするこ
とである。レジスタ３１８の出力は、ライン３２０およ
び３２２を介してマルチプレクサ２５６へ送られる。他
に、レジスタ３１８の出力はまた、ライン３２０および
３２４を介してオフセットレジスタ３１０へ送られる。
オフセット関数の目的は、履歴アレイ中の適切なオフセ
ットを計算すること、またはライン３２４および３０８
を介してレジスタ３１８および３０４から入力されるデ
ータからＨＰＴＲ−ＮＥＸＴを計算することにある。
力されるデータはまた、ラッチ２８２並びにライン２８
４、３００、および３０２を介してレジスタ３０４へ送
られる。このパス上のデータは、ＮＥＸＴと称される変
数に格納された古いハッシュポインタを含んでいる。レ
ジスタ３０４の内容は、ライン３０５、３０６、および
３０７を介してマルチプレクサ２５６へ出力される。レ
ジスタ３０４の出力はまた、ライン３０５および３０８
を介してオフセットレジスタ３１０に与えられる。オフ
セットレジスタ３１０の機能について簡単に説明する。
レジスタ３０４の内容はまた、ライン３０４、３０５、
３０６、および３１２を介してＭＡＴＣＨＰＴＲのため
の変数内容を含むレジスタ３１４へ送られる。レジスタ
３１４の出力（ＭＡＴＣＨＰＴＲ）は、ライン３１６を
介してマルチプレクサ２５６へ送られる。レジスタ３１
８の目的は、ポインタＨＰＴＲをインクリメントするこ
とである。レジスタ３１８の出力は、ライン３２０およ
び３２２を介してマルチプレクサ２５６へ送られる。他
に、レジスタ３１８の出力はまた、ライン３２０および
３２４を介してオフセットレジスタ３１０へ送られる。
オフセット関数の目的は、履歴アレイ中の適切なオフセ
ットを計算すること、またはライン３２４および３０８
を介してレジスタ３１８および３０４から入力されるデ
ータからＨＰＴＲ−ＮＥＸＴを計算することにある。
【０１２３】修正スイッチ３２８はライン３３０を介し
てオフセットレジスタ３１０に与えられ、これによって
オフセット関数はライン３２４を介して入力される現在
のＨＰＴＲのみを出力するようになる。修正スイッチ３
２８が、オフセット関数が定められるように設定された
場合には、オフセット関数３１０の出力は、マルチプレ
クサ２９２または出力管理部２６０のいずれかに送られ
る。その出力が出力管理部２６０へ送られる場合には、
それはライン３３２および３３６を介して送られる。オ
フセットは出力管理部２６０においてコード化ストリン
グにコード化される。他方、その出力はライン３３２お
よび３３４を介してマルチプレクサ２９２へ送られ、次
にライン２９４を介してラッチ２９６へ、そしてライン
２９８を介してＲＡＭ２３８へ出力される。しかし、修
正スイッチ３２８がオフセットレジスタ３１０の出力が
現在のＨＰＴＲであるように設定された場合には、その
出力は、ライン２９４上の出力を調停するマルチプレク
サ２９２へライン３３２および３３４を介して送られ
る。
てオフセットレジスタ３１０に与えられ、これによって
オフセット関数はライン３２４を介して入力される現在
のＨＰＴＲのみを出力するようになる。修正スイッチ３
２８が、オフセット関数が定められるように設定された
場合には、オフセット関数３１０の出力は、マルチプレ
クサ２９２または出力管理部２６０のいずれかに送られ
る。その出力が出力管理部２６０へ送られる場合には、
それはライン３３２および３３６を介して送られる。オ
フセットは出力管理部２６０においてコード化ストリン
グにコード化される。他方、その出力はライン３３２お
よび３３４を介してマルチプレクサ２９２へ送られ、次
にライン２９４を介してラッチ２９６へ、そしてライン
２９８を介してＲＡＭ２３８へ出力される。しかし、修
正スイッチ３２８がオフセットレジスタ３１０の出力が
現在のＨＰＴＲであるように設定された場合には、その
出力は、ライン２９４上の出力を調停するマルチプレク
サ２９２へライン３３２および３３４を介して送られ
る。
【０１２４】出力管理部２６０へのコード化のための長
さ入力は、回路図２２８の最下部に示されているレジス
タ３３８によって維持されている。レジスタ３３８の出
力はライン３４０を介して出力管理部２６０に与えられ
る。マルチプレクサ２５６の目的は、ＲＡＭ２３８内の
適切なデータ構造を選択するために、ライン３１６、３
２２、３０７および２５５上のアドレスの内のいずれを
出力するかを調停することにある。
さ入力は、回路図２２８の最下部に示されているレジス
タ３３８によって維持されている。レジスタ３３８の出
力はライン３４０を介して出力管理部２６０に与えられ
る。マルチプレクサ２５６の目的は、ＲＡＭ２３８内の
適切なデータ構造を選択するために、ライン３１６、３
２２、３０７および２５５上のアドレスの内のいずれを
出力するかを調停することにある。
【０１２５】図１０を参照して、入力および出力ＦＩＦ
Ｏの使用について説明する。入力ＦＩＦＯ２３２（図
９）および出力ＦＩＦＯ２３４（図９）を、圧縮ユニッ
ト４の入力および出力側に示す。入力および出力ＦＩＦ
Ｏは好ましくは、圧縮ユニット４および伸張ユニット６
と同じチップ内にある。
Ｏの使用について説明する。入力ＦＩＦＯ２３２（図
９）および出力ＦＩＦＯ２３４（図９）を、圧縮ユニッ
ト４の入力および出力側に示す。入力および出力ＦＩＦ
Ｏは好ましくは、圧縮ユニット４および伸張ユニット６
と同じチップ内にある。
【０１２６】図１１に、本発明の圧縮されたデータ出力
フォーマットを４００として示す。圧縮されたデータ出
力フォーマット４００は、圧縮されたハフマン長テーブ
ル４０２およびコード化されたハフマントークン４０４
から構成される。コード化されたハフマントークン４０
４は、生のデータバイトまたはハフマン長テーブルに従
ったマッチングストリングを表現している。図１１にも
示す各コード化されたハフマントークン４０４はハフマ
ンビンコード４０６を有している。ハフマンビンコード
４０６が１より多い可能なオフセットを有するマッチン
グストリングを示すなら、コード化されたハフマントー
クン４０４はまた、特定のハフマンビンコード４０６に
対するストリングの正確なオフセットを示す余分なオフ
セットビット４０８を有する。同様に、ハフマンビンコ
ード４０６が１より多い可能な長さを有するマッチング
ストリングを示すなら、コード化されたハフマントーク
ン４０４はまた、特定のハフマンビンコード４０６に対
するストリングの正確な長さを示す余分な長さビット４
１０を有する。
フォーマットを４００として示す。圧縮されたデータ出
力フォーマット４００は、圧縮されたハフマン長テーブ
ル４０２およびコード化されたハフマントークン４０４
から構成される。コード化されたハフマントークン４０
４は、生のデータバイトまたはハフマン長テーブルに従
ったマッチングストリングを表現している。図１１にも
示す各コード化されたハフマントークン４０４はハフマ
ンビンコード４０６を有している。ハフマンビンコード
４０６が１より多い可能なオフセットを有するマッチン
グストリングを示すなら、コード化されたハフマントー
クン４０４はまた、特定のハフマンビンコード４０６に
対するストリングの正確なオフセットを示す余分なオフ
セットビット４０８を有する。同様に、ハフマンビンコ
ード４０６が１より多い可能な長さを有するマッチング
ストリングを示すなら、コード化されたハフマントーク
ン４０４はまた、特定のハフマンビンコード４０６に対
するストリングの正確な長さを示す余分な長さビット４
１０を有する。
【０１２７】ほとんどのデータにおいて、ストリングの
大部分が長さ３、４、または５であることが経験によっ
て判明している。このため、好適な実施態様では、これ
らのストリング長は複数のハフマンビンに分割され、こ
れによりオフセット分布に対するハフマンコードのより
良いマッチングが可能となっている。ハフマンビン内の
これらのストリングの長さおよびオフセットを組み合わ
せなければ、ストリングのハフマン丸め誤差はより有意
なものとなる。例えば、これらの長さのストリングに対
するトークン確率によれば（オフセットを無視して）、
大抵が２〜５ビットの長さを有するハフマンコードを導
いている。長さおよびオフセットを基にしてこれらのビ
ンを分割すると、これらのビンのハフマン長は典型的に
は６〜１０ビットの範囲である。このビン分割によって
得られる余分なコーディング効率により、ほんの２Ｋバ
イトのウインドウサイズでもってしても良好な圧縮比率
が得られる。また、より大きいウインドウを用いると、
組み合わせたビンを用いない場合よりも組み合わせた長
さ／オフセット対を用いる方がわずかに高い圧縮比率が
得られた。
大部分が長さ３、４、または５であることが経験によっ
て判明している。このため、好適な実施態様では、これ
らのストリング長は複数のハフマンビンに分割され、こ
れによりオフセット分布に対するハフマンコードのより
良いマッチングが可能となっている。ハフマンビン内の
これらのストリングの長さおよびオフセットを組み合わ
せなければ、ストリングのハフマン丸め誤差はより有意
なものとなる。例えば、これらの長さのストリングに対
するトークン確率によれば（オフセットを無視して）、
大抵が２〜５ビットの長さを有するハフマンコードを導
いている。長さおよびオフセットを基にしてこれらのビ
ンを分割すると、これらのビンのハフマン長は典型的に
は６〜１０ビットの範囲である。このビン分割によって
得られる余分なコーディング効率により、ほんの２Ｋバ
イトのウインドウサイズでもってしても良好な圧縮比率
が得られる。また、より大きいウインドウを用いると、
組み合わせたビンを用いない場合よりも組み合わせた長
さ／オフセット対を用いる方がわずかに高い圧縮比率が
得られた。
【０１２８】図１２は、本発明に従ったトークンビンの
配列の一例を示す表である。列４５０はハフマンビンの
数を示し、列４５２は各ビンによって表現されているも
のの記述を示し、また列４５４は、存在するならば、各
ビンによって表現されているオフセットの範囲内での正
確なオフセットを特定する必要がある余分なオフセット
ビットの数を示している。例えば行４６２はハフマンビ
ン０から２５５がコード０から２５５を有する生のバイ
トを表現することを示している。生のバイトコードはＡ
ＳＣＩＩまたは他の類似のコード体系から決定され得
る。生のバイトはマッチングストリングではないので、
ハフマンビン０から２５５は余分なオフセットビットを
必要としない。別の実施例では、行４６４はハフマンビ
ン２５６から２５８が１のオフセットを有している長さ
３、４、および５のマッチングストリングそれぞれを表
現していることを示している。１つのオフセット値のみ
がハフマンビン２５６から２５８のそれぞれによって示
されるので、これらのビンは余分なオフセットビットを
必要としない。さらなる実施例では、行４６６はハフマ
ンビン２９５から２９７が１２８から１９１の範囲のオ
フセット値を有する、長さ３、４、および５のマッチン
グストリングそれぞれを表現していることを示してい
る。１２８から１９１の範囲にある６４個のオフセット
値の何れが所定の出力トークンによって表現されるかを
特定するために、６つの余分なオフセットビットが必要
とされる。
配列の一例を示す表である。列４５０はハフマンビンの
数を示し、列４５２は各ビンによって表現されているも
のの記述を示し、また列４５４は、存在するならば、各
ビンによって表現されているオフセットの範囲内での正
確なオフセットを特定する必要がある余分なオフセット
ビットの数を示している。例えば行４６２はハフマンビ
ン０から２５５がコード０から２５５を有する生のバイ
トを表現することを示している。生のバイトコードはＡ
ＳＣＩＩまたは他の類似のコード体系から決定され得
る。生のバイトはマッチングストリングではないので、
ハフマンビン０から２５５は余分なオフセットビットを
必要としない。別の実施例では、行４６４はハフマンビ
ン２５６から２５８が１のオフセットを有している長さ
３、４、および５のマッチングストリングそれぞれを表
現していることを示している。１つのオフセット値のみ
がハフマンビン２５６から２５８のそれぞれによって示
されるので、これらのビンは余分なオフセットビットを
必要としない。さらなる実施例では、行４６６はハフマ
ンビン２９５から２９７が１２８から１９１の範囲のオ
フセット値を有する、長さ３、４、および５のマッチン
グストリングそれぞれを表現していることを示してい
る。１２８から１９１の範囲にある６４個のオフセット
値の何れが所定の出力トークンによって表現されるかを
特定するために、６つの余分なオフセットビットが必要
とされる。
【０１２９】さらに別の実施例では、行４６８がハフマ
ンビン３１９から３３３が長さ６から２０のマッチング
ストリングそれぞれを表現することを示している。６以
上の長さを有するマッチングストリングに対するオフセ
ットを特定するために必要とされる余分なオフセットビ
ットを図１３に示し、以下に説明する。さらに別の実施
例では、行４７０はハフマンビン３３４が長さ２１以上
のストリングを表現することを示している。このビンは
１つの特定の長さより長いストリングを表現しているた
め、余分な長さビットはこのビンを含有するトークンに
よって表現される特定の長さを特定する必要がある。こ
のビン中のマッチングストリングの長さを特定する必要
がある余分な長さビットを図１４に示し、以下に説明す
る。長さが６以上のマッチングストリングのオフセット
を特定する必要がある余分なオフセットビットを図１３
に示し、以下に説明する。最後の実施例では、行４７２
はハフマンビン３３５が圧縮されたデータマーカーの末
端部を表現することを示している。明らかに余分なオフ
セットビットは必要とされない。
ンビン３１９から３３３が長さ６から２０のマッチング
ストリングそれぞれを表現することを示している。６以
上の長さを有するマッチングストリングに対するオフセ
ットを特定するために必要とされる余分なオフセットビ
ットを図１３に示し、以下に説明する。さらに別の実施
例では、行４７０はハフマンビン３３４が長さ２１以上
のストリングを表現することを示している。このビンは
１つの特定の長さより長いストリングを表現しているた
め、余分な長さビットはこのビンを含有するトークンに
よって表現される特定の長さを特定する必要がある。こ
のビン中のマッチングストリングの長さを特定する必要
がある余分な長さビットを図１４に示し、以下に説明す
る。長さが６以上のマッチングストリングのオフセット
を特定する必要がある余分なオフセットビットを図１３
に示し、以下に説明する。最後の実施例では、行４７２
はハフマンビン３３５が圧縮されたデータマーカーの末
端部を表現することを示している。明らかに余分なオフ
セットビットは必要とされない。
【０１３０】当業者であれば、基本圧縮技術を変えるこ
となく、本明細書に記載の全てのパラメータ（例えば、
ＭＥＭＳＩＺＥ、特定のビン配列等）の値を改変し得る
ことを認識するだろう。
となく、本明細書に記載の全てのパラメータ（例えば、
ＭＥＭＳＩＺＥ、特定のビン配列等）の値を改変し得る
ことを認識するだろう。
【０１３１】好適な実施態様では、長さが６以上の全て
のストリングは図１３に示す固定オフセットコード化を
用いている。別の実施態様では、長さが６以上のストリ
ングもまた、好適な実施態様において長さ３、４、およ
び５のストリングに用いられたものと同様の、組み合わ
せたストリング長およびオフセット範囲を持つビンを有
し得る。しかし、ほとんどのストリングが長さ５以下で
あるため、追加のハフマンテーブルエントリを格納する
ために必要とされる余分なスペースは、より長いストリ
ング上におけるより良いコーディングによる利得と匹敵
するものであり、そのような実施態様においては、圧縮
比率において極めて適度な利得が得られたことが、経験
により判明した。同様に、別の実施態様において２バイ
トである最小のストリング長を用いると、ほとんどまた
は全く圧縮比率利得が経験的に観察されなかったが、こ
れは生のバイト上のハフマンがストリングコード化と同
様に長さが２のストリングを典型的にコード化するため
であろう。
のストリングは図１３に示す固定オフセットコード化を
用いている。別の実施態様では、長さが６以上のストリ
ングもまた、好適な実施態様において長さ３、４、およ
び５のストリングに用いられたものと同様の、組み合わ
せたストリング長およびオフセット範囲を持つビンを有
し得る。しかし、ほとんどのストリングが長さ５以下で
あるため、追加のハフマンテーブルエントリを格納する
ために必要とされる余分なスペースは、より長いストリ
ング上におけるより良いコーディングによる利得と匹敵
するものであり、そのような実施態様においては、圧縮
比率において極めて適度な利得が得られたことが、経験
により判明した。同様に、別の実施態様において２バイ
トである最小のストリング長を用いると、ほとんどまた
は全く圧縮比率利得が経験的に観察されなかったが、こ
れは生のバイト上のハフマンがストリングコード化と同
様に長さが２のストリングを典型的にコード化するため
であろう。
【０１３２】図１３の５０２に示すように、１から３２
の範囲のオフセットが２つのビット「００」およびそれ
に続く５ビットからなる余分なオフセットビットにより
表現されている。５０４に示すように、３３から１６０
の範囲のオフセットが２つのビット「０１」およびそれ
に続く７ビットからなる余分なオフセットビットで表現
されている。５０６に示すように、１６１から６７２の
範囲のオフセットが２つのビット「１０」およびそれに
続く９ビットからなる余分なオフセットビットで表現さ
れている。５０８に示すように、６７３から２０４７の
範囲のオフセットが２つのビット「１１」およびそれに
続く１１ビットからなる余分なオフセットビットで表現
されている。
の範囲のオフセットが２つのビット「００」およびそれ
に続く５ビットからなる余分なオフセットビットにより
表現されている。５０４に示すように、３３から１６０
の範囲のオフセットが２つのビット「０１」およびそれ
に続く７ビットからなる余分なオフセットビットで表現
されている。５０６に示すように、１６１から６７２の
範囲のオフセットが２つのビット「１０」およびそれに
続く９ビットからなる余分なオフセットビットで表現さ
れている。５０８に示すように、６７３から２０４７の
範囲のオフセットが２つのビット「１１」およびそれに
続く１１ビットからなる余分なオフセットビットで表現
されている。
【０１３３】図１４に、長さが２１以上であるストリン
グの長さを表現するために用いた余分な長さビットの配
列の一例を表にして示す。５２０の列は可能なストリン
グ長を示しており、５２２の列は所定の長さを特定する
ために用いられる対応する余分な長さビットを示してい
る。
グの長さを表現するために用いた余分な長さビットの配
列の一例を表にして示す。５２０の列は可能なストリン
グ長を示しており、５２２の列は所定の長さを特定する
ために用いられる対応する余分な長さビットを示してい
る。
【０１３４】図１５に、ハフマン長からハフマンコード
を割り当てるアルゴリズムをＣプログラム言語で記載す
る。５４０において、一例であるサブルーチンを通過し
た変数を定義する。変数「lengths」は各コードの長さ
の配列である。変数「codes」は、サブルーチンによっ
て生成される割り当てられたハフマンコードの配列であ
り、それぞれ３２ビットを限度とする。変数「size」は
「lengths」配列中のエントリ数を表現する整数であ
る。５４２において、サブルーチンの頻度カウントが初
期化される。５４４において、各長さの頻度がカウント
される。５４６において、ベースコードが割り当てられ
る。５４８において実際のハフマンコードがビンに割り
当てられる。
を割り当てるアルゴリズムをＣプログラム言語で記載す
る。５４０において、一例であるサブルーチンを通過し
た変数を定義する。変数「lengths」は各コードの長さ
の配列である。変数「codes」は、サブルーチンによっ
て生成される割り当てられたハフマンコードの配列であ
り、それぞれ３２ビットを限度とする。変数「size」は
「lengths」配列中のエントリ数を表現する整数であ
る。５４２において、サブルーチンの頻度カウントが初
期化される。５４４において、各長さの頻度がカウント
される。５４６において、ベースコードが割り当てられ
る。５４８において実際のハフマンコードがビンに割り
当てられる。
【０１３５】図１６において、本発明に従ってハフマン
長さテーブルをコード化するために用いられるランレン
グス符号化の使用法を示す。長さテーブル５７０は種々
のセグメント５７２を含有する。セグメント５７２は、
ゼロカウント５７４、非ゼロカウント５７６および非ゼ
ロ長さ５８０を有している。ゼロカウント５７４および
非ゼロカウント５７６はそれぞれカウント５７８を有し
ている。カウント５７８はゼロまたは非ゼロカウントを
表現する。カウント５７８は図１６に示すようにコード
化される。「００００」のカウントは全テーブルの末端
部を表現する。カウント「０００１」から「１１１０」
はカウント１から１４をそれぞれ表現する。カウント１
５から２７０は「１１１１」およびそれに続く８ビット
からなるカウントによって表現される。非ゼロ長さ５８
０は図１６に示すようにコード化される。「００００」
の非ゼロ長さは全テーブルの末端部を示す。「０００
１」から「１１１１」の非ゼロ長さは１から１５の非ゼ
ロ長さをそれぞれ表現する。
長さテーブルをコード化するために用いられるランレン
グス符号化の使用法を示す。長さテーブル５７０は種々
のセグメント５７２を含有する。セグメント５７２は、
ゼロカウント５７４、非ゼロカウント５７６および非ゼ
ロ長さ５８０を有している。ゼロカウント５７４および
非ゼロカウント５７６はそれぞれカウント５７８を有し
ている。カウント５７８はゼロまたは非ゼロカウントを
表現する。カウント５７８は図１６に示すようにコード
化される。「００００」のカウントは全テーブルの末端
部を表現する。カウント「０００１」から「１１１０」
はカウント１から１４をそれぞれ表現する。カウント１
５から２７０は「１１１１」およびそれに続く８ビット
からなるカウントによって表現される。非ゼロ長さ５８
０は図１６に示すようにコード化される。「００００」
の非ゼロ長さは全テーブルの末端部を示す。「０００
１」から「１１１１」の非ゼロ長さは１から１５の非ゼ
ロ長さをそれぞれ表現する。
【０１３６】テーブルの符号化の一例を５８２に示す。
実施例において示す全ての数量は４ビットニブルであ
る。一例である長さテーブル５８４はコード化される以
下の長さを含有する：０、０、０、０、８、９、１、
０、５、４、０、０、０。テーブルの最初のセグメント
は４、３、８、９、１、であり、それは４つのゼロ、３
つの非ゼロ、および３つの非ゼロ長さ８、９、１を表現
している。テーブルの第２のセグメントは１、２、５、
４、であり、それは１つのゼロ、２つの非ゼロ、および
２つの非ゼロ長さ５、４を表現している。テーブルの最
後のセグメントは３、０であり、それは３つのゼロおよ
びテーブルの末端部を表現している。
実施例において示す全ての数量は４ビットニブルであ
る。一例である長さテーブル５８４はコード化される以
下の長さを含有する：０、０、０、０、８、９、１、
０、５、４、０、０、０。テーブルの最初のセグメント
は４、３、８、９、１、であり、それは４つのゼロ、３
つの非ゼロ、および３つの非ゼロ長さ８、９、１を表現
している。テーブルの第２のセグメントは１、２、５、
４、であり、それは１つのゼロ、２つの非ゼロ、および
２つの非ゼロ長さ５、４を表現している。テーブルの最
後のセグメントは３、０であり、それは３つのゼロおよ
びテーブルの末端部を表現している。
【０１３７】図１７〜図２２を参照して、小さな入力ス
トリームに対する圧縮ユニット４の簡潔化されてはいる
が完全な出力例の段階を、好適な実施態様におけるコー
ド化方法を用いて、説明する。この場合、入力ストリー
ムのサイズは図に示すにはあまりに小さいため、出力デ
ータストリームは実際には入力データストリームより大
きい。しかし、この例は、どのように圧縮符号化ステッ
プが実行されるかを正確に説明するのに役立つ。
トリームに対する圧縮ユニット４の簡潔化されてはいる
が完全な出力例の段階を、好適な実施態様におけるコー
ド化方法を用いて、説明する。この場合、入力ストリー
ムのサイズは図に示すにはあまりに小さいため、出力デ
ータストリームは実際には入力データストリームより大
きい。しかし、この例は、どのように圧縮符号化ステッ
プが実行されるかを正確に説明するのに役立つ。
【０１３８】図１７に、一例として、ＡＳＣＩＩテキス
トのフレーズ"this is a small small example"を示し
ている。列６００に、スライディングウインドウ探索に
よって生成されたトークンを挙げている。列６０２に、
各トークンに対応するハフマンビンを図１２に示すハフ
マンビン配列に従って表記する。
トのフレーズ"this is a small small example"を示し
ている。列６００に、スライディングウインドウ探索に
よって生成されたトークンを挙げている。列６０２に、
各トークンに対応するハフマンビンを図１２に示すハフ
マンビン配列に従って表記する。
【０１３９】図１８において、列６１０にハフマンビン
を数値順に表記する。列６１２に列６１０の各ビンに対
するビンカウントを表記する。列６１４に列６１０の各
ビンに対するハフマン長を表記する。列６１６に、列６
１０の各ビンに対して割り当てられたハフマンコードを
表記する。
を数値順に表記する。列６１２に列６１０の各ビンに対
するビンカウントを表記する。列６１４に列６１０の各
ビンに対するハフマン長を表記する。列６１６に、列６
１０の各ビンに対して割り当てられたハフマンコードを
表記する。
【０１４０】図１９に、圧縮されたハフマンテーブルを
示すが、全ての数値は１６進法ニブルで表している。圧
縮されたテーブルのセグメントを列６２０に表記する。
各テーブルセグメントに対応する記述を列６２２に載せ
る。
示すが、全ての数値は１６進法ニブルで表している。圧
縮されたテーブルのセグメントを列６２０に表記する。
各テーブルセグメントに対応する記述を列６２２に載せ
る。
【０１４１】図２０に、コード化されたトークンのビッ
トストリームを列６３０に示す。対応するコード化され
ていないトークンを列６３２に表記する。
トストリームを列６３０に示す。対応するコード化され
ていないトークンを列６３２に表記する。
【０１４２】図２１に、テーブルおよびコード化された
トークンからなる出力バイトストリーム６４０を示す。
図２２に、出力ワードにプットバック（put back）され
た出力バイトストリーム６４０からなる、出力ワードス
トリーム６４２を示す。
トークンからなる出力バイトストリーム６４０を示す。
図２２に、出力ワードにプットバック（put back）され
た出力バイトストリーム６４０からなる、出力ワードス
トリーム６４２を示す。
【０１４３】図２３に、本発明に従ってコード化された
伸張データの伸張操作を表わすフローブロック図を示
す。伸張操作は圧縮操作より簡潔であるが、それは主と
してストリング探索が必要でないこと、およびデータが
中間バッファなしに１回のパスで処理され得るためであ
る。
伸張データの伸張操作を表わすフローブロック図を示
す。伸張操作は圧縮操作より簡潔であるが、それは主と
してストリング探索が必要でないこと、およびデータが
中間バッファなしに１回のパスで処理され得るためであ
る。
【０１４４】伸張操作はブロック７００において開始
し、伸張ユニット６が圧縮された入力ストリームからハ
フマン長テーブルを読み込む。これらの長さは圧縮され
たフォーマット内に格納されているため、それらは圧縮
ユニット４に用いられる方法に従って圧縮された入力ビ
ットストリームから伸張される。好適な実施態様におい
ては、図１６のランレングス符号化が用いられるが、他
の多くの技術もまた使用可能である。公知の各ハフマン
ビンに対するコードの長さを用いて、処理はブロック７
０２に進み、図１５に示すアルゴリズムを用いて、ハフ
マンコードが各ビンに割り当てられる。トークンビンに
対するハフマンコードの場合、処理はブロック７０４に
進み、トークンをデコードするためにハフマンツリーが
構築される。 好適な実施態様では、ハフマンツリーは
図２４の７５０に示すように、記憶装置中のデータ構造
によって表現される。ツリーを７５６に図示する。対応
するハフマンコードを７５８に列挙する。データ構造７
５０の各メモリセルの内容は２つのフィールド、タグビ
ットフィールド７５２および子／ビンフィールド７５４
からなる。メモリセル中のタグビットはセルがツリーの
葉を含有しているか、または子があるかを知らせる。タ
グビットが子があることを示すと、セルの残りのビット
が左側の子のメモリアドレスＮを与え、右側の子がアド
レスＮ＋１に現れる。タグビットがこれがハフマンツリ
ーの葉であることを示すなら、メモリセルの残りのビッ
トは葉に関連したハフマンビン数を含有している。好適
な実施態様では、メモリ幅は、１つのタグビットおよび
１０のアドレスビットからなる少なくとも１１のビット
である。好適な実施態様では、３３６＊２メモリセルの
みが実際に完全なツリーを含むことを要求され、これが
１０ビットのアドレスを必要としている。
し、伸張ユニット６が圧縮された入力ストリームからハ
フマン長テーブルを読み込む。これらの長さは圧縮され
たフォーマット内に格納されているため、それらは圧縮
ユニット４に用いられる方法に従って圧縮された入力ビ
ットストリームから伸張される。好適な実施態様におい
ては、図１６のランレングス符号化が用いられるが、他
の多くの技術もまた使用可能である。公知の各ハフマン
ビンに対するコードの長さを用いて、処理はブロック７
０２に進み、図１５に示すアルゴリズムを用いて、ハフ
マンコードが各ビンに割り当てられる。トークンビンに
対するハフマンコードの場合、処理はブロック７０４に
進み、トークンをデコードするためにハフマンツリーが
構築される。 好適な実施態様では、ハフマンツリーは
図２４の７５０に示すように、記憶装置中のデータ構造
によって表現される。ツリーを７５６に図示する。対応
するハフマンコードを７５８に列挙する。データ構造７
５０の各メモリセルの内容は２つのフィールド、タグビ
ットフィールド７５２および子／ビンフィールド７５４
からなる。メモリセル中のタグビットはセルがツリーの
葉を含有しているか、または子があるかを知らせる。タ
グビットが子があることを示すと、セルの残りのビット
が左側の子のメモリアドレスＮを与え、右側の子がアド
レスＮ＋１に現れる。タグビットがこれがハフマンツリ
ーの葉であることを示すなら、メモリセルの残りのビッ
トは葉に関連したハフマンビン数を含有している。好適
な実施態様では、メモリ幅は、１つのタグビットおよび
１０のアドレスビットからなる少なくとも１１のビット
である。好適な実施態様では、３３６＊２メモリセルの
みが実際に完全なツリーを含むことを要求され、これが
１０ビットのアドレスを必要としている。
【０１４５】圧縮された入力データストリームからトー
クンを抜き出し、それらをデコードするために、一度に
１ビットずつが読みだされる。開始メモリアドレスがＭ
＝０に設定される。ビットがゼロなら、左ノード（アド
レスＭ）の内容が検査される。ビットが１なら、右ノー
ド（アドレスＭ＋１）の内容が検査される。問題のノー
ドが葉でないなら、ＭはＮ（そのメモリセルの残りのビ
ット）に等しくなるように設定され、ツリートラバーサ
ルが、この方法で葉ノードが見つかるまで継続される。
クンを抜き出し、それらをデコードするために、一度に
１ビットずつが読みだされる。開始メモリアドレスがＭ
＝０に設定される。ビットがゼロなら、左ノード（アド
レスＭ）の内容が検査される。ビットが１なら、右ノー
ド（アドレスＭ＋１）の内容が検査される。問題のノー
ドが葉でないなら、ＭはＮ（そのメモリセルの残りのビ
ット）に等しくなるように設定され、ツリートラバーサ
ルが、この方法で葉ノードが見つかるまで継続される。
【０１４６】ハフマンビンが生のバイトに相当するな
ら、伸張ユニット６は生のバイトを出力する。ハフマン
ビンがストリングに相当するなら、ストリングオフセッ
トおよび長さを特定する必要がある余分なビットが入力
データストリームから抜き出される。次にストリング
が、一度に１バイトずつ出力される。好適な実施態様で
は、ほとんどのスライディングウインドウ伸張体系でそ
うであるように、これは最後のＭＥＭＳＩＺＥバイト出
力の履歴アレイを維持し、バイトを引き出すオフセット
により履歴アレイ中へインデックスバック（indexing b
ack）することにより行われる。出力された全てのバイ
ト、生のバイトまたはストリングバイトのいずれかが、
履歴アレイに加えられる。ハフマンビンが圧縮されたデ
ータマークの末端部に対応するなら、伸張ユニット６は
停止する。そうでなければ、各ストリングまたは生のバ
イトを処理した後、トークンを抜き出す処理は、入力ス
トリームが消耗するまで、または圧縮されたデータマー
クの末端部が見つかるまで継続される。
ら、伸張ユニット６は生のバイトを出力する。ハフマン
ビンがストリングに相当するなら、ストリングオフセッ
トおよび長さを特定する必要がある余分なビットが入力
データストリームから抜き出される。次にストリング
が、一度に１バイトずつ出力される。好適な実施態様で
は、ほとんどのスライディングウインドウ伸張体系でそ
うであるように、これは最後のＭＥＭＳＩＺＥバイト出
力の履歴アレイを維持し、バイトを引き出すオフセット
により履歴アレイ中へインデックスバック（indexing b
ack）することにより行われる。出力された全てのバイ
ト、生のバイトまたはストリングバイトのいずれかが、
履歴アレイに加えられる。ハフマンビンが圧縮されたデ
ータマークの末端部に対応するなら、伸張ユニット６は
停止する。そうでなければ、各ストリングまたは生のバ
イトを処理した後、トークンを抜き出す処理は、入力ス
トリームが消耗するまで、または圧縮されたデータマー
クの末端部が見つかるまで継続される。
【０１４７】別の実施態様では、ハフマンテーブルがマ
ルチビットルックアップテーブルとして構築され、さら
に速い操作を可能とする。ビットの定数（Ｋ）が入力ス
トリームから抜き出され、２kエントリを有するテーブ
ル中でルックアップするために用いられる。テーブルサ
イズは典型的には５１２または１０２４エントリであ
り、Ｋ＝９または１０に相当する。各テーブルエントリ
はコード長（Ｌ）を含有しており、実際に必要とされる
ビット数を知らせる。このコード長がＫ以下であれば、
抜き出されたビットはハフマンビンを独特の方法で同定
するに充分なものであり、またテーブルエントリの残り
はハフマンビン数を特定する。この場合、入力データス
トリームから抜き出されたＫ−Ｌビットは実際には必要
でないため、それらはハフマンビン処理を進める前に入
力ストリームに効果的に「プットバック」された。Ｋが
Ｌよりも大きければ、テーブルエントリの残りは、好適
な実施態様において上述したように、一度に１ビットず
つ、トラバースされるハフマンサブツリーの残りのメモ
リ位置（Ｎ）を特定する。一般にテーブルの葉エントリ
は２(K-L)回反復される。この技術は、ほとんどのハフ
マンビンが、ハフマンコード長の１ビット当り１メモリ
サイクルではなく、１回のメモリサイクルにより抜き出
されることを可能にし、伸張プロセスの実質的なスピー
ドアップを導いている。
ルチビットルックアップテーブルとして構築され、さら
に速い操作を可能とする。ビットの定数（Ｋ）が入力ス
トリームから抜き出され、２kエントリを有するテーブ
ル中でルックアップするために用いられる。テーブルサ
イズは典型的には５１２または１０２４エントリであ
り、Ｋ＝９または１０に相当する。各テーブルエントリ
はコード長（Ｌ）を含有しており、実際に必要とされる
ビット数を知らせる。このコード長がＫ以下であれば、
抜き出されたビットはハフマンビンを独特の方法で同定
するに充分なものであり、またテーブルエントリの残り
はハフマンビン数を特定する。この場合、入力データス
トリームから抜き出されたＫ−Ｌビットは実際には必要
でないため、それらはハフマンビン処理を進める前に入
力ストリームに効果的に「プットバック」された。Ｋが
Ｌよりも大きければ、テーブルエントリの残りは、好適
な実施態様において上述したように、一度に１ビットず
つ、トラバースされるハフマンサブツリーの残りのメモ
リ位置（Ｎ）を特定する。一般にテーブルの葉エントリ
は２(K-L)回反復される。この技術は、ほとんどのハフ
マンビンが、ハフマンコード長の１ビット当り１メモリ
サイクルではなく、１回のメモリサイクルにより抜き出
されることを可能にし、伸張プロセスの実質的なスピー
ドアップを導いている。
【０１４８】図２３において、一度ハフマンツリーが構
築されると、処理はブロック７０６に進み、圧縮された
入力データストリームから次のハフマンコードが抜き出
され、そのコードで表現されたビンを決定するハフマン
コードに対するデータ構造へと続く。次に、ブロック７
０８において、ハフマンビンが生のバイトであるかが決
定される。生のバイトであれば、処理はブロック７１０
に進み、生のバイトが伸張データストリームに出力され
る。次に処理はブロック７０６に戻る。
築されると、処理はブロック７０６に進み、圧縮された
入力データストリームから次のハフマンコードが抜き出
され、そのコードで表現されたビンを決定するハフマン
コードに対するデータ構造へと続く。次に、ブロック７
０８において、ハフマンビンが生のバイトであるかが決
定される。生のバイトであれば、処理はブロック７１０
に進み、生のバイトが伸張データストリームに出力され
る。次に処理はブロック７０６に戻る。
【０１４９】ブロック７０８において、ハフマンビンが
生のバイトでないと決定されると、処理はブロック７１
２に進み、ハフマンビンが「圧縮されたデータの末端
部」マーカであるか否かが決定される。是であれば、処
理は終了し伸張は完了する。否であれば、処理はブロッ
ク７１４に進み、特定のハフマンビンにとって必要であ
れば余分なストリングオフセットビットが抜き出され
る。次に処理はブロック７１６に進み、特定のハフマン
ビンにとって必要であれば余分なストリング長ビットが
抜き出される。
生のバイトでないと決定されると、処理はブロック７１
２に進み、ハフマンビンが「圧縮されたデータの末端
部」マーカであるか否かが決定される。是であれば、処
理は終了し伸張は完了する。否であれば、処理はブロッ
ク７１４に進み、特定のハフマンビンにとって必要であ
れば余分なストリングオフセットビットが抜き出され
る。次に処理はブロック７１６に進み、特定のハフマン
ビンにとって必要であれば余分なストリング長ビットが
抜き出される。
【０１５０】次に処理はブロック７１８に進み、マッチ
ングストリングの次のバイトが、所定のオフセットおよ
び長さで伸張ユニット６により維持された履歴アレイか
ら出力される。次に処理はブロック７２０に進み、出力
されるマッチングストリング内に他にバイトがあるかが
決定される。あるならば、処理はブロック７１８に戻
り、次のバイトが出力される。マッチングストリング内
に他にバイトがなければ、処理はブロック７０６に戻
り、次のハフマンコードが抜き出される。
ングストリングの次のバイトが、所定のオフセットおよ
び長さで伸張ユニット６により維持された履歴アレイか
ら出力される。次に処理はブロック７２０に進み、出力
されるマッチングストリング内に他にバイトがあるかが
決定される。あるならば、処理はブロック７１８に戻
り、次のバイトが出力される。マッチングストリング内
に他にバイトがなければ、処理はブロック７０６に戻
り、次のハフマンコードが抜き出される。
【０１５１】本発明を例を挙げて、好適な実施態様によ
り説明してきたが、本発明はそれらに限定されるもので
はない。
り説明してきたが、本発明はそれらに限定されるもので
はない。
【０１５２】
【発明の効果】本発明によれば、完全に適合性があり、
予め初期化されたコード化テーブルを必要とせず、コン
ピュータファイルのようにバイトに適応したキャラクタ
ストリームを最適化するデータ圧縮が達成される。
予め初期化されたコード化テーブルを必要とせず、コン
ピュータファイルのようにバイトに適応したキャラクタ
ストリームを最適化するデータ圧縮が達成される。
【図１】（ａ）は、本発明による、未圧縮データを受け
取り圧縮データを出力する圧縮ユニットを示すブロック
図、（ｂ）は、本発明による、圧縮データを受け取り伸
張データを出力する伸張ユニットを示すブロック図であ
る。
取り圧縮データを出力する圧縮ユニットを示すブロック
図、（ｂ）は、本発明による、圧縮データを受け取り伸
張データを出力する伸張ユニットを示すブロック図であ
る。
【図２】本発明によって動作するように構成された圧縮
ユニットのブロック図である。
ユニットのブロック図である。
【図３】本発明による出力トークンの生成の例を示す図
である。
である。
【図４】入力データストリームに関してマッチするスト
リングの探索を行うための、本発明の好ましい実施例に
よって実行されるデータ構造を示す図である。
リングの探索を行うための、本発明の好ましい実施例に
よって実行されるデータ構造を示す図である。
【図５】入力データストリームから出力トークンを生成
させるためのスライディングウインドウ探索を示す流れ
ブロック図である。
させるためのスライディングウインドウ探索を示す流れ
ブロック図である。
【図６】入力データストリームから出力トークンを生成
させるためのスライディングウインドウ探索を示す流れ
ブロック図である。
させるためのスライディングウインドウ探索を示す流れ
ブロック図である。
【図７】入力データストリームから出力トークンを生成
させるためのスライディングウインドウ探索を示す流れ
ブロック図である。
させるためのスライディングウインドウ探索を示す流れ
ブロック図である。
【図８】図４に示されるデータ構造のハッシュテーブル
を初期化するためのスライディングウインドウ探索（図
５〜図７）の間に参照される初期化ルーチンの流れブロ
ック図である。
を初期化するためのスライディングウインドウ探索（図
５〜図７）の間に参照される初期化ルーチンの流れブロ
ック図である。
【図９】本発明のスライディングウインドウ探索及び出
力トークン生成をハード的配線で示した概略ブロック図
である。
力トークン生成をハード的配線で示した概略ブロック図
である。
【図１０】入力及び出力ＲＡＭＦＩＦＯを示すブロック
図である。
図である。
【図１１】本発明において用いられる圧縮フォーマット
を示す図である。
を示す図である。
【図１２】本発明による、トークンビンの割当ての一例
を示す表である。
を示す表である。
【図１３】図１２の例のハフマンビン割当てによる６及
びそれ以上のストリングの長さに対する余分なオフセッ
トビットのコード化の一例を示す図である。
びそれ以上のストリングの長さに対する余分なオフセッ
トビットのコード化の一例を示す図である。
【図１４】図１２の例のハフマンビン割当てによって単
一ハフマンビンに割り当てられる２１及びそれ以上のス
トリングの長さに対する余分なレングスビットのコード
化の一例を示す図である。
一ハフマンビンに割り当てられる２１及びそれ以上のス
トリングの長さに対する余分なレングスビットのコード
化の一例を示す図である。
【図１５】ハフマンレングスからハフマンコードを割り
当てるためのアルゴリズムを示す図である。
当てるためのアルゴリズムを示す図である。
【図１６】本発明によるハフマンレングスをコード化す
るために用いられるランレングスコード化の使用を示す
図である。
るために用いられるランレングスコード化の使用を示す
図である。
【図１７】本発明による圧縮コード化の簡単化された例
のステージを示す図である。
のステージを示す図である。
【図１８】本発明による圧縮コード化の簡単化された例
のステージを示す図である。
のステージを示す図である。
【図１９】本発明による圧縮コード化の簡単化された例
のステージを示す図である。
のステージを示す図である。
【図２０】本発明による圧縮コード化の簡単化された例
のステージを示す図である。
のステージを示す図である。
【図２１】本発明による圧縮コード化の簡単化された例
のステージを示す図である。
のステージを示す図である。
【図２２】本発明による圧縮コード化の簡単化された例
のステージを示す図である。
のステージを示す図である。
【図２３】本発明によるコード化データを伸張するため
の伸張動作を示す流れブロック図である。
の伸張動作を示す流れブロック図である。
【図２４】本発明によるコード化データを伸張するため
の伸張ハフマンツリーデータ構造を示す図である。
の伸張ハフマンツリーデータ構造を示す図である。
２３０ 圧縮コントローラ兼シーケンスユニット ２６０ 出力管理部 ２７４ 内部マッチバッファ ３３８ レジスタ
───────────────────────────────────────────────────── フロントページの続き (73)特許権者 593151099 5993 Ａｖｅｎｉｄａ Ｅｎｃｉｎａ ｓ， Ｃａｒｌｓｂａｄ， Ｃａｌｉｆ ｏｒｎｉａ 92008， Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ (72)発明者 ダグラス エル． ホワイティング アメリカ合衆国 カリフォルニア 92009，カールズバッド，フェボ コー ト 3312 (72)発明者 グレン エイ． ジョージ アメリカ合衆国 カリフォルニア 91106，パサデナ，ピー． オー． ボ ックス 60545 (72)発明者 グレン イー． アイビー アメリカ合衆国 カリフォルニア 91106，パサデナ，サウス ミシガン ナンバー202 146 (56)参考文献 特開 平３−68219（ＪＰ，Ａ) 米国特許5016009（ＵＳ，Ａ) 米国特許5003307（ＵＳ，Ａ) Ｃ Ｍａｇａｚｉｎｅ，Ｖｏｌ，３, Ｎｏ．１，1991年１月号，ソフトバン ク，奥村，吉崎，ｐ．44−68，「特集圧 縮アルゴリズム入門」 (58)調査した分野(Int.Cl.6，ＤＢ名) H03M 7/40
Claims (26)
- 【請求項１】 入力バイトのウインドウ内のマッチング
ストリングに対する探索であって、生のバイトまたは一
定の長さおよび該ウインドウへ戻る一定のオフセットを
有するマッチングストリングのいずれかを表現するトー
クンからなるストリームを生成する探索を実行するステ
ップと、 該トークンを予め定義されているビンに割り当てるステ
ップであって、該ビンのいくつかは、マッチングストリ
ングを有するステップと、 各ビンに割り当てられたトークンの発生頻度に基づい
て、可変長コードを各ビンに割り当てるステップと、 生成された各トークンに対し、各トークンが割り当てら
れた該ビンの該可変長コードを、出力データストリーム
に出力するステップと、複数のトークンが特定の１つのビンに割り当てられてい
る場合には、各可変長コードが出力された後に該複数の
トークンのそれぞれを区別する余分な長さビットまたは
余分なオフセットビットを出力するステップ とを包含す
るデータ圧縮方法。 - 【請求項２】 前記方法は、 前記可変長コードを割り当てる前に、入力データストリ
ームの全てのマッチングストリング探索を完了するステ
ップと、 該入力ストリーム全体から各ビンにおけるトークン発生
数をカウントするステップと、 該発生カウントに基づいて前記可変長コードを割り当て
るステップと、 各ビンに割り当てられた該可変長コードを示すコーディ
ングテーブルを生成するステップと、 いかなる符号化されたトークンを出力する前に、該コー
ディングテーブルを前記出力データストリームに出力す
るステップとをさらに包含する、請求項１に記載の方
法。 - 【請求項３】 前記可変長コードを割り当てるステップ
が、前記発生カウントに基づいてハフマンのアルゴリズ
ムを用いて該可変長コードを割り当てるステップをさら
に包含する、請求項２に記載の方法。 - 【請求項４】 前記コーディングテーブルを生成するス
テップが、前記可変長コードの長さのみを有するコーデ
ィングテーブルを生成するステップをさらに包含する、
請求項３に記載の方法。 - 【請求項５】 前記方法は、ランレングス圧縮体系を用
いて前記コーディングテーブルを圧縮するステップをさ
らに包含する、請求項４に記載の方法。 - 【請求項６】 前記方法は、 ハフマンコーディングを用いて、前記コーディングテー
ブルを圧縮するステップと、 該コーディングテーブル中の可変長に割り当てられたハ
フマンコードを特定するために使用される予備テーブル
を生成するステップとをさらに包含する、請求項４に記
載の方法。 - 【請求項７】 前記方法は、 圧縮された出力データの末端部を示す特別なビンを割り
当てるステップと、 全ての他のトークンが出力された後に、該圧縮された出
力データビンの該末端部のコードを出力するステップと
をさらに包含する、請求項１に記載の方法。 - 【請求項８】 前記方法は、前記ビンを以下に示すよう
に割り当てるステップ 【表１】 をさらに包含する、請求項１に記載の方法。 - 【請求項９】 前記方法は、 ビン２５６から３１８のコードの後にストリングオフセ
ットを特定する一定数の余分なオフセットビットを以下
に示すように続けるステップ 【表２】 をさらに包含する、請求項８に記載の方法。 - 【請求項１０】 前記方法は、 ビン３１９から３３４のコードの後にストリングオフセ
ットを特定する一定数の余分なオフセットビットを以下
に示すように続けるステップ 【表３】 をさらに包含する、請求項９に記載の方法。 - 【請求項１１】 前記方法は、 ビン３３４のコードおよびオフセットビットの後にスト
リング長を特定する余分な長さビットを以下に示すよう
に続けるステップ 【表４】 をさらに包含する、請求項１０に記載の方法。 - 【請求項１２】 請求項１に記載のデータ圧縮方法によ
って圧縮された入力データストリームを伸長するデータ
伸長方法であって、 全てのバイト出力の履歴アレイを維持するステップと、 入力データストリームの処理が終わるまで、または、該
圧縮された入力データストリームの末端部を示すコード
が見つかるまで、以下のステップを繰り返すステップ
と、 該圧縮された入力データストリームからビンコードを抜
き出すステップと、 該ビンコードに関連したトークンを正確に決定するため
に必要とされる余分な長さビットまたは余分なオフセッ
トビットを抜き出すステップと、 もし該余分な長さビットまたは余分なオフセットビット
があるなら、該余分な長さビットまたは余分なオフセッ
トビットを用いて該ビンコードに関連した該トークンを
正確に決定するステップと、 該トークンが生のバイトに相当する時、該生のバイトを
出力するステップと、 該トークンがマッチングストリングに相当する時、該ス
トリングのオフセットを用いて該履歴アレイにインデッ
クスバックすることにより該ストリングの全てのバイト
を出力するステップとを包含する、データ伸長方法。 - 【請求項１３】 前記方法は、 前記圧縮された入力データストリームの開始部からコー
ディングテーブルを抜き出すステップと、 該コーディングテーブルからカテゴリーに対する可変長
コードを抜き出すステップとをさらに包含する、請求項
１２に記載の方法。 - 【請求項１４】 入力バイトのウインドウ内のマッチン
グストリングに対する探索であって、生のバイトまたは
一定の長さおよび該ウインドウへ戻る一定のオフセット
を有するマッチングストリングのいずれかを表現するト
ークンからなるストリームを生成する探索を実行する手
段と、 該トークンを予め定義されているビンに割り当てる手段
であって、該ビンのいくつかは、マッチングストリング
を有する手段と、 各ビンに割り当てられたトークンの発生頻度に基づい
て、可変長コードを各ビンに割り当てる手段と、 生成された各トークンに対し、各トークンが割り当てら
れた該ビンの該可変長コードを、出力データストリーム
に出力する手段と、複数のトークンが特定の１つのビンに割り当てられてい
る場合には、各可変長コードが出力された後に該複数の
トークンのそれぞれを区別する余分な長さビットまたは
余分なオフセットビットを出力する 手段とを備えた、デ
ータ圧縮装置。 - 【請求項１５】 前記装置は、 前記可変長コードを割り当てる前に、入力データストリ
ームの全てのマッチングストリング探索を完了する手段
と、 該入力ストリーム全体から各ビンにおけるトークン発生
数をカウントする手段と、 該発生カウントに基づいて前記可変長コードを割り当て
る手段と、 各ビンに割り当てられた該可変長コードを示すコーディ
ングテーブルを生成する手段と、 いかなる符号化されたトークンを出力する前に、該コー
ディングテーブルを前記出力データストリームに出力す
る手段とをさらに備えている、請求項１４に記載の装
置。 - 【請求項１６】 前記可変長コードを割り当てる手段
が、前記発生カウントに基づいてハフマンのアルゴリズ
ムを用いて該可変長コードを割り当てる手段をさらに備
えている、請求項１５に記載の装置。 - 【請求項１７】 前記コーディングテーブルを生成する
手段が、前記可変長コードの長さのみを有するコーディ
ングテーブルを生成する手段をさらに備えている、請求
項１６に記載の装置。 - 【請求項１８】 前記装置は、 ランレングス圧縮体系を用いて前記コーディングテーブ
ルを圧縮する手段をさらに備えている、請求項１７に記
載の装置。 - 【請求項１９】 前記装置は、 ハフマンコーディングを用いて、前記コーディングテー
ブルを圧縮する手段と、 該コーディングテーブル中の
可変長に割り当てられたハフマンコードを特定するため
に使用される予備テーブルを生成する手段とをさらに備
えている、請求項１７に記載の装置。 - 【請求項２０】 前記装置は、 圧縮された出力データの末端部を示す特別なビンを割り
当てる手段と、 全ての他のトークンが出力された後に、該圧縮された出
力データビンの該末端部のコードを出力する手段をさら
に備えている、請求項１４に記載の装置。 - 【請求項２１】 前記装置は、前記ビンを以下に示すよ
うに割り当てる手段 【表５】 をさらに備えている、請求項１４に記載の装置。 - 【請求項２２】 前記装置は、 ビン２５６から３１８のコードの後にストリングオフセ
ットを特定する一定数の余分なオフセットビットを以下
に示すように続ける手段 【表６】 をさらに備えている、請求項２１に記載の装置。 - 【請求項２３】 前記装置は、 ビン３１９から３３４のコードの後にストリングオフセ
ットを特定する一定数の余分なオフセットビットを以下
に示すように続ける手段 【表７】 をさらに備えている、請求項２２に記載の装置。 - 【請求項２４】 前記装置は、 ビン３３４のコードおよびオフセットビットの後にスト
リング長を特定する余分な長さビットを以下のように続
ける手段 【表８】 をさらに備えている、請求項２３に記載の装置。 - 【請求項２５】 請求項１４に記載のデータ圧縮装置に
よって圧縮された入力データストリームを伸長するデー
タ伸長装置であって、 全てのバイト出力の履歴アレイを維持する手段と、 該圧縮された入力データストリームからビンコードを抜
き出す手段と、 該ビンコードに関連したトークンを正確に決定するため
に必要とされる余分な長さビットまたは余分なオフセッ
トビットを抜き出す手段と、 もし該余分な長さビットまたは余分なオフセットビット
があるなら、該余分な長さビットまたは余分なオフセッ
トビットを用いて該ビンコードに関連した該トークンを
正確に決定する手段と、 生のバイトを出力する手段と、 マッチングストリングの全てのバイトを、該ストリング
のオフセットを用いて該履歴アレイにインデックスバッ
クすることにより出力する手段とを備えている、データ
伸長装置。 - 【請求項２６】 前記装置は、 前記圧縮された入力データストリームの開始部からコー
ディングテーブルを抜き出す手段と、 該コーディングテーブルから該カテゴリーに対する可変
長コードを抜き出す手段とをさらに備えている、請求項
２５に記載の装置。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US92734392A | 1992-08-10 | 1992-08-10 | |
| US927,343 | 1992-08-10 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH06224778A JPH06224778A (ja) | 1994-08-12 |
| JP2863065B2 true JP2863065B2 (ja) | 1999-03-03 |
Family
ID=25454608
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP5198670A Expired - Fee Related JP2863065B2 (ja) | 1992-08-10 | 1993-08-10 | マッチングストリング探索およびハフマン符号化を用いたデータ圧縮装置および方法ならびにデータ伸長装置および方法 |
Country Status (2)
| Country | Link |
|---|---|
| EP (1) | EP0582907A3 (ja) |
| JP (1) | JP2863065B2 (ja) |
Families Citing this family (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5592482A (en) * | 1989-04-28 | 1997-01-07 | Abraham; Charles | Video distribution system using in-wall wiring |
| US5442350A (en) * | 1992-10-29 | 1995-08-15 | International Business Machines Corporation | Method and means providing static dictionary structures for compressing character data and expanding compressed data |
| JP3278297B2 (ja) * | 1994-07-20 | 2002-04-30 | 富士通株式会社 | データ圧縮方法及びデータ復元方法並びにデータ圧縮装置及びデータ復元装置 |
| DE69524999T2 (de) * | 1994-08-01 | 2002-07-18 | Opentv Inc | Verfahren zum Komprimieren und Dekomprimieren von Dateien |
| DE4432436C2 (de) * | 1994-09-12 | 1997-04-03 | Tecomac Ag | Datenkompressionsverfahren und Vorrichtung zum Komprimieren von Daten |
| US5696563A (en) * | 1995-03-08 | 1997-12-09 | Lucent Technologies Inc. | Apparatus and methods for performing huffman coding |
| US6169820B1 (en) | 1995-09-12 | 2001-01-02 | Tecomac Ag | Data compression process and system for compressing data |
| US5710719A (en) * | 1995-10-19 | 1998-01-20 | America Online, Inc. | Apparatus and method for 2-dimensional data compression |
| SE512613C2 (sv) * | 1996-12-30 | 2000-04-10 | Ericsson Telefon Ab L M | Metod och organ för informationshantering |
| US5874908A (en) * | 1997-09-19 | 1999-02-23 | International Business Machines Corporation | Method and apparatus for encoding Lempel-Ziv 1 variants |
| US5973626A (en) * | 1998-03-17 | 1999-10-26 | Cornell Research Foundation, Inc. | Byte-based prefix encoding |
| US6393149B2 (en) * | 1998-09-17 | 2002-05-21 | Navigation Technologies Corp. | Method and system for compressing data and a geographic database formed therewith and methods for use thereof in a navigation application program |
| US6130630A (en) * | 1998-10-27 | 2000-10-10 | Hewlett-Packard Company | Apparatus and method for compressing Huffman encoded data |
| US6275588B1 (en) | 1998-11-12 | 2001-08-14 | I-Data International A/S | Apparatus and method for performing and controlling encryption/decryption for data to be transmitted on local area network |
| US6668092B1 (en) * | 1999-07-30 | 2003-12-23 | Sun Microsystems, Inc. | Memory efficient variable-length encoding/decoding system |
| DE10131801B4 (de) * | 2001-06-30 | 2013-03-07 | Robert Bosch Gmbh | Verfahren zur Datenkompression und Navigationssystem |
| US7587396B2 (en) | 2004-11-24 | 2009-09-08 | Oracle International Corporation | Encoding data to be sorted |
| GB201620235D0 (en) | 2016-11-29 | 2017-01-11 | Microsoft Technology Licensing Llc | Neural network data entry system |
| JP2019036810A (ja) * | 2017-08-14 | 2019-03-07 | 富士通株式会社 | データ圧縮装置、データ復元装置、データ圧縮プログラム、データ復元プログラム、データ圧縮方法、およびデータ復元方法 |
| US10944697B2 (en) | 2019-03-26 | 2021-03-09 | Microsoft Technology Licensing, Llc | Sliding window buffer for minimum local resource requirements |
| CN110620637B (zh) * | 2019-09-26 | 2023-02-03 | 上海仪电（集团）有限公司中央研究院 | 一种基于fpga的数据解压装置及方法 |
| CN112332854A (zh) * | 2020-11-27 | 2021-02-05 | 平安普惠企业管理有限公司 | 霍夫曼编码的硬件实现方法、装置及存储介质 |
| CN115801901B (zh) * | 2023-01-05 | 2023-08-04 | 安徽皖欣环境科技有限公司 | 一种企业生产排放数据压缩处理方法 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5003307A (en) | 1989-01-13 | 1991-03-26 | Stac, Inc. | Data compression apparatus with shift register search means |
| US5016009A (en) | 1989-01-13 | 1991-05-14 | Stac, Inc. | Data compression apparatus and method |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5051745A (en) * | 1990-08-21 | 1991-09-24 | Pkware, Inc. | String searcher, and compressor using same |
-
1993
- 1993-07-29 EP EP93112147A patent/EP0582907A3/en not_active Withdrawn
- 1993-08-10 JP JP5198670A patent/JP2863065B2/ja not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5003307A (en) | 1989-01-13 | 1991-03-26 | Stac, Inc. | Data compression apparatus with shift register search means |
| US5016009A (en) | 1989-01-13 | 1991-05-14 | Stac, Inc. | Data compression apparatus and method |
Non-Patent Citations (1)
| Title |
|---|
| Ｃ Ｍａｇａｚｉｎｅ，Ｖｏｌ，３，Ｎｏ．１，１９９１年１月号，ソフトバンク，奥村，吉崎，ｐ．４４−６８，「特集圧縮アルゴリズム入門」 |
Also Published As
| Publication number | Publication date |
|---|---|
| JPH06224778A (ja) | 1994-08-12 |
| EP0582907A2 (en) | 1994-02-16 |
| EP0582907A3 (en) | 1995-05-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2863065B2 (ja) | マッチングストリング探索およびハフマン符号化を用いたデータ圧縮装置および方法ならびにデータ伸長装置および方法 | |
| US5532694A (en) | Data compression apparatus and method using matching string searching and Huffman encoding | |
| US5126739A (en) | Data compression apparatus and method | |
| US5506580A (en) | Data compression apparatus and method | |
| US5016009A (en) | Data compression apparatus and method | |
| US5003307A (en) | Data compression apparatus with shift register search means | |
| US5001478A (en) | Method of encoding compressed data | |
| US5406279A (en) | General purpose, hash-based technique for single-pass lossless data compression | |
| US5951623A (en) | Lempel- Ziv data compression technique utilizing a dictionary pre-filled with frequent letter combinations, words and/or phrases | |
| JP2610084B2 (ja) | データ伸長方法および装置ならびにデータ圧縮伸長方法および装置 | |
| US4906991A (en) | Textual substitution data compression with finite length search windows | |
| US5058144A (en) | Search tree data structure encoding for textual substitution data compression systems | |
| US5229768A (en) | Adaptive data compression system | |
| EP0438955B1 (en) | Data compression method | |
| US5973626A (en) | Byte-based prefix encoding | |
| JPH07104971A (ja) | ネットワークパケットに適用される小型辞書を用いた圧縮方法 | |
| WO1998006028A9 (en) | A lempel-ziv data compression technique utilizing a dicionary pre-filled with fequent letter combinations, words and/or phrases | |
| EP0435802B1 (en) | Method of decompressing compressed data | |
| US5010344A (en) | Method of decoding compressed data | |
| Lin | A hardware architecture for the LZW compression and decompression algorithms based on parallel dictionaries | |
| EP0340039B1 (en) | Search tree data structure encoding for textual substitution data compression systems | |
| EP0340041B1 (en) | Start, step, stop unary coding for data compression | |
| Thomborson et al. | Systolic implementations of a move-to-front text compressor | |
| Bloom | New Techniques in Context Modeling and Arithmetic Encoding. |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 19981112 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20071211 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081211 Year of fee payment: 10 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081211 Year of fee payment: 10 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081211 Year of fee payment: 10 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081211 Year of fee payment: 10 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081211 Year of fee payment: 10 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081211 Year of fee payment: 10 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091211 Year of fee payment: 11 |
|
| LAPS | Cancellation because of no payment of annual fees |