JP2006004230A - File structure, file preparing system and file update system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide the file of file structure for updating the information of a specific file in a library file in which a plurality of files are stored in a single file. <P>SOLUTION: A data block 13 belonging to a plurality of unupdatable information file 11 and a data block 13 belonging to a plurality of unupdatable information file 12 are separately stored so that when the updatable information file 12 is updated, it is not necessary to write the unupdatable file information 11 in a library file again. Also, the updatable file information and the unupdatable file information are stored in separate areas so that it is possible to quickly update the updatable file information, and to quickly update the library file. Furthermore, it is not necessary to rewrite the unupdatable file information, and it is possible to dispense with the erroneous writing of the file due to any unnecessary rewriting or the writing of any program file in use. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a file structure of a file that can be viewed and managed in a computer, a file creation apparatus that creates a file having such a file structure, and a file update apparatus that updates a file.

Currently, many computers are provided with many functions by managing computer resources and the like by basic software called an operating system (hereinafter referred to as “OS”). That is, the user operates the application program through the OS to perform necessary processing, and the application program used by the user can use the resources constituting the computer for the first time through the OS.
In addition, when the hardware constituting the computer performs information processing, two types of digital information are handled. One is data that is information, and the other is a program that is executed by interpreting a command to process the data. Such digital information is managed on a storage medium in the form of a normal file. That is, when a general computer performs information processing, a file held in the storage medium is read through the OS, and the result is recorded in the storage medium. The OS itself is also composed of a plurality of files.
Thus, a large number of files are held on the recording medium, and the OS includes a file management system so that these files can be handled efficiently. In addition, since a plurality of files are held in the storage medium as described above, the current file system usually has a directory structure in which these files can be classified and managed in a hierarchical structure.

However, since this directory structure is managed by the file management system of the OS of the computer, when transferring a plurality of files to another computer, it is necessary to distribute the entire storage medium.
On the other hand, a method of storing a plurality of files in a single file is also common, and a file called a compressed file is generally used because it has an archive file or a data compression function. A typical example is a ZIP file.
These archive files are created by compression work that combines the information of multiple files in a specified format, and conversely, they are restored by decompression work that decomposes the compressed file connected in a specified format into the information of multiple original files. Is done.
Such a compressed file format is currently widely used for file delivery through a network by e-mail or the like. Several proposals have been made for such archive files.
First, there is Patent Document 1 that optimizes the file size of an archive file. In this case, when a plurality of files are made into an archive file, an optimum combination is used to improve the compression rate.
Patent Document 2 proposes applying an archive file to a file management system to convert an object to be deleted into an archive file.
Patent Document 3 stores a plurality of files as archive files and divides the archive file according to the size of the archive file. Patent Document 4 does not perform compression according to the frequency of use. Patent document 5 holds compressed data in units of records.
In contrast to these Patent Documents 1 to 5, the applicant of the present application has proposed that Patent Document 6 encapsulates a plurality of content information and an operation program for displaying and operating the content information using an encapsulating means. In this method, a plurality of files are converted into a single file and operated by an operation program included therein.
Japanese Patent Laid-Open No. 2000-07062 JP 09-034755 A JP 2001-056775 A JP 07-319743 A Japanese Patent Laid-Open No. 08-314689 JP 2003-015941 A

As described above, archive files that handle a plurality of files as a single file are now common. This archive file is a temporary file for the purpose of compressing the file at the beginning, and when it is actually used, all the compressed information is decompressed and the decompressed file is used. As described above, when a part of the compressed file is updated, it is necessary to re-compress after decompressing all the files. In addition, in a file to be held by such an archive (compressed) file, file creation date / time, update date / time, read permission information, and the like are recorded as additional information.
On the other hand, in Java (registered trademark), which is known as a multi-platform programming language, a method for storing a file holding a plurality of intermediate language codes called a class file, which is an operation program, using this archive file Has been proposed.
In this case, the class file position is detected from the directory definition information in the designated archive file, and the class file is read directly from the detected position. That is, only file information having necessary information can be read without decompressing all the archive files.
However, such a method can read information for each file, but cannot update specific file information.
Therefore, the present invention has been made in view of such a point, and in an archive file in which a plurality of files are stored in a single file, the update operation can be performed in a short time, and for each specific file. It is an object to provide a file structure that can be updated, a file creation device that can create a file having such a structure, and a file update device.

