OLE object parsing method, device, computer equipment and storage medium

Abstract

The present application provides an OLE object parsing method, device, computer equipment and storage medium. The method extracts binary data streams corresponding to more than one OLE object from a target drawing file, then extracts and combines each sector of each binary data stream to obtain more than one file stream, then traverses each file stream, determines the file type according to the value of the category identification field in the file stream, and finally, if the file type indicates that the file stream belongs to a source file or a display file, stores the file stream and records the address information and file type, so that the file stream can be displayed in a corresponding manner when the target drawing file is displayed.

Description

Technical Field

[0001] The present application relates to the technical field of computer-aided design, and in particular to an OLE object parsing method, apparatus, computer equipment and storage medium. Background Art

[0002] With the development of information technology, CAD (Computer Aided Design) software has been widely used in all walks of life. CAD software can effectively help designers improve design efficiency. Under the Windows operating system, data from other software can be copied and pasted into CAD software, such as copying part of the table data from an Excel table and pasting it into CAD. CAD saves the data as an OLE (Object Linking and Embedding) object and displays it as a table. In this way, data interaction between CAD and other software can be achieved. In traditional technology, it can be achieved with the help of OLE and COM technology of the Windows operating system, but the problem is that there is no relevant component support in the Linux environment, so it cannot be used across platforms. Therefore, the OLE object data saved in the drawing cannot be displayed normally, nor can it be edited. Summary of the invention

[0003] The purpose of this application is to solve at least one of the above-mentioned technical defects, and in particular to provide a solution that can parse OLE objects in a Linux environment, thereby providing support for the normal display and operation of OLE objects on CAD software.

[0004] In a first aspect, the present application provides an OLE object parsing method, comprising:

[0005] Extract the binary data stream corresponding to one or more OLE objects from the target drawing file;

[0006] For any binary data stream, more than one file stream is obtained by extracting and combining sectors of the binary data stream;

[0007] Traverse each file stream and determine the file type of the file stream according to the value of the category identification field in the file stream;

[0008] If the file type reflects that the file stream belongs to a source file or a display file, the file stream is stored and the corresponding address information and file type are recorded. When the target drawing file is displayed, the file stream is read according to the corresponding address information and the file stream is displayed in a manner corresponding to its own file type.

[0009] In one embodiment, extracting binary data streams corresponding to more than one OLE object from a target drawing file includes:

[0010] In the process of deserializing entity classes of different categories in the target drawing file, it is determined whether the entity class currently being deserialized belongs to the target class;

[0011] If so, the deserialized objects of each object in the target class are used as binary data streams, and an OLE object index table is established with the handles of each object in the target class as keys and the corresponding binary data streams as values;

[0012] In one embodiment, for any binary data stream, more than one file stream is extracted and combined from sectors of the binary data stream, including:

[0013] Traversing each object contained in the OLE object index table, and obtaining a target binary data stream based on the handle of the traversed object and the OLE object index table;

[0014] Building a sector configuration table according to the file header of the target binary data stream, and determining all directory sectors corresponding to the directory stream according to the sector configuration table;

[0015] Traverse all directory entries in the directory sector and determine whether the entry type of the traversed directory entry is a file stream entry;

[0016] If not, continue traversing, if so, extract the file stream starting sector identifier from the current directory entry;

[0017] According to the file stream starting sector identifier and the sector configuration table, the file stream sectors related to the file stream corresponding to the current directory entry are sequentially extracted and spliced ​​to obtain the file stream corresponding to the current directory entry.

[0018] In one of the embodiments, before constructing the sector configuration table according to the file header of the target binary data stream, the method further includes:

[0019] Determine whether the values ​​of the first number of bytes before the target binary data stream are the same as the first combination;

[0020] If yes, the first second number of bytes of the target binary data stream are determined as the file header, and the rest of the target binary data stream are determined as the sector portion;

[0021] If not, continue to traverse each object contained in the OLE object index table.

[0022] In one of the embodiments, after determining the first second number of bytes of the target binary data stream as the file header, the method further includes:

[0023] Read the value of the file header at the first offset position to determine the number of sectors;

[0024] Determine whether the data length of the sector portion matches the number of sectors;

[0025] If yes, then proceed to the step of constructing a sector configuration table according to the file header of the target binary data stream and continue to execute;

