JP2014093612A - 符号化装置及びその制御方法 - Google Patents

Abstract

【課題】 固定サイズの辞書を用いながらも、より効率良く圧縮符号化することを可能にする。
【解決手段】 符号化対象文字列の先頭２文字から辞書１０１へのエントリアドレスを求める。そして、そのエントリアドレスで示される候補１、２、３に格納されたアドレスを参照し、符号済み領域１００内の該当する文字位置を求め、それぞれの中から符号化対象文字列と一致する最長一致数はいずれであるかを判定し、その最長一致数と、最長一致数となった文字列の先頭アドレスを符号化する。
【選択図】 図１

Description

本発明は、例えば文字コードや画像データなどのデータストリームを辞書を用いて圧縮符号化する辞書型符号化技術に関する。

従来から、符号化済みの過去の文字列を参照することにより、符号化対象文字列を符号化する技術として、ＬＺ７７圧縮法などが知られている。

ＬＺ７７圧縮法では、既に圧縮を終えた文字列をスライドバッファ内に保持しておき、これから圧縮を行う文字列と、スライドバッファ内のデータを比較する。その結果、スライドバッファ内で、最も一致長の長い文字列の位置を特定する。そして、特定された文字列の先頭までのオフセット値（特定された文字列の先頭が、圧縮対象文字列の先頭からいくつ遡った位置になるかを示す値）と、一致した文字列の長さの組合せを圧縮する。その後、圧縮を終えた文字列の長さ分、スライドバッファをスライドして、次の文字列を圧縮する。つまり、ＬＺ７７圧縮法は、常に最新の圧縮済みのデータを辞書として用いており、そのためスライド辞書法とも呼ばれている。

図１４に、ＬＺ７７圧縮法でデータが圧縮される様子を示す。図１４（ａ）において、スライドバッファ１４０１は２４文字分のバッファであり、図１４（ａ）では、文字Ａから文字Ｈまでが格納されている。圧縮対象となるのは、スライドバッファのすぐ後ろに続く、ＡＢＤ…から始まる文字列である。ＬＺ７７圧縮法では、スライドバッファ１４０１内で、圧縮対象文字列に一致する最長文字列を検索する。図示の場合、スライドバッファ１４０１内の符号１４０２が示す文字列「ＡＢＤＦ」が、圧縮対象文字列に一致する最長文字列として検索される。この文字列ＡＢＤＦの先頭文字の位置は、検索対象文字列より１２文字だけ遡った位置にあり、そこから４文字が一致しているので、距離「１２」と一致長「４」が圧縮されることとなる。

上記により、圧縮対象文字列の４文字「ＡＢＤＦ」が圧縮されたことになるので、スライドバッファ１４０１は圧縮された文字列の長さ分（ここでは、４文字）スライドし、図１４（ｂ）の状態となる。つまり、文字Ｋから文字Ｆまでがスライドバッファ内に入り、スライドバッファに続く、ＫＥＬ…から始まる文字列が次の圧縮対象となる。

上記の如く、スライドバッファ内の文字列から、圧縮対象となる文字列と同じ文字列を速やかに検索する必要がある。そのための技術として、スライドバッファ内の文字列の出現位置をルックアップテーブル（辞書）に登録することが知られている。すなわち、ルックアップテーブルに登録された情報を用いて、スライドバッファ内に存在する同じ文字列を検索する。

図１５では、スライドバッファ内のＡＢで始まる文字列の先頭位置（文字Ａの位置）のアドレスポインタが、辞書として機能するルックアップテーブル（以下、ＬＵＴという）１５０１内のＡＢのアドレスを保存する位置に書き込まれている様子を示している。これによれば、１回のルックアップテーブルの参照で、ＡＢから始まるスライドバッファ内の文字列の位置を知ることができる。

ここで、１文字が１バイトとすると、図示の場合にはＬＵＴ１５０１には２文字の組合わせが格納されるわけであるから、２文字の組合わせは［０ｘ００；０ｘ００］から「０ｘｆｆ；０ｘｆｆ」（０ｘは１６進数を示している）となるので、ＬＵＴ１５０１へのエントリアドレスは１６ビット必要となる。

ここで、検索対象文字列を２文字から３文字列に増やす場合を考える。この場合、上記の理由で、ＬＵＴへのエントリーアドレスは２４ビット必要とする。すなわち、たった１文字増えるだけで、ＬＵＴの要素数は実に２⁸（＝２５６）倍になってしまう。

これに対して、上記メモリサイズを縮退するために、例えば参照文字列のハッシュ値をルックアップテーブルの参照情報（アドレス）として利用する方法なども知られている（特許文献１）。

特開２０００−８２９６７号公報

上記特許文献１によれば、確かにルックアップテーブルの容量が大きくなることを、ある程度は抑制できるものの、「ハッシュ値の衝突」の問題は残る。

本発明は、上記問題に鑑みなされたものであり、固定サイズの辞書を用いながらも、より効率良く圧縮符号化することを可能にする技術を提供しようとするものである。

この課題を解決するため、例えば本発明の符号化装置は以下の構成を備える。すなわち、
文字列を符号化済みの文字列のアドレスを記憶する辞書を参照して符号化する符号化装置であって、
圧縮符号化するための文字列データを保持するバッファメモリと、
Ｍ個（Ｍは２以上）の文字の組み合わせ分のエントリアドレスに対応すると共に、各アドレス毎に、前記バッファメモリのアドレスを格納するためのＮ個（Ｎは２以上）の固定長のアドレス格納領域を有する固定サイズの辞書を記憶する記憶手段と、
圧縮符号化の開始に先立って、前記記憶手段に記憶された前記辞書の前記アドレス格納領域の全てに、無効アドレスデータを格納する初期化手段と、
前記バッファメモリ内の符号化対象文字列の先頭のＭ個の文字で表わされる文字列で求められたエントリアドレスで前記辞書をアクセスし、当該エントリアドレスにおけるＮ個のアドレス格納領域が有効／無効なアドレスのいずれを格納しているかを判定する判定手段と、
該判定手段で無効アドレスを格納しているアドレス格納領域が有ると判定された場合には、当該無効アドレスを格納しているアドレス格納領域に前記符号化対象文字列の先頭文字のアドレスを登録し、
前記判定手段で無効アドレスを格納しているアドレス格納領域が無いと判定された場合には、有効なアドレスを格納しているアドレス格納領域の１つに前記符号化対象文字列の先頭文字のアドレスを登録する登録手段と、
前記判定手段で有効なアドレスが格納されているアドレス格納領域が有ると判定した場合、有効なアドレスが格納されている各アドレス格納領域に格納されたアドレスが示す位置から、前記符号化対象文字列と一致する最長一致文字数を求め、前記符号化対象文字列から前記最長一致文字数となる文字列までのオフセットアドレス、及び、前記最長一致文字数とを符号化して符号化データを生成し、
前記判定手段で有効なアドレスを格納しているアドレス格納領域が無いと判定された場合、前記符号化対象文字列の先頭の１文字を符号化して符号化データを生成する符号化手段とを有する。

本発明によれば、固定サイズの辞書を用いながらも、より効率良く圧縮符号化することが可能になる。