In order to achieve the above object, the invention of a file structure according to claim 1 is a file structure that converts a plurality of file information into single file information of a single file based on a prescribed format, and holds the file information. Of the single file information of a single file, the updatable file information that can be updated and the non-updatable file information that cannot be updated are distinguished and held.
According to a second aspect of the present invention, the file structure has identification information for identifying distinction between the updatable file information and the non-updatable file information.
The invention of a file structure according to claim 3 is characterized in that the identification information is defined in file units held in the single file.
The invention of a file creation device according to claim 4 is a file creation device that creates a single file by converting a plurality of file information into single file information based on a prescribed format, and is made updatable. Acquisition means for acquiring identification information for identifying updatable file information and non-updatable file information to be non-updatable, and file creation means for creating a file based on the identification information acquired by the acquisition means It is characterized by.
Further, the invention of the file updating apparatus according to claim 5 is an identification for identifying whether the single file information is updateable file information or non-updatable file information created by the file creation apparatus according to claim 4. A file updating apparatus for updating a single file holding information, comprising: file information rewriting means for rewriting the single file information based on identification information held in the single file. Features.
The file update apparatus according to claim 6 operates by the file information rewriting means interpreting and executing one program held as single file information in the single file by a computer. It is characterized by that.

According to the invention of the file structure described in claim 1, in the file structure in which a plurality of file information is converted and held as single file information based on a prescribed format, the file structure can be updated after conversion to single file information. Thus, when the updatable file information is updated, it is not necessary to write the updatable file information to the archive file again. In addition, by maintaining the updatable file information and the non-updatable file information by distinguishing the areas, the updatable file information can be updated at high speed, so that the archive file can be updated in a short time.
Furthermore, since there is no need to rewrite non-updatable file information, there is an advantage that it is not necessary to write a file erroneously due to unnecessary rewriting or to write a program file in use.
According to the invention of the file structure of claim 2, the updateable file information and the non-updatable file information are surely provided by including the identification information for distinguishing and distinguishing the updatable file information and the non-updatable file information. Can be distinguished.
According to the invention of the file structure of claim 3, the identification information can be set flexibly by defining the identification information in units of files encapsulated in a single file, for example. Can do.
According to the invention of the file creation device according to claim 4, the acquisition means for acquiring the identification information for identifying the updateable file information that can be updated and the non-updateable file information that cannot be updated, and the acquisition means File creation means for creating a file based on the identification information acquired by the above, so that the user does not have to bother identifying the file and automatically generates identification information or sets a distinction area. can do.
According to the invention of the file updating apparatus according to claim 5, since the file information rewriting means for rewriting the file information is provided based on the identification information, it is updated based on the identification information when the archive file is updated. can do.
According to the invention of the file updating apparatus according to claim 6, the file information rewriting means is a library file that can be self-updated at high speed by executing a program file of a plurality of files in the single file of the file structure on a computer. Can be realized.

In the following description of embodiments of the present invention, a ZIP file, which is a generally used archive (compressed) file format, will be described first.
A general ZIP file is a multi-file archive format in which information of a plurality of files is compressed and combined into a single file, and an extension indicating a normal file type is ZIP.
FIG. 1 is a diagram schematically showing the data structure (format) of a ZIP file.
Compressed data blocks 100 and 100 of each file composed of header information 101 called a LOC (Local file header) header, followed by compressed data 102, and an optional Ext (Extended local header) header 103; A Cen (Central directory) header 104 corresponding to the compressed data 102 of the compressed data block 100 and an End (End of Central directory) header 105 are configured.
That is, for example, when three files are converted into a single file in the ZIP format, three compressed data blocks 100 each starting with a LOC header 101, followed by three Cen headers 104, and one End header 105 It will be composed of.
FIG. 2 is a diagram schematically showing the structure of each header. Each header 106 starts with a 4-byte signature indicating that it is a header, and each header 106 is detected by detecting this signature. Can be detected. Each signature starts with the ASCII code of PK from the development of ZIP.
The ZIP format file as shown in FIG. 1 can basically restore the uncompressed information by decompressing the compressed data block 100 from the beginning of the file using a prescribed decompression method. Since the name and storage position of the storage file in the compressed file can be detected from the corresponding Cen header 104 information, any stored information is decompressed from the End header 105 information and the Cen header 104 information. be able to. That is, the ZIP format is composed of a plurality of compressed data blocks 100 as shown in FIG. 3 and directory data 110 for determining the position of the file.
When decompressing (decoding) only a specific file in this way, the end header 105 is specified from the archive file based on the signature 106, the Cen header 104 is specified from the information of the end header 105, and the corresponding compressed data block 100 need to be specified.
In this case, when the directory data 110 is described at the head of the compressed data block 100 file as shown in FIG. 4 and the corresponding compressed data block 100 is specified from the directory data 110, only a specific file is decompressed (decoded). Is convenient.