[0026] If not, continue to traverse each object contained in the OLE object index table.

[0027] In one embodiment, according to the file stream start sector identifier and the sector configuration table, sequentially extracting and splicing the file stream sectors related to the file stream corresponding to the current directory entry to obtain the file stream corresponding to the current directory entry includes:

[0028] Find the corresponding sector chain from the sector configuration table according to the file stream starting sector identifier;

[0029] According to the sector chain, the corresponding file stream sectors and reading order are determined in the sector part;

[0030] Read each file stream sector in turn according to the reading order, and splice the reading results to obtain the file stream corresponding to the current directory entry.

[0031] In one embodiment, determining whether the entry type of the traversed directory entry is a file stream entry includes:

[0032] If the value of the traversed directory entry at the second offset position is the same as the second combination, the entry type is determined to be a file stream entry, otherwise it is determined not to be a file stream entry.

[0033] In one embodiment, before determining the file type of the file stream according to the value of the category identification field in the file stream, the method further includes:

[0034] Determine whether the values ​​of more than one target field in the file stream are all set valid values;

[0035] If yes, then executing the step of determining the file type of the file stream according to the value of the category identification field in the file stream;

[0036] If not, continue traversing the file stream.

[0037] In a second aspect, the present application provides an OLE object parsing device, comprising:

[0038] A binary data stream extraction module is used to extract binary data streams corresponding to more than one OLE object from a target drawing file;

[0039] A file stream combination module is used to extract and combine the binary data stream corresponding to any OLE object to obtain more than one file stream from each sector of the binary data stream;

[0040] A file stream type determination module is used to traverse each file stream and determine the file type of the file stream according to the value of the category identification field in the file stream;

[0041] The recording module is used to store the file stream and record the corresponding address information and file type if the file type reflects that the file stream belongs to a source file or a display file, so as to read the file stream according to the corresponding address information when displaying the target drawing file and display the file stream in a manner corresponding to its own file type.

[0042] In a third aspect, the present application provides a computer device comprising one or more processors and a memory, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the one or more processors, the steps of the OLE object parsing method in any of the above embodiments are executed.

[0043] In a fourth aspect, a storage medium stores computer-readable instructions, and when the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the OLE object parsing method in any of the above embodiments.

[0044] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

[0045] Based on the OLE object parsing method provided by the present application, firstly, one or more binary data streams corresponding to OLE objects are extracted from the target drawing file, then for each binary data stream, more than one file stream is extracted and combined from each sector thereof, then each file stream is traversed, and the file type is determined according to the value of the category identification field in the file stream, and finally, if the file type indicates that the file stream belongs to a source file or a display file, the file stream is stored and the address information and file type are recorded, so that the file stream can be displayed in a corresponding manner when the target drawing file is displayed. Through this series of steps, the OLE object can be accurately and comprehensively parsed, and the binary data originally discrete in the sectors can be combined into a complete and continuous file stream. Determining the file type lays the foundation for subsequent correct display, so that different types of file streams can be displayed according to their own characteristics, so that various types of information originally embedded in the drawing file can be presented clearly and completely, which provides great convenience for users to view and use various embedded information in the drawing file in the Linux environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0047] Figure 1 A flowchart of an OLE object parsing method provided by one embodiment of the present application;

[0048] Figure 2 A schematic diagram of a process for extracting a binary data stream corresponding to an OLE object in one embodiment of the present application;

[0049] Figure 3 This is a schematic diagram of a process of combining file streams in one embodiment of the present application;

[0050] Figure 4 An internal structure diagram of a computer device provided for one embodiment of the present application. DETAILED DESCRIPTION

[0051] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0052] This application provides an OLE object parsing method, see Figure 1 , including steps S102 to S108.

[0053] S102, extracting binary data streams corresponding to one or more OLE objects from the target drawing file.

[0054] It is understood that this application is mainly aimed at the use of CAD software in the Linux environment. The target drawing file is the specific drawing file targeted by this operation. It can be various types of drawing files such as engineering drawings, design drawings, and architectural blueprints. These files may contain rich graphic information, annotations, and other related data, and are stored in a specific file format, such as the common DWG format. The target drawing file contains OLE objects, which are other files embedded or linked to external applications, such as Excel tables, Word documents, or image files.