本発明における検索テーブル用ＬＵＴを説明する図。 本発明の機能構成のブロック図および、入力バッファの概念図。 実施形態におけるスライド辞書法圧縮のフローの図。 実施形態における一致文字列の検索フローの図。 実施形態における圧縮対象文字の登録フローの図。 実施形態における入力バッファの更新フローの図。 実施形態における検索用テーブルの更新フローの図。 実施形態のオプションにおける圧縮対象文字の登録フローの図。 オプション１の圧縮対象文字列の先頭以外の登録フローの図。 オプション２の圧縮対象文字列の先頭以外の登録フローの図。 オプション３の圧縮対象文字列の先頭以外の登録フローの図。 圧縮レベルによるオプション、パラメータの組合せの例を示す図。 候補数とＬＵＴの構造を示す図。 スライド辞書法による一致文字列検索の模式図。 ＬＵＴ方式の説明の図

以下、添付図面に従って本発明に係る実施形態を詳細に説明する。なお、実施形態では、辞書型圧縮（辞書型符号化または、辞書型圧縮符号化とも呼ぶ）方式について説明する。以下の説明においては、簡単のため、ＬＺ７７圧縮法をベースとした考え方に基づいて説明することとする。よって説明するまでもなく、圧縮対象の文字列データは、バッファメモリ内における、以前に出現し、符号化済みとなった文字列の中の一致列を知ることによって、その「過去の文字列の位置および過去の文字列との一致長さ」を圧縮データとして出力することをベースとしていることに留意願いたい。

本実施形態では、ルックアップテーブル（ＬＵＴ）を検索用の辞書として備えることになる。そして、この辞書はＲＡＭ等の記憶メモリに確保され、Ｍ個（Ｍは２以上）の文字で構成される文字列で表わし得るエントリアドレスとして機能し、各エントリアドレス毎にＮ個（Ｎは２以上）の固定長のアドレス格納領域として機能する記憶領域を有する固定サイズとする。実施形態では、Ｍ＝２、すなわち、２文字分の文字列の組合せの種類に対応する１つのエントリアドレスに対し、３個の記憶領域が確保されているものとする。辞書内の各記憶領域には、「過去に同じ２文字の文字列が、バッファメモリ内のどこに存在していたか」を示す候補となる位置情報（アドレス情報）を格納することができる。

この候補数を大きくすると、「過去に同じ２文字の文字列が、どこに存在していたか」を示すアドレス情報をより多く保持できるため、圧縮対象文字の文字列と過去の文字列とが長い文字として一致する確率が上がる。その結果、圧縮対象文字（データ列）の圧縮率が向上することになる。

図１は、実施形態における検索テーブル用のＬＵＴ１０１とスライドバッファ１００、格納されている候補アドレスの様子を示したものである。また、実施形態におけるＬＵＴ１０１は、先頭２文字に対する候補数を３つ格納するために、３つのフィールドを有する例を説明する。本実施形態での、各文字は８ｂｉｔで構成されており、０ｘ００〜０ｘＦＦ（０ｘは１６進数を表わす）の２５６種類の値を取り得る。スライドバッファ１００内のデータのアドレスがＬＵＴ１０１に保存されている。図１は、スライドバッファ内において、０ｘ０Ａ０Ｂから始まる文字列のアドレスとして、フィールド１０２と１０３の２箇所のアドレスがＬＵＴ１０１に登録されている様子を示している。ＬＵＴ１０１内の検索対象０ｘ０Ａ０Ｂに対応するフィールド１０２には候補１のアドレスが、フィールド１０３には候補２のアドレスが格納されている。また、０ｘ０Ａ０Ｂのアドレスの候補３として、３つ目のフィールドがあるが、現在のところは登録されておらず、未登録のフィールドであることが分かる値がそのフィールドに保存されている。従って、０ｘ０Ａ０Ｂから始まる文字列がスライドバッファ内に存在するかどうかは、「０ｘ０Ａ０Ｂ」が示すアドレス位置のフィールドを順に見ていくだけで判明することになる。以下、このようなＬＵＴを使って、一致文字列を検索する方法について、図面を用いて説明する。

なお、後述するが、スライドバッファ１００のサイズは３２７６８［Ｂｙｔｅ］とする。ＬＵＴ１０１の各フィールドには、このスライドバッファ１００をバイト単位のアドレスのオフセットアドレスを格納することになるが、そのためには１５ビット必要になる。ただし、上記のとおり未登録の状態をも表わす必要があるため、実施形態では、ＬＵＴ１０１の各フィールドのサイズは１６ビットとし、アドレスが未登録状態である場合には、１６ビットで表わす最大値「６５５３５」を格納するものとした。なお、これは一例であって、スライドバッファ内か否かで判定できるようにすれば良いので、他の値でも構わない。

図２（ａ）は、実施形態におけるデータ符号化装置の機能構成を表わすブロック図である。図示における制御部２１０は本装置を構成する各処理部の制御を司ることになる。

データ圧縮したい入力ファイル２０１が入力部２０２に入力される。入力部２０２は、入力ファイル２０１から適宜入力バッファ２０３にデータを読み込む。入力バッファ２０３はスライドバッファのサイズのちょうど２倍の大きさを持っている。本実施形態では、スライドバッファサイズを３２７６８［Ｂｙｔｅ］とし、入力バッファ２０３はその倍の６５５３６［Ｂｙｔｅ］であるものとする。

入力バッファ２０３内において、圧縮対象文字列の先頭を特定し、その先頭文字列を一致文字列検索部２０４に入力する。一致文字列検索部２０４は、検索テーブル用ＬＵＴ２０５（図１のＬＵＴ１０１に対応）を使って入力バッファ２０３のスライドバッファに該当する部分に、一致文字列があるか検索する。また、一致文字列がある場合には、その一致長とオフセットを取得する。また、一致文字列検索部は、入力バッファ２０３のデータが更新された時には、検索テーブル用ＬＵＴ２０５（以下、検索テーブルと略す）のデータも更新する。一致文字列検索部２０４は、一致文字列の有無、一致文字列がある場合にはその一致長とオフセット値を符号生成部２０６へ出力する。符号生成部２０６は一致文字列検索部２０４から受信したデータを元に符号データを生成、出力ファイル２０７へ出力する。

また、本実施形態での圧縮方法はＺｌｉｂ圧縮方式を用いるものとする。すなわち、Ｚｌｉｂ圧縮において一致文字列を検索することを例に説明する。

また、後の説明を分かりやすくするために、図２（ｂ）、（ｃ）を用いて、入力バッファ２０３の使い方を簡単に説明する。詳細な説明は、後述する図３以降のフローチャートの説明の中で行う。

入力バッファ２０３には、スライドバッファ２０８の文字列と、その直後に続く圧縮対象文字列２０９との両方が必ず含まれる（図２（ｂ）参照）。圧縮対象文字列と一致する文字列をスライドバッファ２０８内から検索する場合、その一致長として、ｚｌｉｂでは３〜２５８を有効範囲としている。したがって、入力バッファ内において、圧縮対象文字列２０９が、最長一致長の許容最大サイズ「２５８」未満になってしまう場合、入力バッファ２０３の後半部分（スライドバッファサイズ分）を入力バッファ２０３の先頭にコピー（移動）する。そして、その後ろに新たにデータを読み込む。係る点を示しているのが図２（ｃ）である。したがって、入力バッファ２０３の終端がスライドバッファとして利用されることはない。

