JP3061278B2 - 可変ビット長コード語のビット長通信方法 - Google Patents

Description

【発明の詳細な説明】 〔発明の分野〕 本発明は、デジタルデータ圧縮システムに関するもの
であり、とりわけ、適応的で、可逆の、すなわち、損失
のないデジタルデータ圧縮システムに関するものであ
る。

〔関連出願に対するクロスリファレンス〕

これは、譲渡先が共通で、同時に提出された、名指し
された発明者の３つの米国特許出願の１つである。他の
出願は、“有限長の探索窓によるテキスト置換データ圧
縮（Textual Substitution Data Compression with Fin
ite Length Search Windows（D/87006））”と、“テキ
スト置換データ圧縮システムのための探索木データ構造
コード化（Search Tree Data Structure Encoding for
Textual Substitution Data Compression Systems（D/8
8068））”に関するものである。これらの異なる出願に
よって取り扱われる発明は、さまざまな方法で組み合わ
せることができるので、共通の詳細説明を用いている。

〔発明の背景〕

デジタルデータ圧縮は、例えばファイルに関する記憶
要件を緩和し、帯域幅を制限された通信チャネルで、デ
ータを転送することができる率を増し、強化された機密
保護を提供するため、そのコード化前に、データの内部
冗長度を低下させるのに用いることができるので、デジ
タルデータ圧縮は、重要なツールである。

専用データ圧縮システムと汎用データ圧縮システムが
ある。専用システムは、それらが最適化されているソー
スデータの圧縮に用いられる場合には、たいてい満足の
いくようになっている。しかし、汎用システムは、通例
的には、ソースデータに適応するように設計されている
ため、通常、それらは、未知または種々のソースデータ
タイプを圧縮するのにより適している。これら汎用シス
テムは、小ファイルのため、及び、内部的に一致性のな
い統計的特性を備えたソースデータのために大幅な圧縮
を加えることが必要とされる可能性のある、ソースデー
タの組成構造の基本的変更に敏速に適応できるだけでな
く、安定した統計的特性を備えた大ファイルのために近
最適圧縮を加えることもできるのが、理想である。設計
者は、これらの競合する設計目的を解決するため、さま
ざまなアプローチを行ったが、彼らの努力結果は、十分
に満足のいくものではなかった。

シャノン（Shannon）の通信理論（1948年のベルシス
テムテクニカルジャーナル（The Bell System Technica
l Journal）第27巻第３号の379〜423頁、及び1948年の
第４号の623〜656頁における、ジー・イー・シャノン
（C.E.Shannon）著“数理通信理論（A Mathematical Th
eory of Communication）”は、所定のソース記号の理
想的コード化では、その記号の発生確率Ｐの−Log 2に
等しいスペースを用いることを示している。コード化
が、このメモリーのないモデルに適合する場合、記号を
表すのに必要な平均スペースは、ソース記号のエントロ
ピーである： ここで:xは、独特のｎ個の記号を含むソース記号から
ランダムに選択した記号であり;c_iは、可能性のある全
てのソース記号をカバーする。

ただし、実際問題として、式（１）のゼロ次エントロ
ピーモデルは、従来の多くのソースの冗長の有効部分を
捕捉することができない。例えば、英語のテキストは、
一般に１次エントロピーにおいてかなりのドロップを示
す： ここで:xyは、ランダムに選択した１対のソース文字
である。

他に、統計的確率における捕捉メカニズムにあらかじ
め調整を施す必要のない、高次の首尾一貫したテキスト
及び同様のソースデータを捕捉するための、いわゆる
“テキスト置換”データ圧縮処理が提案されている。ジ
ェイ・ジブ（J.Ziv）及びエイ・レンペル（A.Lempel）
は、あらかじめコード化された信号のストリングの再発
生は、こうした再発生直後の記号（すなわち、再発生ス
トリングの接尾文字）を、（１）前に発生したストリン
グの一方の端（例えば、前端）を指示し、（２）再発生
ストリングの長さを識別するコピーコード語から始める
ことによって表すことができるという考えに基づいた、
テキスト置換処理用の演算モデルを提案した。彼らは、
こうしたコピー語が、再発生する記号ストリングを十分
かつ完全に規定するものと認識し、従って、彼らは、再
発生する記号ストリングの記号とコード語を“置換”し
て、その圧縮表現を与えることを構想した。1977年のIE
EE情報理論に関する会報（IEEE Transactions on Infor
mation Theory）、IT−23 第３号、337〜343頁におけ
るジェイ・ジブ（J.Ziv）他による“順次データ圧縮の
ための汎用アルゴリズム（A Universal Algorithm for
Sequential Data Compression）”参照のこと。

あいにく、もとのジブ−レンペル（Ziv−Lempel）ア
ルゴリズムに基づく圧縮システムは、許容できないほど
遅い傾向があり、とりわけ高圧縮をなし遂げられなかっ
た。速度を改善するため、彼ら、及び該分野の他の研究
者は、各種代替案を開発した。これらの代替案のいくつ
かは、人工的に厳格なパーシング（parsing）メカニズ
ムを採用して、コピーコード語の発生を簡単にし、圧縮
の実施に必要なデータ構造のサイズを制限した。例えば
ジェイ・ジブ（J.Ziv）他による前述の文献;1978年のIE
EE情報理論に関する会報（IEEE Transactions on Infor
mation Theory）、IT−24 第４号、405〜412頁におけ
るジェイ・ジブ（J.Ziv）による“個々のシーケンスに
関するコード化定理（Coding Theorems for Individual
Sequences）";1978年のIEEE情報理論に関する会報（IE
EE Transactions on Information Theory）、IT−24
第５号、530〜536頁におけるジェイ・ジブ（J.Ziv）他
による“可変速コード化による個々のシーケンスの圧縮
（Compression of Individual Sequences Via Variable
−Rate Coding）";及び1984年８月７日、“データ信号
を圧縮し、圧縮データを復元するための装置及び方法
（Apparatus and Method for Compressing Data Signal
and Restoring the Compressed Data）”に対し発行さ
れたダブリュ・エル・イーストマン（W.L.Eastman）他
の米国特許明細書第4,464,650号参照のこと。しかしな
がら、これら修正されたジブ−レンペル（Ziv−Lempe
l）スタイルのデータ圧縮システムは、それらが適応す
る速度及びそれらが行う圧縮の両方または一方で判断す
るそれらの性能が、一般的には、期待はずれのため、十
分な満足が得られなかった。

データ圧縮にテキスト置換を利用するため提案され
た、幾分異なるアプローチは、個々の記号及び記号スト
リングに関する適応リストまたは辞書の構築に基づくも
のである。例えば、1984年のIBM研究報告書（IBM Resea
rch Report）RC10630、＃47798におけるブイ・エス・ミ
ラー（V.S.Miller）他による“ジブ及びレンペルによる
テーマに関する変形例（Variations on a Theme by Ziv
and Lempel）”、1985年のNATO,ASIシリーズＦ（NATO,
ASI Series F）第12巻、131〜141頁における、語に関す
る組合せアルゴリズム（Combinational Algorithms on
Words）;1984年のIEEEコンピュータ（IEEE Compute
r）、第17巻、第６号の８〜19頁における、ティー・エ
イ・ウェルチ（T.A.Welch）による“高性能データ圧縮
のための技術（A Technique for High Performance Dat
a Compression）";及び、1984年のACMの通信（Communic
ation of the ACM）、第29巻、第４号の320〜330頁にお
ける、ジェイ・エル・ボンクレイ（J.L.Bonkley）によ
る“局所的に適応するデータ圧縮案（A Locally Adapti
ve Data Compression Scheme）”参照のこと。しかし、
これらのシステムは、適応が緩慢で、得られる圧縮は劣
っている。

先行技術の欠点を考慮すると、安定した統計的特性を
有する大規模なソースデータ及び規模がより小さいソー
スデータや可変の統計的特性を有するソースデータに対
し信頼できる、有効な圧縮を施すための、実用的な、汎
用で、適応的な、可逆の（すなわち損失のない）データ
圧縮システムに対する必要が、まだ存在することは明ら
かである。テキスト置換技術は、該タスクによく適合す
るものであるが、その潜在能力を十分に実現するには、
実際に、こうしたデータ圧縮を実施するための改良され
た方法及び手段が必要になる。

〔発明の要約〕

本発明によれば、圧縮データをコード化するための可
変長のコード語を発生させるのに、開始、ステップ、停
止の単項コード化が用いられる。

〔望ましい具体例の詳細な説明〕

本発明は、いくつかの図示具体例に関連して、以下で
少し詳しく説明が施されているが、それらの具体例に本
発明を制限する意図のないことは理解すべきである。そ
れどころか、その目的は、付属の特許請求の範囲によっ
て定義の本発明の精神及び範囲内にある全ての修正、代
替案、及び、相当物を包含することにある。

A.概要 ここで図面を、とりわけこの時点では第１図を参照す
ると、順次デジタル方式でコード化されるソースデータ
を圧縮する圧縮器62と、そのデータを順次復元する伸長
器63を備えたデータ圧縮システム61が示されている。本
発明の各種具体例が説明されており、それ以外について
も連想させられるが、それらのそれぞれが、可逆の、す
なわち、損失のないデータ圧縮システムを提供し、従っ
て、伸長すなわち復元されるデータは、もとのソースデ
ータとほぼ同一である。さらに、本発明の全ての具体例
は適応的であり、従って、ソースデータは、例えば、英
数字テキスト、走査像または合成像、人または機械が読
み取れるコンピュータコード、こうしたソースタイプ及
び／又はその他のソースタイプによるさまざまな組合せ
のいずれかによって構成することができる。

まず、圧縮器62及び伸長器63は、適切な構成のハード
ウェアにより、すなわち、適正にプログラムされた汎用
デジタルコンピュータを用いることにより実現可能であ
ることを理解すべきである。さらに、圧縮器62及び伸長
器63は、例えば、圧縮ソースデータをファイルサーバ
（不図示）にロードしたり、復元ソースデータをファイ
ルサーバから検索するため、それらを局所化することが
所望の場合には、同じ場所に配置することができる。実
際圧縮器62及び伸長器63の単一場所でのソフトウェアの
実現は、同じコンピュータを利用し、指令に基づいて圧
縮器及び伸長器のプログラムを実施することで可能にな
る。代替案として、例えば、制限された帯域幅の通信媒
体（不図示）を介してデータの送信をし、受信をするた
め、それらの機能を分散することが所望の場合には、圧
縮器62及び伸長器63は、異なる場所に配置することがで
きる。ファイル及びストリームの圧縮器及び伸長器につ
いて論考されるが、それらの主たる相違点は、それらの
入力データのフロー制御と、それらのバイトのアライメ
ントを復元するための、パッドコード語で圧縮データに
対し行うパッディング（padding）に関連する。データ
は、“クライアント（client）”（圧縮器の“クライア
ント”はデータソースであり、伸長器の“クライアン
ト”はデータシンクである）によって、ストリーム圧縮
器に“押し（pushed）”込まれたり、ストリーム伸長器
から“引き（pulled）”出されたりするが、一方で、デ
ータは、内部制御によってファイル圧縮器及び伸長器に
“押し”込まれる。パッドコード語による圧縮データの
パッディングについて、さしあたっての言及をおこなう
が、該主題は、一般に、本発明の範囲を超えるものであ
り、当該技術における熟練者の作業知識内のものであ
る。

本発明を実施するため、圧縮器62は、最近圧縮され
た、連携するソース記号の全てに関する完全な、現在の
記録を、その発生順に従ってアセンブルし、保全する。
この記録は、適合するメモリーに保持され、最も新しく
圧縮された記号の位置ｉと、ｗを探索窓の記号長とした
場合の、前に圧縮された記号の位置ｉ−ｗとの間のソー
スデータストリームにおいて、以前に圧縮されている記
号の全てにわたる先入れ／先出し（“FIFO"）“探索
窓”を提供する。動作時、探索部に挿入される前に、ソ
ース記号がテストを受け、記号位置ｉ＋１におけるテス
ト記号に、それに後続する１つ以上の記号を追加するこ
とによって形成される伸長記号ストリングのいずれかに
対する整合を探索窓が含んでいるか否かの判定をし、も
し含んでいれば、該整合のうち最長のものの記号長を求
める。整合が見つからなければ、すなわち、現存する最
長の整合が、所定の“最小有意味コピー長”の基準を満
たすには短すぎる場合には、圧縮器62が、一般形態“リ
テラルX₁"を有する固定長または可変長のリテラルコー
ド語の後の圧縮データストリームにテスト記号を挿入す
る。次に、伸長器63は、このコード語は、それに対し、
次の“X₁"記号を直接その出力に送るように命令するも
のと解釈する。一方、探索窓が、こうした伸長テスト記
号のストリングにとって十分な長さの整合を含んでいる
場合、圧縮器62は、（１）現存する最長の整合を終了す
る記号（すなわち、該整合の長さをそれ以上延長できな
い記号）を見つけるか、または、（２）許容できる整合
の最大長を見つけたと判定するまで、さらに非圧縮デー
タストリームの記号毎に調べを進めていく。こうした事
象のいずれかに応答し、圧縮器62は、整合された記号の
ストリングの代わりに、固定長または可変長のコピーコ
ード語の一般的な形“Xc,−ｙをコピー”を圧縮データ
ストリームに挿入する。このコード語は、ｙ≦ｗの場
合、前に復元されているソース記号“y"を飛び越して戻
り、それから、漸次より最近のものになる連続した記号
“Xc"をその出力にコピーし、飛越し入口位置の記号か
らそのコピー処理を始めるように伸長器63に命令する。