[0055] When processing drawing files containing OLE objects, you first need to extract these OLE objects from the drawing files, which exist in the form of binary data streams. Due to the complexity and diversity of drawing files, their internal storage structures may be different, but they all follow certain file format specifications. By analyzing the file format of the target drawing file during the deserialization process, you can determine the location of the OLE object in the binary data of the target drawing file and extract it. Since the target drawing file can include one or more OLE objects, all OLE objects need to be extracted separately when extracting.

[0056] S104: For any binary data stream, extract and combine sectors of the binary data stream to obtain more than one file stream.

[0057] It can be understood that each binary data stream corresponds to an OLE object, and the OLE object is composed of a file header and a sector part. The sector part includes multiple sectors. In order to ensure data security and facilitate storage, different files in the OLE object will be discretized into several binary data stream fragments according to a certain length. These fragments are randomly saved in various sectors, which causes the file stream storage to be discontinuous and needs to be restored to continuous data before it can be used normally. The sequence of these data is also recorded in a specific sector part (such as a FAT sector), and the location information and quantity information of these sectors related to the sequence of data are recorded in the file header part of the binary data stream, so the content recorded in the file header part can support the extraction of each file stream from the corresponding sector in the order of sequence from the sector part, and splicing into a file stream corresponding to each file in the OLE object.

[0058] S106, traversing each file stream, and determining the file type of the file stream according to the value of the category identification field in the file stream.

[0059] It can be understood that the category identification field is a data field at a specific position in the file stream, which is used to identify the file type to which the file stream belongs. The value of this field is set according to a certain standard or specification, based on which a first mapping relationship between the file type and the value of the category identification field can be established. By reading the value of this field and the first mapping relationship, it can be determined what type of file the file stream belongs to. For example, its value may indicate a Word document type, an Excel table type, an image file type (such as wmf, bmp, emf, etc.) or other application-specific file types.

[0060] Specifically, OLE objects are written according to a variety of set data structures. These data structure types have corresponding names, and the file stream specifies the data structure based on the name. Each data structure contains different fields and the fields are located in different positions. Therefore, a corresponding reading method can be set for each data structure. After identifying the data structure of the current file stream according to the name, the corresponding method is selected for reading. In OLE2.0, the data structures used are OLEStream, OLEPresentationStream, OLENativeStream, CompObjStream, etc., corresponding to the names "\2OlePre", "\2OlePre", "\1Ole10Native", and "\1CompObj" respectively. Taking the file stream of type OLEPresentationStream as an example, the Clipboard field in the ClipboardFormatOrAnsiString structure at the beginning is the category identification field. If the value is "0x00000002", it corresponds to a 16-bit bmp file; if the value is "0x00000003", it corresponds to a wmf file; if the value is "0x00000008", it corresponds to a dib file (Device-Independ-Bitmap, including png / jpeg / bmp format files); if the value is "0x0000000E", it corresponds to an emf file. These files are all display files.

[0061] S108, if the file type reflects that the file stream belongs to a source file or a display file, the file stream is stored, and the corresponding address information and file type are recorded, so that when the target drawing file is displayed, the file stream is read out according to the corresponding address information and the file stream is displayed in a manner corresponding to its own file type.

[0062] It can be understood that the source file refers to the editable file contained in the target drawing file, such as a Word document, an Excel table, etc. Clicking on these source files can jump from the CAD software to the corresponding application for editing. The display file refers to a file used to display the content directly in the target drawing file. The display file can only be displayed in the target drawing file and cannot be edited, such as a vector file (wmf / emf) or a bitmap data (png / jpeg / bmp), etc. The two files, source file and display file, are the files that need to be displayed together when displaying the target drawing file. Of course, the display of the display file is to display the content contained in it, but the display of the source file mainly displays an interactive object, and the content contained in it also needs to rely on the corresponding display file for display, such as a source file of Word document type, and also contains an emf or wmf type display file to display the document content. The file type set belonging to the source file and the display file can be pre-set, and the judgment can be completed in step S108 according to whether the file type of the file stream belongs to the file type set.