次に、本実施形態における圧縮方法について、図３のフローを用いて説明する。ステップＳ３０１では、入力ファイル２０１から入力部２０２を通して、入力バッファ２０３に、入力バッファサイズと同じデータ量のデータを読み込む。そして、その時に読み込めたサイズＲｂを取得する。本実施形態では、入力バッファのサイズが６５５３６［Ｂｙｔｅ］である。たとえば、Ｃ言語のｆｒｅａｄ関数を使って、ｕｎｓｉｇｎｅｄ ｃｈａｒ型のデータを、６５５３６個読み込むようにすれば、戻り値として、読み込めたバイト数が得られる。この戻り値をＲｂとすることができる。読み込めたサイズＲｂは、入力バッファ２０３内の有効バイト数を表すことになる。次に、ステップＳ３０２で、圧縮対象文字へのポインタＰｔを初期化する。本実施形態では、入力バッファ２０３内の先頭から何バイト目が圧縮対象文字なのかを表す値をＰｔとする。したがって、初期化ではＰｔにゼロを代入する。次に、ステップＳ３０３では、候補数Ｙを取得する。この候補数Ｙは、２文字の組合せに対して、いくつのアドレスを検索テーブル内に保持できるかを示す値である。本実施形態では、図１に示すようにフィールド数が３であるので、候補数Ｙを３とする。ステップＳ３０４では、符号化の開始に先立ち、検索用テーブルＳＴをＲＡＭ等のメモリに確保し、そして全ての候補（フィールド）に、初期値を代入し、初期化する。本実施形態では、検索用テーブルＳＴ内の各候補のサイズを１６ビットとし、各候補には入力バッファ２０３の先頭から何バイト目かを示す値をアドレスとして格納するものとする。初期値としては、未登録を表わすため、先に示したように１６ビットで表わす最大値の「６５５３５」を用いる。この最大値「６５５３５」が示すアドレスは、入力バッファ２０３の最後の文字の位置を示すことになるが、先に説明した理由により、最後の文字が符号化対象となることはないので、区別できる。つまり、値「６５５３５」は無効アドレスデータと言うこともできる。

ステップＳ３０５では、一致文字列をスライドウィンドウ２０８内から検索し、その時の一致長とオフセットを取得する。一致文字列の検索方法については、後に、図４を用いて詳しく説明する。ステップＳ３０６では、現在の圧縮対象文字列の先頭文字のアドレスを検索テーブル２０５に登録する。この登録方法については、後に図５を用いて詳しく説明する。

ステップＳ３０７では、一致文字列があったかどうかを判断する。この判断は、ステップＳ３０５で取得した一致長が最短一致長である３以上であったかどうかで判断する。ステップＳ３０７で一致文字列があったと判断された場合には、ステップＳ３０８へ進み、そうでなければ、ステップＳ３０９へ進む。ステップＳ３０８では、一致長とオフセットをｚｌｉｂ圧縮に規定されている方法でハフマン圧縮（ハフマン符号化とも呼ぶ）する。

一方、一致文字列がなかった場合、ステップＳ３０９にて、検索対象の先頭の１文字を出力し、ｚｌｉｂ圧縮に規定されている方法で圧縮する。ステップＳ３０８、Ｓ３０９の圧縮については、本発明の主眼ではないので、詳しい説明を割愛する。

次に、ステップＳ３１０では、圧縮対象文字へのポインタＰｔに、圧縮された文字数を足して、Ｐｔを更新する。すなわち、ステップＳ３０８で圧縮された一致長、または、Ｓ３０９で圧縮された１文字分の「１」を、Ｐｔに加えることで、その値を更新する。この結果、次の圧縮対象文字列の先頭アドレスがＰｔに保持されることになる。

ステップＳ３１１では、圧縮が終了したかどうか判断する。本実施形態では、ポインタＰｔが、入力バッファ２０３における有効バイト数Ｒｂ以上になったかどうかで判断する。圧縮が終了した場合はこのフローを終了する。まだ、圧縮が終了していない場合には、ステップＳ３１２へ進む。ステップＳ３１２では、入力バッファ２０３のデータ容量が不足しているか判断する。すなわち、スライドバッファ２０８より後にあるデータのバイト数と、最長一致長である「２５８」を比較し、「２５８」未満であれば不足と判断し、ステップＳ３１３へ進む。そうでなければ、ステップＳ３０５へ処理を戻し、次の圧縮対象文字列に対する一致文字列の検索を行う。ステップＳ３１３に処理が進んだ場合、入力バッファの更新を行う。入力バッファ２０３の更新については、後に、図６を用いて詳しく説明する。

次に、上記ステップＳ３０５の一致文字列の検索処理を図４のフローチャートに従って説明する。本実施形態での一致文字列の検索は、一致長が最も長いもので、かつ、圧縮対象文字列に一番近いものを優先的に出力する。詳しいフローをステップＳ４０１から順に説明する。

ステップＳ４０１では、圧縮対象文字へのポインタＰｔを取得し、符号化対象文字列の先頭の２文字Ｃｈ０，Ｃｈ１を取得する。ここでは、簡単のため、１文字目のＣｈ０が“０ｘ０Ａ”，２文字目のＣｈ１が“０ｘ０Ｂ”であったとする。ステップＳ４０２では、検索テーブル２０５内において先頭２文字Ｃｈ０，Ｃｈ１に対応する配列の先頭ポインタｐＷｋを取得する。

検索テーブル２０５の先頭アドレスをＳＴ［０］とし、候補の数Ｙとすると、２文字が表わす検索テーブル２０５の該当する配列へのアクセスするためのアドレスポインタｐＷｋは、
ＰＷｋ＝ＳＴ［０］＋｛Ｃｈ０×２５６＋Ｃｈ１｝×Ｙ
となる（１文字目に２５６を乗算するのは、上位に８ビットシフトすることと等価）。本実施形態の場合、１つのアドレスに格納する候補の数は３つであるので、
ｐＷｋ＝ＳＴ［０］＋｛０ｘ０Ａ×２５６＋０ｘ０Ｂ｝×３
＝ＳＴ［０］＋７７１３
＝ＳＴ［７７１３］

つまり、検索テーブル２０５の先頭から、７７１３番目のテーブル要素が、０ｘ０Ａ，０ｘ０Ｂから始まる文字列に該当する配列のエントリアドレスである。なお、実施形態の場合、１つのテーブル要素（候補を示すアドレス情報）は先に説明したように１６ビットである。

ステップＳ４０３では、候補数用のカウンタｉ、候補の中で最も長い文字列が一致した時の一致文字数を格納する変数ｍａｘＭａｔｃｈ，その時のオフセットを格納する変数ｍＯｆｆにそれぞれゼロを代入して初期化する。

ステップＳ４０４では、ｐＷｋ［ｉ］に入っているアドレス値が初期値であるかどうか、又は、有効／無効の判定を行う。初期値（又は無効）の場合は、ｐＷｋ［ｉ］には有効な候補アドレスがないものとし、ステップＳ４１３へ進む。初期値以外の値が格納されていた場合には、ｐＷｋ［ｉ］には有効な候補アドレスが入っていると判断し、ステップＳ４０５へ進む。本実施形態では初期値として６５５３５を用いているので、ｐＷｋ［ｉ］の値を６５５３５と比較すればよい（ｐＷｋ［ｉ］＜６５５３５の場合、有効な候補アドレスが格納されていると判定する）。

ステップＳ４０５では、ｐＷｋ［ｉ］がスライドバッファ内であるかどうかを判断する。スライドバッファ内であると判断した場合は、有効な候補アドレスとしてステップＳ４０６へ処理を進める。スライドバッファの外であると判断した場合には、無効な候補アドレスとしてステップＳ４０９へ進む。本実施形態の場合には、ｐＷｋ［ｉ］は入力バッファ２０３の先頭から何バイト目かを表わす値が入っている。

