Computer method and apparatus for a table driven file interface5421001Abstract An interface between different file formats employs a table for parsing component parts of each file format. The table cross references or categorizes each of the different file formats according to file type from a predefined set of file types. For each file type, the table provides an indication and description of each component part of a file of that type. Each component part description of the table is in a common format. Thus, the present invention method and apparatus employs a table driven parser which utilizes a common form of representation for defining multiple file formats. Claims I claim: Description BACKGROUND OF THE INVENTION
______________________________________
HEX Numeric-Variable Argument
______________________________________
01 A Beginning Column Number
02 B Beginning Row Number
03 C Ending Column Number
04 D Ending Row Number
05 E Total Column Count
06 F Total Row Count
07 G From Column Number
08 H To Column Number
09 I Integer Data Location
0A J Justification Data Location
0B K Label Text Location
0C L Record Length
0D M Data Record Length
0E N Decimal Data Location
0F O Occurrence or Repeat Count
10 P Formula Numeric Location
11 Q Formula Location
12 R Formula Length
13 S Text Data Location
14 T Text Length
15 U Field Type
16 V Number of Decimal Positions
17 W Cell Width
18 X Current Column Number
19 Y Current Row Number
1A Z Date Data Location
1B a Time Data Location
1C b Current Worksheet Number
1D c Mask Repeat Count
1E d Reference Column
1F e Reference Row
20 f Reference Worksheet
21 g Format Mask
22 h Format Mask Index
______________________________________
Arguments A through F are used in Range descriptor records 31, if the subject file type contains a range data record. Arguments G, H and W are used in Column Width descriptor records 31 to specify range of cells which use the width specified. Argument I is used in Integer descriptor records 31 to specify the location of the integer within the subject file type data record. Argument I is used in Text descriptor records 31 to specify the location of the text justification character (right, left, center) within the subject file type data record. Arguments S, T are used in Text descriptor records 31 to specify the location and length, respectively, of the text string within the subject file type data record. Argument K is used in Label or Header descriptor records 31 to specify location of the text associated with the column or row label within the subject file type data record. Arguments L and M are used in descriptor records 31 for a stream file where each subject data record contains a record length indicator. Argument N is used in Decimal descriptor records 31 to specify location of the decimal within the subject file type data record. Argument O is used in Format descriptor records 31 to specify the number of times a portion of the subject file type data record will repeat data information. Arguments P, Q, R are used in Formula descriptor records 31 to specify location of a formula within the subject file type data record. Argument U is used in a Data Type descriptor record 31 to specify location of a data type indicator. Argument V is used to specify the number of decimal places a numeric data item possesses. Arguments X, Y, and b are used for subject file types related to spreadsheets. Specifically, Arguments X and Y are used in Data descriptor records 31 to define to which spreadsheet cell the data belongs. Argument b is used in Data descriptor records 31 to define to which worksheet the data belongs. Argument Z is used in Data descriptor records 31 to specify location of the data within a subject file type data record. Argument a is used in Time descriptor records 31 to specify location of the time indication within a subject file type data record. The next byte 98 of the descriptor record 31b (FIG. 3c) indicates the "type" character of the general numeric-variable format. This "type" character determines whether the associated argument is interpreted as a character, a string or a number, and whether it is stored in byte, word, double-word, short or long IEEE format. It is from this information that the column number format type 53, row number format type 63, record length format type 73 and cell width format type 83 bytes of the first portion 35 of associated description record 29 are defined as mentioned previously. The preferred hex values for byte 98 and corresponding Numeric-Variable "type" character and meanings used in the initial working file descriptions are as follows.
______________________________________
HEX Numeric-Variable Type
______________________________________
01 C One Byte Field
02 U Unsigned One Byte Field
03 H Two Byte Integer
04 W Unsigned Two Byte Integer
05 L Four Byte Integer
06 V Unsigned Four Byte Integer
07 R EXCEL 3.0 RK Unsigned Four Byte
Number
08 J Lotus Two Byte Floating Point
Format
09 F IEEE Floating-Point Format
0A D IEEE Long Floating-Point Format
0B K Ten Byte Floating-Point Format
0C Z One Byte Character Logical
0D I Integer in ASCII Format
0E N Floating-Point ASCII Format
0F E Scientific Notation, ASCII Format
10 B Binary ASCII Format
11 O Octal ASCII Format
12 Y Date in 4-Digit Year, 2-Digit
Month, 2-digit day indication
(YYYYMMDD) ASCII Format.
13 X Hexadecimal ASCII Format
14 S Character String
______________________________________
In byte 99 of the descriptor record 31b of FIG. 3c, the "width" of the Numeric-Variable information is indicated as a minimum number of characters. The "precision" of the Numeric-Variable information is indicated in byte 96 of descriptor record 31b. Preferably the value held by byte 96 is the maximum number of characters in a string (S type) or the number of digits to the right of the decimal point of a decimal (N type) number. The last two bytes 92 of the descriptor record 31b indicate the Numeric-Variable constant. This constant specifies an offset other than default offsets. For example, if the first two bytes of a record contain the length of the record excluding those two bytes then the constant specifies -2 because the present invention interface 21 assumes that the length includes those bytes. As another example, if the lowest cell in a spreadsheet is located in position 1,1 then the constant specifies +1 for the X,Y variable because the interface 21 assumes that the first cell for that file type (i.e., spreadsheet) is located in position 0,0. FIG. 3d illustrates a descriptor record structure for "skip-stop" records 31c. Stored in these types of records is information which helps to define when to ignore unrecognizable data. This information defines two or more (match-if-present) strings which are searched for. The closest "match-if-present" string found, relative to the start scanning position, causes the scanning position to ignore all data between the start scanning position and the found "match-if-present" string. On output, the first "match-if-present" string defined is written to the subject file type record as specified. Further, "skip-stop" characters are special components which end the "skip-many" components (described later). Referring to FIG. 3d, the first byte 42 of descriptor record 31c holds the hex number "0X10" to indicate a skip-stop record. The second byte 44 holds the number of "match-if-present" character groups to scan for. The specific "match-if-present" character groups follow descriptor record 31c. In the corresponding initial working file descriptions, two or more "match-if-present" character groups are enclosed between angle brackets to specify the skip-stop character desired. If the angle bracket characters are used in the subject character group, they are represented by hex characters or they are proceeded by a backslash character. In sum, when the skip-stop record type is encountered, the interface 21 repositions the file pointer to the first "match-if-present" character it finds. FIG. 3e illustrates a descriptor record 31d specifying a "skip-many" component. Such a component is used to indicate that the file format being defined may contain an unknown number of additional characters, in this position of the subject file type data record, which should be ignored on input. This is useful in cases where the "match-if-present" characters in a descriptor record 31 might not match the characters in the subject file type data records, in which case the present invention interface 21 skips to the next recognizable character. On output no characters are written to this position (indicated by the "skip-many" character) within the format file being defined from this information. Note, descriptor record 31d is always followed by "exact-match" or "skip-stop" information so the record matching mechanism of interface 21 knows when to stop skipping characters. That is, skip-many characters are a special case of the "match-if-present" character specifying that the rest of the characters should be skipped until the characters following the "skip-many" character are found. In the initial working file descriptions, a "skip-many" character is represented by three periods enclosed in parenthesis. If the parenthesis character is used in the subject file type data it is specified as a hex character or is preceded by a back slash character. Referring to FIG. 3e the one byte long descriptor record 31d for a "skip-many" component holds the hex value OXFF to indicate the skip-many record type. Generally bytes that follow the record structure of FIG. 3e hold "exact-match" or "skip-stop" information. Referring to FIG. 3f is the record structure for a descriptor record 31e defining repeat records. That is, a group of "exact-match", "skip-fixed", or "variable-numeric" components which repeat within a subject file type data record is defined by descriptor records 31e of the type illustrated in the FIG. 3f. This type of component is used in Format descriptor records 31 where the field information may repeat for an unknown number of times depending on the number of fields defined for the specific file type. The repeat component group is preceded by an occurrence count or followed by a "skip-stop" component so the interface 21 knows when to stop searching for the repeated data. As shown in FIG. 3f, the descriptor record 31e structure indicates in the first byte the repeat record type. In the preferred embodiment, that type is indicated by the hex value of 0X20. The next byte 46 indicates the number of following bytes which make up the repeated components. In the corresponding initial working file descriptions, the repeat characters are special components which repeat the "exact-match", "skip-fix", or "variable-numeric" components and are enclosed within curly brackets. If curly brackets are used in the repeat characters, they are represented in hex characters or are preceded by a backslash. Non-limiting examples of initial working file descriptions used to generate descriptor record 31 contents for various table 23 entries are given in the attached Appendix. In each example, the corresponding file type is identified under the header "NAME", and descriptor records are identified in subheadings under the NAME header with initial working file descriptions for generating descriptor record information following each subheading. The working file descriptions following each subheading are an English interpretation of the binary code actually used in table 23 and includes the OD OA hex designation for carriage return, line feed characters; the parenthesis enclosure for match-if-present characters; the (. . .) symbol for skip-many characters; the square brackets enclosure about skip-fixed characters; the angle bracket enclosure about skip-stop characters; the curly bracket enclosure about repeat characters; and the Numeric-Variable general format detailed above in conjunction with FIGS. 3b-3f. As mentioned above, the Appendix entries are compiled by a table compiler to form the desired descriptor records 31 of table 23. After table 23 has been defined and established according to the foregoing, operation of interface 21 utilizing table 23 in the preferred embodiment is implemented by the following software routines. More accurately, the following describes a group of file access subroutines which provide the functionality of interface 21. By way of general overview, the present invention interface 21 allows applications 15 (FIG. 1) two options for data retrieval, and provides two writing mechanisms to write to a desired file. As to the two options for data retrieval, in one option interface 21 accesses a target file, parses the records of the file according to table 23, and passes the retrieved data back to the calling application 15 one cell or column at a time. In the second option, interface 21 accesses the target file, and passes any and all file records back to the calling application 15 one record at a time without parsing or extracting any of the data. In this instance, the calling application 15 needs to know the record structure of the target file and must parse retrieved records accordingly. This second option is a low level interface designed for applications 15 which need to know more information about the target file than simple data transfer. In the preferred embodiment the former read option is accomplished by a routine called "DXgetcell" 107 (FIG. 4b), and the later read option is accomplished by a routine called "DXgetrec" 109 (FIG. 4c), both described below. As to the writing mechanisms of interface 21, the first writing mechanism is implemented in a routine called "DXpcell". This routine accepts data one cell at a time and writes the data to the target file in the appropriate file format. The second writing mechanism allows the calling application 15 to insert records directly into the output file stream. These output records must already be formatted in a format familiar to the target output file type. This mechanism is generally only used when additional informational records, other than records currently produced and understood by table 23, are required for the type of file being output. This second writing mechanism is implemented by a routine called "DXputrec". These two write routines are described in detail later with reference to FIGS. 5a and b. Referring to FIG. 4a data retrieval (read) operation 103 of interface 21 is illustrated. Before data can be accessed from a target file, the calling application 15 or user must open that file. This is accomplished by the calling application 15 initializing or freeing a global memory read stack 101 and issuing an "open" command to CPU 13 (FIG. 1). Specified in the "open" command is the file name of the desired target file 17 and the file type of that file. In response to the "open" command, interface 21 (via read operation 103) determines whether that file type has previously been opened. If that file type has previously been opened, the local memory space previously allocated and the internal structures previously generated are used. If that file type has not previously been opened, interface 21 allocates local memory space 105. Then at 102 in FIG. 4a read operation 103 opens table 23 and searches for a table entry which maps to the designated file type of the desired file 17. Upon location of the table entry having a file type corresponding to the desired file type, read operation 103 (i.e., interface 21 at 104 in FIG. 4a) reads that entry and interprets the descriptor records 31 specified under that entry. In interpreting descriptor records 31 of the corresponding file type, read operation 103 defines a set of object records 100 in the allocated memory space 105. The contents of these object records 100 specify the file format of the desired file type. According to the file format as specified in the object records 100, interface 21 continues at step 106 of operation 103 by opening the desired file 17 by the given file name. Once the file 17 has been opened, the data contained in that file can be accessed and retrieved according to one of the two options of the present invention. Whatever option is used, the retrieved data is placed on a read stack 101 in global memory which was initialized by the calling application 15. In the preferred embodiment routine "DXgetcell" 107 is called to retrieve one cell/field at a time from the opened spreadsheet/database file 17. In particular, "DXgetcell" 107 accesses the opened file 17 and translates the records of that file using the object records 100 formed from the table 23 entry, and passes one cell of data at a time to the read stack 101 for reading by the calling application 15. Alternatively, routine "DXgetrec" 109 is called to retrieve the desired data from the open file 17. That routine 109 accesses the file 17 in its native format, a record or cell at a time. In this case, the record or native cell is placed on the read stack 101 before it has been parsed, and the calling application 15 must parse the record to retrieve the data. As mentioned previously, this option is generally only used if the calling application 15 requires more information from a target file 17 than the cell content information which is returned through the DXgetcell 107 access method. Further, on output from the retrieval of data, read operation 103 provides (i) a parameter for identifying the file 17 being accessed and object records 100 corresponding thereto, and (ii) a pointer to the read stack 101 on which the retrieved data is written. When the open file 17 is no longer to be accessed, operation 103 may close the file 17 at 108 (FIG. 4a). In particular, read operation 103 writes to disk under the calling application 15 the retrieved data held on the read stack 101 and subsequently clears the read stack 101. This occurs namely in the case where CPU 13 runs out of memory, or the file 17 needs sorting. Further, this is accomplished according to the file format of calling application 15 so that a record and header are formatted on disk for the retrieved file data, the data is written into that format, and numbers or other special characters are properly converted for the calling application disk version of the retrieved data. The foregoing is done in accordance with the variable type and width specified in numeric variable information. of a descriptor record 31 of the calling application file type. Lastly, the stack pointer is moved as appropriate to reflect that the read stack 101 has been cleared. Illustrated in FIG. 4b is routine DXgetcell 107 in more particular terms. Routine 107 reads one file segment (step 200) at a time from open file 17. For each read file segment, DXgetcell 107 identifies the various parts composing that file segment. This is accomplished at step 202 by DXgetcell 107 mapping or matching file segment parts to descriptor record specified width, size and type of data portions according to object records 100. Having identified the various parts, routine 107 allocates memory to store data at 204 and places the read data on read stack 101 at 208. Next routine 107 determines whether the cells of the open file 17 are stored in random order on file 17. If not, routine 107 returns the data placed on read stack 101 to the calling application. If routine 107 determines the data read from open file 17 is in random order i.e., cells of file 17 are stored/read out of order, then routine 107 reads the entire file 17 and sorts the read data before it actually passes the retrieved data back to the calling application via read stack 101. This is illustrated by loop 216 to step 206 in FIG. 4b, where sorting is preferably performed using a temporary file holding the read data. At step 218, if read stack 101 is full or becomes full, routine 107 employs a backup file. The initial contents of read stack 101 are moved to the backup file (step 210) and future retrieved read data is placed on available read stack 101. Referring to FIG. 4c, routine DXgetrec 109 is illustrated. If the user or calling application 15 specifies a desired number of units (i.e., bytes, file segments, or records) to be read from the opened file 17, read operation 103 calls routine 109 instead of routine 107. First, step 212 of routine 109 receives and interprets the specified number of units desired to be read. In particular, at step 212, routine 109 establishes, in bytes or file record segment equivalent units, a working number of read accesses of open file 17 to make. Step 212 passes that working number to step 214. Step 214 implements a loop for reading from open file 17 the working number of record segments/bytes. For each pass through the loop 214, one such record segment/byte is read from file 17 either directly or by a call to routine DXgetcell 107 described above in FIG. 4b. Specifically, if descriptor record information as represented by object records 100 is sufficient so that routine 109 at step 212 can determine what a "record" is, then loop 214 reads directly from open file 17 the appropriate number of bytes for that definition of record or record segment. Otherwise loop 214 calls routine 107, and cycles through loop 214 the working number of times. In this manner the working number or specified number of bytes are read from file 17 one at a time (i.e., until the working number of times has been counted). Referring to FIG. 5a is a flow diagram of the write access operation 110 of interface 21. As in read operation 103, in order for a file to be written to, operation 110 first opens that file. This is accomplished by the user or calling application 15 initializing and freeing a global memory write stack 114, and issuing an "open" command to CPU 13 (FIG. 1). Specified in the "open" command is the file name of the desired target file 17 and the file type of that file. In response to the "open" command, interface 21, (via write operation 110) determines whether that file type has previously been opened. If that file type has previously been opened, the local memory space previously allocated and the internal structures existing therein are used. If that file type has not previously been used, interface 21 allocates local memory space 105. Then at step 230 write operation 110 opens table 23 and searches for a table entry which maps to the designated file type of the desired file 17. Upon location of the table entry having a file type corresponding to the desired file type, write operation 110 (i.e., interface 21 at 235 in FIG. 5a) reads that entry and interprets descriptor records 31 specified under that table entry. In interpreting descriptor records 31 of the corresponding file type, write operation 110 defines a set of object records 236 in the allocated memory space 105. The contents of these object records 236 specify the file format for the file type of the desired file 17. According to the file format as specified in the object records 236, interface 21 at step 232 of operation 110 opens the desired file 17 by the given file name. Once the file 17 has been opened, desired data may be written to that file. Data is received from the user or calling application 15 and stored on the global memory write stack 114. At step 238 of write operation 110 a data part is "popped" or received from the top of the write stack 114. That data part is then written to the opened file 17 according to one of the two write mechanisms provided by the present invention. The receipt of data parts from the top of write stack 114 and writing of that data part to open file 17 continues one data part at a time until the write stack 114 is emptied as indicated by the loop 240 in FIG. 5a. When the open file 17 is no longer to be accessed, write operation 110 closes the file 17 at step 234 in FIG. 5a. In particular, write operation 110 writes to disk under the open file 17, the received data held on the write stack 114 which has not already been written thereto, and subsequently clears the write stack 114. This is accomplished according to the file format indicated in object records 236, so that a record and header are formatted on disk for the desired data, the data is written into that format, and numbers or other special characters are properly converted for the disk version of the received data. This is performed in accordance with the variable type and width specification in numerical variable information of a descriptor record 31 of the corresponding file type of open file 17. Lastly, the stack pointer is moved as appropriate to reflect that the write stack 114 has been cleared. In the preferred embodiment, write operation 110 writes to open file 17 cells or records received by the calling application 15 or user by calling routine DXpcell 111. In general, routine DXpcell 111 accepts one cell of data at a time converts it according to the object records 236 reflecting the file type entry in table 23 and hence file format of file 17, and therefrom generates a record appropriate for the file type of file 17. Then routine 111 writes the generated record to the open file 17 on disk. FIG. 5b illustrates the routine "DXpcell" 111 in more particular detail. Data to be written to the desired file 17 is received from the user or calling application 15 and stored on the write stack 114. If the write stack 114 becomes full, a procedure for moving the current contents of the write stack to a temporary scratch file is called at 250. Next, at step 252 (FIG. 5b) DXpcell 111 performs the following for each data portion read from write stack 114, one portion at a time. First at 254 DXpcell 111 determines the data type of the data portion taken from the stack 114 (i.e., popped from the top of write stack 114). In addition, the type of that data portion, size and width are set at 256. As needed, numerical quantities are converted for writing to the open file 17. As needed, the next step 248 formats a working header and record for the open file 17 according to the object records 236 specifying the file format from table 23. The header is also written to the formatted record. In turn, the data portion from the write stack 114 is written to the formatted working record 246. Ultimately, the working record is written to the open file 17 at step 244 (FIG. 5b). Subsequently, the write stack pointer is moved to the next portion of the data to be read from the stack 114. The foregoing steps are repeated for each data portion read from write stack 114 and temporary files used to store the subject data. In the case where a data portion is read from a temporary file, step 248 formatting the record to be written to the open file 17 also determines whether the subject data is from the current write stack 114 or a temporary file. When all temporary files and stack 114 are empty and hence all desired data has been written to open file 17, routine 111 returns to write operation 110 at the end of loop 240 in FIG. 5a. Alternative to routine 111, write operation 110 uses the optional writing mechanism mentioned above. This involves operation 110 accepting a record of desired data at a time from the calling application 15 or user, and writing the received record or specified number of bytes directly to the open file 17 (i.e., to disk). In addition to read, write access, table 23 is used for file type recognition. In particular, calling application 15 may issue a command "DXfiletype". This routine determines the format of the specified target file and returns an indication of the file format to the calling application 15. More specifically, a command "DXfiletype" is a call to the CPU 13 to open the specified target file 17, and using table 23 look at the open file to figure out the file type. In order for the CPU 13 to open the file 17, this command asks the CPU 13 to open files for all file types it knows. From the CPU list of all of its file types, the DXfiletype routine figures out the closest matching file type from table 23. Equivalents While the invention has been particularly shown and described with reference to a preferred embodiment thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.
APPENDIX
______________________________________
Example Descriptor Record Entries for Given File Type
______________________________________
Example 1 DOS 20/20 File
NAME DS2020
EOR.sub.-- RECORD
## 0D 0A
DATA.sub.-- DELIMITER
#
DECIMAL.sub.-- RECORD
N(1.16,N)
TEXT.sub.-- RECORD
<( J(1,S) S(1.255,S))
( S(1.255,S))>
INTEGER.sub.-- RECORD
I(1,I)
EMPTY.sub.-- CELL.sub.-- RECORD
20
LEFT.sub.-- JUSTIFY
'
RIGHT.sub.-- JUSTIFY
"
REPEAT.sub.-- CHAR
PC.sub.-- FILE 1
INSERTABLE 1
DEFAULT.sub.-- 9
COLUMN.sub.-- WIDTH
CHARACTER.sub.-- SET
3
END
Example 2 VS 20/20 File
NAME VS2020
EOR.sub.-- RECORD
##
DATA.sub.-- DELIMITER
#
DECIMAL.sub.-- RECORD
N(1.16,N)
TEXT.sub.-- RECORD
<( J(1,S) S(1.255,S))
( S(1.255,S))>
INTEGER.sub.-- RECORD
I(1,I)
EMPTY.sub.-- CELL.sub.-- RECORD
20
LEFT.sub.-- JUSTIFY
'
RIGHT.sub.-- JUSTIFY
"
REPEAT.sub. -- CHAR
&
PC.sub.-- FILE 0
VS.sub.-- FIXED 0
VS.sub.-- COMPRESSED
0
VS.sub.-- RECORD.sub.-- LENGTH
80
INSERTABLE 1
DEFAULT.sub.-- 9
COLUMN.sub.-- WIDTH
CHARACTER.sub.-- SET
2
END
Example 3 VS Consecutive File
NAME VSCONS
RECORD.sub.-- FORMAT
L-2(2,H)(...)
TEXT.sub.-- RECORD
L-2(2,H){ S(1,S)}
PC.sub.-- FILE 0
VS.sub.-- FIXED 0
VS.sub.-- COMPRESSED
0
VS.sub.-- RECORD.sub.-- LENGTH
80
INSERTABLE 1
CHARACTER.sub.-- SET
2
END
Example 4 DBASE File
NAME DBASE
TEXT.sub.-- RECORD
20 S(1,S)
EOF.sub.-- RECORD
1A
FORMAT.sub.-- RECORD
<( 03)( 83)( 43)>[ 58 01 01] F
(4,L) L(2,H) M(2,H)[ 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0]{ K
(10.10,S) 0 U(1,C)[ 0 0 0 0] T(
1,C) V(1,C)[ 0 0 0 0 0 0 0 0
0 0 0 0 0 0]} 0D
DATA.sub.-- TYPES
,,,,,,,,,,,L,,N,,,,,D,C
PC.sub.-- FILE 1
INSERTABLE 1
CHARACTER.sub.-- SET
3
RECORD.sub.-- LENGTH
4000
COLUMN.sub.-- LIMIT
512
END
Example 5 Delimited Text File
NAME DELIM
DATA.sub.-- DELIMITER
,
DECIMAL.sub.-- RECORD
N(1.16,N)
TEXT.sub.-- RECORD
( J(1,S) S(1,S) J(1,S))
EOR.sub.-- RECORD
0D 0A
INTEGER.sub.-- RECORD
I(1,I)
LEFT.sub.-- JUSTIFY
"
PC.sub.-- FILE 1
INSERTABLE 1
DEFAULT.sub.-- 1
COLUMN.sub.-- WIDTH
CHARACTER.sub.-- SET
3
END
Example 6 DIF File
NAME DIF
TEXT.sub.-- RECORD
1,0 0D 0A J(1,S) S(1.255,S)
J(1,S) 0D 0A
DECIMAL.sub.-- RECORD
0, N(1.16,N) 0D 0AV 0D 0A
HEADER.sub.-- RECORD
TABLE 0D 0A0,1 0D 0A
"(...)" 0D 0A
RANGE.sub.-- RECORD
VECTORS 0D 0A0,
E(1.3,I) 0D 0A"" 0D 0A
TUPLES 0D 0A0, F(1.3,I)
0D 0A"" 0D 0A
BOD.sub.-- RECORD
DATA 0D 0A0,0 0D 0A"" 0D 0A
BOR.sub.-- RECORD
-1,0 0D 0ABOT 0D 0A
EOF.sub.-- RECORD
-1, 0D 0AEOD 0D 0A
INTEGER.sub.-- RECORD
0, I(1,I) 0D 0AV 0D 0A
DATE.sub.-- RECORD
0, S(1.255,S) 0D 0AV 0D 0A
LEFT.sub.-- JUSTIFY
"
PC.sub.-- FILE 1
INSERTABLE 1
DEFAULT.sub.-- 9
COLUMN.sub.-- WIDTH
WRITE.sub.-- ORDER
HEADER.sub.-- RECORD,
RANGE.sub.-- RECORD,
BOD.sub.-- RECORD
CHARACTER.sub.-- SET
3
END
Example 7 EXCEL Files
NAME EXCEL
VERSION.sub.-- START
02.00.00
RECORD.sub.-- FORMAT
00 00 L-4(2,H)(...)
TEXT.sub.-- RECORD
04 00 L-4(2,H) Y(2,H) X(2,H)
[ 40 0 0] T(1,U) S(1.255,S)
DATE.sub.-- RECORD
02 00 09 00 Y(2,H) X(2,H)
[ 40]<( 0C)( 0D)( 0F)( 4C)
( 4D)( 4E)( 4F)( 8C)( 8D)
( 8E)( 8F)( CC)( CD)( CE)( CF)
>[ 0] Z(2,W)
INTEGER.sub.-- RECORD
02 00 09 00 Y(2,H) X(2,H)
[ 40 0 0] I(2,H)
TIME.sub.-- RECORD
03 00 0F 00 Y(2,H) X(2,H)
[ 40]<( 10)( 11)( 12)( 13)
( 14)( 50)( 51)( 52)( 53)( 54)( 90)
( 91)( 92)( 93)( 94)( D0)( D1)( D2)
( D3)( D4)>[ 0] a(8,D)
DECIMAL.sub.-- RECORD
03 00 0F 00 Y(2,H) X(2,H)
[ 40 0 0] N(8,D)
EMPTY.sub.-- CELL.sub.-- RECORD
01 00 07 00 Y(2,H) X(2,H)
[ 40 0 0]
EOF.sub.-- RECORD
0A 00 00 00
HEADER.sub.-- RECORD
09 00 04 00[ 02 00] 10 00
EXTRA.sub.-- 1 06 00 L-4(2,H) Y(2,H) X(2,H)
[ 40]<( 10)( 11)( 12)( 13)
( 14)( 50)( 51)( 52)( 53)( 54)( 90)
( 91)( 92)( 93)( 94)( D0)( D1)( D2)
( D3)( D4)>[ 0] a(8,D)
[ 0] R(1,C)( Q(0,S)
EXTRA.sub.-- 2 06 00 L-4(2,H) Y(2,H) X(2,H)
[ 40]<( 0C)( 0D)( 0E)( 0F)
( 4C)( 4D)( 4E)( 4F)( 8C)( 8D)
( 8E)( 8F)( CC)( CD)( CE)
( CF)>[ 0] Z(8,D)[ 0]
R(1,C) Q(0,S)
FORMULA.sub.-- RECORD
06 00 L-4(2,H) Y(2,H) Z(2,H)
[ 40 0 0] P(8,D) R(1,C) Q(0,S)
RANGE.sub.-- RECORD
00 00 08 00 B(2,H) D+1
(2,H) A(2,H) C+1(2,H)
EXTRA.sub.-- 3 07 00 L-4(2,H) T(1,U) S(1.255,S)
PASSWORD 2F 00 L-4(2,H)
PC.sub.-- FILE 1
INSERTABLE 0
DEFAULT.sub.-- 9
COLUMN.sub.-- WIDTH
CHARACTER.sub.-- SET
1
WRITE.sub.-- ORDER
HEADER.sub.-- RECORD,
RANGE.sub.-- RECORD
VERSION.sub.-- END
VERSION.sub.-- START
03.00.00
RECORD.sub.-- FORMAT
00 00 L-4(2,H)(...)
TEXT.sub.-- RECORD
04 02 L-4(2,H) Y(2,H) X(2,H)
[ 0 0] T(2,H) S(1.255,S)
DECIMAL.sub.-- RECORD
03 02 0E 00 Y(2,H) X(2,H)
[ 0 0] N(8,D)
EMPTY.sub.-- CELL.sub.-- RECORD
01 02 06 00 Y(2,H) X(2,H)[ 0 0]
EOF.sub.-- RECORD
0A 00 00 00
HEADER.sub.-- RECORD
09 02 6 0[ 0 0] 10 0[ 0 0]
FORMULA.sub.-- RECORD
06 02 L-4(2,H) Y(2,H) X(2,H)
[ 0 0] P(8,D)[ 01 00] R(2,H) Q(0,S)
RANGE.sub.-- RECORD
00 02 0A 00 B(2,H) D+1
(2,H) A(2,H) C+1(2,H)[ 00 00]
EXTRA.sub.-- 1 07 02 L-4(2,H) T(2,H) S(1.255,S)
EXTRA.sub.-- 2 7E 02 0A 00 Y(2,H) X(2,H)
[ 00 00] N(4,R)
PASSWORD 2F 00 L-4(2,H)
BOD.sub.-- RECORD
8 2 10 0[ 0 0 0 0 1 0 ff 0 0 0 0 0 0 0 0 0]
PC.sub.-- FILE 1
INSERTABLE 0
DEFAULT.sub.--
COLUMN.sub.-- WIDTH
9
CHARACTER.sub.-- SET
1
WRITE.sub.-- ORDER
HEADER.sub.-- RECORD,
RANGE.sub.-- RECORD,
BOD.sub.-- RECORD
|
Same subclass Same class Consider this |
||||||||||