B.基本的な具体例 明らかなことではあるが、達成される圧縮は、コピー
語、及び、リテラル語に必要なスペースによって決ま
る。第２図は、それぞれ、固定長の８ビット及び16ビッ
トのリテラルコード語及びコピーコード語を用いた、テ
キストの普通の一節に関する単一パスの圧縮を示してい
る。これらのコード語は長さは、本発明の基本的特徴で
はないが、これらの特定のコード語は、本発明の実施に
とって十分であり、バイトが各文字テキストと各コンピ
ュータソースコードの両方または一方につき、通常の８
ビットで構成されるソースデータとのアライメントがと
れるという利点を有することを理解すべきである。

しばらくコード語のレイアウトに焦点を合わせると、
８ビットのリテラルコード語の最初の４つのビット位置
は、通常“0000"のような、リテラルコード語の一義的
識別を行うための確保された導入ビットシーケンスを納
めるリテラルフラグすなわち識別フィールドLFに割り当
てられることが分かる。その場合、こうしたコード語の
他の、すなわち、最後の４つのビットは、リテラル長X₁
を〔１・・・16〕の範囲でコード化するリテラル長フィ
ードLLに常駐し、これによって、16までのリテラル記号
をこうしたコード語に付加することが可能になる（すな
わち“最大許容リテラル長”）。一方、コピーコード語
は、コピー長と、変位すなわち位置決め値の両方を含ん
でいる。この場合、各コピーコード語の最初の４つのビ
ット位置は、コピー長Xcを〔２・・・16〕の範囲でコー
ド化するコピー長フィールドCLに割り当てられ、一方、
その残りの、すなわち、最後の12のビット位置は、変位
ｙを〔１・・・4096〕の範囲でコード化するコピー変位
フィールドCDを提供する。従って、16までの記号は、単
一のコピーコード語で表すことができ、これにより、
“最大許容可能コピー長”が定義される（これは、コー
ドが適性に１つずつシフトされるいくつかの例の１つで
あり、これにより、２進値１を有するコードは、コピー
長２を表し、２進値２を有するコードは、コピー長３を
表し・・・）。さらに、整合記号ストリングの起点は、
4096の最も新しく処理された記号の位置の１つである場
合に限って、一義的識別が可能になるため、探索窓の有
効長が決まる。

第２図に示す例を単純化するため、圧縮器62の探索窓
が、当初空であり、英数字文字、句読点、及び、サンプ
ルテキストの中間のスペースの全て（すなわち、その
“ソース記号”の全て）を記憶するのに十分な長さを備
えるものと仮定した。本発明の具体例の１つに従ってソ
ースデータを圧縮し、伸長するための単純化コンピュー
タプログラムが、付録Ａに記載されているが（より簡単
な手順の一部については、機能本位に説明されているだ
けである）、これは、参考までに本書に組み入れたもの
である。

明らかに、本発明の付録Ａの具体例は、圧縮器62の動
作に下記の論理規則を課す：（１）圧縮器62がアイドル
状態の場合、及び、それに続く１つ以上の記号によって
拡張される所定のテスト記号（すなわち、拡張テスト記
号ストリング）に関する探索窓内にある最長の整合が、
記号２つの長さ未満の場合には、“リテラル”が開始さ
れる；（２）いったん開始されると、少なくとも３つの
記号にまたがる整合が見つからない限り、その最大許容
可能長に達するまでに、リテラルが割込まれることはな
い；（３）（ｉ）こうした割込みの場合、または、（i
i）圧縮器62がアイドル状態であったり、少なくとも２
つの記号にまたがる整合が見つかる場合には“コピー”
が開始される；（４）（ｉ）リテラルが割り込まれる
か、または（ii）最大許容可能長のリテラルが得られる
場合には、必ず、リテラルコード語及びそれに付加され
るリテラルソース記号が、圧縮データストリームに挿入
される；（５）整合のとられた入力またはテスト記号ス
トリングが、（ｉ）得られる最長の整合の長さをそれ以
上延長しない記号によって終了するか、または、（ii）
最大許容可能コピー長にまたがる場合には、必ず、コピ
ーコード語が圧縮データストリームに挿入される。付録
に見られるコメントは、前述の規則とコードを相互に関
係させる手助けとなる。さらに、付録Ａの序文は、圧縮
プログラムの実行速度を上昇させ、その実行に必要な記
憶量を減少させるために利用可能な、いくつかの技術に
関するものである。

圧縮器62の探索窓が当初空であるという単純化の仮定
を考慮すると、以上の要約された圧縮規則によって、圧
縮器62は、第２図に示すサンプルテキストの最初のいく
つかの記号をリテラルコード語に付加することになるの
は明らかである。実際、この場合には、圧縮規則は、記
号１−26のリテラルコード化を必要とし、従って、この
最初の記号ストリングには、最大許容可能リテラル長を
有するどの１つのリテラルコード語が伸長器63に有効に
伝えることができるよりも多くのリテラルが含まれるこ
とになる。こうした状況は、時々、とりわけ始動時、及
び、圧縮器62があるタイプのソースデータから別のタイ
プのソースデータに移行中に発生しやすくなり、従っ
て、圧縮器62は、最大許容可能リテラル長のリテラル記
号ストリングをアセンブルする場合には、必ず、再循環
するということを理解するのが重要である。この再循環
の結果、圧縮器62は、さらに長いリテラル記号のストリ
ングを２つ以上の許容可能な長さのサブストリング組区
分し、該サブストリングを別個のリテラルコード語に付
加して、それらを伸長器63に送る。例えば、第２図に示
すテキストの記号１−16が、長さの値が16の第１のリテ
ラルコード語に付加され、次に、記号17−26が、長さの
値が10の第２のリテラルコード語に付加される。明らか
なことだが、これらのより長いリテラルの便益の１つ
は、それらが、圧縮データストリームに挿入されるリテ
ラルコード語の数を有効に減少させ、同時に、圧縮器
は、新しいソースデータタイプに適応するということに
ある。

第２図のテキストの記号27は、記号位置ｉ＋１にある
時、記号27−29が前に発生した記号１−３に整合するた
め、記号３つ分の長さの整合が見つかる。従って、さら
に進行中の“リテラル”が割り込まれ、“コピー”が開
始する。サンプルテキストの簡単な再検討により、先行
する記号２つ分の長さの整合がいくつか明らかになる
が、これは、この特定の例において、たまたま生じた
“コピー”の最初の例である。従って、それら先行する
整合のそれぞれは、記号２つ分の長さしかなく、リテラ
ルが発生している間に生じたものであるため、付録Ａの
圧縮規則に従って、それらは無視されたと理解すべきで
ある。

記号27−28に関して見つけた整合に応答して、“コピ
ー”を開始すると、圧縮器62は、さらに記号38における
ような、整合を終了するソース記号（すなわち、それ以
上最も良い整合の長さを延長できない記号）を見つける
まで、または、最大許容可能コピー長の整合を見つける
まで、後続のソース記号について、次々と整合記号のス
トリングを拡張する。これらの事象のいずれかが生じる
と、圧縮器62は、整合のとれた記号ストリングの代わり
に、コピーコード語を圧縮データストリームに送り込
む。コピーコード語は、該記録ストリングの長さを表示
し、その前に発生した先行記号の位置を示すポインタを
提供するが、これによって、伸長器63は、前述の“飛び
越して戻り”、“繰り上げてコピーする”処理により、
コード語で表された記号を回復することが可能になる。

第３図を参照すると、圧縮器62の付録Ａの具体例は、
（２）探索窓記号位置ｉ〜ｉ−ｗにおいて、最も新しく
圧縮された記号によって先行される、（１）記号位置ｉ
＋１にまで至り、それを含む記号位置において、ソース
記号のまさに圧縮されるようとしている部分からの記号
を記憶する先入れ／先出し（FIFO）入力バッファ71から
構成される。ソフトウェアの実現において、バッファ71
は、好都合なことには、四分円に分割される円形バッフ
ァであるため、圧縮すべきソース記号がつきるまで（例
えば、現在のソースファイルの最後に達するまで）、バ
ッチトランザクション（batch transaction）を用い
て、ソース記号を規則的にバッファに対し四分円毎に再
ロードすることができる。それによって、圧縮器62に対
するソース記号のタイムリーなフローを維持するのに必
要なI/Oトランザクションの数が減少する。こうした実
現時には、圧縮器62によって行われる圧縮をその入力バ
ッファ71のローディングから有効に切り離すのに十分な
大きさになるように、四分円が選択される。

探索及び更新論理部72は、発生順に従って、バッファ
71の記号位置ｉ〜ｉ−ｗ（すなわち、探索窓）内におけ
る記号を互いに連係させ、順次記号がシフトされて、探
索窓に入り、それを通り、そこから出てくる時、それら
の記号ストリングのうち最も新しく発生したストリング
を追跡する、探索木編成によるデータ構造73をアセンブ
ルし、これを保全する。探索木データ構造73によって得
られる連係のカットオフの深さは、都合よく、最大許容
可能コピー長に等しくなるように選択され、これによ
り、それを記憶するのに必要な記憶量、及び、それを保
全するのに必要な処理時間が制限されることになる。探
索木73のサイズをさらに縮小するために利用可能な他の
いくつかの技術、及び、それを更新するのに必要な時間
については、さらに詳しく後述される。

動作時、探索及び更新論理部72は、探索木73を用い
て、記号位置ｉ＋１に生じるテスト記号に関するバッフ
ァ71の記号位置ｉ〜ｉ−ｗ内におけるどこかに整合があ
るか否かを判定する。整合が見つかれば、論理部72は、
記号位置ｉ＋２における記号をテストストリングに付加
することによって、それを拡張し、次に、この拡張され
た入力記号ストリングに対する探索窓内に、やはり整合
があるか否かを判定する。これは、反復処理であり、こ
れによって、探索及び更新論理部72は、現在の最長の整
合の長さを延長することができない記号（すなわち整合
を終了する記号）に出くわすまで、または、最大許容可
能コピー長の整合の存在が識別されるまで、非圧縮記号
について、次々と、テスト記号ストリングを拡張するこ
とによって、それを漸次捕捉していく。これらの事象の
いずれかが発生すると、探索及び更新論理部72は、上に
要約したコード化規則に従って動作し、１つまたは複数
のテストされる記号が、コピーエンコーダ75によってコ
ピーコード語としてコード化されるべきか、または、リ
テラルエンコーダ76によってリテラルコード語に付加さ
れるべきか判定するディスクリミネータに対し、報告を
行う。そのため、探索及び更新論理部72によって与えら
れる報告は、見つかった最長の整合の長さと、先行して
発生した整合のとられた記号の探索窓の位置とを識別す
る（整合の長さが、コピーに必要とされる最小整合長末
端であれば、この位置情報は報告する必要がない）。こ
の場合、整合記号ストリングの先行記号すなわち最初の
記号の場所が、記号位置ｉ＋１からの変位としてコピー
エンコーダ75に報告されるが、その場所は、別の方法で
明確に識別できるのは明らかである。

探索及び更新論理部72からの報告に応答して、コピー
コード語が、コピーエンコーダ75によって出力バッファ
77に挿入され、これによって、ディスクリミネータ74
は、こうしたコード語によってコード化するのに十分な
長さの整合が識別されたものと結論を下すことになる。
コピーコード語が、整合のとられた記号ストリングの記
号に取って代わるので、整合のとられた記号ストリング
の全ての記号は、ディスクリミネータ74が探索及び更新
論理部72からのそれ以上の報告に応答する前に、バッフ
ァ71の探索窓の四分円すなわちセクター内へシフトされ
る。そのため、各コピーの長さに対応するカウントが、
カウンタ制御式ゲート78の文字スキップカウンタにロー
ドされ、コピーによって表された記号が入力バッファ71
の探索窓のセクターにロードされている間、コード化論
理部74−76が一時的に、それ以上コード語を発生できな
くなる。整合のとられた記号ストリングの順次記号のそ
れぞれが、探索窓にロードされ、その結果、整合のとら
れたストリングに続く記号からコード化が再開されるこ
とになる。

一方、リテラルの長さがまだ分かっていなくても、探
索及び更新論理部72が、コピーとしてコード化されるの
に十分な長さの整合を見つけることができない場合に
は、ディスクリミネータ74によってリテラルが開始され
る。いったんリテラルが開始すると、探索及び更新論理
部72は、非圧縮記号が記号位置ｉ＋１にシフトされる
際、リテラルに対する割込みを保証するのに十分な長さ
の拡張テスト記号ストリングに関する整合を見つけるま
で（たとえば、少なくとも記号３つ分の長さ）、又はテ
ストされた記号の数が、最大許容可能リテラル長さに達
するまで、非圧縮記号について順次その拡張をテストす
る。該事象のいずれかが生じると、必ずリテラルエンコ
ーダ76がリテラルの長さを識別するリテラルコード語を
出力バッファ77に挿入し、次にリテラルの累積した記号
を順次バッファ77にコピーして、これによりそれらをリ
テラルコード語に付加する。コピーに十分な長さの整合
が見つかれば、即座に又は例示の具体例におけるよう
に、コピーに関する整合がその極限の長さまで拡張され
て、コピーエンコーダ75がコピーコード語を送り出す準
備が整うと、リテラルコード語及びその付加されるリテ
ラル記号が出力バッファ77にロード可能となる。