[0063] Therefore, during the entire OLE object parsing process, the file streams determined as source files or display files are stored and recorded in order to accurately restore the contents of the OLE object when displaying the target drawing file. After determining that the file streams belong to the source file or display file, storing these file streams can save them to a suitable storage medium (such as memory or disk) for subsequent use. The address information is recorded in order to quickly locate and read these file streams, because when displaying the drawing file, the file stream needs to be accurately found based on these address information. The display method corresponding to the file type is based on the characteristics of different file types, ensuring that the OLE object can be presented to the user in the correct form, reducing the problem of garbled characters, and can also support the display of all elements such as text, lines, curves, etc., making the displayed content more complete, so as to ensure that what the user sees is complete and correct.

[0064] Based on the OLE object parsing method provided by the present application, firstly, one or more binary data streams corresponding to OLE objects are extracted from the target drawing file, then for each binary data stream, more than one file stream is extracted and combined from each sector thereof, then each file stream is traversed, and the file type is determined according to the value of the category identification field in the file stream, and finally, if the file type indicates that the file stream belongs to a source file or a display file, the file stream is stored and the address information and file type are recorded, so that the file stream can be displayed in a corresponding manner when the target drawing file is displayed. Through this series of steps, the OLE object can be accurately and comprehensively parsed, and the binary data originally discrete in the sectors can be combined into a complete and continuous file stream. Determining the file type lays the foundation for subsequent correct display, so that different types of file streams can be displayed according to their own characteristics, so that various types of information originally embedded in the drawing file can be presented clearly and completely. It provides great convenience for users to view and use various embedded information in drawing files in a Linux environment.

[0065] In one embodiment, see Figure 2 , extracting binary data streams corresponding to more than one OLE object from the target drawing file, including steps S202 to S204.

[0066] S202 , during the process of deserializing entity classes of different categories in the target drawing file, determining whether the entity class currently being deserialized belongs to the target class.

[0067] It can be understood that in the field of computer-aided design, an entity class can represent various elements in a drawing, such as a straight line, a circle, etc. In this embodiment, an OLE object can be defined as an entity class using a custom entity interface provided by computer-aided software. For example, ZcRxObject is opened as a custom entity interface in Zhongwang CAD, and the entity class related to OLE is ZcDbOle2Frame. The entity class contains an OLE object in CFB format (Microsoft Compound File Binary, CFB). In the process of loading the target drawing file, each entity class needs to be deserialized. In the process of deserialization, the binary data stream of each entity class will be converted. In order to extract the binary data stream corresponding to the OLE object, it is necessary to monitor and filter the entire deserialization process, and set the above-mentioned entity class related to OLE as the target class. In the deserialization process, it is determined whether the entity class currently being deserialized belongs to the target class. If it belongs to the target class, it means that each object in the current entity class is an OLE object, and the deserialized object of each object is the binary data stream corresponding to the OLE object. Specifically, the type information of the entity class currently being serialized can be obtained through the metadata of the entity class object or a specific type identifier. For example, if the entity class is implemented through a class inheritance system, we can use the C++ typeid operator to obtain the type of the entity class.

[0068] S204: If yes, then use the deserialized objects of each object in the target class as binary data streams, and establish an OLE object index table with the handles of each object in the target class as keys and the corresponding binary data streams as values.

[0069] It can be understood that a handle is an identifier used to identify an object in an operating system or programming environment. The handle of each object in the target class is a mechanism for uniquely identifying an OLE object entity class object. A specific OLE object can be accurately referenced and operated through the handle. A handle is usually an integer value or other specific type of data structure, which is assigned by the operating system or program when the object is created and remains unchanged during the life cycle of the object. The corresponding handle can be obtained during the deserialization of the object in the target class. Such as ZcDbHandle in ZWCAD. In order to facilitate the indexing of the binary data stream corresponding to each OLE object, the corresponding binary data stream is associated with the handle as a value in this embodiment, and an OLE object index table is established. Each OLE object can be accurately identified through the handle to avoid confusion.

[0070] In one embodiment, see Figure 3For any binary data stream, more than one file stream is extracted and combined from each sector of the binary data stream, including steps S302 to S310.

[0071] S302, traversing each object included in the OLE object index table, and obtaining a target binary data stream based on the handle of the traversed object and the OLE object index table.

[0072] It can be understood that the target binary data stream is a specific binary data stream to be obtained in the current step, which corresponds to one of the OLE objects. The target binary data stream is composed of a file header and a sector part. This embodiment needs to extract one or more discrete file streams contained in the OLE object from the sector part and combine them into a continuous one.