圧縮対象文字へのポインタＰｔも、同じく入力バッファ２０３の先頭から何バイト目かを表す値が入っている。そこで、「Ｐｔ−ｐＷｋ［ｉ］」がスライドバッファのサイズ「３２７６８」以下であれば、スライドバッファ内にあると判断し、ステップＳ４０６へ進み。そうでなければ、スライドバッファの外と判断し、ステップＳ４０９へ進む。

ステップＳ４０９では、ｐＷｋ［ｉ］に格納されている値は、既にスライドバッファの外に出てしまっている。つまり、検索範囲から外れてしまっているので、ｐＷｋ［ｉ］に初期値（６５５３５）を代入し、検索テーブルの候補から外し、ステップＳ４１３へ処理を進める。

ステップＳ４０６では、入力バッファ２０３内のアドレスｐＷｋ［ｉ］から始まる文字列と圧縮対象文字とを一文字ずつ比較し、一致長ｍＬｅｎを取得する。ただし、検索テーブルから、先頭２文字が一致していることは既に分かっている。したがって、実際には、ｍＬｅｎに２を代入しておき、入力バッファの先頭から（ｐＷｋ［ｉ］＋２）番目からのデータ列と、入力バッファの先頭から（Ｐｔ＋２）番目から始まるデータ列とを一文字ずつ比較すればよい。一致していれば、ｍＬｅｎを１増やして、次の文字の比較を行い、一致しなくなるか、または、最大一致長「２５８」まで比較を繰り返すことになる。ステップＳ４０７では、ステップＳ４０６で得られた一致長ｍＬｅｎを最短一致長「３」と比較する。３以上であればステップＳ４０８へ進む。３未満であれば、圧縮対象として無効な一致長であるため、処理をステップＳ４１３へ進める。

ステップＳ４０８では、ステップＳ４０６で取得した一致長ｍＬｅｎと、今回の検索における最長一致文字数ｍａｘＭａｔｃｈとを比較する。ｍａｘＭａｔｃｈよりもｍＬｅｎが大きければ、ステップＳ４１２へ進む。そうでなければ、ステップＳ４１０へ進む。

ステップＳ４１２に処理が進んだ場合、ｍａｘＭａｔｃｈｍＬｅｎとｐＷｋ［ｉ］を、今回の一致文字列検索の出力候補とし、処理をステップＳ４１２へ進める。すなわち、ｍａｘＭａｔｃｈにｍＬｅｎを代入して更新し、ｍＯｆｆにｐＷｋ［ｉ］を代入して更新する。ステップＳ４１０では、ｍａｘＭａｔｃｈとｍＬｅｎが等しいかどうかを見る。等しくない場合には、ステップＳ４１３へ進み、等しい場合には、ステップＳ４１１へ進む。

ステップＳ４１１では、ｐＷｋ［ｉ］が、現在一致候補として登録されている文字列までのオフセットｍＯｆｆと比較して、圧縮対象文字列に近いか、遠いか判断する。遠い場合は、一致文字列候補とならないため、ステップＳ４１３へ進む。近い場合には、一致文字列候補となるため、ステップＳ４１２へ進む。具体的には、ｐＷｋ［ｉ］よりｍＯｆｆが小さい場合には、ｐＷｋ［ｉ］の方が圧縮文字列に近いと判断できる。逆に、ｐＷｋ［ｉ］よりｍＯｆｆが大きい場合には、ｍＯｆｆの方が圧縮文字列に近いと判断できる。ステップＳ４１３では、候補をカウントするカウンタｉを一つインクリメントする。

ステップＳ４１４では、カウンタｉが候補数Ｙと等しいかどうかを判断する。等しければ、ポインタＰｔで表わされる２文字に対する全ての候補について検索し終えたと判断し、このフローを終了する。等しくなければ、まだ、検索すべき候補が残っていると判断し、処理をステップＳ４０４へ戻す。

このフロー終了時には、一致長としてｍａｘＭａｔｃｈを、そのオフセットとしてｍＯｆｆが出力される。したがって、一致文字列が見つからなかった場合、一致長としてゼロが出力される。有効な一致文字列が見つかった場合には、３以上の値が返される。

次に、図３のステップＳ３０６の処理、すなわち、圧縮対象文字列を、次の検索のために検索テーブル２０５に登録する処理について説明する。本実施形態では、以下のルールに則って登録する。
ルール１：候補となるアドレスを格納する配列（フィールド）の中に、初期値（＝６５５３５）が入っている配列があれば、その配列に登録する。
ルール２：初期値が入っている配列がなければ、今回の検索により最長一致文字列を発見した配列に上書き登録する。
ルール３：最長一致文字列が複数存在した場合（３文字目が一致するものが一つもない場合も含む）、その中で今回の圧縮対象文字列から一番遠い位置情報（格納されているアドレスが最も小さい値）を格納している配列に上書き登録する。

次に、上記のルールに従った図３のＳ３０６の登録方法について、図５のフローを用いて説明する。

ステップＳ５０１では、検索対象文字の先頭２文字（Ｃｈ０，Ｃｈ１）に対応する、検索テーブル内のＹ個の配列に、初期値が設定されている配列があるかどうかを調べる。

該当する配列の先頭は、図４のステップＳ４０２と同様の方法で、Ｃｈ０，Ｃｈ１に対応する検索テーブル内の配列の先頭を取得できる。また、先頭配列に続く配列の値を、先頭配列を含めてＹ個見ることで、その中に初期値が設定されているものがあるか、判断できる。初期値が設定されている配列がある場合には、ステップＳ５０２へ進み、なければ、ステップＳ５０３へ進む。

ステップＳ５０２では、初期値が設定されている配列ｐＷｋ［ｋ］を取得する。実施形態では、候補数（フィールド数）Ｙが３であるので、ｋは｛ｉ，ｉ＋１，ｉ＋２｝のいずれかとなる。

その後、ステップＳ５０６にて、更新対象のｐＷｋ［ｋ］が示す配列（フィールド）に、検索対象文字のアドレスＰｔを代入（格納）することで、登録作業を終了する。

ステップＳ５０３へ進んだ場合、Ｓ５０１で調べたＹ個の配列の中に、一致長がｍａｘＭａｔｃｈとなるオフセットが複数あるかどうかを調べる。複数ある場合には、ステップＳ５０４へ進み、なければステップＳ５０５へ進む。

ステップＳ５０４では、一致長がｍａｘＭａｔｃｈとなるオフセットの中で、今回検索対象とした文字から、一番遠いオフセットが格納されている配列ｐＷｋ［ｋ］を取得する。具体的には、オフセット同士を比較し、一番小さい値のものが、一番遠いオフセットと判断できる。その後、ステップＳ５０６へ進む。

ステップＳ５０５へ進んだ場合は、一致長がｍａｘＭａｔｃｈとなる配列ｐＷｋ［ｋ］を取得し、ステップＳ５０６へ進む。

本実施形態では、説明を分かりやすくするために、一致文字列の検索のフロー（図４）と、検索対象文字列の検索テーブルへの登録のフロー（図５）を分けて記述し、説明した。しかし、この二つのフローには、重複する部分も多くあることが容易に分かる。そのため、一致文字列の検索と、検索対象文字列を登録する配列の特定を同時に行う方が好ましい。

次に、入力バッファ２０３の更新方法について、図６のフローを用いて説明する。