However, normally, when storing a plurality of files in a single file, the size of the compressed file cannot be specified unless each file is compressed.
In addition, the number of blocks cannot be determined unless it is determined how many files are finally compressed. Due to such limitations at the time of compression (encoding), the ZIP format method is currently used. In the description so far, it has been described that only a specific file can be decompressed (decoded) from the End header 105 and the Cen header 104 in the ZIP format, but many of the current compressed file formats are based on the convenience of compression. The format has been determined. For this reason, it is inconvenient at the time of decompression (decoding), and updating only specific files is not supported.
This is because, for example, in the case of an archive file consisting of three files, if the information of the second file is changed to different information, the compressed information after encoding will be different even if the file size before encoding is the same. . This is because, in a normal compression method, since a continuous code pattern is replaced with another code, the size of the encoded code is different if the code pattern is different even if the size of the encoded code is the same. . For this reason, the third and subsequent files have a problem that their storage positions are changed by increasing or decreasing the second size.
Therefore, in the archive file according to the embodiment of the present invention, after being stored in the archive file, an updatable information file that holds updatable information that is updated and an updatable information file that holds updatable information that is not updated are separated. I keep it separately.

FIG. 5 is a diagram showing an example of the data structure of the archive file according to the present embodiment.
As shown in FIG. 5, a data block 13 belonging to a plurality of non-updatable information files 11 and a data block 13 belonging to a plurality of updatable information files 12 are stored separately. Further, when the non-updatable information file 11 and the updatable information file 12 are applied to those having directory data such as the ZIP format, they are as shown in FIGS.
In the case shown in FIG. 6, the archive file 21 does not update the information of the non-updatable information data block group 22 that is a collection of information that is not updated, so the size of the non-updatable information data block group 22 does not change. In addition, the data contents do not change. On the other hand, since the information in the updatable information data block group 23 that may be updated is updated, the size and data contents are changed.
Therefore, when information is updated in the archive file 21 having the structure as shown in FIG. 6, unnecessary file operations are not required by rewriting the end of the non-updateable information.
Specifically, as shown in FIG. 8, the update processing unit 26 updates the updatable information 26 in the updatable information data block group 23 to create the updatable information data block group 28 and updates it. Thereafter, the directory data 27 is created again from the directory data 24 of the archive file 21, and new updatable information 26 and directory data 27 are overwritten from the end of the non-updatable information data block group 22. As a result, an updated new archive file 29 is obtained. In this way, file access to the non-updatable information data block group 22 in the archive file 21 becomes unnecessary at the time of updating.

In the case of the archive file 25 shown in FIG. 7, although not shown, after updating the updatable information on the processing side, a new archive file is created, and the original non-updatable information data block from the end of the updatable information data block group. After copying the group, the directory data 18 may be added in the same manner. In this way, it is necessary to copy the non-updatable information data block group, but there is an advantage that file decompression (decoding) and file compression (encoding) for reducing the file capacity become unnecessary. . Further, as will be described later, when such an archive file is applied to an encapsulated document or the like, most of the information cannot be updated, so the file can be updated at high speed.
Up to this point, it has been stated that the updatable updatable information and the updatable non-updatable information are made into a separate archive file, but here there are some methods for the updatable updatable information and updatable updatable information areas. It is necessary to describe in the archive file.
Several specific methods are conceivable. As one method, it is conceivable to describe information indicating that updating is not possible and information indicating that updating is possible for each compressed data block.
For example, in the case of the ZIP format, it may be described in the extra field in the LOC header 101 shown in FIG. Further, the non-updatable information is compressed, and the updatable information is frequently updated and the size is small. Moreover, you may describe in the Cen header 104 corresponding to a compression block, respectively.
Further, since the information is simply halving the archive file, it may be described in a comment field that holds a comment of the end header 105.
Further, identification information for identifying an updatable file and an unupdatable file may be described in one of the files held as the archive file as shown in FIG.