[0073] S304, constructing a sector configuration table according to the file header of the target binary data stream, and determining all directory sectors corresponding to the directory stream according to the sector configuration table.

[0074] It can be understood that in a binary data stream in CFB format, the file header (Header) is at the beginning of the entire binary data stream, and its size is also fixed, such as 512 bytes. The file header will serve as the metadata of the binary data stream and provide reference information for combining the file stream. Therefore, before starting step S304, it can be determined whether the target binary data stream is a legal CFB format data. Specifically, it can be determined whether the value of the first number of bytes before the target binary data stream is the same as the first combination. The values ​​of the first 8 bytes of the file header in CFB format are a fixed combination, so it can be used as the basis for determining whether it is in CFB format. Specifically, the first combination is 0xD0, 0xCF, 0x11, 0xE0, 0xA1, 0xB1, 0x1A, 0xE1 in sequence. If the value of the first number of bytes before the target binary data stream is the same as the first combination, it can be determined that the target binary data stream is indeed in CFB format. The file header length in CFB format is fixed, and the second number is set according to the fixed value. Then the first second number of bytes of the target binary data stream can be determined as the file header, and the rest can be determined as the sector portion. Otherwise, it can be determined that the current target binary data stream is not in CFB format, and the process returns to step S302 to select another binary data stream to be traversed as the target binary data stream.

[0075] In some embodiments, in order to prevent data reading errors, a legal verification mechanism will be added. That is, between determining the file header and starting to build the sector configuration table. First read the value of the file header at the first offset position to determine the number of sectors. Since the size of each sector is fixed, the theoretical data length of the sector portion of the target binary data stream can be determined based on the sector size and the number of sectors. If the theoretical data length is the same as the actual data length of the sector portion, it means that the target binary data stream is legal and valid, and the step of building the sector configuration table can be started, otherwise it should return to step S302 and select another binary data stream as the target binary data stream.

[0076] The Sector Allocation Table (SAT) is a data table built based on the file header information of the target binary data stream. It is used for recording. It contains the sector chains of all streams (except short-streams) and other internal control streams (short-stream container stream, short sector allocation table, directory). The size of the sector allocation table (that is, the length of the storage SecD array) is equal to the number of existing sectors in the CFB.

[0077] The construction of the sector configuration table requires reference to the information carried in the file header, in which the data involved are DIFAT, FAT and MiniFAT. The value of the DIFAT data represents the sector number, and the sector represented stores the FAT array. The first 109 elements of the DIFAT array are stored in the Header structure. However, if a file exceeds 6.875M, another sector is required to store the DIFAT array. The relevant information is stored in the 8 bytes at the file header offset 0x44, which specifically records the starting sector identifier and the number of sectors storing the DIFAT data. Each sector can store 127 DIFAT arrays, and the last element indicates the number of the next sector (512Byte / 4Byte = 128). By reading the data stored in these sectors, the DIFAT array corresponding to the larger file can be constructed. After the DIFAT array is constructed, the FAT array information can be read from the corresponding sector, with 128 FAT array elements in each sector. In the read FAT array, the subscript of the array is the sector number, and the value of the array represents the number of the next sector or a special value. Special values ​​include 0xFFFFFFFB for reserved sectors, 0xFFFFFFFC for DIFAT sectors, 0xFFFFFFFD for FAT sectors, and 0xFFFFFFFE for the end of the one-way linked list. After reading the value of the array, determine whether it is a special value. If not, the number of the next sector can be read and added to the one-way linked list. If so, and the value is the same as 0xFFFFFFFE, it means the end of the one-way linked list. Therefore, each FAT array can construct a one-way linked list of sectors, and each one-way linked list is a component of the sector configuration table. Similarly, the 8 bytes at byte offset 0x3C in the file header record the MiniFAT starting sector ID and number. The contents of these sectors can be read to construct the MiniFAT array, and each MiniFAT array can also construct a one-way linked list of sectors. The one-way linked lists obtained based on these two arrays only have different corresponding data lengths. If the file length exceeds 4096 bytes, the one-way linked list corresponding to the FAT array will be called, otherwise the one-way linked list corresponding to MiniFAT will be called.