ステップＳ６０１では、入力バッファ２０３において、圧縮対象文字へのポインタＰｔより後に最大一致長「２５８」以上のデータがあるか判断する。最大一致長以上のデータが無ければステップＳ６０２へ進み、そうでなければ、更新の必要はないと判断し、このフローを終了する。本実施形態では、圧縮対象文字へのポインタＰｔは、入力バッファ２０３内の先頭からのオフセットで表している。そのため、「Ｐｔ＋２５８」と、入力バッファ２０３の有効データの終端（入力バッファ２０３への読み込みサイズＲｂ）を比較し、「Ｐｔ＋２５８」の方が大きければ、ステップＳ６０２へ進む。

ステップＳ６０２では、入力バッファ２０３の有効バイト数ＲｂとスライドバッファサイズＳｂｓを比較する。Ｒｂの方が大きければステップＳ６０３へ進む。そうでなければ、ステップＳ６０６へ進む。

ステップＳ６０３では、入力バッファ内の「Ｓｂｓ＋１」番目以降のデータ（入力バッファを２分割した場合の後半）を入力バッファ２０３の先頭にコピーする（図２（ｃ）参照）。ステップＳ６０４では、入力バッファ２０３の有効バイト数Ｒｂから、スライドバッファサイズＳｂｓを引いて、有効バイト数Ｒｂを更新する。ステップＳ６０５では、入力バッファ後半部分のデータを前半部分にコピーしたことを検索テーブルＳＴの値にも反映させるため、検索テーブルＳＴを更新する。この更新方法については、後に図７を用いて説明する。

ステップＳ６０６では、入力バッファの（Ｒｂ＋１）バイト目以降に、最大（入力バッファサイズ−Ｒｂ）バイトのデータを、入力ファイル２０１から読み込む。そして、読み込めたバイト数をＲｂに加算して、新たな入力バッファの有効バイト数とし、このフローを終了する。

次に、図７を用いてステップＳ６０５の検索用テーブルＳＴの更新方法について説明する。

ステップＳ７０１では、検索用テーブルＳＴの配列の個数Ｎを算出する。Ｎは、「先頭２文字の組合せ数」ｘ「候補数」で計算できる。本実施形態の場合、Ｎ＝１９６６０８（＝２５６×２５６×３）となる。

ステップＳ７０２では、検索テーブル内の配列カウンタｊにゼロを代入して初期化する。ステップＳ７０３では、検索テーブルＳＴ［ｊ］の値が初期値以外かどうかを判定する。初期値以外ならステップＳ７０４へ進み、初期であればステップＳ７０７へ進む。

ステップＳ７０４では、ＳＴ［ｊ］の値とスライドバッファサイズＳｂｓを比較する。ＳＴ［ｊ］がＳｂｓ以上であれば、ステップＳ７０５へ進み、そうでなければ、ステップＳ７０６へ進む。

ＳＴ［ｊ］がＳｂｓ以上である場合、スライドバッファサイズ分だけスライドしても、更新後のアドレスは有効である。従って、ステップＳ７０５では、ＳＴ［ｊ］からスライドバッファサイズＳｂｓを引いた値を、新しいＳＴ［ｊ］として更新する。

一方、ステップＳ７０６に進んだ場合には、ＳＴ［ｊ］には初期値を代入して候補から外す。

また、ステップＳ７０７では、カウンタｊに１足して、インクリメントする。そして、ステップＳ７０８では、カウンタｊと検索テーブルＳＴの配列の個数Ｎを比較する。カウンタｊと配列の個数Ｎが等しければ、全ての配列について更新し終えたと判断し、このフローを終了する。そうでなければ、処理をステップＳ７０３へ戻し、次の配列の更新処理に入る。

上記で説明したような本実施形態によれば、検索対象の２文字のエントリアドレス位置に複数個（実施形態では３個）の、一致する文字列のオフセットが格納されることになるので、スライドバッファ内において、検索対象文字列で始まる、より長い文字列の位置がヒットする確率を高めることができ、結果的に高速に、しかもより高い圧縮率で符号化データを生成できるようになる。しかも、検索テーブルのサイズは固定としているので、設計も容易になる。また、検索テーブルから登録データを削除するのも、値を初期値に変えるだけで済む。そのため、検索テーブルのメンテナンスも容易である。

なお、本実施形態では、最長一致であるかどうかだけを、一致列文字列として取得する際の条件としていたが、オフセットの情報を加味しても良い。例えば、直前の一致長３文字のものと、スライドバッファの先頭に位置する一致長４文字のものがある場合、本実施形態では、スライドバッファの先頭が一致文字列として取得される。

しかし、非常に遠いオフセット情報は、しばしば符号長が長くなることが知られている。そこで、オフセットに閾値を設けて、その閾値よりも遠いオフセットの文字列を、一致文字列として取得する際には、予め決められた以上の一致長が認められた時のみ、一致文字列として採用しても良い。複数の一致文字列候補を持ち、それぞれの符号を一度生成した後、最も符号長が短くなるオフセットと一致長の組合せを選択するようにしても良い。

［実施形態のオプション１］
＜未使用配列があるときのみ、登録文字単位ごとにデータを登録する＞
上述の実施形態では、検索テーブル２０５に登録されるアドレスは、圧縮された文字列の先頭位置のみになる。したがって、一致文字列が見つからなかった圧縮対象文字の場合には、その文字の位置が検索テーブル２０５に登録される。

一方、一致文字列が見つかった場合には、その圧縮対象の先頭のみの登録であり、その次に登録されるのは、一致文字長先のデータである。つまり、２８５文字の一致文字列が見つかった場合、その２８５文字の先頭のアドレスが格納されるものの、その次に登録されるのは、２８６文字目以降のアドレスになる。換言すれば、もし２８５文字の一致文字列が見つかった場合、その２８５文字の途中の文字列のアドレスは登録対象とはならない。

そこで、本オプション１では、圧縮対象文字列の先頭以外に対して、一致文字列が見つかった範囲の文字をｐ文字ごとに区切って、検索テーブルに登録する（以下、ｐを登録文字単位と呼ぶ）。ｐ＝１であれば、一致文字列が見つかった全てのデータを検索テーブルに登録することになる。ｐが３以上の値であれば、最短一致長のものは先頭位置のみ登録され、最短一致長よりも長い一致が見つかった場合のみ、先頭位置以外のデータも検索テーブルに登録されることになる。

以下、フローチャートを用いて、本オプション１の説明をする。本実施形態では、一致文字列を２文字ごと（ｐ＝２）に登録するものとする。また、その登録方法は、登録データに該当する配列に、初期値が入っている配列がある場合のみ、登録する。

先頭文字以外の登録は、第１の実施形態で説明した、圧縮対象文字の登録フローの最後に行えばよい。その様子を図８に示す。図８において、図５と同じステップには同じ番号が振ってある。第１の実施形態では、ステップＳ５０６でこのフローを終了したが、本オプションでは、その後に引き続きステップＳ８０１に進む。ステップＳ８０１では、圧縮対象文字の先頭以外の登録を行う。

このステップＳ８０１の登録処理の詳細を図９のフローチャートに従い説明する。

ステップＳ９０１では、検索の結果、圧縮対象文字列が一致した長さを取得する。これはステップＳ３０５で取得した一致長と同じであり、図４の一致文字列検索フローが出力するｍａｘＭａｔｃｈである。本フローでは一致長をｍａｘＭａｔｃｈと表す。ステップＳ９０２では、登録文字単位ｐを取得する。本実施形態ではｐ＝２である。ステップＳ９０３では、圧縮対象文字列の先頭以外の登録文字の位置ｒｐに、登録文字単位ｐを代入し、初期化する。圧縮対象文字列の第１番目、第２番目のアドレスは既に登録済みであるので、ｒｐを３番目の文字を示すように設定すると言うこともできる。