第４図に示すように、圧縮されたソースデータを復元
するため、伸長器63は、適当な速度で又は要求に従って
圧縮データをデコーダ82に供給する入力バッファ81から
構成される。デコーダ82は、リテラル論理部83とコピー
論理部84のためのリテラルコード語とコピーコード語
を、それぞれ交互に解読する。リテラルコード語がデコ
ーダ82によって解読される時、リテラル論理部83は、解
読されるリテラルの長さx_Lに応答して、次のx_L記号を直
接FIFO出力バッファ85に順次ロードする。一方、コピー
コード語が解読される時には、コピー論理部84が変位ｙ
と長さx_cに応答して、予め復元された記号のストリング
を出力バッファ85に順次コピーしバッファ85における予
め復元されたｙ番目の記号から始めて、そこから漸次新
しく伸長されるx_cの記号ストリングまでコピーを拡張す
る。

C.更に、探索木に関して 好都合なことに、探索木73は、そのキーの“デジッ
ト”に従って、任意の時間において、入力バッファ71の
探索窓での記号位置ｉ〜ｉ−ｗ内にあるソース記号によ
って規定されるその“葉”に分岐する。たとえば、第５
図に示す冗長性の高い英語テキストに焦点を合わせる
と、入力バッファ71の探索窓での記号位置の範囲内にあ
る、テキストの任意の部分の個々の文字に従って分岐す
る探索木73は、圧縮ソース記号を探索窓に送り込み、そ
れを通し、そこから出すFIFOシフトの埋め合わせのた
め、動作時にポインタが更新される場合には再発生記号
及び記号ストリングの先に発生した位置を明らかにする
のに必要なポインタを提供するのによく適合する。記号
は、前述のようにリテラルコード語とコピーコード語の
いずれに関連するが判定された直後に、記号位置ｉを介
して窓にシフトインされ、一方、古い記号は、それによ
って占められたスペースがより新しく圧縮された記号及
び記号ストリングを記憶するのに必要になると、記号位
置ｉ−ｗを介して窓からシフトアウトされる。ソース記
号と固定長の探索窓との相対移動は、探索窓に対する記
号の物理的シフトとして最も視覚化しやすいが、それは
ソフトウェアの場合、ソフトウェアの制御下でソース記
号に対してシフトされるポインタを用いることによって
実現可能であることを理解すべきである。

第6A図〜第6E図を参照すると、トリー（Trie）の木デ
ータ構造が（1975年のアジソン・ウェズリー社（Addiso
n−Wesley）、コンピュータプログラミングの技術（The
Art of Computer Programming）第３巻、第２版の481
頁におけるディー・イー・クヌース（D.E.Knuth）によ
る：分類と探索（Sorting and Searching）参照のこ
と）探索木73の基本的な機能要件を満たすことが明らか
になる。周知のように、記号ストリングは、木の根から
ストリングの各順次毎に更にレベル１つ分ずつ下降する
ことによって、トリー（Trie）の木に挿入される。従っ
て、木のｊ番目のレベルは、任意の記号ストリングにお
けるｊ番目の記号に従って分岐し、その結果、木は、本
質的に、探索窓内における全ての記号及び記号ストリン
グの位置を示すのに必要なポインタの全てを含むことに
なる。ただい、記号ストリングをトリー（Trie）の木に
挿入するには、かなりの量の処理時間が必要になる（最
悪の場合、ｎ個の記号からなるファイルに関する挿入時
間は、Ｏ（ｄ・ｎ）になるが、ここでｄは最大許容可能
コピー長である）。更に、こうしたデータ構造のサイズ
は、Ｏ（ｄ・ｗ）にまで増大するが、ここでｗは探索窓
のサイズであり、従って、単純なトリー（Trie）の木の
データ構造は、本発明のほとんどの実際の用途には大き
すぎる。

第7A図〜第7E図を参照すると、パトリシア（PATRICI
A）の木（1968年の米国計算機学会の定期刊行物（Journ
al of the Association for Computing Machinery）の
第15巻第４号513〜534頁におけるディー・アール・モリ
ソン（D.R.Morrison）による“パトリシア：英数字でコ
ード化された情報を検索するための実用アルゴリズム
（PATRICIA−Practical Algorithm to Retrieve Inform
ation Coded in Alphanumeric）”参照のこと）は、ト
リー（Trie）の木に対する比較的コンパクトな代替案で
ある。周知のように、パトリシア（PATRICIA）の木の内
部ノードは、それが牽引を作成中のファイルに対するポ
インタを含んでおり、従って、こうした木データ構造
は、探索径路の枝毎に単一の“デジット”又は記号を含
みさえすればよく、このためトリー（Trie）の木（すな
わち、子孫が、１つしかないもの）の余分な内部のノー
ドが排除される。たとえば、検索木73（第３図）がパト
リシア（PATRICIA）の木であれば、第7B図〜第7E図に弧
で挿入して表示された記号は、木の分岐に影響しないの
で、明らかにデータ構造へ含める必要はない。ただし、
それらが納まっている弧に関するノードの位置ポインタ
とレベルポインタの対により、識別される探索窓記号位
置内における記号を走査することによって回復すること
ができ、従って、それらは該弧で有効に表示される。

古典的なパトリシア（PATRICIA）の木は、各探索の終
了時に、ファイルのアクセス及び比較を１回行うだけで
よい。しかし、パトリシア（PATRICIA）スタイルの探索
木73が本発明の実施に用いられる場合、一般に、木への
記号ストリングの挿入時に横断される弧で表示された記
号を走査するのが望ましく、これによって、木を下降し
ていく間に、該弧が導くノード内の位置ポインタが更新
可能になる。普通、探索木73に挿入される“デジット”
は、バイト（たとえば、８ビットの文字）であり、256
ほどの大きさの分岐要素を提供することができる。しか
しながら、通例、ノードはそれほど多くの子孫を有して
おらず、従って、その探索径路の分岐を規定するため、
木73のノード内に確保しなければならないスペース量
は、その弧のハッシング（hashing）によって、減少さ
せることができる。

比較的カットオフの深さが浅い探索木を用いるにもか
かわらず、十分な圧縮を行うことができる場合、パトリ
シア（PATRICIA）の木は、探索木73にとって受入れるこ
とのできる選択である。前に指摘したように、こうした
木は、適度にコンパクトなデータ構造によって規定され
るが、それはトリー（Trie）の木とほぼ同じ挿入処理
（すなわち、根に戻ってそれから木を降下していく）に
依存している。従って、より長い記号ストリングをパト
リシア（PATRICIA）の木に挿入するのに必要とされる時
間は、最大許容可能コピー長が比較的短い（やはり、最
悪の場合には、ｎ個の記号からなるファイルに関する挿
入時間は、Ｏ（ｄ・ｎ）となるが、ここで木の必要とさ
れる深さｄは最大許容可能コピー長に等しい）具体例に
対して該タイプの木を実際に適用するのを制限する傾向
がある。

幸いなことに、第８図に示す少し修正を施された接尾
木は、Ｏ（ｎ）時間内に、探索木73（第３図）に記号ス
トリングを挿入できることが必要な、又は望ましい具体
例に対して利用することが可能である。1976年の米国計
算機学会定期刊行物（Journal of the Association for
Computing Machinery）の第28巻第１号262〜272頁にお
ける“スペース節約型接尾木アルゴリズム（A Space−E
conomical Suffix Tree Algorithm"）にイー・エム・マ
ックレイト（E.M.McCreight）によって説明されている
ように、接尾木の内部ノードは、第８図にダッシュライ
ンで示すように、それらの接尾部に関するノードにそれ
らを連係させるポインタを含んでいる。更に詳述すれ
ば、第９図に示す一般化した接尾木を参照すると、スト
リングaXのような接尾部を拡張した記号ストリングに関
する内部ノードは、Ｘのようなその接尾部の拡張を表し
たノードに対するポインタを含んでいることが分かる。
従って、探索窓における位置ｐから開始する接尾部を拡
張した記号ストリングが、接尾スタイルの探索木73のレ
ベル１に挿入されたばかりの場合、接尾部を拡張した記
号ストリングを表すノード（たとえば、位置ｐから開始
するストリング）からその接尾部の拡張に関するノード
（たとえば、位置ｐ＋１から開始するストリング）に至
る近接接尾部ポインタが常に存在するので、位置ｐ＋１
から開始するストリングは、その根に戻ることなく、探
索木に挿入可能になる。

第９図について更にもう少し詳しく考察してみると、
aXYからなるストリングに関する前の反復時に、整合が
見つけられた状況を表していることが分かるが、ここ
で、ａは単一の記号であり、Ｘ及びＹは１つ以上の記号
からなるストリングであり、ｂはＹに続く最初の整合の
とられていない記号である。時々生じるそれ以外の複雑
化の要因について説明するため、αは、ストリングaXYb
に関する探索径路とストリングaXYZに関する探索径路と
の間の弁別を行うため、木に付加されたばかりの新しい
内部ノードであり、この場合、Ｚはｂから始まらないも
のと仮定した。該仮定を考慮すると、ノードαに関する
接尾部連係の計算を行う必要がまだあるということが理
解できるであろう。

マックレイト（McCreight）の上記教示に従って、ま
ずノードα（まだ接尾部の連係が行われていない）から
木を登り（すなわちその根に向かって）、次に高位のノ
ードβに達することによって、次のストリングXYbを木
に挿入し、その結果、ストリングaXYからＹを除去する
ことが可能になる。ノードβは、必然的にストリングaX
を表すことになり、従って、その接尾部ポインタが規定
によりストリングaXの接尾部Ｘを表すノードγに続くこ
とになる。Ｘを表すノードを見つけると、ここで木を降
下して、まずストリングＹを“再走査”し、次に、更に
木を降下して“走査”を行い、サブストリングXYで開始
する記号ストリングについて、現存する最長の整合を見
つけることにより、ここで接尾部を拡張した記号ストリ
ングXYbを挿入することが可能となる。その接尾部を拡
張したXYbに関して整合が存在する場合、“再走査”は
サブストリングXYに対応するＩノードδで終了すること
になる。一方、接尾部を拡張した記号ストリングXYbに
対する整合がなければ、Ｙで始まるストリングを表す弧
を開いて、それを引き継ぐ弧によって表されるＹを伴う
新しいノードδを挿入することによって、ノードδが生
成されることになる。どちらの場合にも、ノードδは記
号ｂに分岐し、前の記号ストリングaXYに関する接尾部X
Yを表す。従って、それに対するポインタがノードαの
接尾部の連係フィールドに入力され、これによって、最
も新しく生成されたものを除くことになる可能性はある
が、接尾部木内にある全ての内部ノードが接尾部で連係
する不変量が復元する。

幸いにも、上述の処理時に、“再走査”される弧で表
された記号ストリング（たとえば、ストリングＹ）は、
木に挿入されるストリングの対応する記号と対照する必
要はないというのは、この２組の記号の一致は、前の反
復時に確証されているためである（すなわち、記号スト
リングaXYの接尾部XYが木に挿入されていた時）。その
最も新しい接尾部の拡張だけしか、探索木の内容と対照
する必要がないので、この先行知識によって、ほぼ線形
時間で接尾スタイルの木73に記号ストリングを挿入する
ことが可能になる。

本発明の特徴の１つによれば、マックレイト（McCrei
ght）によって説明された上記接尾スタイルの探索木の
データ構造に対し、そのサイズに制限を加え、その保全
に必要な時間を短縮するため、いくつかの重要な修正が
加えられる。前に指摘したように、木の葉は、FIFOに基
づいて順次シフトされ、バッファ71（第３図）の探索窓
の記号位置ｉ〜iwに送り込まれて、これを通ってそこか
ら送り出され、これにより、固定長の探索窓内にソース
データの最も新しく圧縮された部分を保つための規則正
しい手順が与えられる。更に、“息子（son）カウン
ト”フィールドが、削除すべきノードを識別するために
木の内部ノードに含まれる。明らかなことだが、内部ノ
ードは、代替探索径路間における弁別に必要とされる場
合に限り、木に付加される。残っている“息子”が１つ
しかない“親（parent）ノード”は、探索径路の弁別を
行えない。従って、任意のノードの息子カウントフィー
ルドの値が１にまで下がると、かならずそのノードは削
除され、その唯一残っている、すなわち“孤児となった
（orphaned）”息子は、次に高レベルの、すなわち“祖
父（grandparent）”ノードからの弧で表された記号又
はストリングと組合わされる。