[0078] A directory is an internal control stream, consisting of a series of directory entries. Each directory entry points to a storage or stream of a compound document, and records the key information of the corresponding storage or stream, such as the file name, data start sector index value, file data length, file CLSID information, etc. Therefore, in order to read data from a directory entry, it is necessary to first find the sector corresponding to the directory from the sector part, that is, the directory sector. The index information of the directory sector is also recorded in the file header, specifically, the 4-byte start sector identifier of the directory at byte offset 0x30. According to the start sector identifier of the directory, a one-way linked list matching the start sector can be found from the sector configuration table, and the sector recorded in the one-way linked list is the directory sector.

[0079] S306, traverse all directory entries in the directory sector, and determine whether the entry type of the traversed directory entry is a file stream entry.

[0080] S308, if not, continue traversing, if yes, extract the file stream starting sector identifier from the current directory entry.

[0081] It can be understood that by reading each directory sector in sequence according to the order of the above-mentioned one-way linked list, and extracting and combining the data therein, a complete directory stream can be obtained. Since the directory entries are arranged in sequence in the directory stream, and the length of each directory entry is fixed (such as 128 bytes), the entire directory stream can be traversed according to the fixed length. According to the above description, each directory entry may correspond to a warehouse or a stream (i.e., the file stream mentioned in this application), and the source file and the display file are both a kind of stream, so this step only needs to select the target entry corresponding to the stream. The specific determination of the type of the directory entry can be based on the value of the directory entry at the second offset position, and its value has a corresponding relationship with the stream or warehouse corresponding to the directory entry. If the value of the traversed directory entry at the second offset position is the same as the second combination, the entry type is determined to be a file stream entry, otherwise it is determined to be not a file stream entry. The second offset position here can be four bytes at 0x66, and the second combination is 0x02.

[0082] If the current entry does not correspond to the file stream, the process should return to step S306 to continue traversing the next target entry to be traversed. Otherwise, the relevant information of the combined file stream, i.e., the file stream starting sector identifier, should be extracted from the directory entry. The file stream starting sector identifier is specifically recorded in 4 bytes at 0x78 of the directory entry. Of course, in some embodiments, in order to facilitate more accurate and efficient display of source files or display of files in the subsequent process, some specific types of information in the directory entry can also be extracted to form a file thumbnail information table. This information can be file name, file data length, and file CLSID information. Specifically, 64 bytes at byte offset 0x00 record the file name, 2 bytes at byte offset 0x40 record the file name length, 16 bytes at byte offset 0x50 record the file CLSID, and 8 bytes at byte offset 0x7c record the file byte length. The relationship between the file name and the corresponding file thumbnail information table can be stored using a red-black tree structure. The address information described in the above embodiment can also be added to the file thumbnail information table. When traversing each file stream, the traversal order can be selected by traversing the red-black tree structure, thereby improving the search efficiency.

[0083] S310, according to the file stream start sector identifier and the sector configuration table, sequentially extract and splice the file stream sectors related to the file stream corresponding to the current directory entry to obtain the file stream corresponding to the current directory entry.

[0084] It can be understood that the sector configuration table records multiple one-way linked lists. According to the file stream start sector identifier, the corresponding sector chain is found from the sector configuration table, that is, the sector chain whose first sector identifier in the sector chain is the same as the file stream start sector identifier. According to the sector chain, the corresponding file stream sector and reading order are determined in the sector part. According to the reading order, each file stream sector is read in turn, and the reading results are spliced ​​to obtain the file stream corresponding to the current directory entry.

[0085] In one of the embodiments, in order to increase the error prevention mechanism, after obtaining the file stream and before determining the file type, the validity of the file stream can be checked according to the characteristics of the data structure corresponding to the file stream. That is, the values ​​of some data structures in specific fields are set values ​​that are irrelevant to the content of the file stream itself. Based on this feature, a verification mechanism can be designed for each data structure of the file stream. Specifically, these specific fields can be determined as target fields, and the above-mentioned set values ​​are determined as set valid values. By reading the values ​​of more than one target field of the file stream, it is determined whether he or they all belong to the set valid values. If so, it means that the file stream is compliant, and the step of determining the file type of the file stream according to the value of the category identification field in the file stream is executed. If not, it means that the file stream is not compliant, and other file streams to be traversed should be selected to continue traversing. In addition, if the verification is qualified, the value of the target field can also be recorded as fingerprint information together with the file type, thumbnail information table, etc. of the file stream.