ステップＳ９０４では、ｒｐとｍａｘＭａｔｃｈを比較する。ｒｐが小さければ、ステップＳ９０５へ進む。ｒｐがｍａｘＭａｔｃｈ以上の場合には、登録し終えたものと判定し、本処理を終了する。

ステップＳ９０５では、圧縮対象文字列内のｒｐから示される２文字Ｃｈｐ０，Ｃｈｐ１を取得する。すなわち、Ｃｈｐ０は入力バッファ先頭から「Ｐｔ＋ｒｐ」番目のデータであり、Ｃｈｐ１は「Ｐｔ＋ｒｐ＋１」番目のデータである。ステップＳ９０６では、検索テーブルＳＴ内の「Ｃｈｐ０，Ｃｈｐ１」に対応する配列の先頭ポインタｐＷｋを取得する。ｐＷｋは、ステップＳ４０２と同様の算出方法で取得できる。

ステップＳ９０７では、「Ｃｈｐ０，Ｃｈｐ１」に対応する配列を参照するためのカウンタｉにゼロを代入して、初期化する。ステップＳ９０８では、ｐＷｋ［ｉ］の値と初期値と比較する。初期値と同じであれば、その配列ｐＷｋ［ｉ］は未使用であると判断しステップＳ９０９へ進む。初期値と異なる値であれば、その配列ｐＷｋ［ｉ］は使用されていると判断して、ステップＳ９１０へ進む。

ステップＳ９０９では、ｐＷｋ［ｉ］に「Ｃｈｐ０，Ｃｈｐ１」から始まる文字列の位置（Ｐｔ＋ｒｐ）を代入し、ステップＳ９１２へ進む。ステップＳ９１２では、登録文字位置ｒｐに登録文字単位ｐを加え、次の登録文字の位置を算出し、ステップＳ９０４へ処理を戻す。

一方、ステップＳ９１０に処理を進めた場合には、配列参照用カウンタｉに１を加えて、次の配列を参照するようにする。ステップＳ９１１では、カウンタｉが候補数Ｙ（実施形態ではＹ＝３）と等しいかを調べる。等しい場合には、候補数Ｙ全ての配列を見終えたものとし、ステップＳ９１２へ進む。すなわち、「Ｃｈｐ０，Ｃｈｐ１」に対応する配列には、未使用の配列が無かったため、登録せずに、次の登録文字へと処理を進める。ステップＳ９１１において、カウンタｉが候補数Ｙが異なる場合には、ステップＳ９０８へ処理を進める。