更にもう１つ、既知接尾スタイルの探索木から逸脱し
ている点は、必ずしも更新を行うために木の根に戻るこ
とを必要とせずに、接尾部木の内部ノードにおける位置
ポインタの更新が行えるようになっているということで
ある。更に詳述すると、本発明のより細目にわたる特徴
の１つに従って、接尾部木の内部ノードにおけるポイン
タの更新を行うため、“パーコレーティング更新”を用
い、これによって木の接尾部の葉（すなわち、最近圧縮
されたソース記号）が探索窓を通ってシフトされる際、
それらのポインタをその葉に対し維持することが可能に
なる。そのため、木の各内部ノードは、前述の位置及び
レベルポインタ、接尾部ポインタ及び息子カウントフィ
ールドに加え、単一の“更新”ビットを備えている。更
に、木に新しい記号ストリングが挿入される時には必ず
ストリングの最初の記号すなわち、先行記号の走査窓に
おける現在位置が、挿入されたばかりの記号ストリング
の新しい葉に関する親ノードまで上方へ移行し、これに
より、（１）最も新しく発生した所定の記号ストリング
の先行記号の現在位置が、その発生と探索窓内にまだ存
在する可能性のある同じ記号ストリングの以前の発生と
の区別を行うため、その葉の親ノードの位置フィールド
に書き込まれ、（２）新しい葉の親ノードに関する更新
ビットの状態が反転されることになる。親ノードの更新
ビットが、“偽”の状態から“真”の状態にスイッチさ
れると、それ以上位置の更新は波及しない。しかし、新
しい葉の親ノードの更新ビットが、“真”の状態から
“偽”の状態にスイッチされると、新しく挿入され、記
号ストリングの先行記号に関する探索窓での現在の位置
は、木の上方へ移り（その根に向かって戻る）、更新が
“偽”の更新ビットを有する高レベルのノードに達する
まで、記号ストリングに関する探索径路上の全てのノー
ドの位置フィールドを更新する。この更新処理は更新の
伝播がその更新ビットが“偽”の状態にある時に、更新
を受ける第１のノード（最低レベルのノード）で終了す
るので、“パーコレーティング更新”と呼ばれる。こう
した更新終了ノードの位置フィールドは、新しく挿入さ
れた記号ストリングの先行記号を指示するために更新さ
れ、該ノードの更新ビットが、“真”の状態にスイッチ
されて、これによってそれが受ける次の更新をその親ノ
ードに伝播するように、そのノードの条件付けが行われ
る。最後に新しく挿入される記号ストリングの最後の記
号が探索窓に送り込まれ、これにより探索窓が満杯の場
合には、探索木73（第３図）の最古の葉が削除されるこ
とになる（すなわち、探索窓から送り出される）。

前に指摘したように、接尾スタイルの探索木73から葉
を削除すると、息子１人しか残されない親ノードの削除
がトリガーされるのが望ましい。そのため、こうした木
から削除される親ノードの位置は、やはり上述の処理に
従って、多かれ少なかれ、木の根に向かって上方へ移行
する（すなわち、削除されるノードの位置ポインタが、
必ず次に高レベルのノードの位置フィールドに書き込ま
れるが、高レベルのノードの更新ビットの状態に従っ
て、条件付きでしか、そこから上方へは伝播しない）。
基本的な区別は、削除されたノードからのパーコレーテ
ィング更新の際、こうした更新を受信する高レベルのノ
ードのそれぞれに対し、現存する位置ポインタが、提案
された更新の位置ポインタと対照され、これによって、
その２つのポインタのうち最も新しい方が、（１）更新
を受けるノードに対する位置ポインタとして、及び
（２）更新がそこまで及ぶことを認められる場合には、
次に高いレベルのノードに対する提案された更新として
選択可能になる。

最悪の場合、新しく挿入された記号ストリングの接尾
部の葉、すなわち、最後の記号に関する親ノードから木
の根までの経路における全てのノードが、“真”の更新
ビットを有し、このため更新が木の根に至るまで全面的
に広まる可能性がある。しかしながら、上述のパーコレ
ーティング更新処理は、それを実施するのに必要とされ
る時間が、探索木73の葉の全てについて償却される場合
には、記号又は文字毎に一定の時間量で実施するのが可
能であることが分かる。更に一層重要なことだが、この
処理は、探索木73の内部ノードの全てに妥当な位置ポイ
ンタを保全するのに有効であり、これによりノードはそ
れらが表わしている記号を含む探索窓の記号位置に対
し、正確な参照符が付与されることになるのが分かる。

探索木73の更に別の実施についても思いつくことにな
る。たとえば、トリー（Trie）の木と、パトリシア（PA
TRICIA）の木に関する前述の考察から明らかなように、
接尾部木に備えたパーコレーティング更新は、各記号ス
トリングの挿入毎に、木の根に戻りさえすれば、回避す
ることができる。その場合、木の内部ノードは更新ビッ
トが不要であり、ノードが削除される時、更新を行う必
要がない。同様に、接尾部の連係は、該タスクを実施す
るのに必要な平均時間を大幅に短縮するが、こうした探
索木への記号ストリングの挿入時に、接尾部ノードの位
置を見つけるのに不可欠ではない。それらがなければ、
所定のストリングに対する接尾部の葉から開始しそれか
ら接尾部のノードに達するまで、親ポインタに従って木
の根に向かって戻ることが可能である。明らかなことだ
が、所定の記号ストリングに関する接尾部の葉は、探索
窓における所定の記号位置ｐを起点とする整合を備える
ことが分かっている、ストリングaXY（第８図）のよう
なストリング以後の最初に整合のとられていない記号で
あるため、簡単に位置が求められる。更に、こうした記
号ストリングに関する接尾部のノードは、親ポインタを
用いて、接尾部の葉から木の根に向かって、上方へ挿入
されるストリングの長さによって決まる適当な数のレベ
ルだけ移動させることによって、識別することができ、
これによって各記号ストリングの挿入毎に、木の根まで
戻らなくても済むという利点が保たれる（明らかなこと
がだ、ハッシュテーブルの検索は、通常、接尾部の葉に
向かってレベル毎に下降していく必要があるため、探索
木を移動するコストは均一ではない）。しかし、最大許
容可能コピー長が長い場合には、この接尾部ノードに基
づく代替ストリング挿入処理は、最悪の場合、望ましく
ないほど遅くなる。同様に探索木73の一部が深い場合に
は、全ての更新が木の根にまで及ばねばならない時、極
度に長い平均更新時間が必要になる。従って、通常は接
尾部連係及びパーコレーティング更新が望ましい。

D.拡張された具体例 1.統計的感応コード化 明らかなことだが、固定長のリテラルコード語及びコ
ピーコード語の有効利用には、ソースデータが分解され
ることになりリテラル及びコピーの平均長に対し、該コ
ード語の長さを慎重にバランスさせる必要がある。探索
窓のサイズが増すことは、見つけることができる整合す
る記号ストリングの平均長を増すことにつながるが、探
索窓内において個々の記号位置を指定するのに必要な位
置ポインタのサイズも増す。より新しい記号位置を表示
するポインタが、より利用されることになりやすいの
で、これらのより大きなポインタは、それらが無差別に
用いられる場合、得られる圧縮をおさえることが可能で
ある。更に、リテラル及びコピーが短くなる方が、リテ
ラル及びコピーが長くなるより可能性が高い。従って、
圧縮を増すことが所望の場合には、統計的感応による可
変長のリテラルコード語及びコピーコード語を利用し
て、本発明を実施するのが有効である。

こうした統計的感応による可変長時間のコード語を供
給するために、様々な技術を利用することができる。た
とえば、コード化論理部74（第３図）に報告される、リ
テラル長及びコピー長と、変位のハフマン（Huffman）
適応コード化又は演算コード化を利用することができ
る。しかしながら、こうしたコード化は、一般に遅く、
圧縮器12（第３図）の固定長の探索窓が、すでにそれを
ソースデータに対し適合させているので、それは単に二
次的な適応の利点しか生じない。更にもう１つのアプロ
ーチは、各種長さのコピー及び変位のコード可だけでな
く、各種流さのリテラルのコード化に対しても、ビート
長の異なる拡張された一群の独特のコード語を予め割当
てることである。その場合、短いリテラルと短い近接コ
ピーは、一般にそれらに比較的短いコード語を割当てる
ことによってコード化され、一方、より長いリテラル及
びより長いコピーとより遠くに変位したコピーの両方又
は一方は、それらにより長いコード語を割当てることに
よってコード化され、これによって、用いられるコード
語の長さが平均的なソースデータが分解されるリテラル
成分とコピー成分の頻度分布の所定のモデルに合うよう
調整される。長さが４ビットから30ビット（それらのサ
イズ参照のこと）にわたる、代表的な一群の互いに区別
可能なコード語（それらの導入インジケータのビットシ
ーケンス参照のこと）については、それらが割当てられ
るコード化タスク（それらの名称と16kの長さの探索窓
の様々な変位範囲内で、それらによって扱われるストリ
ング長を参照のこと）、及びそれらが割当てられるリテ
ラルとコピーにこれらのコード語によって独特なコード
化を施すことができるようにするレイアウト（コード語
のレイアウト参照のこと）と共に、以下に述べる。

ただし、本発明のより重要な特徴の１つに従うと、統
計的感応による可変長のリテラルコード語及びコピーコ
ード語を生成するより簡単で有効な技術の１つによっ
て、リテラルの長さとコピーの長さ及び変位を表す〈開
始，ステップ，停止〉の単項コードの線形数列を供給す
る。第10図に91で示すような単項符号器が得られる。明
らかに、コード化規則又は方法は、単項符号器91の前に
配置されるコード化論理部92によって強化されるが、そ
れ以外の点では、第10図に示す圧縮器は、第３図に示す
圧縮器と十分に似ており、同様の部分の識別を行うのに
同様の参照番号を用いることが可能である。

定義の要素として、〈開始，ステップ，停止〉の単項
コードは、リテラルの長さとコピーの長さ又は変位がデ
ジタル方式で記録されており、値のフィールド自体が後
続するフィールドのビット長を指定する単項コードで構
成される。次に値のフィールドは、指定の“開始”数以
上のビットと、指定の“停止”数以下のビットを含むこ
とを強要される。更に、値のフィールドのビット長は、
指定の“ステップ”パラメータの線形関数としてインク
リメンタルに変化し、可変長コードの線形数列を定義す
る。従って、こうしたコードのｎ番目のコード語は、
（開始＋（ｎ−１）・ステップ）のサイズの値フィール
ドが後続する単一の“0"（すなわち、単項フィールド長
インジケータ）によって終了するｎ−１個の“1"から構
成される。整数が、これらの異なるサイズのコード語に
順次割付けられていく。たとえば、〈3,2,9〉の単項コ
ードの異なる長さの４つのコード語が、以下のように、
整数カウント数を写像する。

コード語 範囲 0xxx ０−７ 10xxxx ８−39 110xxxxxxx 40−167 111xxxxxxxxx 168−679 明らかに、値フィールドのビット長が、所定の“停
止”サイズに等しい場合には、単項フィールド長インジ
ケータに対する単一の“0"ターミネータは省略すること
ができる。テーブルの探索手順が単項コードをコード化
するための実行可能な代替案であることを理解すべきで
あるが、参考までに、本書に組込んだ付録Ｂには、単項
コードを生成するための単純化擬似コードによる計算手
順が示されている。更に、参考までに、付録Ｃも組込ま
れているが、それは、上に概略を述べた論理規則に従っ
てソースデータを分解することにより識別されるリテラ
ルとコピーに対し、単項コードを加えるテキスト置換デ
ータ圧縮システムに関するセダー（Cedar）ソースコー
ドのリスティングであるためである。しかしながら、単
項コード化は、圧縮可能なコヒーレンシー（coherenc
y）が存在する長さ（及び／又は圧縮不能な非コヒーレ
ンイーが存在する長さ）を捕捉し、テキスト置換スタイ
ルのデータ圧縮システムの場合には、冗長性を見出すこ
とができる位置を捕捉するための、様々なタイプのラン
長又はストリング長に依存するデータ圧縮に利用できる
ことを理解すべきである。更により一般的には、単項コ
ード化は、ラン長，コピー長，コピー変位，リテラル長
等を含む、数値の可変長コード化をもたらすデジタルデ
ータ圧縮システムに利用することが可能である。

明らかなことだが、さまざまな要素が上述のコード化
規則に従って、圧縮されるデータのリテラル長と、コピ
ー長及び変位をコード化するための〈開始，ステップ，
停止〉単項コードの選択に影響する可能性がある。たと
えば、第11図に示す単純化有限状態機械（FSM）によっ
て表されているようにコピー長のコード化に〈2,1,10〉
の単項コードを利用し、これによって、最大許容可能コ
ピー長を2044の記号に制限することができる。コピー長
がゼロの場合、リテラルの信号を出す。その長さは、さ
らに〈0,1,5〉の単項コードを用いてコード化され、そ
の結果、最大許容可能リテラル長は、63の信号になる。
一方、コピー長が非ゼロであれば、〈10,2,14〉の単項
コードでコピーの変位をコード化し、21,504の記号位置
からなる広い探索窓内のどこかを起点とするコピーを指
摘することができる。実際には、単項数列における無駄
な状態を回避するため、最大コピー長及びリテラル長が
選択されるのが普通である。時には、同様の技術がコピ
ー変位の単項コード化における無駄な状態を回避するた
めにも利用される。

無駄な状態を回避するため、用いられる単項コードに
対し改良を施すことも可能である（不図示）。たとえ
ば、ソースデータをリテラルとコピーに分解するための
前述の規則は、最大許容可能リテラル長未満のリテラル
がその直後に決して、長さが２のもう１つのリテラルも
コピーも続かないことを保証する。従って、こうした非
最大長のリテラルがコード化される時には、必ず、こう
したリテラルに続かねばならないコピーのコード化のた
め、〈2,1,10〉のコードは、２つだけシフトダウンし、
その結果、ゼロのコード値は、３のコピー長を表し、１
のコード値は、４のコピー長を表し・・・といった形に
なるようにすることができる。

開始時における値に属するもう１つの改良は、探索窓
が充填されていく際に、段階的にコピー変位のコード化
を取入れることである。たとえば、こうした段階的利用
はコピー変位に対し〈10−x,2,14−ｘ〉の単項コードを
用いることによって実現することができるが、この場
合、ｘは当初、10に等しくなるようにセットされてお
り、次に変位ポインタが以前に圧縮された記号を含んで
いる全ての窓での位置を識別できることを必要とされる
時、その必要に従って、ゼロまでデクリメントされる。