Also, so far we have explained that there is a distinction between those that are simply updated and those that are not updated, but this is only an example, more detailed files that may not be updated, files that may be deleted The files may be classified into three files that may be partially updated and stored as shown in FIG.
In this case, the total size after compression of the non-updateable information data block group 31 that is a collection of files that are not updated does not change. Further, in the erasable information data block group 32, which is a collection of files that may be deleted, the total size of the block group changes according to the file to be deleted, but the size of each data block does not change. In the partially changeable information data block group 33, which is a collection of files that may be partially updated, only the data block of the updated information changes. From the above, when one of the erasable files and one of the partially updatable files stored in this archive file are updated, the non-updatable information data block group is not changed. Update the file from the end.
Therefore, first, the erasable information data block group 32 not deleted from the end of the non-updatable information data block group 31 is overwritten in order. In this case, the erasable information is deleted in units of stored files. Therefore, it is not necessary to decompress and recompress the erasable information data block group 32, and the data block may be simply copied. Next, with respect to the partial updatable information of the partial update information data block group 33, the data block that has not been updated may be simply copied by the data block, and the file information that has been partially updated is recompressed as data. Create a block.

Next, the distinction between such non-updatable information, erasable information, and partial update information will be described.
As described above, there is a method of specifying and distinguishing the storage distinction of the file that stores the archive file in advance at the time of creation, but it may be automatically performed based on the type of the file. For example, an extension is added to a normally stored file. Therefore, file storage may be distinguished based on this extension.
For example, **. DLL, **. Since a file having an extension representing a program code such as CLASS is a program code, it is held as data of the non-updatable information data block group 31, and **. Files representing contents such as images such as JPEG and moving images are stored as data in the erasable information data block group 32, and **. Since DAT or the like represents data, it may be held in the partially updatable information data block group 33.
In this case, a file having a size as large as possible may be arranged at the head of the file in the example shown in FIG.
Further, attribute information that is normally added to a file may be used. For example, a read-only file that is read-only and cannot be written may be held in a non-updatable data block, and a file having a read / write attribute may be held in an updatable data block.
Further, in addition to prescribing the position where the file is stored as a data block in advance as described above, the order may be changed according to the degree of update. For example, a file that is frequently updated may be stored at the beginning if it is rarely updated at the end.
Further, the file creation apparatus for creating the archive file of the present embodiment as described above is realized by executing a predetermined file creation program stored in a memory or the like by a CPU such as a computer (not shown). Can do.
For example, plural pieces of file information are converted into single file information such as ZIP format. Then, in order to distinguish whether the converted single file information is updatable file information that can be updated or non-updatable file information that cannot be updated, information such as the above-mentioned extension is acquired. Then, a single file may be created based on the acquired identification information.

Next, an example in which an archive file is actually used will be described again from document creation to update based on the encapsulated document format proposed by the present applicant.
FIG. 11 shows an encapsulated document in an encapsulated document format.
First, there is a document definition file 41 that defines the entire encapsulated document, a content file 43 that represents the contents of the document, and a program file 42 that displays the content file 43.
FIG. 12 is a diagram showing a configuration of a file creation / editing (updating) apparatus for creating and editing (updating) the above-described encapsulated document. As shown in FIG. 12, the file creation / editing device 51 includes creation / editing means 52 for creating and editing a document and a program file 53.
In this case, the creator creates a document using a GUI (Graphical User Interface) provided from the file creation / editing device (editing application) 51. At this time, content information 54 as needed may be inserted into the document from the outside. The content information created by such editing work and the information related to the entire document are converted into a content file and a document definition file, respectively, and a program file to be encapsulated is selected from the program file 53 in the file creation / editing device 51. And encapsulated in an encapsulated document 55.
Here, some means for encapsulating can be considered, but the encapsulated document 55 may be created by encapsulating the plurality of files in the archive file format as in the present invention. When the encapsulated document 55 encapsulating a plurality of files is distributed in this way, since the program for displaying and operating the document contents is encapsulated, the distribution destination does not require an application for browsing. Therefore, there is an advantage that the browsing environment is not selected.