上記をまとめると、最長一致数Ｘで表わされる最長一致文字列を構成する文字をＣｈ(0),Ｃｈ(1),…,Ｃｈ(X-1)と表わし、文字間隔をＰとしたとき、
｛Ｃｈ(P），Ｃｈ(P+1），…, Ｃｈ（P+M-1）｝
｛Ｃｈ(2P），Ｃｈ(2P+1），…, Ｃｈ（2P+M-1）｝
｛Ｃｈ(3P），Ｃｈ(3P+1），…, Ｃｈ（3P+M-1）｝
：
で表わされる、各文字列の出現アドレスを、検索テーブル２０５に登録することを意味する。この結果、入力バッファ２０３の残り容量が少なくなって、スライドバッファ２０８が一気にシフトしたとても、検索テーブル２０５には有効なアドレスが残る確率が高くなり、効率の良い符号化処理を継続できる。

以上説明したように、本オプションを加えると、処理時間は上記第１の実施形態より長くなるが、検索テーブルへの登録文字が増えるため、その後の検索により一致する確率が高くなり、高い圧縮率が期待できる。

また、オプションを加えない場合には未使用だった配列にデータを登録することになり、検索テーブルの使用率があがり、より有効に検索テーブルのメモリ容量を使用できる、というメリットもある。なお、上記ではｐ＝２の例を説明したが、この値はユーザが適宜変更できるようにしても良い。

［実施形態のオプション２］
＜未使用配列がない場合、一番遠い位置のデータに上書きする＞
オプション２では、符号対象文字列の先頭文字以外の登録時に、未使用配列がない場合には、一番遠い位置情報が保存されている配列を上書きする。

上記オプション１と異なるのは、圧縮対象文字列の先頭以外の登録部分のみである。そこで、圧縮対象文字列の先頭以外の登録方法について、図１０を用いて説明する。ただし、図９と同じ動作のステップには、図９と同じ番号を付し、詳しい説明は割愛する。

ステップＳ９０１からステップＳ９０７は、上記オプション１と同様の動作をする。ステップＳ１００１では、候補配列の中の位置情報を一時的に記憶しておくための変数ｏｆｆｓｅｔを、圧縮対象文字列の先頭位置の値Ptで初期化し、ステップＳ９０８へ進む。ステップＳ９０８では、ｐＷｋ［ｉ］の値と初期値とを比較する。

ｐＷｋ［ｉ］に初期値が入っていれば、ステップＳ９０９へ進み、その後の処理は、オプション１と同様になる。初期値と異なる値が入っている場合には、ステップＳ１００２へ進む。ステップＳ１００２では、ｐＷｋ［ｉ］と変数ｏｆｆｓｅｔの値を比較する。ｐＷｋ［ｉ］の値がｏｆｆｓｅｔより小さければ、すなわち、変数ｏｆｆｓｅｔの値よりも遠い位置を示している場合にはステップＳ１００３へ進む。そうでなければ、ステップＳ９１０へ処理を進める。

ステップＳ１００３では、変数ｏｆｆｓｅｔにｐＷｋ［ｉ］の値を代入し、その時のカウンタｉの値を、上書き候補の配列番号ｄとして保存し、ステップＳ９１０へ進む。ステップＳ９１０ではカウンタｉを一つインクリメントする。

ステップＳ９１１では、カウンタｉと候補数Ｙと比較する。カウンタｉと候補数Ｙが同じであればステップＳ１００４へ進み、そうでなければ、ステップＳ９０８へ進む。ステップＳ１００４では、未使用の配列が無かったと判断し、最終的に上書き候補となった配列ｐＷｋ［ｄ］にＣｈｐ０，Ｃｈｐ１から始まる文字列の位置（Ｐｔ＋ｒｐ）を代入し、ステップＳ９１２へ進む。

以上説明したように、本オプション２を加えると、オプション１よりも更に処理時間は長くなるものの、検索テーブルの位置情報がオプション１に比べて、より近い位置情報に書き換わる。ｚｌｉｂ圧縮の場合、位置情報もハフマン圧縮するが、より近い位置の方が頻繁に出現するため、符号列が短い傾向になる。そのため、検索テーブル内の情報が、オプション１よりもより近い情報を持つオプション２の方が、高い圧縮率が期待できる。

［実施形態のオプション３］
＜先頭文字以外も、先頭文字と同じルールで検索テーブルへ登録する＞
本オプション３では、符号対象文字列の先頭文字以外の登録時にも、一致長を算出する。そして、最も長く一致する文字列の中で、符号対象文字列から一番遠い位置情報が保存されている配列に、そのアドレスで上書きする。

上記オプション１、２と異なるのは、圧縮対象文字列の先頭以外の登録部分のみである。そこで、圧縮対象文字列の先頭以外の登録方法について、図１１を用いて説明する。ただし、図９や図１０と同じ動作のステップには、それぞれ図９、図１０と同じ番号を付し、詳しい説明は割愛する。

ステップＳ９０１からステップＳ９０７までは上記オプション１と同様の動作をする。ステップＳ１１０１では、上書き候補となる配列に格納されている位置を保存するための変数ｏｆｆｓｅｔにＰｔを、また、その一致長を保存する変数ｍａｘｌｅｎにゼロを代入して初期化する。

ステップＳ９０８では、オプション１と同様にｐＷｋ［ｉ］の値と初期値を比較する。初期値であれば、ステップＳ９０９、ステップＳ９１２、ステップＳ９０４と処理を進める。これらの処理はオプション１のそれぞれのステップと同様である。

ステップＳ９０８で、ｐＷｋ［ｉ］の値が初期値と異なる値であればステップＳ１１０２へ進む。ステップＳ１１０２では、登録文字位置ｒｐから始まる登録文字列と、アドレスｐＷｋ［ｉ］から始まる文字列を比較し、一致長ｌｅｎを算出する。

一致長の算出方法は、ステップＳ４０６と同様の動作であるので、ここでの詳しい説明は割愛する。ステップＳ１１０３では、ステップＳ１１０２で算出した一致長ｌｅｎと、上書き候補となる配列の位置からの一致長ｍａｘｌｅｎを比較する。ｌｅｎの方が大きければステップＳ１１０４へ、そうでなければ、ステップＳ１１０５へ進む。

ステップＳ１１０４では、ｍａｘｌｅｎにｌｅｎを代入し、ステップＳ１００３へ進む。ステップＳ１００３では、オプション２と同様の動作であり、ｏｆｆｓｅｔにｐＷｋ［ｉ］を、上書き候補番号ｄとしてｉを代入しステップＳ９１０へ進む。

ステップＳ１１０５では、ｌｅｎとｍａｘｌｅｎが同じ長さであるか比較する。同じ長さであれば、ステップＳ１００２へ進む。異なる値であれば、ステップＳ１１０６へ進む。ステップＳ１１０６では、ｍａｘｌｅｎと最短一致長を比較する。

本実施形態では最短一致長は３であるので、ｍａｘｌｅｎが３以上であれば、既に一致文字列が見つかっているので、ステップＳ９１０へ進み、次の配列に進む。ｍａｘｌｅｎが３未満であれば一致文字列は見つかっていないため、一番遠いオフセットを持つ配列を探すため、ステップＳ１００２へ進む。

ステップＳ１００２では、オプション２と同様にｐＷｋ［ｉ］とｏｆｆｓｅｔを比較する。ｏｆｆｓｅｔの方が小さければ、ｉ番目の配列より現在の上書き候補の配列の方が遠い位置情報であるためステップＳ９１０へ進む。

ｏｆｆｓｅｔの方が大きければ、ｉ番目の配列を上書き候補とするためにステップＳ１００３へ進む。ステップＳ１００３はオプション２と同様の動作である。ステップＳ９１０はカウンタｉを一つインクリメントする。

ステップＳ９１１では、カウンタｉと候補数Ｙ（本実施形態では３）を比較し、異なる値であれば、ステップＳ９０８へ処理を戻す。同じであれば、ステップＳ１００４へ進む。ステップＳ１００４では、上書き候補番号ｄの配列ｐＷｋ［ｄ］に登録文字位置（Ｐｔ＋ｒｐ）を登録し、ステップＳ９１２へ進み、次の登録文字位置について、同様の動作を繰り返す。

以上説明したように、本オプション３を加えると、オプション２よりも更に処理時間は長くなるが、一致文字列を優先的に上書きすることができる。すなわち、オプション２の場合には、距離しかみていなかったために、登録の結果、候補全てが同一の３文字から始まるデータになる可能性がある。それに対して、本オプション３では、一致長をみることで、候補の３文字目以降のデータに多様性が生まれ、その後の一致文字列検索の際に、より多くの一致文字列を見つけることができる。したがって、オプション２よりもさらに高い圧縮率が期待できる。

［実施形態の変形例］
以上説明した実施形態によれば、検索テーブル内の候補数Ｙを変えることで、圧縮率と処理時間、あるいは、圧縮率と使用メモリ容量を調整することが可能である。

また、検索テーブルへのデータ登録方法について、オプション１〜３を切り替えることでも、圧縮率と処理時間を調整することが可能である。また、登録文字単位を小さくすると時間はかかるが、長い一致文字列の間の文字も細かく検索テーブルに登録できるため、圧縮率の向上が図れる。

以上を踏まえて、たとえば、圧縮率と処理時間・使用メモリ量の組合せを予めテーブルとして容易しておく。その上で、圧縮時のオプションとして、例えば圧縮度合いを０〜６の７レベルでユーザに選ばせ、それぞれのアルゴリズム、メモリ使用量で圧縮方法を適宜変えても良い。

図１２（ａ）はこのテーブルの例を示している。同図の場合、圧縮率レベルを変えると使用メモリ量も変わってしまう。一方、圧縮アルゴリズムを組み込む機器によっては、固定のメモリ容量だけで、圧縮率レベルを変えたい、という要望もある。そのような場合には、図１２（ｂ）に示すように、候補数を変えずに、アルゴリズムと登録文字単位だけを変化させればよい。

また、システムによっては、使用メモリ量を可変にしても良いが、ある程度の速度は維持したいという要望もある。そのような場合は、図１２（ｃ）のようにオプションのアルゴリズムを使わずに、候補数のみを変えることで、圧縮率のレベルを変えても良い。図１２（ｃ）における、候補数１，２，４，６，８，１２の時のＬＵＴの様子を図１３（ａ）〜（ｆ）にそれぞれ示す。

図１３に示すように、候補数が決まると、ＬＵＴのサイズが決まる。それぞれ固定長のメモリが２文字の組合せ順、候補順に並んでいるだけであるので、候補数が増えても、ＬＵＴのサイズは候補数に比例したサイズになるだけである。圧縮対象文字列が２文字から３文字にする場合には、テーブルサイズが２⁸倍になることを考慮すると、この候補数の増加により要求されるメモリサイズによるデータ検索やデータの削除にかかる負荷はそれほど大きくならず、候補数を増やすことによる影響は少ないと言える。また、上記のオプションを加える、あるいは、その際の登録文字単位を変更するよりは、処理時間に与える影響も小さい。

さらに、図１２（ｃ）のように候補数を増やして、すべての候補を検索すると、やはり処理時間が長くなるため、ある程度の速度は維持したい、という要望に応えきれなくなることもある。そのような場合には、一致長にあるスレッショルド（たとえば、８文字）を設定し、候補を先頭から順に検索し、スレッショルド以上の一致長が見つかったら、それ以降の候補については検索しない、という処理を加えても良いであろう。

上記各実施形態によれば、３文字以上の長い文字列の一致を確認したい場合であっても、ハッシュ値などをルックアップテーブルの参照データとしなくとも十分に実用的なメモリ容量でルックアップテーブルを構成できることが理解できよう。また、過去の文字列を参照するためのルックアップテーブルとして、固定容量のメモリ領域を効果的に利用することにより、効率よく過去の文字列を検索することが可能である。特に、予め割り当てられた固定長メモリを利用するため、使用メモリ領域を逐次更新する等の煩雑なメモリ管理が不要である。

＜その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (9)

1. 文字列を符号化済みの文字列のアドレスを記憶する辞書を参照して符号化する符号化装置であって、
   圧縮符号化するための文字列データを保持するバッファメモリと、
   Ｍ個（Ｍは２以上）の文字の組み合わせ分のエントリアドレスに対応すると共に、各アドレス毎に、前記バッファメモリのアドレスを格納するためのＮ個（Ｎは２以上）の固定長のアドレス格納領域を有する固定サイズの辞書を記憶する記憶手段と、
   圧縮符号化の開始に先立って、前記記憶手段に記憶された前記辞書の前記アドレス格納領域の全てに、無効アドレスデータを格納する初期化手段と、
   前記バッファメモリ内の符号化対象文字列の先頭のＭ個の文字で表わされる文字列で求められたエントリアドレスで前記辞書をアクセスし、当該エントリアドレスにおけるＮ個のアドレス格納領域が有効／無効なアドレスのいずれを格納しているかを判定する判定手段と、
   該判定手段で無効アドレスを格納しているアドレス格納領域が有ると判定された場合には、当該無効アドレスを格納しているアドレス格納領域に前記符号化対象文字列の先頭文字のアドレスを登録し、
   前記判定手段で無効アドレスを格納しているアドレス格納領域が無いと判定された場合には、有効なアドレスを格納しているアドレス格納領域の１つに前記符号化対象文字列の先頭文字のアドレスを登録する登録手段と、
   前記判定手段で有効なアドレスが格納されているアドレス格納領域が有ると判定した場合、有効なアドレスが格納されている各アドレス格納領域に格納されたアドレスが示す位置から、前記符号化対象文字列と一致する最長一致文字数を求め、前記符号化対象文字列から前記最長一致文字数となる文字列までのオフセットアドレス、及び、前記最長一致文字数とを符号化して符号化データを生成し、
   前記判定手段で有効なアドレスを格納しているアドレス格納領域が無いと判定された場合、前記符号化対象文字列の先頭の１文字を符号化して符号化データを生成する符号化手段と
   を有することを特徴とする符号化装置。
2. 前記登録手段は、
   前記判定手段で無効アドレスを格納しているアドレス格納領域が無いと判定された場合には、有効なアドレスを格納しているアドレス格納領域のうち、最長一致文字数となる文字列の先頭アドレスを格納していたアドレス格納領域に、前記符号化対象文字列の先頭文字のアドレスを登録し、最長一致文字数となる文字列の先頭アドレスが複数存在している場合には、前記符号化対象文字列から最も遠いアドレスを記憶しているアドレス格納領域に、前記符号化対象文字列の先頭文字のアドレスを登録する
   ことを特徴とする請求項１に記載の符号化装置。
3. 前記符号化手段は、
   前記辞書のアドレス格納領域に格納されたアドレスのうち、前記符号化対象文字列の直前の位置から予め設定されたサイズ分のスライドバッファ内を指し示すアドレスを有効なアドレス、それ以外を無効なアドレスとして判定する
   ことを特徴とする請求項１又は２に記載の符号化装置。
4. 前記符号化対象文字列を符号化した結果、前記バッファメモリ内の未だ符号化されていない文字列のサイズが、前記符号化手段で符号化する一致長の許容最大サイズより少なくなった場合、前記バッファメモリの前記スライドバッファが示すサイズが示す位置よりも後のデータを前記バッファメモリの先頭に移動させ、移動により空いたメモリの領域に新たに符号化する対象の文字列データを読み出すと共に、前記辞書を更新する更新手段を有し、
   前記更新手段は、
   前記辞書内の全てのアドレス格納領域に格納されたアドレスから、前記スライドバッファのサイズを示すアドレスで減じることで前記辞書を更新する
   ことを特徴とする請求項３に記載の符号化装置。
5. 前記更新手段は、
   前記符号化手段で符号化した最長一致数Ｘで表わされる最長一致文字列を構成する文字をＣｈ(0),Ｃｈ(1),…,Ｃｈ(X-1)と表わしたとき、当該最長一致文字列における
   ｛Ｃｈ(P），Ｃｈ(P+1），…, Ｃｈ（P+M-1）｝
   ｛Ｃｈ(P），Ｃｈ(2P+1），…, Ｃｈ（2P+M-1）｝
   ｛Ｃｈ(3P），Ｃｈ(3P+1），…, Ｃｈ（3P+M-1）｝
   ：
   で表わされる、各文字列のアドレスを、前記辞書の該当するアドレス格納領域に格納することを特徴とする請求項４に記載の符号化装置。
6. 前記更新手段は、無効なアドレスを格納しているアドレス格納領域を更新対象とし、無効なアドレスを格納しているアドレス格納領域が無い場合には前記バッファメモリの先頭に近いアドレスを格納しているアドレス格納領域を更新対象として判定することを特徴とする請求項５に記載の符号化装置。
7. 前記更新手段は、無効アドレスを格納しているアドレス格納領域が無いと判定された場合には、有効なアドレスを格納しているアドレス格納領域のうち、最長一致文字数となる文字列の先頭アドレスを格納していたアドレス格納領域を更新対象とすることを特徴とする請求項５に記載の符号化装置。
8. 圧縮対象の文字列データを保持するバッファメモリと、Ｍ個（Ｍは２以上）の文字の組み合わせ分のエントリアドレスに対応すると共に、各アドレス毎に、前記バッファメモリのアドレスを格納するためのＮ個の固定長のアドレス格納領域を有する固定サイズの辞書を記憶する記憶手段とを有する符号化装置の制御方法であって、
   初期化手段が、圧縮符号化の開始に先立って、前記記憶手段に記憶された前記辞書の前記アドレス格納領域の全てに、無効アドレスデータを格納する初期化工程と、
   判定手段が、前記バッファメモリ内の符号化対象文字列の先頭のＭ個の文字で表わされる文字列で求められたエントリアドレスで前記辞書をアクセスし、当該エントリアドレスにおけるＮ個のアドレス格納領域が有効／無効なアドレスのいずれを格納しているかを判定する判定工程と、
   登録手段が、
   該判定工程で無効アドレスを格納しているアドレス格納領域が有ると判定された場合には、当該無効アドレスを格納しているアドレス格納領域に前記符号化対象文字列の先頭文字のアドレスを登録し、
   前記判定工程で無効アドレスを格納しているアドレス格納領域が無いと判定された場合には、有効なアドレスを格納しているアドレス格納領域の１つに前記符号化対象文字列の先頭文字のアドレスを登録する登録工程と、
   符号化手段が、
   前記判定工程で有効なアドレスが格納されているアドレス格納領域が有ると判定した場合、有効なアドレスが格納されている各アドレス格納領域に格納されたアドレスが示す位置から、前記符号化対象文字列と一致する最長一致文字数を求め、前記符号化対象文字列から前記最長一致文字数となる文字列までのオフセットアドレス、及び、前記最長一致文字数とを符号化して符号化データを生成し、
   前記判定工程で有効なアドレスを格納しているアドレス格納領域が無いと判定された場合、前記符号化対象文字列の先頭の１文字を符号化して符号化データを生成する符号化工程と
   を有することを特徴とする符号化装置の制御方法。
9. 圧縮対象の文字列データを保持するバッファメモリと、
   Ｍ個（Ｍは２以上）の文字の組み合わせ分のエントリアドレスに対応すると共に、各アドレス毎に、前記バッファメモリのアドレスを格納するためのＮ個の固定長のアドレス格納領域を有する固定サイズの辞書を記憶する記憶手段と
   を有するコンピュータに読み込ませ実行させることで、前記コンピュータに、請求項８に記載の方法の各工程を実行させるためのプログラム。

Images