JP4179660B2

JP4179660B2 - 文字列に対するハッシュ値の計算方法およびその方法を実現するプログラムを記録した機械可読な記録媒体、文字列に対するハッシュ値の計算装置ならびに情報管理装置

Info

Publication number: JP4179660B2
Application number: JP11324398A
Authority: JP
Inventors: 英樹西村; 薫稗田
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 1998-04-23
Filing date: 1998-04-23
Publication date: 2008-11-12
Anticipated expiration: 2018-04-23
Also published as: JPH11306194A

Description

【０００１】
【発明の属する技術分野】
この発明は、文字列に対するハッシュ値の計算方法に関し、特に、いわゆるインターネットのＷＷＷ（ＷｏｒｌｄＷｉｄｅＷｅｂ）上のホームページ等のアクセス履歴を、それらのＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）から計算したハッシュ値を用いて定められる記憶領域に保存する際に、コンピュータを用いて効率的にハッシュ値を計算するための方法に関する。
【０００２】
【従来の技術】
インターネットのＷＷＷ上のホームページを閲覧したりするためのプログラムとして、ブラウザと呼ばれるものが知られている。ブラウザを用いて所望のホームページを閲覧するためには、基本的にはブラウザに対してそのホームページのＵＲＬを与える。通常はブラウザは、与えられたＵＲＬにしたがってインターネット上の所定の資源にアクセスし、当該ブラウザが動作しているコンピュータのモニタ上にたとえばホームページを表示する。
【０００３】
ＵＲＬとは、ホームページを管理しているサーバ名と、そのサーバにおけるそのホームページのファイル名とを、アクセスに使用するプロトコル名と組み合わせたものである。たとえば「http://www.sharp.co.jp/sc/zaurus/index.html 」というＵＲＬでは、「http: 」の部分がプロトコル名（ｈｔｔｐ（ｈｙｐｅｒｔｅｘｔｔｒａｎｓｆｅｒｐｒｏｔｏｃｏｌ））を指定し、「//www.sharp.co.jp 」の部分がサーバ名を表し、「/sc/zaurus/index.html 」の部分が（ファイルパスを含めた）ファイル名を示している。
【０００４】
サーバ名は、通常はそのサーバが提供するサービスにしたがった名前（ｗｗｗやｆｔｐなど）と、そのサーバの存在するドメイン名とからなる。ドメイン名とは、ネットワーク（この例ではインターネット）を構成する部分ネットワークに与えられた名称（インターネット上で一意）である。上の例では「www 」の部分がｈｔｔｐプロトコルにしたがったｗｗｗサービスを提供するサーバであることを示し、「sharp.co.jp 」の部分がドメイン名を表す。
【０００５】
ところで、インターネットに接続されるコンピュータの数が増加してインターネット上のトラヒックが増加すると、通信速度が低下し、良好なサービスが提供されなくなるというおそれがある。また、ブラウザを使用する個々のユーザからみると、一旦アクセスして表示されたホームページに対して、それほど間隔を置かずに再度アクセスしようとする場合、一度めと同様の時間をかけて当該ホームページをアクセスしなおすのはレスポンスの点から見て問題がある。
【０００６】
そこで、一般的なブラウザは、一度アクセスしたホームページについては、当該ブラウザが動作しているコンピュータの記憶装置（典型的には固定ディスク）にそのファイルをＵＲＬの履歴とともにキャッシュファイルとして保存している。そして、再度同じＵＲＬが与えられたときには、キャッシュファイルに当該ＵＲＬと一致するものがないかどうか調べ、存在する場合には遠隔のサーバをアクセスすることなく、キャッシュファイル中のファイルをアクセスして表示する。キャッシュファイルに当該ＵＲＬと一致するものがないときだけインターネット上の当該ＵＲＬをアクセスし表示するとともにキャッシュファイルとして保存する。
【０００７】
キャッシュファイルを持つことにより、インターネット上のトラヒックの増加は防止され、かつユーザは良好なレスポンスを得ることができる。キャッシュファイルの内容をどのように維持するか、については種々の方式があるが、その詳細は本願発明とは直接の関係がないのでここでは詳細には述べない。
【０００８】
ファイルを固定ディスクに格納する方式としては一般的には種々考えられるが、あるＵＲＬを与えられたときに当該ＵＲＬに対応するファイルがあるかどうかを高速に検索する必要があることから、キャッシュファイルの履歴を蓄積する方式は自ずと限られる。たとえば履歴として各ファイルのＵＲＬとその格納アドレスとを組にして単に履歴リスト中に順に蓄積し、ＵＲＬが与えられるたびに履歴リストを先頭から調べて、一致するＵＲＬのものがあるか否かを見るという方式は、データが増大するとそのために要する平均時間が大きくなるという問題点がある。そこで、従来から一般的に、ファイルのＵＲＬから所定の計算式にしたがって算出されるハッシュ値を用いて履歴リストを二段階にする方式が採用されている。
【０００９】
この方式では、与えられたＵＲＬからハッシュ値を計算する。ハッシュ値の計算には典型的にはｍｏｄ演算が用いられ、ＵＲＬをそのハッシュ値に基づいて複数個のグループに分類する。例えば、文字Ｕｉ（ｉ＝１…ｎ）がＵＲＬ文字列のｉ番目の文字を表すとして、変数ＳＵＭを次のようにして計算する。
【００１０】
初期値としてＳＵＭ＝０とする。以下の計算をｉ＝１〜ｎに対して繰返す。
【００１１】
【数１】
ＳＵＭ＝ＳＵＭ×５＋Ｕｉ
ｉ＝ｎまで計算が完了したら、ＳＵＭの下位３２ビットをハッシュコード（ハッシュ値）とする。下位３２ビットのみをハッシュコードとすることで、ｍｏｄ演算が行われ、ハッシュコードに基づいてＵＲＬが分類される。
【００１２】
こうして計算されたハッシュコードにしたがって各ＵＲＬを振り分ける。つまり、履歴リストは各ハッシュコードのリストとなり、各ハッシュコードにはそのハッシュコードをもつＵＲＬがサブリストとして連結される。各ＵＲＬには、そのＵＲＬに対応したファイルの固定ディスクにおける格納アドレスが付加される。
【００１３】
ＵＲＬが与えられると、まずそのハッシュコードが前述の式にしたがって計算される。そして、履歴リスト内の、計算されたハッシュコードに連結されたサブリストをたどり、そのサブリスト内に目的のＵＲＬが存在するかどうかを調べる。当該ＵＲＬが存在する場合にはそのＵＲＬに付されていた格納アドレスを用いて固定ディスクをアクセスし目的のファイルを取り出して表示する。なければ履歴中に存在しないものとしてインターネット上で目的ＵＲＬをアクセスする。
【００１４】
こうした２段階の履歴リストを用いることで、ＵＲＬの検索のための文字列の比較が、最大でも、一つのハッシュコードに連結されたサブリストの要素の数となるので、履歴を順次に保存しておく場合と比較して比較の回数が大幅に減る。
【００１５】
【発明が解決しようとする課題】
このようなハッシュを用いた分類を使用するときには、各ハッシュコードごとにそのハッシュコード値を持つＵＲＬの数が均等になるのが望ましい。ところが、ＵＲＬについてはハッシュコードを用いても均等に分類されないという問題点があることがわかった。これは次のような要因による。
【００１６】
ＵＲＬは、上記したようにプロトコル名と、サーバ名と、ファイル名との組み合わせである。ところが、プロトコルの種類は限られており特にブラウザプログラムがアクセスするときにはほとんどの場合ｈｔｔｐプロトコルが用いられるから、ＵＲＬ文字列のうちのプロトコルを表す部分についてはほとんどすべてが「http:// 」となる。同じ文字列がＵＲＬ中の同じ部分にあると、上記した式にしたがって計算した場合にはこの部分から得られるハッシュコードは同一となる。
【００１７】
またサーバ名のうち、多くの場合先頭部分も各サービスを表す文字列に固定されているのが通常である。たとえば「www 」である。すると、この部分でもハッシュコードの計算において差は生じない。
【００１８】
さらに、同一のドメインに存在するデータのＵＲＬはその大部分が共通で、一部分しか相違していないことが多い。そもそも、同一のドメイン内では、ＵＲＬのうちのドメイン名の部分が同一となる。この場合にもハッシュコードの計算において差が生じない。
【００１９】
その結果、ＵＲＬの文字列中に出現する文字の並びに偏りがあるので、ハッシュコードによるＵＲＬの分類にも偏りが生じるという問題点がある。
【００２０】
このようにＵＲＬの分類に偏りが生じると、与えられたＵＲＬ文字列をそのＵＲＬに対して計算されたハッシュコードと同一のハッシュコードを持つ多数のＵＲＬ文字列と比較する必要が生じる。この場合には文字列をその先頭から順次比較して一致しない部分が発見されてはじめて次のＵＲＬ文字列との比較が行われる。ところが、たとえば同一ドメインに属するデータのＵＲＬ文字列はその先頭から大部分が等しく、異なる部分は最後の何文字かだけであるという場合が多く、その場合には先頭から多数の文字を比較して最後に近い部分になってはじめて相違が認識されるので、ＵＲＬ文字列ごとに各文字の比較を多数回繰返す必要が生じる。そのため、ハッシュコードによるばらつきが効率的に行われない場合には、比較対象となるＵＲＬの数自体が多くなることとあいまって、検索を非効率的にしている。
【００２１】
これを避けるためには、ハッシュコードを計算するためのハッシュ関数をより複雑なものとしてハッシュコードを効率的にばらつかせる必要がある。しかしそれでも、同一のハッシュコード内で直接比較する場合に、比較の対象となる文字列が長くなるという問題を解決することはできない。また、関数が複雑であれば処理に要する時間も長くなる。
【００２２】
こうした問題は、インターネットのＵＲＬをキャッシュするためのブラウザに限らず、これと同様の性質をもったデータの格納場所をハッシュにより定める場合にも遭遇する問題である。また、こうしたハッシングを行うときには、そのために必要なメモリ領域をなるべく節約し、かつハッシング計算も高速で行うことができるようにしたようが好ましい。
【００２３】
それゆえにこの発明の目的は、ＵＲＬのように、文字の並びの出現頻度に偏りがあるような文字列に対して効率的にハッシングが行なえる、文字列に対するハッシュ値の計算方法およびその方法を実現するプログラムを記録した機械可読な記録媒体、文字列に対するハッシュ値の計算装置ならびに情報管理装置を提供することである。
【００２４】
【課題を解決するための手段】
この発明のある局面に従うと、方法は、偏った頻度で文字の並びが出現する処理対象の文字列に対するハッシュ値の計算方法であって、特定の文字列を、より短い長さの変換後文字列と一意に関連付けるための機械可読なテーブルを準備するステップと、コンピュータを用いて、処理対象文字列中に出現する文字列を、テーブルを参照して対応の変換後文字列に変換するステップと、コンピュータを用いて、変換後文字列を含む処理対象文字列に基づいてハッシュ値を計算するステップとを含む。
【００２５】
変換後文字列は、変換前の文字列と比較して文字列長が短くなる。そのためハッシュ値の計算が高速で行なえ、かつ文字列を記憶しておく領域の容量が少なく済む。また、ハッシュ値が同一の場合には文字列を直接比較する必要があるが、変換後の短い文字列が比較の対象となるので比較を高速に行うことができる。
【００２６】
好ましくは、テーブルを準備するステップは、過去に出現した処理対象文字列をコンピュータ中に準備するステップと、過去に出現した処理対象文字列の部分文字列の各々の、出現回数と文字列長とを、コンピュータを用いて集計するステップと、集計された出現回数と文字列長とに基づき、過去に出現した処理対象文字列の部分文字列のうち、所定文字に置換したときに過去に出現した処理対象文字列を最も効率的に圧縮することが可能な部分文字列を選択しテーブルに追加するステップと、選択された部分文字列を考慮して出現回数を再計算し、さらに、追加するステップを所定の条件が成立するまで繰返すステップとを含む。
【００２７】
過去に出現した処理対象文字列について、その部分文字列の出現回数と文字列長とを集計することにより、各部分文字列を所定文字列に置換したときに得られる圧縮量を計算できる。この圧縮量に基づいてテーブルにあげるべき文字列を選択することで、効果的に処理対象文字列を圧縮しハッシュの計算が行なえるようになる。
【００２８】
この発明の他の局面に従うと、記録媒体は、偏った頻度で文字の並びが出現する処理対象の文字列に対するハッシュ値の計算方法を実現するプログラムを記録した機械可読な記録媒体であって、プログラムは、特定の文字列を、より短い長さの変換後文字列と一意に関連付けるための機械可読なテーブルを準備するステップと、処理対象文字列中に出現する文字列を、テーブルを参照して対応の変換後文字列に変換するステップと、変換後文字列を含む処理対象文字列に基づいてハッシュ値を計算するステップとを含む。
【００２９】
変換後文字列は、変換前の文字列と比較して文字列長が短くなる。そのためハッシュ値の計算が高速で行なえ、かつ文字列を記憶しておく領域の容量が少なく済む。
【００３０】
好ましくは、テーブルを準備するステップは、過去に出現した処理対象文字列を準備するステップと、過去に出現した処理対象文字列の部分文字列の各々の、出現回数と文字列長とを集計するステップと、集計された出現回数と文字列長とに基づき、過去に出現した処理対象文字列の部分文字列のうち、所定文字に置換したときに過去に出現した処理対象文字列を最も効率的に圧縮することが可能な部分文字列を選択しテーブルに追加するステップと、選択された部分文字列を考慮して出現回数を再計算し、さらに、追加するステップを所定の条件が成立するまで繰返すステップとを含む。
【００３１】
過去に出現した処理対象文字列について、その部分文字列の出現回数と文字列長とを集計することにより、各部分文字列を所定文字列に置換したときに得られる圧縮量を計算できる。この圧縮量に基づいてテーブルに含ませるべき文字列を選択することで、効果的に処理対象文字列を圧縮しハッシュの計算が行なえるようになる。
【００３２】
【発明の実施の形態】
［第１の実施の形態］
図１を参照して、本願発明の第１の実施の形態にかかる方法は、ブラウザ２０によるキャッシュファイル領域２４の管理において、ブラウザ２０から与えられたＵＲＬを後述する方法にしたがって圧縮し、圧縮したＵＲＬに対してハッシュ計算を行って、圧縮後の当該ＵＲＬおよびそのＵＲＬに対応するキャッシュファイルのアドレスの組からなるハッシュレコード４２を、ハッシュメモリ２６内の、当該ＵＲＬに対して計算されたハッシュ領域４０に格納する処理を行うＵＲＬ圧縮装置２２により実現される。なお本実施の形態はブラウザによるＵＲＬのアクセス履歴の管理について述べるが、本発明はこれに限らず、文字列をキーとしてハッシングを行い、そのハッシュ値に基づいてレコードを格納したり検索したりするシステム全般に適用することができる。
【００３３】
ＵＲＬ圧縮装置２２は、実際にはコンピュータ上で実行されるソフトウェアにより実現されるが、ＵＲＬを置換する際に使用される、置換前後の文字列のテーブルである文字列リスト５０と、過去のアクセス履歴ファイル４６に基づいて文字列リスト５０を構築するためのリスト作成処理５６と、ブラウザ２０から与えられたＵＲＬに含まれる部分文字列を、文字列リスト５０を参照して、より短い長さの所定のコード（本実施の形態では１バイトのコード）に置換するための文字列置換処理５２と、文字列置換処理５２によって部分文字列をそれぞれ所定のコードに置換したＵＲＬに基づいてハッシュ計算を行って、計算により得られたハッシュ値にしたがってハッシュメモリ２６を維持・管理するためのハッシュ計算処理５４とを含む。
【００３４】
図２を参照して、文字列リスト５０は、置換の対象となる文字列（左欄）と、置換後の文字列（右欄）とを組とし、この組を３０個含んだものである。図２に示される例では、「http://www. 」という文字列が「１」に置換され、「http:// 」という文字列が「２」に置換され、「.co.jp./」という文字列が「３」に置換され、以下同様である。
【００３５】
一般的に通常のパーソナルコンピュータではＡＳＣＩＩ（American Standard Code for Information Interchange ）コードを用いている。しかし、実際に文字として使用されるのはＡＳＣＩＩコードで「３２」以上である。そこで、圧縮後のコードとしてコード１〜３１を用いれば、あるハッシュレコード４２のうちのＵＲＬ文字列のうちのあるバイトが、もともとのＵＲＬに含まれていた文字か、文字列置換処理５２によって置換されたコードかを、そのコードの値から判別することができる。この実施の形態では置換後のコードとして１〜３０を用いている。
【００３６】
図３に、文字列リスト５０を用いて文字列を置換する前のＵＲＬ文字列（左欄）と、置換後のＵＲＬ文字列との例を示す。図３において、左欄の文字列のうち「http://www. 」の部分は図２の文字列のうち１行目の左欄と一致する。図２によれば、この文字列はＡＳＣＩＩコードの「１」に置換される。また、図３の左欄の文字列において、最後の「.co.jp/ 」の文字列は図２の表では３行目の左欄と一致し、対応のＡＳＣＩＩコードは「３」である。したがって「http://www.sharp.co.jp/ 」は図３の右欄に示すとおり「[1]sharp[3] 」に変換される（コードであることを角かっこで示す）。
【００３７】
このようにして部分文字列を文字列リスト５０を参照しながら可能なかぎり対応のＡＳＣＩＩコードに変換したのち、変換後の文字列に対してハッシュ計算処理５４を行う。そして、計算されたハッシュコードにしたがって当該ＵＲＬを各ハッシュ領域４０に振り分けて、ＵＲＬの保存であれば置換後のＵＲＬと対応のキャッシュファイルのディスクアドレスとをハッシュ領域４０に格納し、ＵＲＬから対応のキャッシュファイルのディスク格納領域を検索する場合であれば対応のハッシュ領域４０内で当該置換後のＵＲＬ文字列を検索したのち、付加されているディスクアドレスをブラウザ２０に返す。
【００３８】
このようにすることにより次の効果が生ずる。まず、ハッシュ計算が、部分文字列を対応のより短いコードに置換した後のＵＲＬに対して行われるため、ハッシュ計算の対象となる文字列そのものが短くなりハッシュ計算の計算量が減少する。特に、ハッシュ計算のばらつきを効率的にするためにハッシュ計算式として複雑なものを選んだ場合に、計算量の増大を押さえることができる。そのためハッシュ計算をより処理を高速化できる。また、同様のばらつきを実現しようとする場合、対象となる文字列が短くなっているので、ハッシュ計算式としてそれほど複雑な式を使用しなくともよいという効果もある。
【００３９】
また、ハッシュ領域４０のハッシュレコード４２に格納されるＵＲＬは置換後のより短い文字列となっているので、同じ容量のハッシュ領域４０であればより多くの数のＵＲＬを格納することができる。または、同じ数のＵＲＬを格納するために必要なハッシュ領域４０の容量が少なくて済む。すなわち、ハッシュ領域４０のための記憶領域を有効に利用することができる。また、同一のハッシュ領域４０内でＵＲＬ文字列の比較を行わなければならない場合でも、比較の対象となる文字列の長さが短いので、比較が高速に行なえるという効果を奏する。
【００４０】
前述のようにＵＲＬ圧縮装置２２は実際には、パーソナルコンピュータまたはワークステーションなど、コンピュータ上で実行されるソフトウェアにより実現される。図４に、文字列に対するハッシュ値の計算方法を実現するコンピュータの外観を示す。図４を参照してこのコンピュータ１２０は、ＣＤ−ＲＯＭ（Compact Disc Read-Only Memory ）駆動装置１４４およびＦＤ（Flexible Disk ）駆動装置１４２とを備えたコンピュータ本体１３０と、モニタ１４８と、プリンタ１４６と、キーボード１３６と、マウス１３４とを含む。
【００４１】
図５に、このコンピュータ１２０の構成をブロック図形式で示す。図５に示されるようにコンピュータ本体１３０は、ＦＤ駆動装置１４２およびＣＤ−ＲＯＭ駆動装置１４４に加えて、相互にバスで接続されたＣＰＵ１３２（Central Processing Unit ）と、メモリ１３８と、固定ディスク１４０とを含んでいる。ＣＤ−ＲＯＭ駆動装置１４４にはＣＤ−ＲＯＭ１５２が装着される。ＦＤ駆動装置１４２にはＦＤ１５０が装着される。
【００４２】
既に述べたようにこの文字列に対するハッシュ値の計算方法は、コンピュータハードウェアと、ＣＰＵ１３２により実行されるソフトウェアとにより実現される。一般的にこうしたソフトウェアは、ＣＤ−ＲＯＭ１５２、ＦＤ１５０などの記憶媒体に格納されて流通し、ＣＤ−ＲＯＭ駆動装置１４４またはＦＤ駆動装置１４２などにより記憶媒体から読取られて固定ディスク１４０に一旦格納される。さらに固定ディスク１４０からメモリ１３８に読出されてＣＰＵ１３２により実行される。図４および図５に示したコンピュータのハードウェア自体は一般的なものである。したがって、本発明の最も本質的な部分はＣＤ−ＲＯＭ１５２、ＦＤ１５０、固定ディスク１４０などの記憶媒体に記憶されたソフトウェアである。
【００４３】
なお図４および図５に示したコンピュータ自体の動作は周知であるので、ここではその詳細な説明は繰返さない。
【００４４】
図６を参照して、図１に示したリスト作成処理５６の詳細について説明する。なお、本実施の形態の装置では過去のアクセス履歴ファイル４６から、置換前の文字列と置換後の文字列とを一意に対応つけるテーブルである文字列リスト５０を作成するが、これは、過去の履歴を用いれば、最もＵＲＬの文字列の置換の効率がよくなるように文字列リスト５０を作成することが可能と考えられるためである。ただし、このようにアクセス履歴ファイル４６が準備できない場合には理論的に考えて文字列リスト５０を手作業で作成してもよい。また、他のサイトでのアクセス履歴から作成された文字列リスト５０を用いるようにしてもよい。文字列リスト５０が、ブラウザ２０により参照されるＵＲＬのうちに比較的高い頻度で出現するできるだけ長い文字列を短いデータに置き換えられるように文字列リスト５０を用意すればよい。
【００４５】
また、本実施の形態では文字列リスト５０を準備するために最初の一度だけアクセス履歴ファイル４６に基づいてリスト作成処理５６を行うものとしているが、稼動を開始したのちその実績に基づいてリスト作成処理５６を随時行い文字列リスト５０を作成しなおすようにしてもよい。ただしその場合には、作りなおす前の文字列リスト５０に基づいて作成されたハッシュメモリ２６の内容を、作り直した後の文字列リスト５０に合わせて作りなおさなければならないことは勿論である。
【００４６】
図６を参照して、まずＵＲＬ中の部分文字列の出現回数を各部分文字列ごとに集計する（２００）。このとき、ＵＲＬを単位とするだけでなく、ＵＲＬに含まれる部分文字列までも含め、各文字列がアクセス履歴ファイル４６中に何回出現したかを各文字列長とともに集計する。集計する部分文字列の長さは置換後のコードの長さよりも長ければよいので、この実施の形態においては３文字以上の部分文字列について全て集計することとしている。この集計の結果、３文字以上の文字列と、その文字列の文字列長と、アクセス履歴ファイル４６内におけるその文字列の出現回数とが全て集計される。
【００４７】
続いて変数ｉに０を代入する（２０２）。変数ｉは、文字列リスト５０にリストされた文字列の数をカウントするための変数であり、ここでその初期値を代入している。
【００４８】
次に、変数ｉに１を加算し（２０４）、変数ｉの値が、文字列リスト５０の最大文字列数として予め定められた数（本実施の形態では３０）よりも大きいか否かを判定する（２０６）。もしも判定結果がＹＥＳなら処理を終了する。判定結果がＮＯであれば制御はステップ２０８に進む。
【００４９】
ステップ２０８では、ステップ２００で得られた集計表のうち、最も高い圧縮効果が得られる部分文字列を選択する。圧縮効果は、たとえば以下の式にしたがって求められる。
【００５０】
【数２】
総圧縮長＝（文字列長−圧縮後のサイズ）×出現回数
こうして計算された総圧縮長が最も大きい部分文字列をステップ２０８で選択し、ステップ２１０で文字列リスト５０に追加する。そして、この部分文字列をもとの集計表から削除する（２１２）。たとえば、集計表が図７に示されるようなものである場合を考える。この場合、上述の式にしたがって計算した総圧縮長が最も大きくなるのは、「http://www」である（総圧縮長＝（１０−１）×８００＝７２００）。したがって、「http://www」を文字列リスト５０に追加して集計表から削除する。
【００５１】
このとき、この部分文字列が削除されたことにより、もとの集計表内の各文字列のうち、削除された部分文字列に含まれている文字列についてもそれぞれ当該部分文字列の出現回数分だけその出現回数を減算し集計表を再計算する（２１４）。図７に示される例では、「http://www」の部分文字列であって図７の表にリストされているのは「http:// 」である。「http://www」の出現回数が図７によれば８００回であったから、「http:// 」の出現回数は、もとの「９００」から８００を減算した「１００」となる（図８）。
【００５２】
こうして集計表を再計算した後制御はステップ２０４に戻り、以下ステップ２０４からステップ２１４までを、ステップ２０６の判断により処理終了となるまで繰返す。もちろんこの途中で集計表に文字列が残っていない状況となったらその時点で処理を終了すればよい。
【００５３】
次に図９を参照して、ＵＲＬの格納をする場合の処理について説明する。まず、ブラウザ２０からＵＲＬと当該ＵＲＬに対応するキャッシュファイルのディスクアドレスとを受け取る（２５０）。次に、文字列リスト５０を読込む（２５２）。
【００５４】
以下、ＵＲＬの文字列の先頭から、文字列リスト５０の各行と一致する文字列があるかどうかを比較していく。まず、ステップ２５４で、処理対象の文字が最後の文字であるか否かを判定する。最後の文字であれば上述した比較を終了し制御はステップ２６０に進む。ステップ２６０以下については後述する。
【００５５】
ステップ２５４で、処理対象の文字が最後の文字でないと判定されたときには、ステップ２５６でこの文字から始まる文字列のいずれかが文字列リスト５０の文字列のいずれかと一致するか否かを判定する。一致しなければ処理対象を次の文字に進めて制御をステップ２５４に戻す。一致するものがあるときは、当該文字列を、文字列リスト５０中でその文字列に対応するものとして示されているコードに置換する（２５８）。その後処理対象を次の文字に進めて制御はステップ２５４に戻る。このようにして、入力されたＵＲＬのうちの文字列を順次コードに置換していく。
【００５６】
ステップ２５４の判定結果がＹＥＳとなるときには、入力されたＵＲＬのうちコードに置換されるべきものは置換されており、当初のＵＲＬの長さと比較してかなり短くなっている。この場合ステップ２６０で、このようにして文字列がコードに変換されたＵＲＬに基づいてハッシュが計算される。この場合のハッシュ計算式は、既に述べたようなものでもよいし、ばらつきをより均等にするためにより複雑なものであってもよい。計算の対象となるＵＲＬ文字列がもとのＵＲＬ文字列と比較して短くなっているのでハッシュ計算も高速に行なえる。そのためハッシュ計算を複雑にしても処理速度が不当に増大することはない。
【００５７】
こうして計算されたハッシュコードに基づいて当該ＵＲＬを格納すべきハッシュ領域４０が選択され、当該領域内のたとえば最後のレコードとしてこの置換後のＵＲＬと、当該ＵＲＬに対応のキャッシュファイルのディスクアドレスとが追加格納（または更新）される（２６２）。
【００５８】
図１０を参照して、ブラウザ２０からＵＲＬの入力を受けて、ハッシュメモリ２６内を検索する場合の処理について説明する。図１０において、図９と同一の処理には同一のステップ番号を付してある。それら各ステップで行われる処理は互いに同じなので、ここでは説明は繰返さない。図１０が図９と異なるのは、図９のステップ２６２に代えて、ハッシュコードにしたがって定められたハッシュ領域４０をアクセスして当該ＵＲＬが存在するか否かを調べるするステップ（２７０）と、当該ＵＲＬが存在する場合に、そのＵＲＬに付加されているディスクアドレスをブラウザ２０に返し、存在しない場合には存在していないことを示す情報をブラウザ２０に返す処理を行うステップ２７２とが設けられていることである。
【００５９】
図１０に示される処理によって、ブラウザ２０は、当該ＵＲＬがキャッシュファイル領域２４に存在する場合には、返されたディスクアドレスにしたがってそのキャッシュファイルにアクセスできる。当該ＵＲＬがキャッシュファイル領域２４に存在しない場合には、改めてインターネットを介してそのＵＲＬに対してアクセスを行う。
［第２の実施の形態］
上述の第１の実施の形態では、置換後の文字コードとして１〜３０までを使用することとしていた。しかし、これよりもさらに多くの数の文字列を置換できるようにしておくとさらにハッシュ計算が効率化できると考えられる。また、この場合にもユーザごとに設定するものとは別に、全ユーザに共通の置換文字列を定めて運用できるようにすることが望ましい。そこで第２の実施の形態では、共通の置換のための文字列表と、ユーザごとの文字列表とを別個のものとすることとした。ただし、使用される文字列リストがこの二種類となることを除いて、ソフトウェアは第１の実施の形態におけるものと同様である。そこで、以下では文字列リストの詳細についてのみ述べる。
【００６０】
図１１に、この第２の実施の形態で使用される、複数のユーザで共通に使用される置換用文字列リストの例を示す。また図１２に、ユーザごとに使用される置換用文字列リストの例を示す。
【００６１】
前述のように、ＡＳＣＩＩコード体系を用いたシステムでは、コード０〜３１は通常は用いられない。そこで、第１の実施の形態では、１〜３０までのＡＳＣＩＩコードを置換後のコードとして用いた。しかし、この場合に置換後の文字コードとして使用可能な文字コードは最大でも０〜３１までの３２通りしかない。共通のものに加えて各ユーザごとに置換文字列を定義するためには、これだけでは数が不足である。
【００６２】
そこでこの第２の実施の形態では、第１の実施の形態と同様に共通の置換文字列リストの置換後文字コードとして１〜３０を用いる（図１１参照）とともに、ユーザごとの文字列リストでは、ＡＳＣＩＩコード「３１」をエスケープコードとし、コード「３１」とその後の１バイトとによってユーザ定義の置換後文字コードを示すこととした（図１２参照）。このようにエスケープコードを用いることにより、その後の文字コードの範囲には制限がなくなるから、ユーザ定義の置換後文字列にはコード「３１＋０」からコード「３１＋２５５」までの２５６種類を利用することができ、ユーザの状況に応じて効率的なＵＲＬの管理が可能となる。
【００６３】
図１３に、図１１および図１２に示される文字列リストを用いてＵＲＬ文字列を置換した前後の文字列の組の例を示す。図１３の左欄の１行目に示されるＵＲＬのうち、文字列「http://www.sharp.co.jp」は図１２の左欄の１行目に現れている。これに対応する文字コードは「０」であり、かつその前にはエスケープコード「３１」が必要とされる。また図１３の残りの文字列「/index.html 」は図１１の最後の行に現れており、対応の文字コードは「３０」である。しかもこの場合にはエスケープコードは不要である。したがって「http://www.sharp.co.jp/index.html 」は「[31][0][30] 」に置換されることになる。その結果が図１３の１行目の右欄に示されている。
【００６４】
図１３の２行目も同様である。ただしこの場合、文字列「slab.tnr」については置換できないので右欄にはそのまま残っている。この場合にも、置換後の文字列として通常は使用されないコード１〜３１を使用しているので、置換後の文字列と置換されなかった文字列とを区別することができる。
【００６５】
この第２の実施の形態によっても、第１の実施の形態と同様の効果を得ることができる上、ユーザの状況に応じてより柔軟にＵＲＬの管理を行うことが可能になり、しかも置換後の文字列として利用可能な文字コードの数が増えるので、より効率的なＵＲＬの管理を行うことができる。
［第３の実施の形態］
以上の第１の実施の形態および第２の実施の形態のいずれにおいても、使用されていないＡＳＣＩＩコードを置換後の文字列に割り当てていた。しかし本発明はそれには限定されない。たとえばこの第３の実施の形態におけるように、置換後の文字列として２けたの数字（「００」から「９９まで」）を用いることもできる。つまり、置換後の文字列から置換前の文字列が復元でき（つまり置換文字列と置換後コードとが一意に対応付けられ）、かつ置換後には置換前よりも文字列長が確実に短くなっている限りは、置換後の文字列としてどのような文字列を用いてもよいということである。
【００６６】
この第３の実施の形態では、図１４に示されるように、置換後の文字列として２けたの数字を使用している。各数字自体は通常使用されているＡＳＣＩＩコードにおける数字と変わりはない。この場合しかし、置換後の文字列である２けたの数字と、本来の数字とを区別する必要が生じる。そこで、この第３の実施の形態では、もともとの１けたの数字を全て２けたの数字で表すこととし、かつその場合の上位１けたを「０」とすることにした（図１４の右欄参照）。つまり１けたの数字を、上位１けたが「０」で下位１けたがもともとの数字と等しい２けたの数字に置換することとした。
【００６７】
こうしたルールを定めることで、置換後の文字列中に数字が見い出された場合、それらを２桁ずつ取り扱って、図１４の右欄から左欄を参照すれば元の文字列を復元することができる。
【００６８】
図１５に、図１４に示される文字列リストを用いた文字列（ＵＲＬ）の置換例を示す。図１５の１行目の左欄に示される文字列のうち、「http://www. 」は図１４から「１０」に置換される。「sharp 」は「５０」に置換される。「.co.jp/ 」は「１２」に置換される。したがって全体は「１０５０１２」となる。
【００６９】
また図１５の２行目の左欄に示される文字列のうち、「http://www.sharp.co.jp/ 」は前述のとおり「１０５０１２」に置換される。その後の「zaurus/ 」は置換ができないが、その後の「index 」は図１４から「１３」に、「０」は同じく「００」に、「.html 」は同じく「１４」に、それぞれ置換される。したがって全体は「１０５０１２ｚａｕｒｕｓ／１３００１４」に変換されることになる。
【００７０】
このように、置換後の文字列をどのようにするか、については様々な方式が考えられる。要は、置換によって、できるだけ多くのＵＲＬができるだけ短い文字列に置換されるように、かつそのように置換された文字列からもとのＵＲＬが間違いなく導出されるように、置換後の文字列を定めればよい。
【００７１】
この第３の実施の形態では、１けたの数字が２けたの数字に置換されるので、部分的には文字列が長くなる場合がありうる。しかし、たとえばよく出現する非常に長い文字列がわずか２けたの数字に置換できるので、全体としては第１の実施の形態および第２の実施の形態と同様にＵＲＬ文字列を短く圧縮することができる。そしてそのように圧縮されたＵＲＬに対してハッシュ計算を行うので、計算量が少なく、かつハッシュメモリの領域が少なくて済み、さらに同一のハッシュコード値の場合の文字列の直接比較も、比較の対象となる文字列自体が短いので高速に行なえるという効果を奏することができる。
【図面の簡単な説明】
【図１】図１は、本願発明の第１の実施の形態にかかる方法を実現するためのＵＲＬ圧縮装置を、周囲の要素と共に示すブロック図である。
【図２】図２は、文字列リスト５０を模式的に示す図である。
【図３】図３は、置換前後のＵＲＬを模式的に示す図である。
【図４】図４は、図５に示すコンピュータの外観図である。
【図５】図５は、本願発明の第１の実施の形態にかかる方法を実現するためのコンピュータのブロック図である。
【図６】図６は、リスト作成処理５６の概略を示すフローチャートである。
【図７】図７は、再計算前の集計表の例を模式的に示す図である。
【図８】図８は、再計算後の集計表の例を模式的に示す図である。
【図９】図９は、ＵＲＬの格納処理のフローチャートである。
【図１０】図１０は、ＵＲＬの検索処理のフローチャートである。
【図１１】図１１は、本願発明の第２の実施の形態にかかる方法で使用される共通文字列置換表を模式的に示す図である。
【図１２】図１２は、本願発明の第２の実施の形態にかかる方法で使用されるユーザ定義文字列置換表を模式的に示す図である。
【図１３】図１３は、第２の実施の形態にかかる方法による文字列置換前後のＵＲＬを模式的に示す図である。
【図１４】図１４は、本願発明の第３の実施の形態にかかる方法で使用されるユーザ定義文字列置換表を模式的に示す図である。
【図１５】図１５は、第３の実施の形態にかかる方法による文字列置換前後のＵＲＬを模式的に示す図である。
【符号の説明】
２０ブラウザ
２２ＵＲＬ圧縮装置
２４キャッシュファイル領域
２６ハッシュメモリ
４６アクセス履歴
５０文字列リスト
５２文字列置換処理
５４ハッシュ計算処理
５６リスト作成処理