コピー変位のコード化における無駄な状態を回避する
ために利用できる更にもう１つの技術は、そのフィール
ドが表わさねばならない様々な変位値のそれぞれを、一
義的に識別するため一群をなす“疎（sparse）”コード
語を提供するのに丁度の大きさになるまで、その単項数
列における最大のフィールドを収縮させることである。
従って、最大の、すなわち“停止（stop）”サイズのフ
ィールドの〈10−x,2,14−ｘ〉の単項コードでコード化
される値が合計Ｖ個ある場合、そのフィールドに関する
“疎コード化”により、Ｖ個の値のうち小さい方は、 のビットでコード化され、その大きい方は、 のビットでコード化される。明らかなことだが、こうし
た疎コード化は、Ｖ個の値のそれぞれをコード化するた
めに、14−ｘのビットを用いる必要をなくし、この結
果、最大変位値を備えたコピーコード語のビットサイズ
を縮小することになる。

この疎コード化技術をさらに説明するため、６つの値
のうち１つに関するコード化について考える。その値を
コード化するのに３ビットのフィールドが用いられる場
合には、可能性のある８つの状態のうち２つが、無駄な
２状態になる。しかし下記のように、値０と１は２ビッ
トでコード化し、値〔2..5〕は３ビットでコード化する
と、無駄な状態がなくなる。

値 コード ０ 00 １ 01 ２ 100 ３ 101 ４ 110 ５ 111 典型的な疎コード化手順及び解読手順について以下に
示す。

2.高速の圧縮器 前述の圧縮器は、伸長器63（第５図）のような記憶容
量を制限した伸長器によって、比較的迅速に伸長できる
ように、圧縮データを書式作成する。従って、それらは
最終ユーザに配布し、彼等によって伸長されるように、
フロッピーディスクへの圧縮形態でソフトウェアの大量
放出を行うことが所望される場合のように、圧縮速度が
設計を単純化したり、伸長器の性能を最適化することほ
ど重要でない用途には、とりわけよく適合する。さら
に、前述の圧縮器は、普通の適度に簡単なハードウェア
の実現にむいている。たとえば、VSLIによるハードウェ
アの具体例では、探索木は、排除され、最長の整合を求
めるように探索窓内の多数の文字に対し同時に作用する
幾つかのコンパレータに置き換えられる。都合のよいこ
とに、探索窓に含まれている記号は、半導体のメモリー
チップに記憶されるので、最長の適合を求める際、外部
メモリーを参照する必要がない。部分的には外部メモリ
ーを参照する必要がないため、この種の圧縮器は極めて
高速度で働き、広範な種々のデータに対し優れた圧縮を
行うことができる。さらに、それらは単一のチップに納
まるため、汎用計算機能を用いずに、“独立（stand al
one）”データ圧縮機能が望まれる用途には適してい
る。

しかしながら、ファイルが圧縮した形で得られねばな
らない場合のように、より高速のソフトウェア圧縮器が
望ましい別の状況もある。このため、本発明の更にもう
１つの特徴に従って、本発明の上述の固定長のコード語
と単項コード化された可変長のコード語の具体例による
圧縮速度は、先行コピーの最初の記号によって、又は、
前にリテラルとして圧縮データストリームに挿入された
記号によって画定される境界上からコピーが開始するよ
うに制限することによって大幅に増大させることが可能
である。前述の圧縮器におけるように、探索窓内の各記
号毎に、１つの葉を探索木73（第３図）に備えているの
ではなく、本発明のこれらのより高速の具体例は、各コ
ピーコード語及び各リテラルコード語毎に、１つの葉し
か探索木73に備えていない。これは、該木73を探索し、
更新するのに必要な計算を減少させ、これによって、平
均的データの圧縮速度を大幅に増すことになる。前のコ
ピーの第２の、すなわち、後続の記号を起点とする整合
は無視されるので、従って“得らる最長の整合”は、探
索窓内のどの場所においても最長の整合かもしれない
し、そうでないかもしれない。従って、このアプローチ
によって上昇する圧縮速度は、システムがソースデータ
の変化に順応する速度を低下させるという犠牲を払って
得られることになるのは明らかである。さらに、明らか
になる理由によって、これらの、より高速の圧縮器のた
めの相補形（complementary）伸長器は、幾分遅くな
り、より多くの記憶を必要とする。

全てのコピーが先行コピー又はリテラルを起点とする
ように制限する利点の１つは、再発生する記号ストリン
グの前の前の発生位置を明らかにする位置ポインタは、
放出された以前のｙ番目のコード語又はリテラル文字の
始めを識別できさえすればよいため、圧縮することがで
きるということである。たとえば、“圧縮変位”は、次
のように実現することができる：まず、圧縮器の入力バ
ッファにポインタを記憶するために、窓のサイズに等し
い長さの記憶素子のアレイが設けられる。このアレイの
各素子は、圧縮器から送り出されるコピーコード語又は
リテラル文字の異なる１つを示し、従って、探索木73に
おける葉とこのアレイにおける素子との間には、１対１
の対応が存在しており、木の各内部ノードは、その派生
する葉の１つに対応したアレイの素子を識別する。次に
整合のとられた記号ストリング（すなわち、コピーが取
って代わろうとしている記号ストリング）の葉に対応し
たアレイ素子と、最長の整合が見出された葉、すなわ
ち、内部弧に対応したアレイ素子の間におけるアレイ素
子の数によって、コピー変位が測定される。すなわち、
前の具体例と同じように、コピー変位は、“固定長の
窓”において測定されるが、再発生する記号ストリング
の以前の発生に関する先行記号の文字バッファにおける
位置は、“探索窓”の記号位置に直接アドレス指定する
ことによってではなく、このポインタのアレイを“間接
的に”詳しく検討することによって求められる。従っ
て、参照ポインタアレイのサイズは固定されているが、
探索窓の長さは最近圧縮されたデータの組成に従って伸
長したり、収縮したりする可能性がある。コピー長は、
やはり記号で測定されるので、コピー長の測定及びコー
ド化についての先行する説明は、これらの修正具体例に
も当てはまる。参考までに、本書に組み込んだ付録Ｄ
は、圧縮変位と単項コード化の組合せによる上述の圧縮
規則に基づく圧縮システムに関する、セダー（Cedar）
のソースコードのリスティングである。

各反復時に、根から始めて、該高速圧縮器の探索木73
（第３図）に記号ストリングが挿入される。ストリング
は、現存のコード語／リテラル文字の境界に挿入される
だけであるため、それらは、線型時間に挿入することが
できる。接尾部ポインタ及び伝播更新は不必要であり、
従って、該具体例に関する探索木73（第３図）は、比較
的シンプルなパトリシア（PATRICIA）の木（第7A図〜第
7E図参照のこと）が望ましい。しかし、該具体例の場
合、パトリシア（PATRICIA）スタイルの探索木73の深さ
１における全ての記号について、永久ノードのアレイを
生成するのが有効である点には、注意すべきである。長
さ１のコピーは決して送り出されることがないので、探
索窓が、たとえこれらの永久ノードのそれぞれに対応し
た記号を常に含んでいることができなくても、それを行
うことは可能である。探索木73に対しこうしたノードの
永久アレイが設けられる場合、記号ストリングは、挿入
されているストリングの最初の記号に基づく永久ノード
のアレイに指標付けを行うことによって、木に挿入する
ことが可能になる。その後、挿入処理は普通ハッシュテ
ーブルの探索と弧比較に依存して、パトリシア（PATRIC
IA）スタイルの探索木の利用に関して概略を記述したよ
うに、さらに深く木を降下していく。探索木に記号スト
リングが挿入される間、探索木に挿入される記号ストリ
ングに関する探索経路の全てのノードを通過するので、
挿入処理時に探索木を降下していく間に、それらのノー
ドによって表される記号に関する更新された探索窓の記
号位置をノードの位置フィールドに書き込むことができ
る。

前のコピーコード語を開始する記号で、または、前の
リテラルに含まれた記号で始めるようにコピーを制限す
ることによって、これらの修正された圧縮器がソースデ
ータの局所コヒーレンスを捕捉する能力が低下するが、
それは比較的控えめなビットサイズの圧縮ポインタを利
用して、比較的遠くまで戻って前に圧縮したソースデー
タに達することを可能にし、その結果より大きい探索窓
を用いて、より長い整合を行うことが実現可能になる。
これは、テキストのような自然語の構造を有するソース
データにとって好都合である。しかし、前述の制限は、
例えばソースデータが走査像を表わす場合に通常存在す
るような、極めて局所化されたコヒーレンスを大量に備
えたソースデータの圧縮には望ましくない場合もあるこ
とが分かる。

3. 追加変形例 全ての先行するコピー／リテラルの境界に比べて、よ
り頻繁に探索木73（第３図）を更新するため、これらの
案に対するいくつかの変更を用いることができる。例え
ば、探索木73に対して、長さが２の各コピーコード語に
よって表される記号の間に葉を加えることと、長さが３
のコピーコード語によって表される全ての記号ストリン
グの最後の記号に後続して、探索木に葉を挿入すること
の両方または一方を行うことができる。実際のところ、
前述の圧縮器によって表される極値の中間において、探
索木に葉を挿入するという変更（そのうちの１つにおい
ては、全ての記号について、探索木に葉が入力され、そ
のもう１つにおいては、各コピーコード毎に１度、各リ
テラル文字毎に１度、葉が入力される）が、どれも、こ
の方法の一般的な枠内で実現可能である。これらのより
高速の圧縮システムの能力を増すためのこれらの技術及
びその他の技術を用いて、ソースデータの局所コヒーレ
ンスを捕捉することによって、ある程度圧縮度を増すこ
とが可能になるが、その圧縮及び伸長の速度は低下す
る。さらに、ある時点で木が凍結されて更新されず、従
ってその後は探索木の静的データ構造に基づいて、コピ
ー及びリテラルとしてそれ以上のソース記号がコード化
されるが、木はコード化されたばかりのストリングにつ
いては更新されないという変更もある。その場合、圧縮
度はソースデータの非定常統計値のために低下するが、
必要の際には木のサイクリングを再開することができ
る。このアプローチは最高速が必要とされる用途に用い
られる可能性があるが、圧縮量を減らすことになりがち
である。

更に、有効な記号によって、窓が準備すなわち初期設
定され、ソースデータの最初の部分の圧縮が改善可能に
なる、前述の２つの方法に対する変更もある。これはソ
ースデータが準備データと似ている場合には圧縮を改善
する可能性があるが、ソースデータが準備データと似て
いない場合には、少し複雑になり、圧縮を悪化させるこ
とになる。

ストリングが探索木に加えられ、あるいは探索木から
除去される場合に関する変更以外に、ソフトウェアの具
体例に用いられるデータ構造に関する変更もある。付録
Ｃにおいて、我々は、連鎖した円形のハッシュテーブル
に弧が挿入される接尾部の木を用いた。明らかなことだ
が、ハードウェアの具体例において木は不要であり、窓
自体だけが圧縮方法の中心をなす。また、明らかではあ
るが、ソフトウェアの具体例において、接尾部の木を実
現するために、他の多くの種類のハッシュテーブル、リ
スト又はそれ以外のデータ構造を用いることが可能であ
る。更に、明らかなことだが、我々は、その実施が有効
でないと信じているが、接尾部の木をより単純なパトリ
シア（PATRICIA）の木に置き換えることもできるし、あ
るいは、それを２進木、分類済みリスト又は他のデータ
構造に置き換えることも可能である。こうした変更は、
付録Ｃについても可能である。こうした変更の全ては、
プログラミング技術における熟練者の能力の範囲内にあ
る。

更に明らかなことだが、付録A,C及びＤの実現には８
ビットの記号又は文字が用いられるが、他の記号サイズ
を利用して、同等の圧縮器を実現することが可能であ
る。

更に、理解できるはずだが、付録A,C及びＤは、それ
らのコピーコード語が窓内で見つけられる最長の整合に
必ず当てはまるという意味において“貪欲”であるが、
それが最長の整合よりも短いコード語で表すことが可能
であれば、最長の整合よりも短い整合が時々コード化さ
れる変更を実現することは、該技術の熟練者の能力の範
囲内である。こうした変更は“貪欲な”もう片方の方法
に比べて遅くなる可能性があるが、概して少し高めの圧
縮度を達成することができる（最悪の場合でも、かなり
高い圧縮度を達成する可能性がある）。

更に、前述の２つの圧縮器は、コピーコード語とリテ
ラルコード語との選択を行い、コピーのためにどの時点
でリテラルコード語を終了すべきかを決めるための特定
の方法を用いている。明らかなことだが、他の多くの方
法が可能であり、これらのいずれかを実現することは、
当該技術における熟練者の能力の範囲内にある。

最後に、付録Ｃの具体例では、単項コード〈開始，ス
テップ，停止〉を用いて、コピー長及び変位を別個にコ
ード化するが、コピー長の単項コード化又はそれ以外の
コード化がすでにコード化されているコピー変位によっ
て決まる変更又はコピー変位の単項コード化又はそれ以
外のコード化がすでにコード化されているコピー長によ
って決まる変更を利用することも可能である。実際に
は、コピー長とコピー変位の両方のコード化を決めるの
に単一の接頭部コードを用いることを含め、更に他の変
更も思い浮かぶことになる（上述の固定長のコード化参
照）。これらの変更の全てが、プログラミング技術にお
ける熟練者の能力の範囲内にあり、特定の選択は実現の
容易さと代表的なソースデータのサンプルの統計的特性
によって決まることになる。

4.圧縮比の改良 全ての必要なコピーを行えるようにするのに、各記号
ストリングの１つの例しか必要としない場合でも、圧縮
データは探索窓のアドレス可能なスパン内に同一の記号
ストリングの複数コード化例を含んでいる可能性がある
ため、上述の圧縮器による圧縮データのコード化が最善
である。しかし、探索木データ構造は再発生記号ストリ
ングがそれらと共通の探索経路を共用するため、スペー
スをむだにしない。

