(57)【要約】【課題】  複数のファイルを単一ファイに格納した書庫ファイルにおいて、特定ファイルの情報更新を可能にするファイル構造のファイルを提供することを目的とする。【解決手段】  複数の更新不可情報ファイル１１に属するデータブロック１３と、複数の更新可能情報ファイル１２に属するデータブロック１３をそれぞれ分けて格納することで、更新可能な更新可能情報ファイル１２を更新した場合に、更新不可ファイル情報１１を再度書庫ファイルに書き込む必要が無い。また更新可能ファイル情報と更新不可ファイル情報とを領域を区別して保持しておくことで、高速に更新可能ファイル情報を更新することができので、短時間で書庫ファイルを更新することができる。さらに、更新不可ファイル情報を書き換える必要が無いので、不要な書き換えに伴うファイルの誤書き込みや、使用中のプログラムファイルの書き込みを行わずに済む。【選択図】      図６
2006004230.tif 000002
【特許請求の範囲】
【請求項１】
複数のファイル情報を規定の書式に基づいて単一ファイルの単一ファイル情報に変換して保持するファイル構造であって、前記単一ファイルの単一ファイル情報のうち、更新可能とされる更新可能ファイル情報と更新不可とされる更新不可ファイル情報とを区別して保持することを特徴とするファイル構造。
【請求項２】
前記更新可能ファイル情報と前記更新不可ファイル情報との区別を識別するための識別情報を有することを特徴とする請求項１記載のファイル構造。
【請求項３】
前記識別情報は、前記単一ファイル内に保持されるファイル単位で規定することを特徴とする請求項２のファイル構造。
【請求項４】
複数のファイル情報を規定の書式に基づいて単一ファイル情報に変換することにより単一ファイルを作成するファイル作成装置であって、更新可能とされる更新可能ファイル情報と更新不可とされる更新不可ファイル情報とを識別する識別情報を取得する取得手段と、該取得手段により取得した識別情報に基づいてファイルを作成するファイル作成手段と、を備えていることを特徴とするファイル作成装置。
【請求項５】
前記請求項４に記載のファイル作成装置で作成され、単一ファイル情報が更新可能ファイル情報か、あるいは更新不可ファイル情報かの区別を識別する識別情報を保持している単一ファイルを更新するファイル更新装置であって、単一ファイル内に保持されている識別情報に基づいて前記単一ファイル情報の書き換えを行うファイル情報書換手段を備えることを特徴とするファイル更新装置。
【請求項６】
前記ファイル情報書換手段は、前記単一ファイル内の単一ファイル情報として保持されている一つのプログラムをコンピュータにより解釈して実行することで動作することを特徴とする請求項５に記載のファイル更新装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータにおいて閲覧及び管理が可能なファイルのファイル構造、及びこのようなファイル構造のファイルを作成するファイル作成装置とファイルを更新するファイル更新装置に関するものである。
【背景技術】
【０００２】
現在、多くのコンピュータは、通常オペレーティングシステム（以下、「ＯＳ」という）と呼ばれる基本ソフトウェアによりコンピュータのリソース等を管理して利用者に多くの機能を提供するようにしている。つまり、利用者はＯＳを通してアプリケーションプログラムを動作させて必要な処理を行っており、利用者が利用しているアプリケーションプログラムはＯＳを通して始めてコンピュータを構成しているリソースを利用することができる。
またコンピュータを構成するハードウェアが情報処理を行う場合は大きく分けて二つのデジタル情報を取り扱う。その一つが情報であるデータであり、もう一つがそのデータを処理するためにコマンドを解釈して実行されるプログラムである。これらのデジタル情報は、通常ファイルと言う形式で記憶媒体上に管理される。つまり、一般的なコンピュータが情報処理を行う場合、ＯＳを通じて記憶媒体に保持されているファイルを読込み処理し、その結果を記憶媒体に記録する。またＯＳ自身も複数のファイルから構成されている。
このように記録媒体上には多数のファイルが保持されており、これらのファイルを効率的に扱えるようにＯＳは、ファイル管理システムを備えている。また前述のように複数のファイルが記憶媒体に保持されているので、通常、これらのファイルを階層構造に分類管理できるディレクトリ構造を現在のファイルシステムは備えている。
【０００３】
しかしながら、このディレクトリ構造は、コンピュータのＯＳのファイル管理システムにより管理されているので、複数のファイルを他のコンピュータに伝達する場合は、記憶媒体ごと配布する必要がある。
これに対して、複数のファイルを単一ファイルに格納する方式も一般的になっており、書庫ファイルまたはデータ圧縮機能を備えることから圧縮ファイルと呼ばれるファイルが一般的になっている。代表的なものとしてはＺＩＰファイルが知られている。
これらの書庫ファイルは、複数のファイルの情報を規定のフォーマットでつなぎあわせる圧縮作業により作成され、逆に規定のフォーマットでつなぎ合わされた圧縮ファイルを元の複数のファイルの情報に分解する解凍作業によって復元される。
このような圧縮ファイル形式はメール等によるネットワークを通じたファイル配信などに現在多用されている。またこのような書庫ファイルについて幾つかの提案がなされている。
まず書庫ファイルのファイルサイズを最適にするものとして特許文献１がある。これは複数のファイルを書庫ファイル化する場合に、最適な組み合わせにすることで、圧縮率の向上を図るようにしたものである。
また特許文献２では、ファイル管理システムに書庫ファイルを応用し、削除対象になるものを書庫ファイル化するものが提案されている。
特許文献３は、複数のファイルを書庫ファイルとして格納し、書庫ファイルのサイズに応じて書庫ファイルを分割するものであり、特許文献４は使用頻度に応じて圧縮を行わないものである。また特許文献５は圧縮データをレコード単位に保持するものである。
これらの特許文献１〜５に対して、本願出願人は特許文献６において複数のコンテンツ情報とそれを表示動作させる動作プログラムをカプセル化手段でカプセル化するものを提案している。これは複数のファイルを単一のファイルにし、その中の動作プログラムで動作させるようにしたものである。
【特許文献１】特開２０００−０７６１０２公報
【特許文献２】特開平０９−０３４７５５号公報
【特許文献３】特開２００１−０５６７７５公報
【特許文献４】特開平０７−３１９７４３号公報
【特許文献５】特開平０８−３１４６８９号公報
【特許文献６】特開２００３−０１５９４１公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
以上のように、現在複数のファイルを単一ファイルとして扱う書庫ファイルが一般化している。この書庫ファイルは当初ファイルの圧縮を目的としたテンポラリなファイルで、実際に利用する段階では圧縮された情報を全て解凍し、解凍されたファイルを利用するように成っている。このように圧縮ファイルは一部のファイルを更新する場合は、全てのファイルを解凍後、再圧縮する必要があるため、更新作業に時間がかかるという問題がある。なお、このような書庫（圧縮）ファイルにより保持されることになるファイルには、付加情報としてファイルの作成日時、更新日時、読込み許可情報等などが記録されている。
これに対して、マルチプラットフォームのプログラミング言語として知られているＪａｖａ（登録商標）においては、この書庫ファイルを使って動作プログラムであるクラスファイルと言う複数の中間言語コードを保持したファイルを格納する方式が提案されている。
この場合は指定の書庫ファイル内のディレクトリ定義情報からクラスファイル位置を検出し、検出した位置から直接クラスファイルを読み出すことを行っている。つまり、書庫ファイルを全て解凍せずに必要な情報があるファイル情報のみを読み出すことができる。
しかしながら、このような方式はファイル毎に情報を読み出すことは可能であるが特定のファイル情報を更新することはできないものであった。
そこで、本発明はこのような点を鑑みてなされたものであり、複数のファイルを単一ファイルに格納した書庫ファイルにおいて、更新作業を短時間で行うことができ、且つ、特定のファイルごとに更新することができるファイル構造と、そのような構造のファイルを作成することができるファイル作成装置と、ファイル更新装置を提供することを目的とする。
【課題を解決するための手段】
【０００５】
上記目的を達成するため、請求項１記載のファイル構造の発明は、複数のファイル情報を規定の書式に基づいて単一ファイルの単一ファイル情報に変換して保持するファイル構造であって、前記単一ファイルの単一ファイル情報のうち、更新可能とされる更新可能ファイル情報と更新不可とされる更新不可ファイル情報とを区別して保持することを特徴とする。
また請求項２記載のファイル構造の発明は、前記更新可能ファイル情報と前記更新不可ファイル情報との区別を識別するための識別情報を有することを特徴とする。
また請求項３記載のファイル構造の発明は、前記識別情報は、前記単一ファイル内に保持されるファイル単位で規定することを特徴とする。
また請求項４記載のファイル作成装置の発明は、複数のファイル情報を規定の書式に基づいて単一ファイル情報に変換することにより単一ファイルを作成するファイル作成装置であって、更新可能とされる更新可能ファイル情報と更新不可とされる更新不可ファイル情報とを識別する識別情報を取得する取得手段と、該取得手段により取得した識別情報に基づいてファイルを作成するファイル作成手段と、を備えていることを特徴とする。
また請求項５記載のファイル更新装置の発明は、前記請求項４に記載のファイル作成装置で作成され、単一ファイル情報が更新可能ファイル情報か、あるいは更新不可ファイル情報かの区別を識別する識別情報を保持している単一ファイルを更新するファイル更新装置であって、単一ファイル内に保持されている識別情報に基づいて前記単一ファイル情報の書き換えを行うファイル情報書換手段を備えることを特徴とする。
また請求項６記載のファイル更新装置の発明は、前記ファイル情報書換手段は、前記単一ファイル内の単一ファイル情報として保持されている一つのプログラムをコンピュータにより解釈して実行することで動作することを特徴とする。
【発明の効果】
【０００６】
請求項１記載のファイル構造の発明によれば、複数のファイル情報を規定の書式に基づいて単一のファイル情報として変換して保持するファイル構造において、単一ファイル情報に変換後に更新可能とされる更新可能ファイル情報と、更新不可とされる更新不可ファイル情報とを区別して保持することで、更新可能ファイル情報を更新した場合に、更新不可ファイル情報を再度書庫ファイルに書き込む必要が無い。また更新可能ファイル情報と更新不可ファイル情報とを領域を区別して保持しておくことで、高速に更新可能ファイル情報を更新することができるので、短時間で書庫ファイルを更新することができる。
さらに更新不可ファイル情報を書き換える必要が無いので、不要な書き換えに伴うファイルの誤書き込みや、使用中のプログラムファイルの書き込みを行わずに済むという利点もある。
請求項２記載のファイル構造の発明によれば、前記更新可能ファイル情報と前記更新不可ファイル情報とを区別して識別するための識別情報を有することで、確実に更新可能ファイル情報と更新不可ファイル情報を区別できる。
請求項３記載のファイル構造の発明によれば、識別情報は、例えば単一ファイルにカプセル化されるファイル単位に規定することで、柔軟に識別情報が設定できるので、柔軟にファイルを区別することができる。
請求項４記載のファイル作成装置の発明によれば、更新可能とされる更新可能ファイル情報と、更新不可とされる更新不可ファイル情報とを識別する識別情報を取得する取得手段と、該取得手段により取得した識別情報に基づいてファイルを作成するファイル作成手段とを備えていることで、ユーザがわざわざファイルを識別する必要が無く、自動的に識別情報を生成したり、区別領域を設定したりすることができる。
請求項５記載のファイル更新装置の発明によれば、前記識別情報に基づいて、前記ファイル情報の書き換えを行うファイル情報書換手段を備えているので書庫ファイルを更新するときに識別情報に基づいて更新することができる。
請求項６記載のファイル更新装置の発明によれば、ファイル情報書換手段は前記ファイル構造の単一ファイル内の複数のファイル一つのプログラムファイルをコンピュータで実行することで高速に自己更新のできる書庫ファイルを実現できる。
【発明を実施するための最良の形態】
【０００７】
以下、本発明の実施の形態について説明するにあたって、まず一般的に広く利用されている書庫（圧縮）ファイル形式であるＺＩＰファイルに付いて説明しておく。
一般的なＺＩＰファイルは、複数のファイルの情報を圧縮し、単一ファイルに複合するマルチファイル書庫形式で、通常ファイルの種類を表す拡張子はＺＩＰとされる。
図１はＺＩＰファイルのデータ構造（フォーマット）を模式的に示した図である。
ＬＯＣ（Local file header）ヘッダと呼ばれるヘッダ情報１０１、それに続く圧縮データ（Compressed Data）１０２、省略可能なＥｘｔ（Extended local header）ヘッダ１０３から構成される各ファイルの圧縮データブロック１００、１００と、各圧縮データブロック１００の圧縮データ１０２に対応するＣｅｎ（Central directory）ヘッダ１０４と、Ｅｎｄ（End of Central directory）ヘッダ１０５とから構成される。
つまり、例えば３個のファイルをＺＩＰ形式で単一ファイル化した場合は、それぞれＬＯＣヘッダ１０１で始まる３個の圧縮データブロック１００と、それに続いて３個のＣｅｎヘッダ１０４と、１つのＥｎｄヘッダ１０５とから構成されることになる。
図２は、各ヘッダの構造を模式的に示した図であり、各ヘッダ１０６は、ヘッダであることを表す４Ｂｙｔｅのシグネチャ（Signature）で始まり、このシグネチャを検出することで、各ヘッダ１０６を検出することができる。なお、各シグネチャは、ＺＩＰの開発由来からＰＫのアスキーコードで始まる。
図１に示すようなＺＩＰ形式のファイルは、基本的には圧縮データブロック１００をファイルの最初から規定の解凍方法で解凍していくことで圧縮前の情報を復元できるが、Ｅｎｄヘッダ１０５の情報と対応するＣｅｎヘッダ１０４の情報から圧縮ファイル内の格納ファイルの名前と格納位置を検出することができるので、Ｅｎｄヘッダ１０５の情報とＣｅｎヘッダ１０４の情報から任意の格納されている情報を解凍することができる。つまり、ＺＩＰ形式は、図３のような複数の圧縮データブロック１００と、そのファイルの位置を決定するディレクトリデータ１１０とから構成されていることになる。
このように特定のファイルのみを解凍（復号）する場合には書庫ファイル内からシグネチャ１０６を元にＥｎｄヘッダ１０５を特定し、Ｅｎｄヘッダ１０５の情報からＣｅｎヘッダ１０４を特定し、対応する圧縮データブロック１００を特定する必要がある。
この場合、図４のように圧縮データブロック１００ファイルの先頭にディレクトリデータ１１０を記述し、ディレクトリデータ１１０から対応する圧縮データブロック１００を特定する方式のほうが、特定のファイルのみ解凍（復号）する場合には都合が良い。
【０００８】
しかしながら、通常、複数のファイルを単一ファイルに格納する場合は、それぞれのファイルは圧縮してみないと圧縮後のファイルのサイズが特定できない。
また、最終的に幾つのファイルを圧縮するかが決定していないとブロックの個数が決定できない。このような圧縮（符号化）時の制約から、現在はＺＩＰ形式の方法が用いられている。これまでの説明では、ＺＩＰ形式において、Ｅｎｄヘッダ１０５、Ｃｅｎヘッダ１０４から特定のファイルのみを解凍（復号）できることに付いて述べたが、現在の多くの圧縮ファイル形式は、圧縮時の都合を元にフォーマットが決定されている。このため、解凍（復号）時には不便なものであり、特定のファイルのみ更新することをサポートしていない。
なぜならば、例えば３個のファイルからなる書庫ファイルの場合に、２番目のファイルの情報を異なる情報に変更した場合は、符号化前のファイルサイズが同じでも符号化後の圧縮情報は異なってしまう。これは、通常の圧縮方式では、連続するコードパターンを他のコードに置き換えるため、符号化されるコードのサイズが同じでもコードのパターンが異なると符号化コードのサイズは異なることによるものとされる。このため、３番目以降のファイルは２番目のサイズの増減で格納位置が変更されることになるという不具合がある。
そこで、本発明の実施の形態に係る書庫ファイルでは、書庫ファイルに格納した後、更新される更新可能情報を保持する更新可能情報ファイルと更新されない更新不可情報を保持する更新不可情報ファイルとを区別して保持するようにしている。
【０００９】
図５は、本実施の形態に係る書庫ファイルのデータ構造の一例を示した図である。
図５に示すように、複数の更新不可情報ファイル１１に属するデータブロック１３と、複数の更新可能情報ファイル１２に属するデータブロック１３をそれぞれ分けて格納するものである。また、更新不可情報ファイル１１と更新可能情報ファイル１２をＺＩＰ形式のようなディレクトリデータを有するものに適用した場合は、図６、図７に示すようになる。
図６に示す場合、書庫ファイル２１は、更新されない情報の集まりである更新不可情報データブロック群２２の情報の更新が行われないので、更新不可情報データブロック群２２のサイズは変化することなく、且つ、データの内容も変化しない。一方、更新される可能性のある更新可能情報データブロック群２３は情報が更新されるのでサイズやデータの内容が変わることになる。
そこで、図６に示すような構造の書庫ファイル２１において情報を更新する場合は、更新不可情報の末尾以下を書き換えることで不要なファイル操作が不要である。
具体的には、図８に示すように、読込み処理装置側において、更新可能情報データブロック群２３の更新可能情報２６の更新作業を行って、更新可能情報データブロック群２８を作成すると共に、更新後、書庫ファイル２１のディレクトリデータ２４から再度ディレクトリデータ２７を作成し、更新不可情報データブロック群２２の末尾より新たな更新可能情報２６とディレクトリデータ２７を上書きすればよい。これにより更新された新たな書庫ファイル２９が得られることになる。このようにすれば、更新時には書庫ファイル２１内の更新不可情報データブロック群２２に対するファイルアクセスが不要になる。
【００１０】
また図７に示す書庫ファイル２５の場合は、図示しないが、処理側で更新可能情報を更新後、新たな書庫ファイルを作成し、更新可能情報データブロック群の末尾から元の更新不可情報データブロック群をコピーした後、同様にディレクトリデータ１８を付加すれば良い。このようにすれば、更新不可情報データブロック群をコピーする必要は有るが、ファイル容量を削減するためのファイルの解凍（復号化）、ファイルの圧縮（符号化）が不要になるという利点がある。また、後述するように、このような書庫ファイルをカプセル化文書等に応用した場合は、殆どの情報が更新不可情報なので、高速にファイルを更新できる。
ここまでは、更新可能な更新可能情報と更新できない更新不可情報を区別して書庫ファイル化することに付いて述べたが、ここで更新可能な更新可能情報と更新できない更新不可情報の領域を何らかの方法で書庫ファイル内に記述する必要がある。
具体的な方法として幾つか考えられる。一つの方法としては、圧縮データブロック毎に更新不可を表す情報と、更新可能を表す情報を記述することが考えられる。
例えば、ＺＩＰ形式の場合は、図１に示したＬＯＣヘッダ１０１内のExtra Fieldに記述すればよい。また更新不可情報は圧縮し、更新可能情報は頻繁に更新され、サイズも小さいので非圧縮で保存し、この圧縮、非圧縮の違いで判別しても良い。また圧縮ブロックに対応するＣｅｎヘッダ１０４にそれぞれ記述しても良い。
また単に書庫ファイルを二分するだけの情報なのでＥｎｄヘッダ１０５のコメントを保持するComment Fieldに記述しても良い。
また、書庫ファイルとして保持されるファイルの一つに、図９のように更新可能ファイル、更新不可ファイルを識別する識別情報を記述しても良い。
【００１１】
また、ここまでは単に更新されるものと更新されないものの二つに区別することに付いて説明したが、これはあくまでも一例であり、より詳細には更新されないファイル、削除される可能性のあるファイル、部分的に更新される可能性のあるファイルの３つに分類して図１０のように格納しても良い。
この場合は更新されないファイルの集まりである更新不可情報データブロック群３１の圧縮後の総サイズは変化しない。また削除される可能性があるファイルの集まりである削除可能情報データブロック群３２は削除されるファイルに応じてブロック群の総サイズは変化するが、各データブロックのサイズは変化しない。また部分的に更新される可能性のあるファイルの集まりである部分変更可能情報データブロック群３３は更新された情報のデータブロックのみ変化する。以上から、この書庫ファイルに格納されている削除可能ファイルの一つと部分更新可能ファイルの一つが更新された場合には更新不可情報データブロック群は変更が無いので、更新不可情報データブロック群３１の末尾からファイルを更新すればよい。
そこで、まず更新不可情報データブロック群３１の末尾から削除されていない削除可能情報データブロック群３２から順番に上書きする。この場合に削除可能情報は、格納ファイル単位に削除されるので、削除可能情報データブロック群３２を解凍、再圧縮する必要はなく、単にデータブロックをコピーすればよい。次に部分更新情報データブロック群３３の部分更新可能情報に付いては、更新されていないデータブロックは単にデータブロックをコピーすればよく、部分的に更新されているファイル情報は再度圧縮してデータブロックを作成すればよい。
【００１２】
次に、このような更新不可情報、削除可能情報、部分更新情報の区別に付いて述べる。
前述のように予め書庫ファイルを作成時点で格納するファイルの格納区別を個別に指定して区別する方式もあるが、ファイルの種類に基づいて自動的に行っても良い。例えば通常格納されるファイルには、拡張子が付加されている。そこで、この拡張子に基づいて、ファイルの格納区別をつけても良い。
例えば、＊＊．ＤＬＬ、＊＊．ＣＬＡＳＳ等のプログラムコードを表す拡張子を持つファイルはプログラムコードなので更新不可情報データブロック群３１のデータとして保持し、＊＊．ＪＰＥＧ等の画像、動画等のコンテンツを表すファイルは削除可能情報データブロック群３２のデータとして保持し、＊＊．ＤＡＴ等はデータを表すので部分更新可能情報データブロック群３３に保持するようにしても良い。
この場合、なるべくサイズの大きなファイルは、図１０に示す例では、ファイルの先頭側に配置するようにしても良い。
また、ファイルに通常付加される属性情報を利用しても良い。例えば読込みのみ許可で書き込み不可のリードオンリーファイルは、更新不可データブロック、読み書き可の属性のあるファイルは更新可能データブロックに保持するようにしても良い。
また上記のように予めファイルをデータブロックとして格納する位置を規定する以外に更新度合いに応じ順序を入れ替えても良い。例えば、頻繁に更新されるファイルは末尾に更新が殆どされない場合は、先頭側に格納するようにしても良い。
また、上記したような本実施の形態の書庫ファイルを作成するファイル作成装置は、図示しないがコンピュータなどのＣＰＵが、メモリなどに格納されている所定のファイル作成プログラムを実行することにより実現することができる。
例えば、複数にファイル情報をＺＩＰ形式などの単一ファイル情報に変換する。そして、変換した単一ファイル情報が更新可能とされる更新可能ファイル情報か、あるいは更新不可とされる更新不可ファイル情報であるかを区別するために、上記したような拡張子などの情報を取得し、取得した識別情報に基づいて単一ファイルを作成すればよい。
【００１３】
次に実際に書庫ファイルを利用した例を本出願人が提案しているカプセル化文書形式を基に文書の作成から更新に付いて再度説明する。
図１１は、カプセル化文書形式のカプセル化文書である。
まずカプセル化文書の全体の文書を定義する文書定義ファイル４１と文書の内容を表すコンテンツファイル４３と、そのコンテンツファイル４３を表示動作させるプログラムファイル４２がある。
図１２は、上記したカプセル化文書を作成、編集（更新）するファイル作成編集（更新）装置の構成を示した図である。図１２に示すように、ファイル作成編集装置５１は、文書の作成及び編集を行う作成、編集手段５２とプログラムファイル５３とから構成される。
この場合、作成者はファイル作成編集装置（編集アプリケーション）５１から提供されるＧＵＩ（グラフィカルユーザインターフェース）を使って文書を作成する。この時、必要に応じたコンテンツの情報５４を外部から文書に挿入しても良い。このような編集作業によって作成されたコンテンツ情報と文書全体に関わる情報を、それぞれコンテンツファイル、文書定義ファイルに変換すると共に、カプセル化するプログラムファイルをファイル作成編集装置５１内のプログラムファイル５３から選択し、カプセル化文書５５にカプセル化する。
ここで、カプセル化する手段は幾つか考えられるが、本発明のように書庫ファイル形式で、上記複数のファイルをカプセル化してカプセル化文書５５を作成するようにしても良い。このように複数のファイルをカプセル化したカプセル化文書５５を配布した場合には、文書内容を表示動作させるプログラムが共にカプセル化されているので、配布先では、閲覧のためのアプリケーションが不要とされるので、閲覧環境を選ばないという利点がある。
【００１４】
次に、このようなカプセル化文書に閲覧者が注釈等の加筆を行う場合は、加筆情報等をカプセル化文書に保持させる必要がある。このような情報は頻繁に更新される可能性が高いので、その場合は更新情報ファイルとして別個に保持することが望ましい。
図１３は、そのような場合に好適なカプセル化文書のデータ構造を模式的に示した図である。
この場合は、まずカプセル化文書の全体の文書を定義する文書定義ファイル４１と文書の内容を表すコンテンツファイル４３とそのコンテンツファイル４３を表示動作させるプログラムファイル４２とは別に更新情報ファイル４４を設けるようにしている。
このような構成のカプセル化ファイルを本発明で説明してきた書庫ファイル等に適用した場合は、図１４に示すようなデータブロックで情報が書庫ファイル内に保持される。つまり、文書定義ファイルデータブロック６１、プログラムファイルデータブロック６２、コンテンツファイルデータブロック６３、更新情報ファイル６４、ディレクトリデータ６５とから構成される。
具体的には、例えば図１２に示したようなファイル作成編集装置５１を利用して、図１５に示すような文書７１を作成し、作成した文書をカプセル化文書として配布する。そして、例えばファイル作成編集装置５１などを利用して閲覧者が閲覧し、閲覧時に例えば図１５に示す文書７１に対して、図１６に示すような画像７３を加筆して文書７２に変更したとする。
【００１５】
図１７は、ファイル作成編集装置５１においてカプセル化文書に加筆を行う場合の基本的な処理を示したフローチャートである。この場合の処理は、図１７のように示され、カプセル化文書閲覧（Ｓ１）、カプセル化文書に加筆（Ｓ２）、加筆情報の保存（Ｓ３）の順で処理を実行することで加筆情報の付加が行われる。
図１８は、ファイル作成編集装置５１においてカプセル化文書に加筆を行う場合の具体的な処理を示したフローチャートである。
まず、カプセル化文書を閲覧する場合には、カプセル化文書を起動するカプセル化文書起動プログラムを起動し（Ｓ１１）、カプセル化文書内の動作プログラムの一つである文書内容を表示するための文書内容表示プログラムを起動する（Ｓ１２）。これにより、コンピュータなどの画面上に、図１５に示すような文書画像、すなわちカプセル化文書内のコンテンツファイルに保持された情報を表示させる。次に、ユーザのマウス等による加筆入力を取得する加筆情報取得プログラムを起動し（Ｓ１３）、ユーザがマウス等のＧＵＩ手段を利用して加筆入力した情報を取得できるようにする。なお、これらの動作プログラムの詳細は、本発明の本旨とは関係が無いので、特に詳しくは述べないが、本出願人が先に提案した特開２００３−９９４２４公報に記載の例を適用しても良い。
次に、ユーザの入力した加筆情報を取得してメモリ上に保持する（Ｓ１４）、この後、保持された加筆情報を重層表示する（Ｓ１５）すなわち、前記文書内容表示プログラムで図１５に示すように表示された文書７１に対して、図１６に示すような画像７３を重層表示する。
【００１６】
次に、加筆情報を保存するか判断する（Ｓ１６）。これについては、通常ユーザが保存指示を行ったかどうかを検出する。ステップＳ１４において加筆情報を保存しないと判断した場合（Ｓ１６で「Ｎ」）は、ステップＳ１４からの加筆情報の取得、保持、表示処理を繰り返すようにする。
一方、ユーザから加筆情報を保存する指示があったと判断した場合は（Ｓ１６で「Ｙ」）、加筆情報をカプセル化ファイル内に保存するための加筆情報ファイル名を取得する（Ｓ１７）。この加筆情報ファイル名は予め文書定義ファイル内に記述しておいても良いし、加筆情報の保存を司るプログラム内に埋め込んでおいても良い。
次に、カプセル化文書ファイルのディレクトリデータを読込み（Ｓ１８）、更新可能情報領域の位置を取得し（Ｓ１９）、更新情報（加筆情報）のファイルを書き込むようにする（Ｓ２０）。
このカプセル化文書ファイルに対して始めて加筆情報を保存する場合は、更新情報をカプセル化文書内に保持していないので、最後のデータブロック以降に更新情報（加筆情報）のファイルを書き込むようにする（Ｓ２０）。
例えばカプセル化文書ファイルが始めて加筆情報を保存する場合、カプセル化文書ファイルのデータ構造は、図１９に示すように更新情報データブロックを保持していないので、この場合は、図２０に示すように最後のデータブロック以降に更新情報を保持する更新情報（加筆情報）データブロック６４を追加して、このデータブロック６４に加筆情報の内容をこの部分に書き込むようにする。具体的には、例えば、図２２に示すように、ＬＯＣヘッダ１０１、圧縮データ１０２、Ｅｘｔヘッダ１０３から構成される更新情報データブロック６４を付加する。
【００１７】
次に、上記により新たに更新情報データブロック６４が追加、更新されたので、先に読込まれたディレクトリデータを再作成し（Ｓ２１）、ディレクトリデータをカプセル化文書ファイルに追加する（Ｓ２２）。つまり、図２０に示すようなカプセル化文書ファイルに対してディレクトリデータ６５を追加して、図２１に示すようなカプセル化文書ファイルに更新する。具体的には、例えば図２３に示すように、対応するCen Header８１を付加した新たなCen Header群８０と更新したEnd Header８２を付加すればよい。
ここまでの例は更新情報ファイルを更新情報が生成された時点で付加するように述べたが、予めデフォルトの更新情報データブロックを文書作成時に付加しておき、更新情報が生成された場合は、この更新情報ブロックとそれに対応するディレクトリデータを更新するようにしても良い。この場合更新情報データブロックのサイズが変わるので、更新情報データブロックとディレクトリデータは再書き込みが必要であるが、図２３のCen Header８１とEnd Header８２のサイズが同じなのでディレクトリデータ６５の作成が容易になるという利点がある。
また、図１８の点線部を説明した加筆情報等の更新情報をカプセル化文書に付加するプログラムをカプセル化文書内の動作プログラムの一つとして備えることで、このようなカプセル化文書はカプセル化文書のみで閲覧表示、加筆取得、加筆情報保存が行えるので、このカプセル化文書のみで閲覧、更新の機能を有することができる。
また、ここまではカプセル化文書に限定して説明して来たがこれらの更新機能を持つプログラムを通常の書庫ファイル内に保持させるようにしても良い。
このように構成することで現在、書庫ファイル内に自己解凍機能を有するものがあるが、このように更新領域を区別することで簡単に自己更新を行うことのできる書庫ファイルを構成することができるようになる。
【図面の簡単な説明】
【００１８】
【図１】ＺＩＰ形式のデータ構造を模式的に示した図。
【図２】各ヘッダの構造を模式的に示した図。
【図３】ＺＩＰ形式のデータ構造を模式的に示した図。
【図４】他の圧縮ファイル形式のデータ構造を模式的に示した図。
【図５】本実施の形態に係る書庫ファイルのデータ構造の一例を示した図。
【図６】本実施の形態の書庫ファイルをＺＩＰ形式のディレクトリデータを有するものに適用した場合のデータ構造を示した図。
【図７】本実施の形態の書庫ファイルをＺＩＰ形式のディレクトリデータを有するものに適用した場合のデータ構造を示した図。
【図８】本実施の形態に係る書庫ファイルを更新するときの更新処理を示した図。
【図９】更新可能ファイルと更新不可ファイルを識別する識別情報の一例を示した図。
【図１０】本実施の形態に係る書庫ファイルの他のデータ構造例を示した図。
【図１１】カプセル化文書形式のカプセル化文書。
【図１２】ファイル作成編集装置の構成を示した図。
【図１３】カプセル化文書形式のデータ構造を模式的に示した図。
【図１４】本実施の形態とされる書庫ファイルにカプセル化文書を適用した場合のデータ構造を模式的に示した図。
【図１５】作成した文書の表示例を示した図。
【図１６】図１５に示した文書に加筆した文書の表示例を示した図。
【図１７】カプセル化文書に加筆を行う場合の基本的な処理を示したフローチャート。
【図１８】カプセル化文書に加筆を行う場合の具体的な処理を示したフローチャート。
【図１９】更新前におけるカプセル化文書のデータ構造の一例を示した図。
【図２０】更新後におけるカプセル化文書のデータ構造の一例を示した図。
【図２１】更新完了後におけるカプセル化文書のデータ構造の一例を示した図。
【図２２】更新情報データブロックのデータ構造の一例を示した図。
【図２３】Ｃｅｎヘッダのデータ構造の一例を模式的に示した図。
【符号の説明】
【００１９】
１１  更新不可情報ファイル、１２  更新可能情報ファイル、２１  書庫ファイル、２２  ３１  更新不可情報データブロック群、２３  ２８  更新可能情報データブロック群、２４  ２７  ３４  ６５  ディレクトリデータ、２６  更新可能情報、３２  削除可能情報データブロック群、３３  部分更新可能情報データブロック群、４１  文書定義ファイル、４２  ５３  プログラムファイル、４３  コンテンツファイル、５１  ファイル作成編集装置、５２  作成、編集手段、５４  コンテンツ情報、５５  カプセル化文書、６１  文書定義ファイルデータブロック、６２  プログラムファイルデータブロック、６３  コンテンツファイルデータブロック、６４  更新情報ファイル（データブロック）、７１  文書、８０  Cen Header群、８１  Cen Header、８２  End Header
【図１】
2006004230.tif 000003
【図２】
2006004230.tif 000004
【図３】
2006004230.tif 000005
【図４】
2006004230.tif 000006
【図５】
2006004230.tif 000007
【図６】
2006004230.tif 000008
【図７】
2006004230.tif 000009
【図８】
2006004230.tif 000010
【図９】
2006004230.tif 000011
【図１０】
2006004230.tif 000012
【図１１】
2006004230.tif 000013
【図１２】
2006004230.tif 000014
【図１３】
2006004230.tif 000015
【図１４】
2006004230.tif 000016
【図１５】
2006004230.tif 000017
【図１６】
2006004230.tif 000018
【図１７】
2006004230.tif 000019
【図１８】
2006004230.tif 000020
【図１９】
2006004230.tif 000021
【図２０】
2006004230.tif 000022
【図２１】
2006004230.tif 000023
【図２２】
2006004230.tif 000024
【図２３】
2006004230.tif 000025