Claims

文字の並びの出現頻度に偏りを有する処理対象の文字列に対するハッシュ値の計算装置であって、
前記計算装置はＣＰＵとメモリとを含み、
１つ以上の特定の文字列それぞれを、より短い長さの変換後文字列と一意に対応付けるための機械可読なテーブルを準備する手段と、
前記ＣＰＵを用いて、処理対象文字列中に出現する文字列を、前記テーブルを参照して対応の変換後文字列に変換する手段と、
前記ＣＰＵを用いて、変換後文字列を含む前記処理対象文字列に基づいてハッシュ値を計算する手段とを含み、
前記処理対象文字列に含まれる前記変換後文字列は、前記テーブルの当該変換後文字列に対応付けられている前記特定の文字列を用いて、変換前の前記処理対象文字列中に出現する文字列に復元可能である、文字列に対するハッシュ値の計算装置。
前記テーブルを準備する前記手段は、
過去に出現した処理対象文字列を前記メモリに準備する手段と、
前記過去に出現した処理対象文字列の部分文字列の各々の、出現回数と文字列長とを、前記ＣＰＵを用いて集計する手段と、
前記ＣＰＵを用いて、前記集計された出現回数と文字列長とに基づき、前記過去に出現した処理対象文字列の部分文字列のうち、所定文字に置換したときに前記過去に出現した処理対象文字列を圧縮することが可能な部分文字列を選択し、選択された前記部分文字列を前記特定の文字列として前記テーブルに追加する手段とを含む、請求項１に記載の、文字列に対するハッシュ値の計算装置。
前記テーブルを準備する前記手段は、
前記ＣＰＵを用いて、前記選択された部分文字列の出現回数を減じることにより前記出現回数を再計算し、さらに、前記追加するステップを所定の条件が成立するまで繰返す手段を含む、請求項２に記載の、文字列に対するハッシュ値の計算装置。
変換前の処理対象文字列に使用される文字セットに含まれない文字を、前記変換後文字列の文字として用いることを特徴とする、請求項１から３のいずれかに記載の、文字列に対するハッシュ値の計算装置。
前記テーブルは、複数のユーザに共通に使用される共通テーブルと、
ユーザ毎に使用されるユーザ毎テーブルを含む、請求項１から４のいずれかに記載の、文字列に対するハッシュ値の計算装置。
前記ユーザ毎テーブルの前記変換後文字列には、前記共通テーブルの前記変換後文字列に用いられない文字が含まれる、請求項５に記載の、文字列に対するハッシュ値の計算装置。
前記共通テーブルの前記変換後文字列それぞれは１バイトの異なる文字コードを示し、かつ前記１バイトの異なる文字コードはＡＳＣＩＩコードの所定のコード群のうちのいずれかのコードを示し、
前記ユーザ毎テーブルの前記変換後文字列のそれぞれは複数バイトの異なる文字コードを示し、かつ前記複数バイトのうち先頭の１バイトはＡＳＣＩＩコード中の前記所定のコード群を除いた所定コードを示す、請求項６に記載の、文字列に対するハッシュ値の計算装置。
変換前の前記処理対象文字列は、ＵＲＬを示す文字列である、請求項１から７のいずれかに記載の、文字列に対するハッシュ値の計算装置。
請求項１から８のいずれかに記載の、文字列に対するハッシュ値の計算装置により計算された前記ハッシュ値を用いて情報を管理する情報管理装置であって、
前記処理対象文字列を用いて参照されるファイルを記憶する記憶部と、
ハッシュ領域と、
計算された前記ハッシュ値が指示する前記ハッシュ領域のアドレスに、前記処理対象文字列を用いて参照される前記ファイルの前記記憶部における記憶アドレスと、変換後の前記処理対象文字列とを対応付けて格納する手段とを備える、情報管理装置。
請求項９に記載の、文字列に対するハッシュ値の計算装置により計算された前記ハッシュ値に従う前記ハッシュ領域のアドレスをアクセスし、当該アドレスに格納された前記変換後の処理対象文字列と対応付けて格納された前記記憶アドレスを読出す手段と、
前記読出された前記記憶アドレスに基づき前記記憶部を検索する手段とをさらに備える、請求項９に記載の情報管理装置。
文字の並びの出現頻度に偏りを有する処理対象の文字列に対するハッシュ値を、ＣＰＵとメモリを備えるコンピュータを用いて計算する方法を実現するプログラムを記録した機械可読な記録媒体であって、前記プログラムは、
１つ以上の特定の文字列それぞれを、より短い長さの変換後文字列と一意に対応付けるための機械可読なテーブルを準備するステップと、
前記ＣＰＵを用いて、処理対象文字列中に出現する文字列を、前記テーブルを参照して対応の変換後文字列に変換するステップと、
前記ＣＰＵを用いて、変換後文字列を含む前記処理対象文字列に基づいてハッシュ値を計算するステップとを含み、
前記処理対象文字列に含まれる前記変換後文字列は、前記テーブルの当該変換後文字列に対応付けられている前記特定の文字列を用いて、変換前の前記処理対象文字列中に出現する文字列に復元可能である、文字列に対するハッシュ値の計算方法を実現するプログラムを記録した機械可読な記録媒体。
前記テーブルを準備する前記ステップは、
過去に出現した処理対象文字列を前記メモリに準備するステップと、
前記過去に出現した処理対象文字列の部分文字列の各々の、出現回数と文字列長とを、前記ＣＰＵを用いて集計するステップと、
前記ＣＰＵを用いて、前記集計された出現回数と文字列長とに基づき、前記過去に出現した処理対象文字列の部分文字列のうち、所定文字に置換したときに前記過去に出現した処理対象文字列を圧縮することが可能な部分文字列を選択し、選択された前記部分文字列を前記特定の文字列として前記テーブルに追加するステップとを含む、請求項１１に記載の、文字列に対するハッシュ値の計算方法を実現するプログラムを記録した機械可読な記録媒体。
文字の並びの出現頻度に偏りを有する処理対象の文字列に対するハッシュ値を、ＣＰＵとメモリを備えるコンピュータを用いて計算する方法であって、
１つ以上の特定の文字列それぞれを、より短い長さの変換後文字列と一意に対応付けるための機械可読なテーブルを準備するステップと、
前記ＣＰＵを用いて、処理対象文字列中に出現する文字列を、前記テーブルを参照して対応の変換後文字列に変換するステップと、
前記ＣＰＵを用いて、変換後文字列を含む前記処理対象文字列に基づいてハッシュ値を計算するステップとを含み、
前記処理対象文字列に含まれる前記変換後文字列は、前記テーブルの当該変換後文字列に対応付けられている前記特定の文字列を用いて、変換前の前記処理対象文字列中に出現する文字列に復元可能である、文字列に対するハッシュ値の計算方法。
前記テーブルを準備するステップは、
過去に出現した処理対象文字列を前記メモリに準備するステップと、
前記ＣＰＵを用いて、前記過去に出現した処理対象文字列の部分文字列の各々の、出現回数と文字列長とを、集計するステップと、
前記ＣＰＵを用いて、前記集計された出現回数と文字列長とに基づき、前記過去に出現した処理対象文字列の部分文字列のうち、所定文字に置換したときに前記過去に出現した処理対象文字列を圧縮することが可能な部分文字列を選択し、選択された前記部分文字列を前記特定の文字列として前記テーブルに追加するステップとを含む、請求項１３に記載の、文字列に対するハッシュ値の計算方法。