従って、圧縮比を改良するため、パトリシア（PATRIC
IA）の木（第7A図〜第7E図）構造のような探索木のデー
タ構造に直接基づいたコピーコード語を利用してコード
化を実施することが可能である。例えば、こうした木の
任意の葉で終了する整合を表すコピーコード語（LeafCo
py）と、木の内部弧で終了する整合を表すコピーコード
語（NodeCopy）との区別を行うため、単一ビットの接頭
部（“0"または“1"）を用いることができる。圧縮器と
伸長器においては同一の探索木が構築されるが、伸長器
はそれが圧縮器から受信するコード語を用いて、圧縮器
が構築した木を複製する。各LeafCopyコード語及び各No
deCopyコード語は明らかに、それが表す記号ストリング
を指定するための２つの情報要素：ノードまたは葉と弧
の変位（パトリシア（PATRICIA））の木の弧は２つ以上
の記号を表す可能性があるため、変位が必要とされる）
を含んでいる。探索部のスパン内に２回以上現れるスト
リングは、単一ノードの弧として現れ、従って、それら
はそれらのコード化において冗長性のないNodeCopyとし
て圧縮されることを理解すべきである。

さらに詳述すると、NodeCopyが要求される場合、その
識別接頭部には〔０・・・最大ノード番号〕の範囲内に
おける次の自由ノードを示すノード番号が続くが、この
場合、最大ノード番号は圧縮システムの初期設定以後に
用いられた最大のノード番号である。従って、弧の変位
は入力弧に関する記号数に基づいてコード化される。よ
くあることだが、入力弧に対し単一の記号しかなけれ
ば、その変位は長さのフィールドを抑制することによっ
て推論的にコード化することができる。しかし、入力弧
が複数の記号を表す場合、整合が生じた弧に沿った位置
を示す値を記録するため、ノード番号に長さのフィール
ドが付加される。普通、記録される値は、ちょうど新し
いノードに生じる整合については０、その親ノードから
下方へ記号１つ分変位したところで生じる整合について
は１、親ノードから下方へ記号２つ分変位したところで
生じる整合については２・・・になる。都合のよいこと
に、NodeCopyの弧変位をコード化するため疎コードが用
いられるので、このためこれらのコード語の長さフィー
ルドは通常わずか１または２ビットで構成される。

一方、LeafCopyが要求される場合には、その識別接頭
部の後に、整合が終了した（リテラルを意味するゼロの
弧変位によって）親ノードから葉の弧を下降した距離を
指定するため、〈1,1,11〉の単項コード化長さフィール
ド（こうした単項数列は、4094の記号の長さまでの延長
さをコード化することができる）が続く。非ゼロの弧変
位値（すなわち、リテラルを意味しない値）を有するLe
afCopyに関する長さフィールドの後に、整合する記号ス
トリングの先行記号に関する探索窓での記号位置が、で
きれば上述の数列〈10−x,2,14−ｘ〉のような別の適合
する単項数列を漸次段階的に組み込むことによってコー
ド化される。

都合のよいことには、リテラルはその導入ビットシー
ケンスすなわち“フラグ”として０の弧変位を有するLe
afCopyを用いることによって、一義的に識別される。そ
れらの導入フラグのビットには、〈0,1,5〉のコードの
ようなさらにもう１つの＜開始、ステップ、停止＞の単
項数列を用いて、リテラルの長さがコード化されている
長さのフィールドが後続する。コード化規則は、最大許
容可能長未満のリテラルの直後に別のリテラルが続くの
を禁じており、従ってこうしたリテラルの直後にコード
化されるLeafCopyの弧変位に関する単項コードは１つだ
けシフトダウンされ、１の弧変位が従って０としてコー
ド化され、２の変位が１としてコード化され・・・とい
った形をとるようにすることができる。

NodeCopyに対するノード番号は、最低使用頻度（LR
U）選択アルゴリズムに従って取り扱い、より使用頻度
の高いノードを識別するのに必要なビット数を減らすコ
ード化を用いるのが望ましい場合であっても、値〔０・
・・最大ノード番号〕に関する疎コード化を用いてコー
ド化される。明らかなことだが、こうしたノードの取り
扱い及びコード化案は、設計者の裁量によって実施する
ことができる。

前に指摘したように、データを復元するためこの具体
例の場合の伸長器は、ソースデータの対応する部分の圧
縮／伸長時に、圧縮器の探索木の探索経路と同一の探索
経路を含む探索木を再構築し保全しなければならない。
ただし圧縮器とは異なり、伸長器に加えられるコード語
は各コピーの長さを判定し、即座に木に加えられるべき
新しいノードの親の位置をつきとめることができるよう
にする。従って、最長の適合が２つ以上の記号にまたが
ると、あるコピーが必ず選択されるように制限されてい
る場合、コード化方法が記号ストリングを木に挿入する
のにハッシュテーブルは必要とされない。コード化方法
に関するこの制限により、伸長器は、それが解読した特
定のNodeCopyコード語またはLeafCopyコード語によって
示されるノードまたは弧から各新しい葉をたらすことに
よって、木を再構築することができる。さらに解読され
るのがリテラルの場合には、伸長器はリテラル記号に関
する永久深さ、すなわちレベル１のノードから葉をたら
すことができる（想起されるように、永久深さ１のノー
ドは都合のよいことに各ソース記号毎に与えられてい
る）。

E.代表的な機能的流れ図 前述の説明を補足するため、代表的な機能的流れ図の
説明を以下に行う。これらの図は単純化されており、い
くつかの具体例に特定されるものであるが、それらは本
発明をその様々な形態で実施することに関心のある人に
対して、一般的な枠組みを提供する。可逆の、すなわ
ち、損失のない圧縮システムの場合、伸長器は必然的に
圧縮器を補足することになり、従って、圧縮器の機能的
性能特性は、伸長器の性能要件をかなり決定する。上述
の圧縮器には、再発生する記号ストリングの前に発生し
た位置を明らかにするため、探索窓内の全ての記号に対
する直接アドレス指定を可能にするものもあるし、一方
では、探索窓内におけるいくつかの記号（すなわち、先
行するコード語を開始する記号、又はリテラルとして前
に放出された記号）に対して、ポインタのアレイを利用
してあるいは木構造のコード化によって、間接アドレス
指定を行うことにより、前に発生したこうした位置を明
らかにするものもある。ソースデータの圧縮及び伸長に
関する木構造のコード化及び解読は、探索窓の内容に対
する直接又は間接アドレス指定よりも少し複雑であり、
従って、木構造のコード化及び解読は、下記流れ図に特
徴が示されている。

1. 整合記号ストリングの位置決定及び拡張 第12図を参照すると、ストリーム圧縮器の全てが、そ
れらの探索木73（第３図）を保全し、再発生する記号ス
トリングの以前の発生を識別するために、ほぼ同じプロ
セスを利用している。想起されるように、ファイル圧縮
器は、ソース記号をそれらに“押し付けられる”のでは
なく、ファイルからソース記号を“引き出す”が、さも
なければ、それらは記号ストリングをそれらの探索木に
挿入し、それらのストリーム圧縮器の片一方とほぼ同じ
やり方で、それら探索木を保全する。本発明の“ストリ
ーム”の実現は、標準的な“ストリーム"I/Oインターフ
ェイス仕様を満たすように設計されているので、データ
暗号化及び解読ルーチン、及びデータ通信プロトコルの
ような他のストリーム手順によって簡単に層化すること
ができる。

このため、参考までに組み込まれている付録Ｅは、前
述のI/O仕様（本発明の範囲外である）に則してストリ
ームの圧縮及び伸長機能を付与するのに必要な手順を示
している。オペレーティングシステムによって、圧縮ソ
フトウェアのパッケージがロードされると、それらは、
圧縮方法登録簿（不図示）によってそれ自体を登録し、
その方法によって与えられる手順にクライアント（すな
わち、圧縮システムのサービスを必要とする送信データ
端末装置及び受信データ端末装置）がアクセス可能にな
る。圧縮を実施するため、クライアントはまず、“Crea
teEncodingStream"手順によって、圧縮器が必要とする
データ構造を初期設定するが、コード化ストリーム生成
に対するアーギュメントは、ソースデータを表すコード
語が送られる出力ストリーム手順である。その後、クラ
イアントは、“CSUnsafePutBlock"手順を用いて、圧縮
のための文字ブロックを提示したり、あるいは“CSPutC
har"手順を用いて、単一の文字を提示する。一連のソー
ス記号を圧縮する途中で、圧縮器がその出力バッファに
コード語を累積するが、それは、その内部データ構造で
表された別の記号を有しており、該データ構造に対する
コード語はまだ生成されていない。従って、いつでもク
ライアントがまだコード語で表されていない全ての記号
のコード化を強要し、これらのコード語の全てが出力ス
トリームに送られるように強要することを望む場合、そ
れは“CSFlush"手順を呼び出す。CSUnsafePutBlock,CSP
utChar及びCSFlushは、任意の順序で繰返し呼び出すこ
とができる。最後に、クライアントが圧縮器の使用を終
えて、最後のCSFlushを出すと、“CSClose"手順を呼び
出すことによって、圧縮器が用いていた記憶領域を解放
することができる。

同様に、伸長器は、そのためのアーギュメントがコー
ド語を入手すべき入力ストリームである“CreateDecodi
ngStream"手順を有している。それは、また非圧縮すな
わち解読ソース記号のブロックを得るために呼び出すこ
とができる“ESUnsafeGetBlock"手順と、単一の非圧縮
ソース記号を得るため呼び出すことができる“ESGetCha
r"手順を有している。更に、伸長器はそれが用いた記憶
領域を解放する“ESClose"手順を有している。

このストリーム圧縮システムが、ファイルを圧縮する
ために用いられる場合、CSFlushはファイルの終了時に
１度だけ用いられる。CSFlushは通常、以下に述べるよ
うに、PadCopyコード語又はPadLiteralコード語のいず
れかを生成する。これらのコード語はストリーム圧縮器
とファイル圧縮器の間における主たる相違点である。こ
れらのコード語には、極めて低い確率が割当てられるた
めストリーム圧縮器によって用いられるコード化は相当
するファイル圧縮器によって用いられるものとほぼ同一
であり、得られる圧縮器もほぼ同一である。明らかなこ
とだが、ストリーム圧縮器の主たる利点は、前述のよう
に、ファイル圧縮に加えて他の用途にも利用できるとい
うことにある。

ここで、第12図に図示されている、圧縮器のCSUnsafe
PutBlock手順を参照すると、探索木は当初、永久深さ１
のノード、空の窓及び空の入力文字バッファから構成さ
れており、現在の整合の深さは０である。圧縮のためCS
UnsafePutBlock又はCSPutCharによって文字が提供され
るに従って木は成長し、その３つの資源の１つがつきる
まで窓が満たされる。これらの資源は、サイズパラメー
タmaxCopyDisp（木における葉すなわち窓の位置の
数）、maxNodes（木内で許容される最大ノード数）、及
び、oBufSize（入力文字バッファの最大サイズ）によっ
て規定される。maxNodesとoBufSizeの値は、普通、ノー
ドと文字バッファのどちらを使い果たす前に大部分のソ
ースデータがmaxCopyDispの葉を使い果たすように選択
される。その場合、圧縮器は各コピーコード語又はリテ
ラル文字に関し、１つの葉は自由になり、１つの葉は割
当てられるという“定常状態”の動作条件に結局たどり
つくとになる。テキスト及び他の何らかの種類のデータ
に関し、大きいソースデータで得られる圧縮度は、maxC
opyDispが増大するにつれて増すことになる。付録Ｅに
おける具体例は、maxCopyDisp＝16,384の位置の窓サイ
ズを用いているが、この実施は約1000〜63000の間のmax
CopyDispの値について十分機能を果たせるということが
分かる。

圧縮器の初期設定時及びCSFlushの後、最長の整合の
深さは０である。しかしCSUnsafePutBlock又はCSPutCha
rの実施後、最長の整合の深さは常に１以上である。101
におけるように、圧縮のため次の文字が送られると、圧
縮器はまず、この文字を含めるため、現在の最長の整合
を拡張しようとし、拡張された記号のストリングは、10
2,103,104,111,113,110及び112に示すように木に挿入さ
れる。拡張記号ストリングの挿入時にたどる探索径路
は、木における現在の整合位置によって決まる。すなわ
ち、（１）現在の整合が葉の弧上にあれば、拡張ストリ
ングの探索径路は102,111,113及び112として規定され、
（２）現在の整合がちょうどノード位置であれば、探索
径路は102,103,110及び112として決定され、あるいは
（３）現在の整合が木の内部弧上にあれば探索径路は10
2,103,104及び112として識別される。

104のような探索木の内部弧上で、または111のような
木の葉の弧上でそれ以上整合の拡張ができなくなると、
ノードが自由リストから取り出されて、105のような整
合の終了したポイントで木に分割される。次に106にお
けるように、新しい葉がこの新しいノードからたらされ
る。或いは、整合が110のような既存のノードを越えて
拡張できない場合には、新しい葉は106のような既存の
ノードからたらされる。整合は113のような葉の弧にお
ける最大許容可能コピー長、すなわち深さに達するとや
はり必ず終了する。ただしこうした状況下では、新しい
ストリングと、整合することになった以前に生じたスト
リングとの間には、時間的な差異と、結果的に生じる探
索窓に対するそれらの位置の違いを除くと、実質的な相
違はない。従って114におけるように、ストリングに関
する切取られた葉は除去され、106におけるように新し
い葉がその位置につく。ノードが自由リストから取出さ
れる場合、自由リストが全てのノードが使用されている
ことを表す、空ではないか確かめる。これが生じると、
“maxNodes"パラメータによって決まる最大ノード割当
てに達していなければ、新しいノードが生成されて自由
リストに加えられる。