[0086] Specifically, taking the file stream of the OLEPresentationStream structure as an example, first read the field corresponding to the ClipboardFormatOrAnsiString structure signature at the beginning, and the legal values ​​of its signature are limited to "0x00000000", "0xFFFFFFFE" and "0xFFFFFFFF". Then check the value of the Clipboard field, and the legal values ​​are limited to "0x00000002", "0x00000003", "0x00000008" and "0x0000000E". Then check the TocSignature field, and the legal value is "0x494E414E". You can also read the length information (size) of the file stream. The verification can only be passed if the theoretical length information matches the actual length. It is worth mentioning that the TocSignature field is located at the end of the file stream. After reading the fields in the file stream header, the body part can be skipped according to the length information of the file stream record, so as to read the TocSignature field.

[0087] The present application provides an OLE object parsing device, comprising:

[0088] A binary data stream extraction module is used to extract binary data streams corresponding to more than one OLE object from a target drawing file;

[0089] A file stream combination module, for extracting and combining, for any binary data stream, sectors of the binary data stream to obtain more than one file stream;

[0090] A file stream type determination module is used to traverse each file stream and determine the file type of the file stream according to the value of the category identification field in the file stream;

[0091] The recording module is used to store the file stream and record the corresponding address information and file type if the file type reflects that the file stream belongs to a source file or a display file, so as to read the file stream according to the corresponding address information when displaying the target drawing file and display the file stream in a manner corresponding to its own file type.

[0092] For the specific definition of the OLE object parsing device, please refer to the definition of the OLE object parsing method above, which will not be repeated here. The various modules in the above-mentioned OLE object parsing device can be implemented in whole or in part by software, hardware and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules. It should be noted that the division of modules in the embodiments of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0093] The present application provides a computer device, including one or more processors and a memory, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the one or more processors, the steps of the OLE object parsing method in any of the above embodiments are executed.

[0094] Indicatively, if Figure 4 As shown, Figure 4 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of the present application. Figure 4 , the computer device 400 includes a processing component 402, which further includes one or more processors, and a memory resource represented by a memory 401, for storing instructions executable by the processing component 402, such as an application. The application stored in the memory 401 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 402 is configured to execute instructions to perform the steps of the OLE object parsing method of any of the above embodiments.

[0095] The computer device 400 may further include a power supply component 403 configured to perform power management of the computer device 400 , a wired or wireless network interface 404 configured to connect the computer device 400 to a network, and an input / output (I / O) interface 405 .

[0096] Those skilled in the art will understand that Figure 4 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0097] The present application provides a storage medium, in which computer-readable instructions are stored. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the OLE object parsing method in any of the above embodiments.

[0098] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can refer to each other.

[0099] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An OLE object parsing method, characterized in that: include: Extracting binary data streams corresponding to more than one OLE object from a target drawing file; specifically comprising: in the process of deserializing entity classes of different categories in the target drawing file, determining whether the entity class currently being deserialized belongs to the target class; if so, using the deserialized objects of each object in the target class as the binary data stream; For any binary data stream, extract and combine from each sector of the binary data stream to obtain more than one file stream; specifically comprising: constructing a sector configuration table according to the file header of the target binary data stream, and determining all directory sectors corresponding to the directory stream according to the sector configuration table; traversing all directory entries in the directory sector, and judging whether the entry type of the traversed directory entry is a file stream entry; if not, continuing the traversal, and if so, extracting the file stream starting sector identifier from the current directory entry; according to the file stream starting sector identifier and the sector configuration table, sequentially extracting and splicing from the file stream sectors related to the file stream corresponding to the current directory entry to obtain the file stream corresponding to the current directory entry; Traversing each of the file streams, and determining the file type of the file stream according to the value of the category identification field in the file stream; If the file type reflects that the file stream belongs to a source file or a display file, the file stream is stored, and the corresponding address information and the file type are recorded, so that when the target drawing file is displayed, the file stream is read out according to the corresponding address information and the file stream is displayed in a manner corresponding to the file type itself.