Next, when a viewer adds annotations or the like to such an encapsulated document, it is necessary to retain the added information or the like in the encapsulated document. Since such information is likely to be updated frequently, in that case, it is desirable to keep it separately as an update information file.
FIG. 13 is a diagram schematically showing a data structure of an encapsulated document suitable for such a case.
In this case, first, an update information file 44 is provided separately from the document definition file 41 that defines the entire encapsulated document, the content file 43 that represents the contents of the document, and the program file 42 that displays and operates the content file 43. I have to.
When the encapsulated file having such a configuration is applied to the archive file described in the present invention, the information is held in the archive file by data blocks as shown in FIG. That is, it is composed of a document definition file data block 61, a program file data block 62, a content file data block 63, an update information file 64, and directory data 65.
Specifically, for example, a file 71 as shown in FIG. 15 is created using a file creation / editing device 51 as shown in FIG. 12, and the created document is distributed as an encapsulated document. Then, for example, the viewer browses using the file creation / editing device 51 and the like, and at the time of browsing, for example, the image 71 as shown in FIG. 16 is added to the document 71 shown in FIG. To do.

FIG. 17 is a flowchart showing a basic process when the file creation / editing apparatus 51 performs writing on the encapsulated document. The processing in this case is shown in FIG. 17, and the processing of the added information is performed by executing the processing in the order of viewing the encapsulated document (S1), adding the encapsulated document (S2), and storing the added information (S3). Append is performed.
FIG. 18 is a flowchart showing specific processing when the file creation / editing apparatus 51 performs writing on the encapsulated document.
First, when viewing an encapsulated document, an encapsulated document activation program for activating the encapsulated document is activated (S11), and a document for displaying the document contents as one of the operation programs in the encapsulated document is displayed. The content display program is activated (S12). As a result, the document image as shown in FIG. 15, that is, the information held in the content file in the encapsulated document is displayed on the screen of a computer or the like. Next, a rewriting information acquisition program for acquiring rewriting input by the user's mouse or the like is started (S13), and the user can acquire rewriting information using GUI means such as a mouse. The details of these operation programs are not related to the gist of the present invention, and thus will not be described in detail. However, the example described in Japanese Patent Laid-Open No. 2003-99424 previously proposed by the applicant is applied. Also good.
Next, the user-input additional information is acquired and stored on the memory (S14), and thereafter, the stored additional information is displayed in multiple layers (S15). That is, as shown in FIG. An image 73 as shown in FIG.

Next, it is determined whether to save the writing information (S16). For this, it is usually detected whether or not the user has given a save instruction. When it is determined in step S14 that the retouching information is not stored (“N” in S16), the rewriting information acquisition, holding, and display processing from step S14 is repeated.
On the other hand, if it is determined that the user has instructed to save the writing information (“Y” in S16), the writing information file name for saving the writing information in the encapsulated file is acquired (S17). The name of the additional information file may be described in advance in the document definition file, or may be embedded in a program that manages the storage of additional information.
Next, the directory data of the encapsulated document file is read (S18), the position of the updatable information area is acquired (S19), and the file of update information (added information) is written (S20).
When rewriting information is stored for the first time with respect to this encapsulated document file, since update information is not held in the encapsulated document, a file of update information (retouch information) is written after the last data block. (S20).
For example, when the encapsulated document file stores the write information for the first time, the data structure of the encapsulated document file does not hold the update information data block as shown in FIG. 19, so in this case, as shown in FIG. An update information (addition information) data block 64 that holds update information is added after the last data block, and the contents of the addition information are written in this portion of the data block 64. Specifically, for example, as shown in FIG. 22, an update information data block 64 including a LOC header 101, compressed data 102, and an Ext header 103 is added.