最後に、107におけるように、木位置が更新されて新
しい葉に対する親ノードから始まり、永久深さ１のノー
ドに達するまで、木を登っていく。この具体例の場合、
全てのノードが根まで更新されるが、記述のようなパー
コレーティング更新の利用が可能であることは理解でき
よう。また具体例には、木の降下時に、ノード位置を更
新できるものもある。

この時点で木の更新が済み、新しい記号ストリングを
正確に表すことになる。次のステップは木で表されたば
かりのストリングをコード化し、次の整合を求める準備
を行うことに関するものである。窓が満杯の場合には、
108におけるように、木から最古の葉が除去され、その
記憶域は次に生成されることになる葉のために再利用可
能になる（圧縮器がその窓をまだ満たしていなければ、
あるいは114のように切り取り深さに達したために、そ
の葉がすでに除去されている場合には、あるいは117に
おけるように、それがすでに除去されてバッファ内にス
ペースができている場合には、あるいは121におけるよ
うに、木に割当てられた数のノードを使い果たしたため
に、それがすでに除去されている場合には、このステッ
プは不要である）。次に、115におけるように、コード
化が実施されるが、これについては以下で第13図におい
て更に詳しく説明される。

コード化の後、圧縮器は、116におけるように出力バ
ッファをチェックし、バッファが最大許容可能コピー長
のコピー（次のコード語にとって最悪の場合）を記憶す
るのに十分な自由スペースを備えているか確かめる。も
しなければ、117におけるように、木から最古の葉が除
去され、コピーに加えて追加記憶量にとって十分な記憶
スペース“oBufReserve"（付録Ｅ参照のこと）がバッフ
ァ内で自由になる。各葉は、バッファ内の１つ以上の記
号を表しているので、葉を自由にするとバッファスペー
スも自由になる。出力バッファをチェックした後、圧縮
器は122におけるように、ノード自由リストが空（maxNo
desノードが、現在木内で使用中であることを意味して
いる）か否かを確かめる。そうであれば、それはバッチ
除去処理“ToFreeleaves"（パラメータ値100を有する）
によって、木から最古の葉を除去する。葉を頻繁に削除
すると、残された息子が１人しかない親ノードを生じる
ことになり、従って、次に上述のノード削除処理すなわ
ち、再生処理が用いられると該親ノードを再生し、自由
リストにそれを加えることが可能になるが、このステッ
プは、ノード自由リストが１つ以上の自由ノードを含む
ようになるまで反復されることに注意すべきである。明
らかなことだが、maxCopyDispの葉にとって最悪の場合
の要件以上の数のノードを割当てることによって、少し
シンプルになるように圧縮器に変更を加えることで、第
12図のステップ121及び122をなくすことができる。実際
のところ、この代替案は、付録Ｅにおけるコメントとし
て記述され、付録Ｃ及びＤの具体例で用いられている。
しかし、この代替案のアプローチの欠点は、圧縮器の記
憶要件におけるものである。

最後に最長の整合を拡張しなかった圧縮器に対し提出
されたばかりの文字が、123におけるように新しい整合
の最初の文字になる。この文字に関して木位置は永久深
さ１のノードになるようにセットされ、圧縮器は更に、
もう１つの文字を受け入れるループを実施する。

明らかに、第12図は付録Ｅの圧縮器と付録Ｄの圧縮器
のいずれかを表しているが、これらの２つの圧縮器は、
後述するコード化機能115に隠されたコード化の細部に
おいて異なっている。更に、付録Ｄの圧縮器は“maxCop
yDisp"の葉の最悪の場合の要件にとって十分な数のノー
ドを設けることによって、ノード取扱いステップ121及
び122が排除される、上述のよりシンプルな変更を利用
している。

2. 木構造エンコーダ 第12図におけるステップ105は、圧縮器のコード化セ
クションを表しており、第13図には、付録Ｅの木構造に
よるエンコーダがより詳しく図示されている。コード化
セクションのジョブは、NodeCopy,LeafCopy,Literal,Pa
dLiteral及びPadCopyコード語によって、ソースデータ
をコンパクトに表すことである。用いられる種類のコー
ドは、都合のよいことに、接頭部コードであり、これは
どのコード語も他のコードの接頭部にならないことを意
味し、従って、伸長器はコード語のストリームを明確に
解読することができる。

付録Ｃの具体例の場合、文字がすでにコピーコード語
によって表されているか否かに関係なく、各文字毎にコ
ード化セクションが入力され、従って、第３図のステッ
プ78のように、文字スキップカウントが用いられる。こ
れは、別のコード語を生成する時間になるまで、コピー
コード語ですでに表されている文字をカウントダウンす
るのに用いられる。しかし、付録Ｄ及びＥにおける具体
例に関するエンコーダは、すでにコード化された文字に
ついては２度と入力されないので、それらはこのスキッ
プカウントを必要としない。

エンコーダは、まず次の文字がリテラルで表されるよ
うになる時、及びそれがコピーで表されるようになる時
を決める。最長の整合が、長さ１である場合、その文字
はリテラルで表さねばならないが、最長の整合が長さ２
以上であれば、この方法は、リテラルとコピーのいずれ
でそれを表すか選択することができる。付録Ｃ及びＤの
具体例はこの方法の決定を純粋に最長の整合の長さに基
づいても行うものではないが、この理由は、長さ１のリ
テラルのコード化が４ビット（及び文字）を必要とし、
一方長さ２又３のリテラルが６ビット（及び文字）を必
要とすることにある。すなわち、リテラルを開始する
“コスト”は４ビットであるが、長さ１から長さ２への
拡張はコストが２ビットしかかからず、長さ２から長さ
３への拡張はコストが０ビットである。これらのコスト
が異なるため、都合のよいことに、エンコーダはなかな
かリテラルを開始しようしないが、一旦それを始める
と、コピーのためになかなかそれを終了しようとしな
い。すなわち、好都合なことには、方法の決定には“ヒ
ステリシス”が存在する。これらを考慮すると、長さ２
のコピーがリテラルにとって望ましいが、一旦リテラル
が開始されると長さ３の（すなわち、最大リテラル長に
達する）コピーしかそれを停止することができないとい
う上述のシンプルな方法になる。わずかに複雑さが増す
という犠牲を払って、少し高めの圧縮度が得られる他の
方法を考えることも可能である。

ただし、付録Ｅの木構造のエンコーダの場合別の考慮
が働くことになる。すなわち、伸長器は圧縮器のものと
同様のハッシュテーブルまたは他のデータ構造に頼らず
に、解読するコード語から木を再生成できるのが望まし
い。このため最長の整合が長さ２以上の場合には、必ず
コピーを選択し、最長の整合が長さ２未満の場合に限っ
てリテラルを開始または拡張するように、その方法に制
限を加えることが望ましい。この制限の結果、伸長器は
必ずリテラル文字に関する葉をそのリテラル文字に対応
する永久深さ１のノードからたらすことができるように
なる。この方法の制限の結果、伸長器はより複雑な方法
に従った場合に比べて圧縮度が少し低くなるのが普通で
あるが、よりシンプルで、より速く動作し、より少ない
記憶域ですむことになる。

第13図を参照すると明らかだが、コード化は用いられ
る圧縮アルゴリズムによって決まる。しかし、望ましい
圧縮アルゴリズムの全てに共通した特性に従い、127に
おけるように、まずリテラルがコード化中か否かを判定
する。リテラルがコード化中の場合、128におけるよう
に、上述の挿入処理における各反復の間、コード化され
るコピーが出てくるまで、または129におけるように最
大許容可能長のリテラルがアセンブルされるまで、リテ
ラルの長さが拡張される。リテラルがその最大許容可能
長に達すると、131におけるように、リテラルコード語
は累積されたリテラル記号の直前にある出力バッファに
ロードされる。同様にコード化すべきコピーがあると、
134におけるように、累積したリテラル長カウントをチ
ェックしてリテラルが累算中かどうか確かめる。そうで
あれば、135におけるように、リテラルコード語と累算
したリテラル記号がコピーコード語の前の出力バッファ
にロードされる（想起されるように、リテラルコード語
とそれに付属のリテラルソース記号は、コピーの存在が
確認された後及びコピーに関するコード語がロードされ
る前には、いつでも圧縮器の出力バッファにロードする
ことができる）。リテラルが出力されると、必ず134に
おける累算されたリテラル記号のカウントが０にリセッ
トされるため、別のリテラルの累算が可能になる。

この場合、138において判定されるように、コピーが
葉の弧上で終了するか否かに従って、LeafCopy136また
はNodeCopy137を用いてコピーがコード化される。139に
おけるように、各リテラルの後出力バッファがチェック
されコピーがそれにロードされるが、140におけるよう
に、それが略満杯の場合にはダンプされる。木構造のコ
ード化のさまざまな細部については、付録Ｅのコメント
に記述されている。コード化に関する追加説明について
は、以下の伸長器の説明において行うものとする。

3.エンコーダのバイトアライメント 第14図を参照すると、フラッシュ指令が出される時、
任意の部分リテラルと圧縮器内に残っているコピーの両
方または一方に関するコード語を出力するため、フラッ
シュ処理が用いられる。ファイル圧縮器の場合、こうし
た指令はファイルの終了時に限って出されるが、その時
点においては圧縮器が通常のコピーコード語またはリテ
ラルコード語を出力する用意が整っていなくても、ビッ
トの進行ストリングを終了し、それらが間違ってコード
語と解釈されないようにする必要のある場合には、通常
圧縮器からファイルの最後のわずかな記号もいっきょに
送り出す必要がある。ストリーム圧縮器の場合、フラッ
シュ処理は圧縮器に関するソースデータが一時的に使い
果たされている間に、受信器に対し追加圧縮データをい
くつか提供するのに用いることもできる。どちらかのタ
イプの圧縮器においても、フラッシュは圧縮データはバ
イトまたは語アライメントを復元する（付録Ｅの具体例
は、16ビットの境界に対するアライメントを復元す
る）。

フラッシュが開始すると圧縮器の通常の動作は一時的
に中断され、その探索木73（第３図）が次の記号または
文字を挿入する準備の整えられる深さが141におけるよ
うにチェックされる。木がすでに根までセットされてい
る場合、フラッシュは142において打ち切られ、圧縮器
はすぐに通常の動作に復元される。さもなければ、143
におけるように累算されたリテラルカウントがチェック
され、144におけるようにフラッシュによって中断され
たリテラルの累算記号を伴ってリテラルコード語が出力
される。累算されたリテラルの出力後最古の葉がまだ削
除されていなければ、144におけるように、それが木か
ら除去される。しかし、パッドコード語によってコード
化される記号は明確な探索経路を規定していないので、
木はそれらに対し更新されない。次に145におけるよう
に、フラッシュが開始する時木が深さ１のノードにある
場合には、まだ圧縮器の探索木内にある１つのソース記
号を伴うパッドリテラルコード語を用いて、あるいは木
内にまだ２つ以上のソース記号がある場合には、中断さ
れたコピーの探索窓での記号位置及び長さを識別するパ
ッドコピーコード語を用いてフラッシュがコード化され
る。圧縮器の出力バッファにパッドリテラルコード語ま
たはパッドコピーコード語がロードされ、それに追加ビ
ットを加えて、この特定の例におけるように次の16ビッ
トの境界のような都合のよい境界で、バッファの出力の
アライメントがとられる。最後に、146におけるように
バッファがダンプされ、さらに147におけるように、探
索木73（第３図）はその根にリセットされて圧縮器がそ
れ以上の文字を受信するのに備える。

4.木構造の伸長器 本発明の付録Ｅの具体例によれば、クライアントはコ
ード語を取り出すことになる入力ストリーム（あるいは
データ源）をアーギュメントとして備える“CreateDeco
dingstream"手順を呼び出すことによって、伸長器の初
期設定を行う。初期設定後、クライアントは文字ブロッ
クを読み取る“ESUnsafeGetBlock"と、単一の文字を読
み取る“ESGetChar"に対し、繰り返し手順呼出しを行
い、クライアントの指示に従って入力ストリームからコ
ード語を順次解読することにより、非圧縮または伸長記
号が抽出されるようにする。“ESEndOf"は、伸長ストリ
ームがそれ以上記号を送り出すことができないかチェッ
クするのに用いることができる。“ESGetChar"の実施
は、単に記号カウント１を備える“ESUnsafeGetBlock"
を呼び出すだけであるため、ここでの説明は“ESUnsafe
GetBlock"に制限するが、“ESGetChar"手順に対しても
同様の説明があてはまることは理解できよう。

第15A図及び第15B図を参照すると、伸長器は圧縮器を
補足して忠実にもとのソースデータを回復することが分
かる。そのため上に指摘したように、伸長器のデータ構
造は圧縮器のデータ構造とちょうど同じように初期設定
される。さらにコード語が解読される時には、必ず伸長
器の木と探索窓は圧縮処理の対応するステップにおける
圧縮器の木と同一になる。明らかに、コード語を解読す
るために伸長器がとるステップはコード化によって完全
に書き取られる。