2. The OLE object parsing method according to claim 1, characterized in that: The step of extracting the binary data stream corresponding to more than one OLE object from the target drawing file also includes: In the case that the entity class currently being deserialized belongs to the target class, an OLE object index table is established with the handles of each object in the target class as keys and the corresponding binary data stream as values.

3. The OLE object parsing method according to claim 2, characterized in that: The step of constructing a sector configuration table according to the file header of the target binary data stream, and determining all directory sectors corresponding to the directory stream according to the sector configuration table, further includes: Each object contained in the OLE object index table is traversed, and the target binary data stream is obtained based on the handle of the traversed object and the OLE object index table.

4. The OLE object parsing method according to claim 3, characterized in that: Before constructing the sector configuration table according to the file header of the target binary data stream, the method further includes: Determining whether the values ​​of the first number of bytes before the target binary data stream are the same as the first combination; If yes, the first second number of bytes of the target binary data stream are determined as the file header, and the rest of the target binary data stream are determined as the sector portion; If not, continue to traverse each object contained in the OLE object index table.

5. The OLE object parsing method according to claim 4, characterized in that: After determining the first second number of bytes of the target binary data stream as the file header, the method further includes: Reading the value of the file header at the first offset position to determine the number of sectors; Determining whether the data length of the sector portion matches the number of sectors; If yes, then proceed to the step of constructing a sector configuration table according to the file header of the target binary data stream and continue to execute; If not, continue to traverse each object contained in the OLE object index table.

6. The OLE object parsing method according to claim 4, characterized in that: The step of sequentially extracting and splicing file stream sectors related to the file stream corresponding to the current directory entry according to the file stream start sector identifier and the sector configuration table to obtain the file stream corresponding to the current directory entry includes: Finding a corresponding sector chain from the sector configuration table according to the file stream starting sector identifier; According to the sector chain, determining corresponding file stream sectors and a reading order in the sector portion; The file stream sectors are read in sequence according to the reading order, and the reading results are spliced ​​to obtain the file stream corresponding to the current directory entry.

7. The OLE object parsing method according to claim 3, characterized in that: The determining whether the entry type of the traversed directory entry is a file stream entry includes: If the value of the traversed directory entry at the second offset position is the same as the second combination, the entry type is determined to be the file stream entry; otherwise, it is determined not to be the file stream entry.

8. The OLE object parsing method according to claim 1, characterized in that: Before determining the file type of the file stream according to the value of the category identification field in the file stream, the method further includes: Determining whether the values ​​of more than one target field in the file stream are all set valid values; If yes, then executing the step of determining the file type of the file stream according to the value of the category identification field in the file stream; If not, continue traversing the file stream.

9. An OLE object parsing device, characterized in that: include: The binary data stream extraction module is used to extract binary data streams corresponding to more than one OLE object from the target drawing file; specifically, it includes: in the process of deserializing entity classes of different categories in the target drawing file, it is determined whether the entity class currently being deserialized belongs to the target class; if so, the deserialized objects of each object in the target class are used as the binary data stream; The file stream combination module is used for extracting and combining more than one file stream from each sector of the binary data stream for any binary data stream; specifically comprising: constructing a sector configuration table according to the file header of the target binary data stream, and determining all directory sectors corresponding to the directory stream according to the sector configuration table; traversing all directory entries in the directory sector, and judging whether the entry type of the traversed directory entry is a file stream entry; if not, continuing the traversal, and if so, extracting the file stream starting sector identifier from the current directory entry; according to the file stream starting sector identifier and the sector configuration table, sequentially extracting and splicing from the file stream sectors related to the file stream corresponding to the current directory entry to obtain the file stream corresponding to the current directory entry; A file stream type determination module, used for traversing each of the file streams and determining the file type of the file stream according to the value of the category identification field in the file stream; A recording module is used to store the file stream and record the corresponding address information and the file type if the file type reflects that the file stream belongs to a source file or a display file, so as to read the file stream according to the corresponding address information when displaying the target drawing file and display the file stream in a manner corresponding to the file type itself.

10. A computer device, characterized in that: The method comprises one or more processors and a memory, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the one or more processors, the steps of the OLE object parsing method according to any one of claims 1 to 8 are executed.

11. A storage medium, characterized in that: The storage medium stores computer-readable instructions, and when the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the OLE object parsing method according to any one of claims 1 to 8.

Images