Next, since the update information data block 64 is newly added and updated as described above, the previously read directory data is recreated (S21), and the directory data is added to the encapsulated document file (S22). That is, the directory data 65 is added to the encapsulated document file as shown in FIG. 20, and the encapsulated document file is updated as shown in FIG. Specifically, for example, as shown in FIG. 23, a new Cen Header group 80 to which a corresponding Cen Header 81 is added and an updated End Header 82 may be added.
The examples so far have been described so that the update information file is added when the update information is generated, but a default update information data block is previously added at the time of document creation, and when update information is generated, The update information block and the corresponding directory data may be updated. In this case, since the size of the update information data block changes, it is necessary to rewrite the update information data block and the directory data. However, since the sizes of the Cen Header 81 and the End Header 82 in FIG. 23 are the same, the directory data 65 can be easily created. There is an advantage.
18 is provided as one of operation programs in the encapsulated document by adding a program for adding update information such as additional information describing the dotted line portion of FIG. 18 to the encapsulated document. Thus, only the encapsulated document can be browsed and updated, since the browsing display, the addition acquisition, and the addition information storage can be performed only by this.
Further, the description so far has been limited to encapsulated documents, but a program having these update functions may be held in a normal archive file.
With this configuration, some archive files currently have a self-extracting function, but by distinguishing update areas in this way, an archive file that can be easily updated can be configured. It becomes like this.

The figure which showed the data structure of ZIP format typically. The figure which showed the structure of each header typically. The figure which showed the data structure of ZIP format typically. The figure which showed typically the data structure of the other compression file format. The figure which showed an example of the data structure of the archive file which concerns on this Embodiment. The figure which showed the data structure at the time of applying the archive file of this Embodiment to what has the directory data of ZIP format. The figure which showed the data structure at the time of applying the archive file of this Embodiment to what has the directory data of ZIP format. The figure which showed the update process when updating the archive file which concerns on this Embodiment. The figure which showed an example of the identification information which identifies an updatable file and an unupdatable file. The figure which showed the other data structure example of the archive file which concerns on this Embodiment. Encapsulated document in encapsulated document format. The figure which showed the structure of the file creation edit apparatus. The figure which showed typically the data structure of the encapsulated document format. The figure which showed typically the data structure at the time of applying an encapsulated document to the archive file made into this Embodiment. The figure which showed the example of a display of the produced document. The figure which showed the example of a display of the document added to the document shown in FIG. The flowchart which showed the basic process in the case of adding to an encapsulated document. The flowchart which showed the specific process in the case of adding to an encapsulated document. The figure which showed an example of the data structure of the encapsulated document before an update. The figure which showed an example of the data structure of the encapsulated document after an update. The figure which showed an example of the data structure of the encapsulated document after update completion. The figure which showed an example of the data structure of an update information data block. The figure which showed typically an example of the data structure of a Cen header.

Explanation of symbols

11 Updatable information file, 12 Updatable information file, 21 Archive file, 22 31 Updatable information data block group, 23 28 Updatable information data block group, 24 27 34 65 Directory data, 26 Updatable information, 32 Deletable information Data block group, 33 Partially updatable information data block group, 41 Document definition file, 42 53 Program file, 43 Content file, 51 File creation / editing device, 52 Creation, editing means, 54 Content information, 55 Encapsulated document, 61 document Definition file data block, 62 Program file data block, 63 Content file data block, 64 Update information file (data block), 71 Document, 80 Cen Header group, 81 Cen Header, 82 En d Header

Claims (6)

  A file structure in which a plurality of file information is converted into single file information of a single file based on a prescribed format and held, and the updatable information that can be updated out of the single file information of the single file A file structure that distinguishes and holds file information and non-updatable file information that cannot be updated.   The file structure according to claim 1, further comprising identification information for identifying distinction between the updatable file information and the non-updatable file information.   3. The file structure according to claim 2, wherein the identification information is defined in units of files held in the single file.   A file creation device that creates a single file by converting multiple file information into single file information based on a prescribed format, and that is updatable and updatable. A file creation apparatus comprising: an acquisition unit that acquires identification information for identifying file information; and a file generation unit that generates a file based on the identification information acquired by the acquisition unit.   A file that is created by the file creation device according to claim 4 and that updates a single file that holds identification information that identifies whether single file information is updatable file information or non-updatable file information An update device, comprising: file information rewriting means for rewriting the single file information based on identification information held in a single file. 6. The file update according to claim 5, wherein the file information rewriting means operates by interpreting and executing one program held as single file information in the single file by a computer. apparatus.

Images