付録Ｅの伸長器は、その入力ストリームからビットを
得るための入力サブルーチンを備えている。156、159及
び160におけるように、別のコード語またはリテラル文
字のためにさらにビットが必要とされる場合には、ビッ
トを得るためにこのサブルーチンが必ず呼び出される。
入力ストリームが完全に使い果たされると、“EndOfStr
eam"エラーフラグが掲げられ、その結果“ESUnsafGetBl
ock"手順がそのクライアントに戻されて、文字カウント
は要求されるカウント未満になる。その結果、クライア
ントは伸長を終了する。

伸長器は、もしあれば伸長されている現在のコピーの
バッファ位置と残りの長さ、あるいは、もしあれば伸長
されている現在のリテラルの残りの長さである状態変数
を有している。151におけるように、別の文字が要求さ
れると、“ESUnsafeGetBlock"はまずこれらの変数をチ
ェックし、他のコードを解読しなくても次の記号を送り
出すことができるか確かめる。NodeCopy、非ゼロの弧変
位を有するLeafCopy、またはPadCopyコード語が伸長さ
れる処理中であれば、伸長器は152、153及び154で示す
ステップを利用して、次の文字を別の場所から文字バッ
ファへ複写することによりそれを送り出す。一方、リテ
ラルコード語（すなわち、ゼロ弧変位を有するLeafCop
y）が伸長される処理中であれば、伸長器は152、155、1
56、157及び158で示すステップを利用して次のリテラル
文字を伸長する。

明らかに、木は全てのリテラル文字毎に、及び全ての
コピーコード語毎に更新される。ステップ108′、11
6′、117′、122′及び121′は、圧縮器に関連して前に
述べたのと全く同様に、葉、ノード、及びバッファを規
定することに関連したものである。同様に、ステップ10
8′、116′、117′、122′及び121′は、157におけるよ
うに圧縮器によって行われたのと全く同様に、葉が伸長
器の木の永久深さ１のノードに取りつけられるようにす
る。従って圧縮器を説明するのに用いられたものに対応
する準備基準数値が、伸長処理の同様のステップの識別
に用いられている。

現在のコピーまたはリテラルが使い果たされると、15
9におけるように次のコード語を解読するのが適性であ
る。コード語がNodeCopyまたはLeafCopyであれば、これ
は木に新しい葉を加えることになる。更に、葉は伸長器
の木に対し各リテラルの最初の文字毎に加えられること
になる。こうした可能性のあるコード語にそなえるた
め、再びステップ108′、116′、117′、122′及び12
1′が用いられて、葉に必要な資源が得られるか確認が
され、またコード化時に圧縮器が有していたのと同じ構
成を伸長器が解読時に備えるか確認がされる。

コード化は“接頭部コード”として知られる１群のコ
ードを用いるが、これはどのコード語も他のコード語の
接頭部にならないということを意味するため、159にお
けるように、デコーダはあるコード語と別のコード語を
簡単に区別することができる。従って、任意のビットシ
ーケンスの可能性のある解釈は１つだけしかないことに
なる。詳述すると、付録Ｅによって用いられるコード化
において、コード語の最初のビットがLeafCopy、Litera
l、PadCopy及びPadLiteralコード語からNodeCopyコード
語を区別する。このビット信号がNodeCopyを知らせる
と、使用中の最大ノード数が記述の“疎コード化”技術
を用いてノード番号として読み取られ、解読されること
になるビット数を求める。次に、このノード数は木に参
照符をつけ、その特定のノードに対する入力弧の長さを
求めるために利用される。さらに、特定のノードに対す
る入力弧が記号１つの長さを越えると、その記号長はや
はり弧長の“疎コード”表現に基づいて、弧変位として
解読されるビット数を決める。ノード番号の解読は、伸
長器が最大ノード数について圧縮器と同じ値を用いるこ
とと、圧縮器とちょうど同じようにノードに番号をつけ
て用いられる木を有する必要のあることに注意すべきで
ある。

159におけるように、デコーダによって処理される最
初のビットが解読中のコード語がNodeCopyでないことを
示す場合には、必ずそのコードの最大、すなわち停止サ
イズのフィールド（すなわち11個の２進数１の“インジ
ケータ”（すなわち1111111111）から成る単項コード
語）が単項コードから“エスケープ”して、パッドコピ
ーコード語またはパッドリテラルコード語を出力するよ
う予約されるということを除き、〈1,1,12〉の単項コー
ドが解読される。〈1,1,12〉の単項コードの解読値がリ
テラルを表す０の場合、デコーダは次にリテラル長とし
て〈0,1,5〉の単項コードを解読し、リテラルに付加さ
れるリテラルソース記号の数を求める。

〈1,1,12〉の単項コードの解読値が〔１・・・4094〕
の範囲内であれば、それは葉の弧の親ノードから葉の弧
を下降する弧変位として解釈される。従って、圧縮器変
位は、エンコーダに関して上に述べたように、この場合
〈10−x,2,14−ｘ〉の単項コードと、その最大すなわち
“停止”フィールドの“疎コード化”に基づいて解読さ
れる。

弧変位がPadCopyまたはPadLiteralを意味する場合、P
adCopy長フィールドは〈1,1,12〉の単項コードを用いて
解読される。このフィールドの解読値が０の場合、それ
はコード語が単一のリテラル文字の後続するパッドリテ
ラルであることを意味している。でなければ、PadCopy
長が解読された後、最長の整合の最初の、すなわち先行
する記号の探索窓での位置に対する相対変位が〈10−x,
2,14−ｘ〉の単項コードを用いて解読され、最大すなわ
ち“停止”フィールドに関する疎フィールドが改善され
る。これらの細部の全てが、前述の圧縮器によって実行
されるコード化動作に一致する。

159におけるように、デコーダがLeafCopyまたはパッ
ドコピーを解読すると、それは現在の窓位置と、最長の
整合が見つけられた窓位置の間における圧縮位置の数
（すなわち、コピーコード語またはリテラル文字の数）
である圧縮変位を送り出す。圧縮変位は、窓サイズを法
とした現在の窓位置から圧縮変位を引くことによって、
圧縮窓位置、すなわち相当する葉の数に翻訳される。デ
コーダがNodeCopyを解読すると、指定ノードに関する圧
縮窓位置は木内のノードから得られる。これらの場合の
全てにおいて、圧縮窓位置は、圧縮窓位置に関する“cW
indow"アレイ項目を読み取ることによって文字バッファ
位置に翻訳される（付録Ｅ参照のこと）。これらの翻訳
は、第15B図に162及び170で概略が示されている。

PadLiteralまたはPadCopyコード語の解読に応答し
て、伸長器の木に葉が加えられることはない。木に葉が
加えられない理由は、圧縮器システムのこの特定の具体
例に特有のものであり、付録Ｅの“CSFlush手順”に先
行する長いコメントに説明されている。しかしながら、
それらはこれ以上の解説を正当化するほど十分に本発明
の趣旨に関連したものではない。実際のところ、プログ
ラミング技術における熟練者には、パッド機能を実施す
るのにさまざまな方法があることが分かるであろう。そ
れにもかかわらず、この機能は重要であり、従って伸長
器はボックス160におけるように、PadLiteralコード語
から文字バッファへ単一の記号を移し、次に入力ストリ
ームからアライメントのとれる次の16ビット位置までビ
ットをスキップすることによって、161におけるよう
に、16ビット語の境界において入力ストリームのアライ
メントをとるということに留意すること。同様にPadCop
yに応答して、伸長器は、162におけるようにPadCopy圧
縮変位を文字バッファ位置に翻訳し（上述のように）、
PadCopy長を保管する。それは次に、153及び154におけ
るように、PadCopyによって表される記号をバッファに
複写することによって、このプロセスを完了する前に、
ちょうどPadLiteralの場合のように16ビットの境界にお
いてアライメントをとる。

デコーダが、159におけるようにLeafCopyを解読する
と、それは次に、上述のように圧縮変位を葉の数すなわ
ち窓位置に翻訳する。次に、それは親ポインタに従っ
て、木内の指示された葉からその葉の親ノードに進む
（明らかなことだが、このノードの深さプラス弧変位
は、複写されることになる文字数である）。113におけ
るように、計算されたコピー長が最大許容可能コピー長
に等しいと判定されると、再発生記号ストリングに関す
る切り取られた葉が、114′におけるように木から除去
されて、106′におけるように新しい葉に置き換えられ
る。やはり、これらの働きは、圧縮器内における相当す
る働きにちょうど対応している。通常はそうであるよう
に、最大許容可能コピー長に達しなかった場合には、16
4におけるように、葉及びノードが木に加えられる。ス
テップ165、166、及び167は、最大許容可能数のノード
“maxNodes"が使用されるまで、使用されるノード数を
漸増させることに関連している（それらは、圧縮器にお
けるステップ105の機能に関して少し詳しい説明を提供
する）。maxNodesノードが用いられていない限り、ノー
ド自由リストが空でないことを確認するこれらノード自
由リストのチェック後、ちょうど107における圧縮器の
場合のように、木の位置は107′におけるように更新さ
れ、窓位置は、上述のように“cWindow"アレイを読み取
ることによって、170におけるように文字バッファ位置
に翻訳される。最後に、LeafCopyの最初の文字が153及
び154におけるように複写される。

デコーダがNodeCopyを解読すると、指示されたノード
の深さ及び窓位置が、169におけるように木から得られ
る。168においてテストされたように弧変位がゼロであ
れば、最長の整合はちょうどノードで終了したことにな
る。この場合新しい葉は、106′におけるように指示さ
れたノードからたれ下がる。さもなければ、自由リスト
から新しいノードが取り出され、指示されたノードの親
から指示された弧変位をしたところで木に挿入されて、
164におけるように新しいノードから新しい葉がたれ
る。その他の働きは、165、166、167、107′、170、153
及び154に示したように葉のコピーの場合と同じであ
る。

文字が送り出された後、伸長器は循環してステップ15
1に戻り続行する。

〔結論〕

以上を考慮すると、本発明の＜開始、ステップ、停止
＞の単項コード化は、本書に開示のさまざまなテキスト
置換データ圧縮処理に関するコピー及びリテラルのよう
な、圧縮データをコード化するための一群の可変長コー
ド語を提供するということが理解できる。ただし、テキ
スト置換データ圧縮は、この＜開始、ステップ、停止＞
の単項コード化を有効に利用できる、あるタイプのデー
タ圧縮のほんの一例にしかすぎない。

【図面の簡単な説明】

第１図はデータ圧縮システムの簡易ブロック図、第２図
は本発明の基本的具体例に従ったサンプルテキストのス
トリングに関するコード化を示す図、第３図は第２図に
示すコード化を実施するように構成されたデータ圧縮器
のさらに詳細なブロック図、第４図は第３図に示す圧縮
器によって圧縮されたデータを復元する伸長器のブロッ
ク図である。第５図はサンプル記号のストリングに関す
る記号毎のパーシングを示し、第6A図〜第6E図はトリー
（Trie）の探索木編成が施されたデータ構造の構成を図
表で示し、第7A図〜第7E図はパトリシア（PATRICIA）の
木編成が施されたデータ構造の構成を図表で示し、第８
図は第7E図に示すデータ構造の接尾木編成を図表で示し
ている。第９図は接尾木の一般化表現、第10図は単項符
号器を備える圧縮器の略ブロック図、第11図は第10図に
示す単項符号器の動作を示す有限状態図、第12図は圧縮
変位を利用する、すなわち、木構造エンコーダを備えた
テキスト置換圧縮器に関する簡易フロー図、第13図は第
12図に示す圧縮器の木構造エンコーダに関する簡易フロ
ー図、第14図は第12図に示す圧縮器の圧縮出力のアライ
メントをとる語に関するフラッシュ及びパッドサブルー
チンの簡易フロー図である。第15A図〜第15B図は組み合
わせると第12図〜第14図に示す圧縮器に対する伸長器の
簡易フロー図を形成する。 61:データ圧縮システム 62:圧縮器、63:伸長器

フロントページの続き (56)参考文献 特開 昭54−54506（ＪＰ，Ａ) 特開 昭56−102162（ＪＰ，Ａ) 特開 昭60−116228（ＪＰ，Ａ) Ｔｈｅ Ａｕｓｔｒａｌｉａｎ Ｃｏ ｍｐｕｔｅｒ Ｊｏｕｎａｌ，Ｖｏｌ. 19，Ｎｏ．２，Ｍａｙ 1987，Ｒ．Ｐ. Ｂｒｅｎｔ，”Ａ Ｌｉｎｅａｒ Ａｌ ｇｏｒｉｔｈｍ ｆｏｒ Ｄａｔａ Ｃ ｏｍｐｒｅｓｓｉｏｎ”，ｐ．64−68 (58)調査した分野(Int.Cl.⁷，ＤＢ名) H03M 7/40

Claims (1)

(57)【特許請求の範囲】
1. 【請求項１】既知の最小ビット長、既知の最大ビット
   長、および複数のコード語間におけるビット長における
   既知のインクリメンタルな差を有する可変ビット長コー
   ド語のビット長通信方法であって、 カウント数として記録されるそれぞれのコード語のデー
   タフィールドのビット長を記述する単項コードを、 前記複数のコード語のそれぞれのデータフィールドに予
   め記録し、 前記コード語の既知の最小ビット長を表す“0"で開始
   し、 ビット長における前記既知のインクリメンタルな差の倍
   数ずつ増大させるステップを含み、 これによって、 前記コード語のデータフィールド長が前記既知の最小の
   ビット長から前記既知の最大ビット長によって決定され
   る制限値までオフセットされることを特徴とする可変ビ
   ット長コード語のビット長通信方法。