WO2011079796A1

WO2011079796A1 - Method for compressing.net document

Info

Publication number: WO2011079796A1
Application number: PCT/CN2010/080459
Authority: WO
Inventors: 陆舟; 于华章
Original assignee: 北京飞天诚信科技有限公司
Priority date: 2009-12-30
Filing date: 2010-12-29
Publication date: 2011-07-07

Abstract

A method for compressing.net document is provide, in which the method includes at least one of the following steps: obtaining a reference type in the.net document and compressing the reference type; obtaining a definition method in the.net document and compressing the definition method; obtaining a method body of the definition method in the.net document and compressing the method body; obtaining a name space in the.net document and compressing the name space; obtaining a definition type in the.net document and compressing the definition type. By compressing the.net document, the memory capacity occupied by the.net document can be effectively reduced, so that the.net document can be stored and operated on a memory medium such as an intelligent card with a small capacity.

Description

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a computer application or to a .net file compression method. BACKGROUND OF THE INVENTION Net is Microsoft's next-generation technology platform. It is a new Internet-based cross-language software development platform that conforms to today's software industry distributed computing, component-oriented, enterprise-level applications, software, and Web-centric. Trend. .net is not a development language, but it can support multiple development languages on the .net development platform, such as 语言#language, C++, Visual Basic, Jscript, etc. A smart card is a plastic card that is similar in size to a normal business card. It contains a silicon chip with a diameter of about 1 cm and has the function of storing information and performing complex calculations. It is widely used in telephone cards, financial cards, identification cards, and mobile phones, pay TV and other fields. Among them, the smart card chip integrates a microprocessor, a memory, and an input/output unit, so that the smart card is considered to be the world's smallest electronic computer. Moreover, the smart card has a set of strong security and security control mechanisms, and the security control program is solidified in the read-only memory, thus having reliable security guarantees such as the inability to copy passwords. Compared with ordinary magnetic cards, smart cards also have a large information storage capacity, and the advantages of the card function can be increased by using a microprocessor.

A .net card is a smart card that contains a .net card virtual machine that can run .net programs. The so-called virtual machine means that it can be imagined as a machine that is simulated by software. In this machine, there are various hardware such as processors, memory, registers, etc., which simulate various commands and software running on this machine. There are no special requirements for the runtime environment, so the virtual machine is transparent to the programs running on it. For example, the x86 virtual machine simulates the operating environment of the x86 instruction program, and the c51 virtual machine simulates the operating environment of the c51 instruction program.

.net programs include namespaces, reference types, definition types, definition methods, reference methods, IL (Intermediate Language) code, and more. However, due to the limitation of the size and storage chip, the current smart card still has limited storage space. With the development of software, some programs with large functions occupy a large storage space, and many .net programs cannot be stored and run. In summary, the .NET program in the related art has a poor compression effect and cannot be stored and operated on a small-capacity storage medium (for example, a smart card), and an effective solution has not been proposed for this problem. SUMMARY OF THE INVENTION The present invention is directed to a compression method for a .net file, which can solve the problem that the .net program has a poor compression effect and cannot be stored and operated on a small-capacity storage medium (for example, a smart card). In an embodiment of the present invention, a method for compressing a .net file is provided, the method comprising at least one of the following steps: obtaining a reference type in a .net file, compressing the reference type; obtaining . net a definition method in the file, compressing the definition method; obtaining a method body of the definition method in the .NET file, compressing the method body; obtaining a namespace in the .net file, and compressing the namespace Get the definition type in the .net file and compress the definition type. By compressing the .net file, the invention effectively reduces the storage capacity occupied by the .net file, and facilitates the use of the net file on a small storage device, which also saves resources and improves resource utilization. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are set to illustrate,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 1 is a structural block diagram of a compression device of a reference type in a .NET file provided by Embodiment 1 of the present invention; FIG. 2 is a block diagram showing a specific structure of a reference type name obtaining module according to Embodiment 1 of the present invention; 2 is a flowchart of a compression method of a reference type in a .NET file provided; FIG. 4 is a flowchart of a compression method of a reference type in a .NET file provided by Embodiment 3 of the present invention; 5 is a schematic structural diagram of a .NET file provided by Embodiment 3 of the present invention; FIG. 6 is a flowchart of a method for counting and counting a method of a statistical reference type according to Embodiment 3 of the present invention; FIG. 7 shows an embodiment of the present invention. 4 is a flowchart of a compression method for defining a method of a .NET file; FIG. 8 is a flowchart showing a compression method of a method for defining a .NET file according to Embodiment 5 of the present invention; FIG. 9 shows the present invention. A flowchart of a method for constructing a character string using the definition method information in the .NET file provided in Embodiment 5; FIG. 10 is a flowchart showing a method for compressing a data item specific to the big header method according to Embodiment 5 of the present invention; FIG. 12 is a structural block diagram of a compression device of a method body for defining a .NET file according to Embodiment 6 of the present invention; FIG. 13 is a structural block diagram of a compression method of a method body for defining a .NET file according to Embodiment 6 of the present invention; A block diagram of a compression method of a method body of a method for defining a .NET file; FIG. 14 is a flowchart of a method for compressing a method body of a method for defining a .NET file according to Embodiment 8 of the present invention; A flowchart of a method for compressing a method body of a method for defining a .NET file according to Embodiment 9 of the present invention; FIG. 16 is a flowchart of a method for compressing a method body for defining a .NET file according to Embodiment 10 of the present invention; FIG. 18 is a schematic diagram of a method for obtaining a method header according to Embodiment 10 of the present invention; FIG. 18 is a schematic diagram of a data format of a method for providing a header according to Embodiment 10 of the present invention; 20 is a schematic diagram of a data format of a small head method according to Embodiment 10 of the present invention; FIG. 21 is a flowchart of a method for compressing ILcode according to Embodiment 10 of the present invention; and FIG. 22 is a .net file provided by Embodiment 11 of the present invention. FIG. 23 is a flowchart of a method for compressing a namespace in a .NET file according to Embodiment 12 of the present invention; FIG. 24 is a schematic diagram showing a structure of a .NET file according to Embodiment 12 of the present invention; 25 is a structural diagram of a compression device of a type defined in the .NET file provided in Embodiment 13; FIG. 26 is a flowchart showing a compression method of a type defined in the .NET file provided in Embodiment 14. FIG. A schematic diagram of the structure of a .NET file provided in Embodiment 14; FIG. 28 is a flowchart showing a compression method of a type defined in the .NET file provided in Embodiment 15. BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, the present invention will be described in detail with reference to the accompanying drawings in conjunction with the embodiments. The invention will be described in detail below with reference to the drawings in conjunction with the embodiments. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict. The implementation of the technical solution is further described in detail below with reference to the accompanying drawings: Embodiment 1 This embodiment provides a compression device of a reference type in a .NET file. As shown in FIG. 1, the device includes: a reference type name acquisition module. 102. The compression module 104, the statistics module 106, and the combination module 108, the functions of each module are as follows: a reference type name obtaining module 102, configured to obtain a name of a reference type used in a .net file; and a compression module 104, configured to reference a type The name of the reference type obtained by the name obtaining module 102 is compressed to obtain the name of the compressed reference type; The statistics module 106 is configured to collect a method count and a field count of the reference type obtained by the reference type name obtaining module 102. The combining module 108 is configured to: name the reference type compressed by the compression module 104 according to a predetermined format, and the statistics module 106. The calculated method count and field count are combined to obtain a compression result of the reference type. The reference type name obtaining module 102 can obtain the name of the reference type in a plurality of manners. This embodiment is described by using FIG. 2 as an example. As shown in FIG. 2, the reference type name obtaining module provided in this embodiment is used. The specific structure block diagram, the reference type name obtaining module 102 includes: a first metadata table obtaining unit 1022, configured to obtain a first metadata table in the .net file; and a plurality of tables included in the .net file, in this embodiment The metadata table TypeRef (reference type or interface table) is used as the first metadata table, which records the name of the reference type used in the .NET file and the namespace to which the reference type belongs. The address information reading unit 1024 is configured to read the address information of the name of the reference type used in the .NET file from the first metadata table acquired by the first metadata table obtaining unit 1022; the reference type name reading unit 1026 And for reading the name of the reference type based on the address information read by the address information reading unit 1024. Preferably, the algorithm used by the compression module 104 for compression may be a hash algorithm, and specifically, may be MD5, SHA-1 or SHA-2. The statistics module 106 may perform statistics on the information recorded in the second metadata table when the method count and the field count are performed, wherein the second metadata table is a metadata table MemberRef in the .net file, and each row in the table The data records the reference type information and the feature identification value. According to the data in the type information, the current row data can be determined to point to the reference type of the first row of the first metadata table TypeRef, and then the reference type pointed to by the current row data is determined. The data in the feature identifier value is used to indicate whether the current row data record is a method or a field. According to the data in the feature identifier value, the method count and the field count corresponding to the name of each reference type can be counted. Preferably, the predetermined format in the combination module 108 is a fixed length byte, and the fixed length byte includes three parts, wherein the first part is the name of the compressed reference type, and the second part is the method count, The three parts are the field counts. These three parts can be combined arbitrarily. The purpose of including method counts and field counts in the compression result of a reference type is: when .net When other parts of the piece are also compressed, the corresponding method can be found according to the method, and the corresponding field is found according to the field count, so that the compressed reference type can be used normally. The compression module 104 in this embodiment compresses the name of the reference type obtained by the reference type name obtaining module 102, and the combination module 108 calculates the name of the reference type compressed by the compression module 104 and the statistical module 106. Counting and field counting are combined to obtain a compressed reference type, which can effectively reduce the storage space occupied by the .net file, so that the .net file can be stored and run on a small-capacity storage medium (for example, a smart card), thereby enhancing the small size. The function of a capacity storage medium (for example, a smart card). Embodiment 2 This embodiment provides a compression method of a reference type in a .NET file. The method is described as an example of running in the compression device provided in Embodiment 1. As shown in FIG. 3, the method includes: Step 202 : obtaining the name of the reference type used in the .net file; Step 204: Compressing the name of the reference type to obtain the name of the compressed reference type; Step 206: Counting the method count and the field count of the reference type; Step 208: Combine the name of the compressed reference type, the method count, and the field count according to a predetermined format to obtain a compression result of the reference type. Preferably, the step 202 specifically includes: acquiring a first metadata table in the .net file; reading address information of a name of the reference type used in the .net file from the first metadata table; reading the above according to the address information The name of the reference type. Preferably, the step 202 may further include the step of generating a reference type name string by using the obtained reference type name, and the reference type name string may be implemented in any one of the following two ways:

1) Convert the name of the reference type obtained above into a predetermined encoding format, such as ASCII encoding, to generate a reference type name string.

2) First obtain the namespace name to which the above reference type belongs; combine the namespace name with the name of the above reference type to generate a reference type name string. The step of compressing the name of the above-mentioned I type includes: hashing the name of the type I for the above I (or the generated reference type name string) to obtain a hash value; taking a predetermined byte of the hash value As the name of the compressed reference type. Among them, the algorithm used in hashing is:

MD5, SHA-1 or SHA-2, etc. Preferably, the step of counting the statistics and the counting of the fields specifically includes: acquiring a second metadata table; performing the following operations on each row of the second metadata table: reading the current row data in the second metadata table a reference type; when the name of the reference type pointed to by the current row data is consistent with the name of the obtained reference type, determining whether the current row data record is a method according to the feature identifier value of the current row data, and if so, the above The method type of the reference type is incremented by 1; otherwise, the field of the above reference type is counted as 1. Preferably, the predetermined format mentioned in step 208 is a fixed length byte, and the fixed length byte includes three parts, wherein the first part is the name of the compressed reference type, and the second part is the method count. The third part is the field count. The first metadata table and the second metadata table may be specifically the metadata table in Embodiment 1, and details are not described herein again. The method provided in this embodiment is explained by taking the implementation in the compression device provided in Embodiment 1 as an example.压缩 Compress the name of the obtained reference type, combine the name of the compressed reference type, and count the method count and field count to obtain the compressed reference type, which can effectively reduce the storage space occupied by the .net file. The .net file can be stored and run on a small-capacity storage medium (for example, a smart card), thereby enhancing the functionality of a small-capacity storage medium (for example, a smart card). Embodiment 3 This embodiment provides a compression method of a reference type in a .NET file, in which an uncompressed file compiled by the i±.net platform is referred to as a .net file. As shown in FIG. 4, the flowchart of the compression method of the reference type in the .NET file provided in this embodiment includes steps 302 to 310, as follows: Step 302: Obtain the first metadata table in the .net file, The first metadata table in the embodiment is specifically a metadata table TypeRef; There are multiple tables in the .net file, where the metadata table TypeRef (reference type or interface table) records the name of the reference type used in the .NET file and the namespace of the reference type. Metadata table As part of the PE (Portable Excutable, Portable Executable) file, this example uses the .net file compiled from the following code as an example: namespace MyCompany. MyOnCardApp { public class My Service: MarshalByRefObject

{

Static Version ver = new Version(l _? 1, 1, 1); static Int32 callCount = 0; static ClassB classb = new ClassB();

String strResult = Boolean.FalseString; public String MySampleMethod()

{

String strHello = "Hello World!"; return strHello + callCount. ToString();

}

} public class ClassB {} public struct StructB{ }

} After compiling the above code using the .net platform, the helloworldexe file is obtained and stored in binary form on the hard disk. The binary file is a .net file, as shown in Figure 5, for this embodiment. A schematic diagram of a .NET file, including a Dos header, a PE feature, and metadata (metadata). The metadata includes a metadata header (metadata header), a metadata table (tables), and the like. The following describes the process of obtaining the metadata table TypeRef: a. Positioning the Dos header of the net file, the Dos header obtained in this embodiment is 0x5 a4d; b. skipping the first agreed byte from the dos header, reading The offset address of the PE feature is obtained, and the offset address of the PE feature is 0x00000080. In this embodiment, the first agreed byte is 0x003a bytes; c. The PE feature is located according to the PE feature offset address 0x00000080. Positioning the PE feature 0x4550; d. Reading the four bytes after the PE feature is shifted backward by the second predetermined byte. In this embodiment, the 32-bit machine is taken as an example for description, and the second agreed byte is used. After offsetting 0x0074 bytes from the PE feature, the data of 4 bytes is read as 0x00000010. This value indicates that there are 0x10 directories in the binary file and contains .net data; where, the metadata header of the .net file The relative virtual address is written in the above OxOF directory,

The second agreed byte in the 64-bit machine is 0x0084 bytes; e. Read eight bytes of data after shifting the third agreed byte backward from the above data 0x00000010, in this embodiment, preferably The third agreed byte is 112 bytes. In the eight bytes of data, the first four bytes are 0x00002008, which is the relative virtual address of the .net data header, and the last four bytes are 0x00000048. The length of the net data header;

The data base of the .net data header gets the linear address 0x00000208, and reads the .net header to get the following data:

48000000020005008C210000A0090000 090000000500000600000000000000005

020000080000000000000000000000000 0000000000000 It should be noted that the above data is stored by the little endian. For example, the first 4 bytes of the above data 0x48000000 is the length of the data, and the storage mode converted to the big end is 0x0000048; in this embodiment, the linear address is. The address of the net data in the .net file, the relative virtual address is the memory offset relative to the PE load point, and the conversion relationship between the linear address and the relative virtual address is: linear address = relative virtual address - section relative virtual address + section File offset, in this embodiment, the relative virtual address of the section of the .net data directory in the .net file is 0x00002000, and the file offset of the section is 0x00000200, then the linear address

=0x00002008-0x00002000+0x00000200=0x00000208; g. The eight-byte data is read after the fourth contract byte is shifted backward by the .net data header. In this embodiment, the fourth agreed byte is from _.net After the data header is shifted backward by 8 bytes, a total of 8 bytes are read. Among the 8 bytes, the first four bytes are 0x0000218c, which is the relative virtual address of the metadata header (MetaData Header). The four bytes are 0x000009a0, which is the length of the metadata; h. The relative virtual address 0x0000218c of the metadata header is converted to the linear address 0x0000038c, and the metadata content is obtained according to the linear address and the metadata length; i. by the metadata header After reading, when reading the flag "#~", read the eight bytes before the flag "#~", where the first four bytes are the address of "#~", which is obtained by the address "#~ "Stream, in the ##" stream, the fifth agreed byte starts reading and starts reading data of length 8 bytes, ie 0x000000092002 lc57, its binary form is 100100100000000000100001110001010111; in this embodiment, the fifth convention The number of bytes is "#~" in the stream. Counting the ninth byte; j. According to the binary data obtained in step i, reading from the lower bit, for example, the first bit represents whether the metadata table Module exists, and if it is 1, the metadata table Module is present, if Yes, the certificate is not present. In this embodiment, there is a metadata table Module, and the second bit is 1 indicating that the metadata table TypeRef exists; wherein, in the data obtained in step i, starting from the lower bit, each bit Represents whether there is a corresponding table in the .net file; k. Reading the number of data rows of the metadata table TypeRef after offsetting the sixth agreed byte after the data 0x000000092002 lc57, in this embodiment, offsetting 12 backwards After reading 4 bytes after the byte, the data OxOOOOOOle is obtained, and it is judged that there are 30 data rows in the metadata table TypeRef; In the metadata, the data 0x000000092002 lc57 is shifted backward by 8 bytes, and the number of data rows of the metadata table existing in the .net file is sequentially stored in units of 4 bytes. After the data representing the number of data rows, the specific content of each metadata table is sequentially stored as a metadata table area; 1. The specific content of the metadata table TypeRef is read according to the agreed method. The agreed method is as follows. The .net file in this embodiment is taken as an example for description. In step j, it is determined that the metadata table Module exists, and the data of the data row number is 1, and the data of the metadata table Module is read. The row data is 10 bytes per row, so in the metadata table area, the backward offset is 10 bytes, the 11th byte starts as the content of the metadata table TypeRef, and the data behavior of the metadata table TypeRef is 30 rows. The data per line is 6 bytes, so the data length of the metadata table TypeRef is 30*6=180 bytes; part of the data of the metadata table TypeRef is as follows:

0600 6100 5A00

0600 7400 5A00

0600 7B00 5A00 0600 8500 5A00

0600 EF00 DD00

0600 0801 DD00

0600 2101 DD00

0600 3C01 DD00 The above data is the first 8 rows of data in the metadata table TypeRef in the .net file provided in this embodiment. In this embodiment, the metadata table TypeRef has 30 rows of data, and the remaining data processing methods are the same, no longer - enumeration. In each row of the above data, from the high to the low, the first two bytes are the coded identifier of the type resolution scope, and the third and fourth bytes are the offset of the name of the reference type in the "#Strings" stream. The last two bytes are the offsets of the namespace name to which the reference type belongs in the "#Strings" stream. For ease of explanation, see Table 1: Table 1

It should be noted that the data in the table uses a big end representation method, for example, the data of the first data line is 0060, 0061, 005a, and the corresponding small end representation method is 0600 6100 5a00^ using the compression method provided by this embodiment. When the initialization method sets the reference count of all reference types to 0, the field count of all reference types is 0, the method of the above reference type counts as the number of methods included in the reference type in the .net file, and the field count of the reference type The number of fields included in the reference type; Step 304: Get the name of the reference type in the .net file, and convert the name of the reference type to the reference type name string; in step 302, obtain the name of the reference type relative to For the offset of the "#Strings" stream, the first reference type in the metadata table TypeRef, that is, the reference type with a relative offset of 0x0061 is taken as an example. The method for obtaining the name of the reference type is as follows: After obtaining the address 0x0000038c of the metadata header in step h in 302, the content is read backward from the metadata header. When the tag "#Strings,," is found, Read the first 8 bytes of "#Strings" to get the data 0x5C0300003C040000; the upper 4 bytes of the data 0x5C0300003C040000 are the offset of the "#Strings" stream relative to the metadata header, the lower 4 bytes are "#Strings" The length of the stream, where the high 4 bytes are converted to the big end, the representation is 0x0000035c, and the lower 4 bytes are converted to the big end, the representation is 0x0000043c; the data header 0x0000038c is offset backward by 0x0000035c. #Strings,,3⁄4f The data area, according to the offset of the first reference type in the metadata table TypeRef, offset by 0x0061 from the head of the "#Strings" stream, and read backward until the end of 00, get the first a reference type The name is 0x4D61727368616C42 795265664F626A656374; The name of the first reference type is converted by the ASC II code to get the reference type name string MarshalByRefDbject. The name reading and conversion methods of other reference types are the same as the name of the first reference type, and will not be described again. ; The reference type name string can also be obtained by: obtaining the name of the reference type, and obtaining the namespace name to which the reference type belongs, and using the connector "" to connect with the name of the reference type to get a reference. The type name string, for example, the namespace of the first reference type belongs to System, and the reference type name string of the first reference type after the name conversion is obtained as follows: System. MarshalByRefDbject; Step 306: Reference type name The string is hashed, and the predetermined byte is taken as the name of the compressed reference type; wherein the algorithm for performing the hash operation may be MD5, SHA-1, SHA-2, etc., in this embodiment, preferably进行 Illustrated with the MD5 algorithm, in step 304 The reference type name string "MarshalByRefDbject" is subjected to the MD5 operation to obtain a 120-bit MD5 value "3064AB63C4B4DC57770E9BDF25B7547D"; in this embodiment, the first two bytes of the MD5 value are preferably taken as the name of the compressed reference type. That is, "3064"; it should be noted that, in this embodiment, the names of a reference type may be sequentially read and compressed to obtain a compression result in the order of steps 302-306, or all the .NET files may be obtained first. Referencing the name of the type, and then compressing the names of the many reference types one by one to obtain the compressed result, and buffering the obtained compression result; Step 308: Counting the method count and the field count of the reference type obtained above; see FIG. 6, The method for counting the method count and the field count of the statistical reference type provided in this embodiment, the method for counting the count of the reference type and the method for counting the field are as follows: Step 3081: Obtain the second metadata table, the second metadata in this embodiment The table is specifically a metadata table MemberRef; in this embodiment, the metadata table MemberR is obtained. The process of ef includes: It can be seen from the binary data 100100100000000000100001110001010111 obtained in the step i of the metadata table TypeRef in step 302 that the reading is started from the lower bit, the 11th bit is 1 indicating that the metadata table exists, and there are 5 1s before the 11th bit. There are five other metadata tables before the metadata table MemberRef; from step k, there are 23 data rows in the metadata table MemberRef, and there are 50 data rows in the five tables before the metadata table MemberRef. Wherein, the metadata table Module includes 1 row of data behavior, the metadata table TypeRef includes 30 rows of data behavior, the metadata table TypeDef includes 6 rows of data behavior, the metadata table Field includes 7 rows of data behavior, and the metadata table Method includes data behavior. 6 lines; according to the method agreed in step 1 in step 302, the data row of the metadata table Module has 10 bytes per behavior, and the data row of the metadata table TypeRef has 6 bytes per behavior, and the metadata table Each line of TypeDef has 14 bytes of data, and each row of data in the metadata table Field has 6 bytes. Each data row of the metadata table Method is used. Is 14 bytes; therefore the offset of the metadata table MemberRef in the metadata table area is 1* 10+30*6+6* 14+7*6+6* 14=400, from the metadata table area i or After starting offsetting 400 bytes, the content of the metadata table MemberRef is obtained. The data behavior of the metadata table MemberRef is 6 bytes per line, and the length of the metadata table MemberRef is calculated to be 23*6=138 bytes, metadata. Some of the data for the table MemberRef are as follows:

2900 C000 4300 3100 C000 4300

3900 C000 4800

4100 C000 4300

4900 C000 4300

5100 C000 4300 5900 C000 4300

6100 C000 4300 The above data is the first 8 in the metadata table MemberRef of the .net file provided in this embodiment. The data in the line, the other data processing methods are the same, here no longer - enumerated. A method and field information of a reference type are stored in the metadata table MemberRef, and each row of the above data records a reference feature of a method or field, that is, a signature value. The upper 2 bytes of each row of data represent the reference type pointed to by the field or method, the middle 2 bytes are the name of the field or method, and the lower 2 bytes indicate the feature identifier value of the method or field relative to The offset of the "#Blob" stream, the signature value of the signature records whether the data row represents a method or a field, and a return value. For convenience of explanation, see Table 2, Table 2 is a list form of the above 8 rows of data:

Table 2

Step 3082: Read the reference type pointed to by each method or field in the metadata table MemberRef; as shown in Table 2, the high 2-byte record is the reference type pointed to by the row method or field, and the metadata table MemberRef is below. The first row of data is described, Class is 0x0029, 0x0029 is converted to binary 101001, 3 bits are shifted to the right to get 101, and converted to decimal is 5, then the field or method of the first row in the metadata table of the metadata table points to the metadata table. The reference type recorded in the fifth row of the TypeRef can be obtained by the method described in step 302 and step 304, and the name of the reference type recorded in the fifth row of the metadata table TypeRef is AssemblvKevNameAttribute; Step 3038: sequentially obtain the metadata table MemberRef The feature identifier value of each method or field is signature; as shown in Table 2, the 氐2 byte of each row in the metadata table MemberRef is the feature identifier value of the method or field relative to the "#Blob" stream. Move; get the method of the signature of each method or field in the metadata table MemberRef: ^下下: Positioning the "#Blob" stream, that is, after obtaining the address 0x0000038c of the metadata header in step h in step 302, reading backward from the metadata header, and reading "#Blob" after reading "#Blob" The first 8 bytes of Blob" get the data Ox E4070000BC010000, where the upper 4 bytes are the offset of the "#Blob" stream relative to the metadata header, and the lower 4 bytes are the length of the "#Blob" stream, high The conversion of 4 bytes into big end is 0x000007e4, and the conversion of 4 bytes into big end is 0x00000 lbc; the compression program offsets 0x000007e4 according to the address 0x0000038c of the metadata header to get the stream of "#Strings" The data area; in this embodiment, the first row data behavior example in the metadata table MemberRef is read. The first row feature identifier value Signature offset is 0x0043, and the first row data is obtained by offsetting 0x0043 in the "#Blob" stream. The feature identifier value Signature is 0x2001010e; Step 3084: determining whether the current row data record is a method or a field according to the read feature identifier value Signature, if it is a method, performing step 3085; if it is a field, performing step 3086; To read The feature identification value Signature read out in the first row of data rows in the metadata table is described as an example. The specific process of determining whether the method or the field is based on the read feature identification value Signature is as follows: The first row of data rows is read out. The signature value of the feature identifier is 0x2001010e. The criterion of the embodiment is that when the last 4 digits of the signature value Signature is 0x060e, the current row data record is a field, otherwise, the row data record is a method; In this embodiment, the data of the first row of the metadata table is recorded, that is, the reference type AssemblvKevNameAttribute refers to the method recorded in the first row of the metadata table MemberRef; Step 3085: The current row data in the metadata table MemberRef The method count of the reference type pointed to is incremented by 1, and then returns to step 4 to gather 3083; Step 3086: increment the field count of the reference type pointed to by the current row data in the metadata table MemberRef, and then return to step 4 to gather 3083; Step 4: The method provided in 3081-3086, after reading the metadata table MemberRef, all the references in the .net file are obtained. The method count and the field count of the type; it should be noted that, in this embodiment, the sequence of steps 302-306 and step 308 can be performed interchangeably, that is, step 308 is performed first, and then steps 302-306 are performed, and the present invention can also be obtained. The same effect of the embodiment; Step 310: Combine the name of the compressed reference type, the method count of the reference type, and the field count according to a predetermined format to obtain a compression result of the reference type. In this embodiment, the predetermined format may be Table 3. The format shown, that is, the format is a fixed length of bytes, the fixed length can be set as needed, the byte includes three parts, the first part is the name of the compressed reference type, and the second part is the The method count of the reference type, and the third part is the field count of the reference type. table 3

The name of the compressed reference type I method count I field count combines the name of the compressed reference type obtained in step 306 with its corresponding method count and field count according to the structure shown in Table 3, and obtains the compressed reference type. When the method count or field count of the reference type is 0, it is padded with 0x00, for example, the compression result of the reference type MarshalByRefObj ect is: 0x30640100. The compression structure shown in Table 3 is only an optimal structure, and the compression structure can also be transformed accordingly. For example, after the method count and the field count in the above compression structure are placed under the name of the compressed reference type, or the method is counted, The value of the field count is equivalently encoded, etc.; the compression result of the reference type in a .net file is given below:

8E3B 0100 0000

//System.Runtime.CompilerServices.RuntimeHelpers

(1) DB8C 0100 0000

//.HelloWorld.exe.3805F8269D52A5B2.

(2) 8 ICE 0000 0000 //System. Void

(3) 2711 0100 0000 //System. String

(4) 2722 0000 0100 //System.Boolean

(5) 3064 0100 0000 //System. MarshalByRefObj ect

(6) 34B6 0100 0000 //System. Version (7) C061 0100 0000 //System.Int32

(8) A245 0000 0000 //System. Byte

(9) 4410 0000 0000 //System. Array

(10) 4970 0100 0000 //System. Object (11) ED88 0000 0000 //System. ValueType

(12) A1FA 0100 0000 //System. Type

(13) CBOF 0100 0000

//SmartCard. Runtime . Remoting . Channel s . APDU . APDUS erverChannel

(14) D9F8 0100 0000 //System.Runtime. Remoting. Channels. ChannelServices

(15) F55B 0100 0000

〃Sy stem. Runtime . Remoting . RemotingConfiguration The above data is used in the little endian representation, the first two bytes are the name of the compressed reference type, the middle two bytes are the method count, the last two bytes are The field count, after "//" is the reference type name string in the .net file. It can be concluded by comparison. The method provided in this embodiment has a good compression effect, and can be made by compressing the reference type. The occupied storage space is reduced, which can be reduced. The use of net files is limited by the storage space. It should be noted that the steps shown in the flowchart of the accompanying drawings may be performed in a computer system such as a set of computer executable instructions, and, although the logical order is shown in the flowchart, in some cases, The steps shown or described may be performed in an order different than that herein. Embodiment 4 Referring to FIG. 7, this embodiment provides a compression method for defining a .NET file, and the method includes: Step 4: 401: Locate the .net file, and then locate the .net file to .net. The definition method table and related streams in the metadata table in the file; Step 402: Construct a character string of the content of the corresponding data item of each definition method in the stream according to the definition method table, and the content of the data item includes a parameter count; Step 403: hash the constructed character string Computation to convert to a name hash value; Step 404: Compress the execution identifier and the access identifier of the above defined method; Step 405: Compress the parameter table of the method defined in the stream; Step 406: Organize the name hash value, The compressed execution ID and access identification, parameter count, and compressed parameter tables yield a compressed structure. The parameter hash value, the compressed execution identifier, the access list, the parameter count, and the compressed parameter table are organized according to preset rules. The above .net file has a .net file header, which stores the starting position of the metadata structure table, the content description, and the byte size occupied by each content, with the starting position and contents. The byte size can be used to calculate the specific addresses of the metadata stream, the string stream, the blob stream, the GUID stream, and the user string stream to be used in this embodiment, so that the calculated address can locate the corresponding stream. . In this embodiment, by partially compressing the definition method in the .net file, the storage capacity occupied by the .net file is effectively reduced, and the .net file is used on a small storage device; at the same time, resources are saved, and resources are improved. Utilization rate. Embodiment 5 This embodiment provides a compression method for defining a .NET file. Referring to FIG. 8, the method specifically includes the following steps: Step 501: According to the PE file structure and the .net file, locate the metadata table. In the definition method table and related stream, read the number of rows in the method table in the header, the number of rows represents the number of methods; set the method count value; the positioning process includes: by the file header of the PE file The content is located in the .net file, and the content in the .NET file header is located at the address of each stream in the .NET file (including the metadata stream, the string stream, the blob stream, the GUID stream, and the user string stream). size. The .net file is shown in the following table: Consists of a storage signature, a storage header, a stream header, and six data streams. Where the size of the storage signature is fixed, The size of the storage header is also fixed. The stream header stores the name, size, and offset address of each stream contained in the current .net file. With this data, you can locate the six streams of the .net file. The streams that need to be used in this example are a string stream, a blob stream, and a stream of metadata. Once you have located the metadata stream, you will continue to locate the metadata table in it. A metadata stream consists of a metadata header, a table record count, and a metadata table. The length of the metadata header is a fixed value, with an 8-byte MaskValid field, which identifies the bit vector of all existing tables. Each bit of the bit vector represents a table, and the value of each bit vector There are two choices of 0 and 1, 0 means that the table pointed to by the bit vector does not exist, and 1 means existence. At present, there are 44 types of tables defined in the metadata mode. The bit vectors mentioned above point to the tables of each type respectively. According to the values, it can be determined whether the tables exist, for example, the seventh bit of the bit vector corresponds to Define the method table, the value of the bit vector is 1, indicating that the definition method table does exist in the metadata table, so the metadata header identifies how many tables are in the metadata table. The table record count defines 4 bytes of data for each table identified above, the 4 bytes of data indicating the number of rows in each table, and the data width of each row in each table is specified. Since the length of the metadata header is fixed, the byte length of the table record count is also determined (this length is equal to the number of tables determined in the metadata header multiplied by 4), so that the metadata stream can be located from the metadata stream. The process of locating from the metadata table to defining the method table is as follows: The metadata table stores a number of different types of tables in turn (how many tables can be calculated according to the MaskValid field in the metadata header above), in each table There are many rows in the column, the number of rows has been specified by the table record count, and the length of each row is pre-defined. Therefore, by calculating the length of all the tables before the definition method table, you can locate from the metadata table. Define a method table. Each row in the metadata table corresponds to a method, each method has a table of data items, and some items in the table are associated with a predefined stream, such as: The name item is associated with the string stream. The space occupied by each method in the table is determined, so that the data item address of a method can be located, and the value of the data item can be read from the data item address. The setting method count value is specifically that the initial value of the setting parameter i is 1, and the value represents the number of methods of performing compression. Step 502: Read a data item in each method in the definition method table; construct a character string according to the content in the obtained data item; each method in the method table includes the following data items: (1) RVA (4-byte unsigned integer) is the relative virtual address of the method body in the module, and the RVA turns to the read-only segment of the PE;

(2) ImplFlags (2-byte unsigned integer) implementation of the binary flag, indicating how the method is implemented; (3) Flags (2-byte unsigned integer) represents the binary accessibility of method accessibility and other features;

(4) The name of the Name (offset in #Strings) method, associated with the string stream. The entry index is a string of UTF-8 encoding format length greater than 0 and less than 1023 bytes;

(5) Signature (offset in #Blob 3⁄4ϊ) method feature, associated with blob 3⁄4ϊ. The record item indexes a blob stream whose length is greater than 0;

(6) ParamList (RID of the parameter table) The index of the record, indicating the starting position of the parameter list belonging to the method. The start point of the parameter list of the next method or the end point of the Param table determines the end position of this parameter list. Referring to FIG. 9, a flowchart for constructing a string by using a method of defining a method of a .NET file, the method for constructing a string includes: Step 5021: Read a value of a name item in the data item, and read according to the value Corresponding to the data in the string stream to get the name of the method; the name item corresponds to the "Name" item in the above data item, where the value indicates the offset address of the item in the string stream, according to the offset The address reads the method name from the "string stream", such as: MySampleMethod. Step 5022: Read the value of the signature item, and read the data in the corresponding blob stream according to the value, obtain and analyze the parameter information of the definition method and The type of the return value, where the parameter information specifically includes: the number of parameters and the type of each parameter, etc.; the signature item corresponds to the Signature item in the above table, as can be seen from the above table, the value in the signature item indicates the item The offset address in the "Blob stream" is used to read the signature information from the "Blob stream" according to the offset address, that is, a series of parameter information used by the method (eg: number of parameters, each parameter) Types of Etc.) and return value information (including the return value type), where the return value type points to the specific type in the other types of tables that are used during the use of the defined method. Step 5023: According to the return value type, find the type information pointed to by the return value type in the metadata table definition type table or the reference type table, and record the partial name and the namespace item in the data item table of the type. The information of the class such as the type name and the namespace name is read in the string stream; Step 5024: The return value of the full name string is constructed by applying the name of the namespace name and the type obtained above, and the return value constructed in this embodiment is all The preferred format of the name string is: namespace name-type name; the type name and namespace name of the parameter are respectively read according to the obtained parameter type, and the parameter full name string is constructed according to the obtained data, and the parameters constructed in this embodiment are all The preferred format of the name string: Namespace name and type name; Step 4: 5025: Determine whether the number of parameters obtained in step 4 is 5022 is greater than 1, if yes, return to step 5024, continue to obtain information of each parameter; Go to step 5026; Step 5026: According to the return value obtained in step 5024, the full name string and the parameter The full name string, the method name obtained in step 5021, and the information construct string of each parameter obtained in step 5022; the preferred format of the constructed string is as follows: Return value Full name string method name (parameter full name character) String, ... ) Note: The ellipses are each parameter information in the number of parameters. Step 503: Perform a hash operation on the string obtained in step 502, and convert the first two bits of the operation result into a value type storage, where the data is a name hash value of the method; A series of data items are hashed, and a part of the values are intercepted, and the compression of the definition method is implemented. Step 504: Acquire an execution identifier and an access identifier of the defined method, and perform compression; the compression process is performed in step 502. In the original definition method, the data items in the execution identifier (ImplFlags) and the access identifier (Flags) are reorganized, and some of the data items are discarded, and finally the 4-byte identification items are combined into a 2-byte identification item. The compression of the identification item is implemented. Step 505: Determine the type of the method. If the method is a fat header method, set the method type related item in the combined identifier bit in step l 504 to 1, indicating that the method is a big header method. Step 4: 506; If the method is a tiny header method, step 4 is performed; the step of determining the method type is specifically: analyzing the RVA value in the method data item obtained in step 502, and positioning the method by RVA Header information, the first byte of the method header information, the two bits of the byte indicate the method header type. If the value of the two bits is 2 (0010), the method is the small header method; if the low The value of two bits is 3 ( 0011 ), indicating that the method is a big method. Step 506: Acquire a data item unique to the big head method, and compress the content therein. Referring to FIG. 10, a method flowchart for compressing the data item specific to the big head method, the method for compressing the unique data item includes: Step 5061: Steps The big-head method type information obtained in the 505 is analyzed, and the maximum stack size and the big-head method identifier are obtained, and the data describing the maximum stack size is compressed, and the data occupies 2 bytes (16 bits) in the original structure, and the 16-bit byte is taken.氐 8 digits, discarding the upper 8 digits. Step 1062: Analyze the big head method identifier obtained in step 505, and obtain the local variable signature identifier to obtain the number of local variables. Referring to FIG. 11, the structure of the big head method identifier provided by this embodiment is shown in FIG. The identifier consists of 12 bytes. The first two bytes are identification information, which corresponds to the Flags item in the figure; the next two bytes are the maximum stack size information, corresponding to the MaxStack item in the figure; the next four The byte is the code size information, which corresponds to the Code Size item in the figure; the last 4 bytes are the local variable signature serial number, which corresponds to the Local Variables Signature Token item in the figure. Analyze the data in the serial number of the local variable signature in the big-head method identifier. If the data is 0, it indicates that the number of local variables is 0; otherwise, the value is mapped to the StandAloneSig table of the metadata table (independent feature descriptor table, The table has a composite feature as a method local variable), reading the offset of the data item signature from the content of the Value item in the table, and reading the number of local variables; setting the header of the big header method after being compiled 16 The hex code is as follows:

1B 30 02 00 38 00 00 00 03 00 00 11 00 14 0A 00 72 21 00 00 70 OA 00 DE 12 0B 00 06 07 6F 14 00

00 OA 28 0D 00 00 OA OA 00 DE 00 00 DE OF 00 06

72 3F 00 00 70 28 0D 00 00 OA OA 00 DC 00 06 0C 2B 00 08 2A Step 5063: Analyze the big head method identifier, get the abnormal structure count and abnormal information, and compress the abnormal information; the Flags item in the big head method identifier occupies 2 bytes (corresponding to 301B in the above code), 0x301B =(0011 0000 0001 1011) 2, ^口果中ό The fourth digit is 0, and the shell 'J indicates that there is no abnormal information in the big header method, the number of the abnormal structure is 0, and step 507 is performed; otherwise, if the fourth digit is If it is 1, it indicates that the method has multiple segments after the IL code, that is, the exception structure processing table, and performs the following steps: a) analyzing the big head method identification information, and obtaining the exception structure processing table; the structured exception processing table is composed of many segments , at least one exception message exists in each segment. The big head method obtained in the analysis step 505 identifies the fourth bit of the first byte in the Flags item. If the corresponding identifier of the bit is 1, the method has multiple segments; the fifth and sixth words in the Flags item are analyzed. Section gets the size of the code; according to the method header width and code size obtained above, it can be offset to the exception structure processing table; the byte width of the method header is specified in advance, the method header byte width of the big header method For the 12 bytes, the header byte width of the method of the small header method is also fixed. There is at least one segment stored in the method. If there are multiple segments, the segments are sequentially stored in a storage area; at least one abnormal structure is stored in each segment. b) The offset address of the storage area stored in the segment is located in the segment, and the first byte of the stored data is analyzed. If the 7th bit of the byte is 1, it indicates that the large header segment is abnormal. The structure type is FatFormat format, and step c is performed; otherwise, the exception structure type of the big header method is TinyFormat format, and step d is performed; specifically, the content in the segment is located according to the position of a segment in the structured exception processing table. And analyze the first byte of data stored in the segment. c) Locating the contents of the segment according to the offset address of the storage area stored in the segment, and analyzing the 2nd to 5th bytes of the stored data, the 3 bytes indicating the storage space occupied by all the abnormal structures in a segment If the 8th bit in the 2nd byte is 1, it means that there are other segments (sections) behind the segment; if there are other segments, repeat the following operations until all segments are pressed After the completion of the following operations, the compressed structure of the abnormal structure information is organized, and then step 5064 is performed. The process of compressing each segment is as follows: If the abnormal structure of the segment is a large-head type, the storage space occupied by the abnormal structure in the segment is the first length, which is preferably n*24+4, where n is Number of exception structures; Flags bytes in the read method body), TryOffset (4 bytes), TryLength (4 bytes), HandlerOffset (4 bytes), HandlerLength (4 bytes;), ClassToken (4 bytes), discarding HandlerLength, compressing the values of TryOffset (4 bytes), TryLength (4 bytes), and HandlerOffset (4 bytes) into 2 bytes, compression method To discard the high order, retain the bit position; the four bytes of data in the ClassToken are compressed into one byte, and the compression method is to discard the high order, leaving only 8 bytes; the ClassToken obtained by the above steps is in the definition type and reference type table. Find the corresponding parameter type information. See Table 4 for the table of abnormal structure information after organization: Table 4

The order of each data item in the table is arbitrary, and the order can be adjusted at will. d) analyzing the data in the offset address obtained in step b, the second byte indicating the size of the storage space occupied by all the exception structures in a segment; if the eighth bit of the byte is 1, it means There are other sections following the section; if there are other sections, repeat the following operations until all the sections are compressed; otherwise, after performing the following operations, go directly to step 5064. The process of compressing each segment is as follows: According to the type of the abnormal structure in the segment, it is determined that the abnormal structure in the current segment is TinyFormat (the small header format;), and the storage space occupied by the abnormal structure in the current segment is the second length. This embodiment is preferably: n* 12+4; Flags (2 bytes), TryOffset (2 bytes), TryLength (2 bytes), HandlerOffset (2 bytes), HandlerLength (2 words) of the read method in sequence Section) and ClassToken items; remove the HandlerLength item from the various configurations obtained above. The ClassToken item obtained by the above step 4 finds the corresponding exception type information in the definition type and the reference type table. Step 5064: Obtain the Finally count value; when the expression n*24+4 is used (see step c above to calculate the number of exception structures in the current segment, whether it is an exception structure of a big header type or an exception structure of a small header type, All follow this structure: 0 2 logo, see below for details:

2 2 TryOf set The offset of the try block from the method body (in bytes)

4 1 Length of the TryLength try block (in bytes)

5 2 HandlerOf set Handler address of the above try block

7 1 HandlerLength Size of the above Handler code (in bytes)

8 4 ClassToken Metadata ID of the basic type of exception handling 8 5 FilterOf set From this structure, the flag bit can be read. In this flag bit, the big header type is represented by 4 bytes, and the header type is represented by 2 bytes, see Table 5. There are several possible values: The following table lists the identity values used for each exception handling item:

table 5

If the flag of the current exception structure is a filter exception or a final exception, the Finally count is incremented by one until all abnormal structures are analyzed, thereby obtaining a Finally count value. Step 5065: Obtain the garbage collection control attribute, where the step specifically includes: a) analyzing the CustomAttribute metadata table in the metadata table, if there is a data item in the row and the current analysis method (including the method header and method) Corresponding to the parameter, then analyze the value of the Type item, get the type information, the type name and its constructor, etc., and locate the offset value of the Blob stream in the Value item to locate the position in the blob stream, and analyze the first byte data. Get the length, skip the two-byte Prolog to get the parameter value of the constructor of the custom property type; b) If the information obtained in step 4 gathers a custom property has the type Transaction The attribute is identified as 0x40, that is, the seventh position is 1; c) if the type obtained in step a has a custom attribute type GCControl, and the value of the constructor parameter of the defined type obtained in step a, that is, the GCControlMode type The value of the corresponding value of the garbage collection control identifier is set accordingly:

Force = 1 ,

Skip = 2,

Step 5066: The value obtained above is organized according to the structure shown in Table 6. The header structure table is as follows: Table 6

Among them, the garbage collection mark is the garbage collection control mark, and the data in the head structure table of the above-mentioned big head method has no order, and the order can be arbitrarily adjusted. Step 507: compress the parameter table; locate the value in the parameter data item ParamList (parameter table) obtained in step 502 to the parameter row corresponding to the metadata table parameter table, and according to the number of parameters obtained in step 502 Information, read the corresponding parameter line information, the information includes the following data items Flags (2 bytes), Sequence and Name items, compress these data items, specifically to discard the Sequence and Name items, and in the Flags item Compressing the content into 1 byte; analyzing the identifier of the parameter from the value of the Flags item of the read parameter row information; combining the above identifier and the parameter type obtained in step 502 in the type storage area in the compressed file The parameter information is in the format: Parameter identification 'offset of the parameter type. Step 508: If the number of parameters acquired in step 502 is greater than 1, return to step 507; otherwise, perform step 509; Step 509: organize the compressed data in steps 503, 504, 506, and 507 according to a preset rule to obtain a definition method. The compression structure, preferably, the preset rules in this embodiment are specifically shown in Table 7 (the parameter count is the number of parameters): Table 7

Among them, the order of each data item in Table 7 is arbitrary, and the order can be adjusted at will. The big header data block only exists when the identifier is identified as a big header in the identifier. The header header compression structure is as shown in Table 4; the exception information is determined according to the abnormal structure count, and all the exception structures are arranged in turn. The compressed structure of the abnormal structure information is shown in Table 8: Table 8

After the current definition method is compressed, the method count value is incremented by one; Step 510: If the method count value is smaller than the number of rows of the header obtained in step 501, return to step l 502; otherwise, all operations are ended. The number of rows of the headers obtained in step 501 represents the number of defined methods stored in the data table, so the method count value is smaller than the number of rows in the header, indicating that there is also a definition method that is not compressed. This embodiment saves the storage space of the .net file by compressing the method part defined in the .net file, so that the .net file can be run on the small-capacity storage device; at the same time, resources are saved and the resource utilization is improved. Embodiment 6 This embodiment provides a compression method of a method body for defining a .NET file. As shown in FIG. 12, the apparatus includes: a method obtaining module 602, configured to obtain a definition method used in a .NET file. Method header; the method header can obtain the location information of the method header by first reading the information in the metadata table MethodDef, for example, RVA (relative virtual address), according to the location information, the data of the method header is obtained. And reading the ILcode recorded after the method header by the length of the ILcode recorded in the method header; the compression module 604 is configured to obtain the ILcode obtained by the module 602 by the compression method, by compressing ILcode compresses the method body to obtain the compression result of the method body. In this embodiment, by compressing the method body in the definition method of the .net file, the storage space occupied by the .net file can be effectively reduced, and the .net file can be stored and run on a small-capacity storage medium (for example, a smart card). This enhances the functionality of small-capacity storage media such as smart cards. Embodiment 7 This embodiment provides a compression method for a method body of a method for defining a .NET file. As shown in FIG. 13, the device includes: a method obtaining module 702 and a compression module 704, where the compression module 704 includes: The variable offset determining unit 7042, the instruction compressing and calculating unit 7044, and the combining unit 7046, wherein the functions of the modules are as follows: The method obtaining module 702 is configured to obtain a method header of the definition method used in the .net file, and The method header obtains the ILcode corresponding to the definition method; the specific acquisition manner of the method header is the same as that of the embodiment 6, and is not described in detail herein. The compression module 704 is configured to compress the ILcode obtained by the module 702, and compress the method body by compressing the ILcode to obtain a compression result of the method body. The compression module 704 specifically includes: a local variable offset determining unit 7042, configured to acquire a local variable of the defined method according to a method header acquired by the method obtaining module 702, and determine an offset of the local variable according to the type of the local variable, where The offset of the local variable refers to the offset of the local variable in the compression structure corresponding to the above .net file; when the definition method is the Tiny Headers method, there is no local variable in the defined method, and at this time, the obtained The local variable is empty, and the offset of the corresponding local variable is also empty. When the definition method is a Fat Headers, there is a local variable in the defined method. At this time, the local variable is obtained, and the local variable is determined to be The offset in the compression structure; the basis for judging whether the definition method is a small header method is: reading the first byte of the method header, and determining whether the definition method is a big header method or a small header method according to the first byte above When the two bytes of the first byte read are 10, the definition method is a small header method, otherwise the definition method is a big header. ; Compression instruction computing unit 7044, a method for acquiring module 702 acquires the compressed ILcode, ILcode length after compression calculation; The ILcode mentioned in this embodiment includes an operation instruction and an operation parameter, wherein the operation parameter may be empty, or may be an identifier token, an offset of a local variable in the method body, or an offset of mega-transition, for ILcode. When compressing, the compression mode can be determined according to the specific ILcode. For example: For the operation instruction without the operation parameter in ILcode, the operation instruction can be directly recorded; for the operation instruction with the operation parameter, the following three types can be used. The situation is handled separately:

(1) When the operation parameter is the offset of the jump (that is, the operation instruction is a jump instruction), the skipped ILcode portion is determined according to the offset of the jump, and the skipped ILcode is determined. Partially recalculating the offset of the jump of the operation instruction (ie, the above jump instruction), recording the operation instruction and the recalculated jump offset; for example: there are 10 operation instructions in the ILcode, wherein, The three operation instructions are jump instructions, and their operation parameters are 2, that is, two bytes are jumped after pointing. If two bytes are jumped, the jump to the fifth operation instruction is skipped. The ILcode part is the fourth operation instruction and its operation parameters. According to the method of the embodiment, the skipped ILcode part needs to be compressed first, and the third part is re-modified according to the length of the compressed skipped ILcode part. The operation parameters of the operation instruction modify the original jump offset to the length of the compressed skipped ILcode portion. In turn, after all the operation instructions and operation parameters in ILcode are compressed, the meaning of the original ILcode is not changed.

(2) when the operation parameter is an offset to the local variable in the body of the method, the operation instruction and the operation parameter are recorded;

(3) When the operation parameter is the identification token, the corresponding offset of the identification token in the above compression structure is determined, and the operation instruction and the determined offset are recorded. The content of the above record is the compression result of the IL instruction. The combining unit 7046 is configured to compress the length of the compressed ILcode calculated by the instruction compression and calculation unit 7044, the offset of the local variable determined by the local variable offset determining unit 7042, and the compression of the instruction compression and calculation unit 7044 according to a predetermined format. After the ILcode is combined, the compression result of the method body is obtained. Preferably, the predetermined format is a format in which the calculated length of the compressed ILcode, the offset of the local variable, and the compressed ILcode are sequentially arranged, and the front and rear positions of the three parts may be arbitrarily changed. The compression structure corresponding to the .net file mentioned in this embodiment means that the data in the .net file is arranged in order, and the offset of each row of data corresponds to the identifier token of the row data, for example: Namespace The offset of the data listed in the first row is 0, the corresponding token is 0, the offset of the data listed in the second row is 1 , the corresponding token is 1, and the class 4 dances in turn, as the .net file. Compressed structure; It should be noted that in the three types of data: type, method, and field, there are two types of data that are referenced and defined. The referenced data is arranged in the compressed structure before the definition data, and the token defining the data is also arranged. After the data is referenced, the offset should correspond to the token. Preferably, the offset is one byte. For example, there are already 6 reference types, which are respectively placed at offsets of 0-5, so in the definition type module. The first defined type of token should be 6 and the offset is 6. For example, the source code for a .net file is as follows: public String My S ampleMethod() {

String strHello = "Hello World!"; if (strHello != null) strHello += "Y"; return strHello + callCount.ToString(); } The converted compression structure is: Namespace Namespace:

(0) 0100 5E5F8700 (1) 0100 35F47B00

(2) 0100 A17EC300

(3) 0700 00F64D00 (A) 0200 ACE6EB00 Reference Type TypeRef: (0) F55B 0100 0000

(1) D9F8 0100 0000

(2) CBOF 0100 0000

(3) 8 ICE 0000 0000

(4) 2711 0100 0000

(5) 2722 0000 0000

(6) 4970 0100 0000

(7) C061 0100 0000

(8) AIFA OIOO 0000

(9) 3064 0100 0000 Reference Method MethodRef:

(0) E8CB

(1) CE72

(2) 9080

(3) 3973

(4) 9080

(5) 6A4D

(6) 6AF2

(7) 9080

Reference field FieldRef: Blob:

(0) 0D00

(1) 0100

(2) 0D00 Definition Type TypeDef:

(A) A70914 0009000200 Definition Method MethodDef:

(8) DFEE000600040104

(9) 9080020600000103 In the above data, the first parenthesis of each row of data is the offset of the row data, followed by the row specific data. For example, in the namespace Namespace, each row of data records a namespace information, the first row of data (0) 0100 D93DEB00, where 0 in the parentheses is the offset of the namespace, the offset is not actually present , 0100 D93DEB00 is the specific information of the namespace, the structure of other data is similar to this row of data. The above data is only part of the .NET file compression structure, just to illustrate the correspondence between the identifier token in the .NET file and the offset in the compression structure. In this embodiment, the ILcode is compressed by the instruction compression and calculation unit 7044 and the length of the compressed ILcode is calculated. The combined unit 7046 combines the compressed ILcode, the length of the compressed ILcode, and the offset of the local variable as the compression of the method body. As a result, the storage space occupied by the .net file can be effectively reduced, so that the .net file can be stored and run on j, a storage medium (for example, a smart card), thereby enhancing the storage of a small-capacity storage medium (for example, a smart card). Features. Example 8 This embodiment provides a method for compressing a method body of a method for defining a .NET file. The method is described by using a compression device provided in Embodiment 6. As shown in FIG. 14, the method includes: Step S20: Obtaining the method header of the definition method used in the .net file, and obtaining the ILcode of the definition method according to the method header; Step S30: compressing the ILcode in the above method, compressing the method body by compressing the ILcode, and obtaining the compression of the method body result. In this embodiment, by compressing the method body in the definition method of the .net file, the storage space occupied by the .net file can be effectively reduced, and the .net file can be stored and run on a small-capacity storage medium (for example, a smart card). This enhances the functionality of small-capacity storage media such as smart cards. Embodiment 9 This embodiment provides a method for compressing a method body of a method for defining a .NET file. As shown in FIG. 15, the method includes: Step 802: Obtain a method header of a definition method used in a .NET file, and Obtain the ILcode of the defined method according to the method header; include a namespace (Namespace), a reference type (TypeRef), a definition type (TypeDef), a definition method (MethodDef), a string, etc. in a .net file compiled by the .net platform. And storing in the form of a table and a stream. Before compressing the IL in the .net file, the structure of the .net file can be first converted into a compressed structure. The compression structure in this embodiment is compressed in the first embodiment. The structure is the same and will not be mentioned here.

The IL includes: an operation instruction and an operation parameter, and the operation parameter may be empty, or may be an identifier token, an offset to a local variable, or an offset of a mega-turn. The first half of the identifier token indicates the table corresponding to the operation instruction, and the second half indicates the data of the first row of the table. The specific implementation of the method header may be obtained by first obtaining the metadata table MethodDef in the .net file; reading the address information of the definition method used in the .net file from the metadata table MethodDef; reading the definition method according to the address information Method header. The step 4 of reading the ILcode according to the method header includes: The information in the method header determines the length of the ILcode; the ILcode is read according to the determined length of the ILcode. When the definition method is a big method, The 5-8 bytes in the method header are the length of the IL corresponding to the method, and the 9-12 bytes are the identifier token of the local variable in the method; when the definition method is the small header method, the method header is high 6 bits are the length of ILcode. Step 804: The method header obtains a local variable of the defined method, and the type of the local variable determines an offset of the local variable, where the offset of the local variable refers to the local variable in the compressed structure corresponding to the .net file. The offset is because there is no local variable in the small head method. At this time, the obtained local variable is empty, and the offset of the corresponding local variable is also empty. It is judged whether the definition method is a small header method or a large header method. It can be implemented by the method in Embodiment 6, and will not be described in detail here. Step 806: Compress the read ILcode and calculate the length of the compressed ILcode. When compressing the ILcode, the compression mode may be determined according to the specific ILcode. For the specific compression method, refer to the ILcode compression method in Embodiment 7. Implementation, no longer detailed here. Preferably, after reading and compressing an operation instruction, determining whether all operation instructions and operation parameters in the ILcode are read and compressed, and if so, performing calculation of the length of the compressed IL; otherwise, reading An operation instruction and compression. Step 808: Combine the length of the compressed ILcode, the offset of the local variable, and the compressed ILcode according to a predetermined format to obtain a compression result of the IL. Preferably, the predetermined format is a format in which the calculated length of the compressed ILcode, the offset of the local variable, and the compressed ILcode are sequentially arranged, and the front and rear positions of the three parts may be arbitrarily changed. Preferably, the compression method provided in this embodiment may further include: determining whether the method headers of all the defined methods used in the above .NET file have been read and completing IL compression, and if not, continuing to read the next definition method. Method header, and perform steps 802-808; otherwise, end compression. In this embodiment, by compressing ILcode and calculating the length of the compressed ILcode, combining the compressed ILcode, the length of the compressed ILcode, and the offset of the local variable as the compression result of the method body can effectively lower the net file. The occupied storage space enables the .net file to be stored and run on a small-capacity storage medium (for example, a smart card), thereby enhancing the small-capacity storage medium (for example) Such as: Smart card) features. Embodiment 10 This embodiment provides a method for compressing a method body of a .NET file definition method. As shown in FIG. 16, the method includes: Step 902: Obtain a definition method metadata table MethodDef; included in a .net file There are a plurality of tables, wherein the method metadata table MethodDef records the location information of the method headers of each definition method in the .net file; this embodiment takes the .net file obtained by compiling the following code as an example, and obtains the description thereof. Method of metadata table MethodDef: public String My S ampleMethod() {

String strHello = "Hello World!"; if (strHello != null) strHello += "Y"; return strHello + callCount.ToString(); } Use the .net platform to compile the helloworldexe file in binary code. The form is stored on the hard disk. The binary file is a .net file. As shown in FIG. 17, the structure of the .net file provided in this embodiment includes a Dos header, a PE feature, and metadata (metadata). It includes metadata headers (metadata headers), metadata tables (tables), and so on. The process of reading the metadata table MethodDef is as follows: a. Positioning. The net file Dos header, the Dos header obtained in this embodiment is 0x5a4d; b. The first agreed byte is skipped from the dos header, and the PE feature is read out. The address is shifted to obtain the offset address 0x00000080 of the PE feature. In this embodiment, the first agreed byte is 0x003a bytes. c. The PE feature is located according to the PE feature offset address 0x00000080, and the PE feature 0x4550 is obtained. d. Four bytes are read at the second agreed byte backward of the PE feature. In this embodiment, 32 The bit machine is taken as an example for description. After the second agreed byte is offset from the PE feature by 0x0074 bytes, the data of 4 bytes is read as 0x00000010. This value indicates that there are 0x10 directories in the binary file and includes . net data; wherein, the metadata header of the .net file is written in the above OxOF directory relative to the virtual address, and the second agreed byte in the 64-bit machine is 0x0084 bytes; e. from the above data 0x00000010, After the third predetermined byte is read, the eight bytes of data are read. In this embodiment, preferably, the third agreed byte is 112 bytes, and among the eight bytes of data, the first four are The byte is 0x00002008, which is the relative virtual address of the .net data header, and the last four bytes are 0x00000048, which is the length of the .net data header;

48000000020005008C210000A0090000 090000000500000600000000000000005

020000080000000000000000000000000

0000000000000 It should be noted that the above data is stored by the little endian. For example, the first 4 bytes of the above data 0x48000000 is the length of the data, and the storage mode converted to the big end is 0x0000048; in this embodiment, the linear address is. The address of the net data in the .net file, the relative virtual address is the memory offset relative to the PE load point, and the conversion relationship between the linear address and the relative virtual address is: linear address = relative virtual address - section relative virtual address + section File offset. In this embodiment, the relative virtual address of the section of the .net data directory in the .net file is 0x00002000, the file offset of the section is 0x00000200, and the linear address=0x00002008-0x00002000 +0x00000200 =0x00000208; Reading eight bytes of data from the .net data header backward by the fourth contracted byte, in this case In the example, the fourth agreed byte is offset from the _.net data header by 8 bytes, and reads a total of 8 bytes. Among the 8 bytes, the first four bytes are 0x0000218c, which is The relative virtual address of the metadata header (MetaData Header), the last four bytes are 0x000009a0, which is the length of the metadata; h. The relative virtual address 0x0000218c of the metadata header is converted to the linear address 0x0000038c, according to the linear address and the length of the metadata. , get the metadata content; i. read backward by the metadata header, when reading the flag "#~", read the eight bytes before the flag "#~", where the first four bytes are " The address of #~", the "#~" stream is obtained by the address, and the data of length 8 bytes is read in the fifth agreed byte in the "#~" stream, that is, 0x0000000920021c57, and its binary form is 100100100000000000100001110001010111; In this embodiment, the fifth agreed byte is the ninth byte starting from the start bit in the "#~"stream; j. according to the binary data obtained in step i, starting from the lower bit, for example, The first bit represents whether the metadata table Module exists. If it is 1, it proves that there is a metadata table Module. If it is 0, the certificate does not exist. In this embodiment, there is a metadata table Module, and the second bit is 1, indicating that the metadata table TypeRef exists, according to this rule, the bit is The unit reads from the low position to the high position, and the seventh bit is 1, indicating that the metadata table MethodDef exists; wherein, in the data obtained in step i, starting from the lower position, each bit represents whether there is a corresponding table in the .net file; a) k. After the data 0x0000000920021c57, the sixth predetermined number of bytes is read and the number of data rows of the metadata table MethodDef is read. In this embodiment, the sixth agreed byte is 24 bytes, specifically backward biased. After shifting 24 bytes, 4 bytes are read, and the data 0x00000002 is obtained. It is judged that there are 2 data rows in the metadata table MethodDef; wherein, in the metadata, the data 0x0000000900021C57 is shifted backward by 8 bytes. In the data, the number of data rows of the metadata table existing in the .net file is sequentially stored in units of 4 bytes, and after the data indicating the number of data rows, the specific contents of each metadata table are sequentially stored. Yuan According to the table area. In this embodiment, there are four metadata tables before the metadata table MethodDef, so after the data 0x0000000900021C57 is offset by 8+4*4=24 bytes, the number of data rows of the metadata table MethodDef is read, the above is the first The calculation method of the six-byte byte; b) 1. The specific content of the metadata table MethodDef is read according to the agreed method; wherein, the agreed method is as follows, and the .net file in this embodiment is taken as an example for explanation. In the method described in k, there are 28 data rows in the five tables before the metadata table MethodDef, wherein the metadata table Module includes 1 row of the data row, and the metadata table TypeRef includes the number According to line 23, the metadata table TypeDef includes 3 rows of data rows, and the metadata table Field includes 1 data row, wherein the data row of the metadata table Module per transaction has 10 bytes, and the data row of the metadata table TypeRef per behavior 6 bytes, the data row of the metadata table TypeDef is 14 bytes per behavior, and the data row of the metadata table Field is 6 bytes per behavior, so the offset of the metadata table MethodDef in the metadata table area i is 1 * 10+23*6+3* 14+1*6=196 bytes, the data of MethodDef in metadata table is 2 lines, each line of data is 14 bytes, so the data length of the metadata table MethodDef is 2* 14=28 bytes; the data of the metadata table MethodDef is as follows:

0C210000 0000 8600 8900 3000 0100

47210000 0000 8618 8300 2C00 0100 where each row of data represents information corresponding to a defined method, and the first four bytes of each row of data are relative virtual addresses RVA of the method header of the defined method. For convenience of explanation, the above data is listed. Formal representation, see Table 9: Table 9

The data in Table 9 uses the big endian representation, for example, the data of the first data row is

0C210000 0000 8600 8900 3000 0100, the corresponding small end representation method is 0000210C 0000 0086 0089 0030 0001; Step 904: Read the method header in the definition method, and obtain the local variable information according to the information in the method header; The first definition method in the metadata table MethodDef is taken as an example.

Step 904a: Obtain the address of the method header of the definition method, and read the first byte of the method header. According to the data in the metadata table MethodDef obtained in step 902, the RVA of the method header of the first definition method is 0x0000210C. , the linear address obtained by RVA conversion is 0x0000030C, the data is read in the .net file according to the address 0x0000030C, and the length of the read data byte is one word. In this embodiment, the first byte read is: 0x13; Step 904b: Determine whether the definition method is a big header method or a small header method, if it is a big header method, perform step 904d, if it is a small header method Step 904c is performed. The method for determining whether the definition method is a big head method or a small head method is the same as that of Embodiment 6 and Embodiment 7, and will not be described in detail herein. For example, in the present embodiment, the data 0x13 obtained in step 904a is expressed in binary form as: 00010011, and the last two digits are 11, which is a big header method. Step 904c: The definition method is a small header method, there is no local variable, the local variable is set to null, and a complete definition method header information and ILcode corresponding to the method are obtained; Step 904d: Obtain a complete definition method header information and The IL code corresponding to the method, and obtains the local variable token; see FIG. 19, which is a schematic diagram of the data format of the big-head method provided by the embodiment, which can be composed of FIG. 19, and the large-head method label i consists of only 12 bytes. The two bytes are the information of the standard i, which corresponds to the Flags item in the figure; the next two bytes are the maximum stack size information, corresponding to the MaxStack item in the figure; the next four bytes are corresponding to the method. The ILcode size information corresponds to the Code Size item in the figure; the last 4 bytes are the local variable token, corresponding to the Local Variables Signature Token item in the figure. Analyze the data of the local variable token in the big-head method identifier. If the data is 0, it indicates that the number of local variables is 0; otherwise, the value is located in the StandAloneSig table of the metadata table (independent feature descriptor table, the table has As a composite feature of the method local variable), the offset of the data item signature is read from the content of the Value item in the table, and the number of local variables is read; the format of the big head method is known, the method header information is 5-8 The byte is the ILcode length, the 9th-12th byte is the local variable token, and the local variable token is ILcode. In this embodiment: 0x11000002, the local variable token uses the big endian representation. In this embodiment, the method header is obtained, and the ILcode corresponding to the method is obtained according to the method header as follows:

20 is a schematic diagram of a data format of the small head method provided by this embodiment. It is known that the upper 6 bits of the method header of the small header method are the length of ILcode, and the lower 2 bits are the identification bits indicating that it is the small header method. Step S904e: The local variable token acquires a local variable, and the type of the local variable determines the offset of the local variable in the compressed structure of the .net file; the method of obtaining the local variable is: positioning the data row of the metadata table StandAloneSig according to the local variable token The table records the offset of the local variable information of the defined method in the Blob stream, and reads the information of the local variable according to the offset. In this embodiment, the local variable token is Ox 11000002, and the Ox 11 indicates that the pointing sequence is The metadata table of Ox 11, that is, the metadata table StandAloneSig, 0x000002 is the second row of data of the table, then the local variable of the definition method corresponds to the second row data of the metadata table StandAloneSig, and the obtained data is: 0x0100, 0x0100 is local The offset of the variable in the Blob stream is based on the offset. The local variable information is read in the Blob stream: 0x0607040E080E02 , where 0x06 represents the length of the local variable information, 0x07 is the local variable identifier, and 0x04 represents the length of the local variable. , OxOE indicates that the type of the local variable is the reference type String, only the compression structure of .net can be known, to S The tring offset in the reference type TypeRef is 0x04. For example, the compression program replaces the local variable storing the definition method in the .net file with: 0x04. Similarly, 08 indicates that the type of the local variable is the reference type Int. The net file compression structure has an offset of 0x07; 02 indicates that the local variable type is a reference type Boolean, and the offset is 0x05 in the compression structure of the .net file; there are two OxOEs in the definition method, indicating the definition method There are two local variables in the type String. Wherein, the positioning method of Blob 3⁄4ϊ is: the compression program locates the position of the blob stream, and after obtaining the address 0x0000038c of the metadata header in step h in step S302, the backward reading is started from the metadata header, when the tag is found. After #Blob", the first 8 bytes of "#Blob" are read, and the data Ox 2006000098010000 is obtained, where the upper 4 bytes are the offset of the Blob stream relative to the metadata header, and the lower 4 bytes are the Blob stream. The length, the high 4 bytes are converted to the big end representation of Ox 00000620, ^ 4 bytes are converted to the big end representation is 0x00000198; the compression program is based on the metadata header address 0x0000038c, backward offset Ox 00000620 to get the Blob stream Step 906: Read ILcode, and compress ILcode; In this embodiment, the method header and ILcode information of the above defined method obtained in step 904d are as follows: Among them, the local variable tokenOx 11000002 is followed by ILcode,

0x0000002F indicates the length of ILcode, and determines ILcode as:

061201281300000A281200000A0C2B00082 A

The IL in the .net file includes one or more operation instructions and operation parameters, including two combinations, one in the form of "operation instruction opcode+operation parameter" and the other only operation instruction. Among them, the operation parameters mainly include three types: the operation object's token, offset or local variable offset in the ILcode of the method. In general, the operation parameter after the jump instruction is an offset, and the local variable is in the ILcode of the method. The offset is the sequence number of the local variable in the local variable in the defined method. Referring to FIG. 21, which is a flowchart of a method for compressing ILcode according to the embodiment, the method for compressing the IL command is as follows: Step 906a: Acquire an operation instruction in ILcode; Step 906b: Determine whether there is an operation parameter after the operation instruction, If not, perform the steps

906c, if yes, executing step 906d; step 906c: directly recording the operation instruction, performing step 4 906h; step 906d: determining the following operation parameter type according to the operation instruction, if the operation parameter is a jump offset, performing steps 906e, if the operation parameter is an offset of the local variable in the method to which it belongs, step 906f is performed, if the operation parameter is token, step 906g is performed; step 906e: recalculating the offset of the operation instruction, replacing the original offset, Step 906h is performed; in the embodiment, the operation parameter after the jump instruction is a jump offset, and in this embodiment, the ILcode is compressed, resulting in a change in the data position, so the offset needs to be recalculated. The original offset is replaced. For example, in the ILcode provided in this embodiment, there is a mega-transition operation: 0χ2Β00, where 0χ2Β is a mega-instruction, and 0x00 is an offset, indicating that the mega-to 0x00 is in the present embodiment. After the provided ILcode is compressed, it is calculated that the offset is still 0x00, so the ILcode is still compressed after: 0x2B00; Another jump operation in this embodiment: 0x2D0C, where 0x2D is a jump operation, OxOC is a jump offset, indicating that after jumping to the 12 bytes after the data OxOC, the ILcode part is: 0x0C067239000070281200000A0A skip After compressing the jumped ILcode portion, in this embodiment, ILcode0x0C067239000070281200000A0A is compressed to 06720128030A, which is 6 bytes, so the offset after the operation instruction 0x2D should be recalculated to 0x06, ILcode: 0x2D0C is compressed to 0x2D06^ Step 906f: Record the operation instruction and the operation parameter, and execute step 906h; In this step, a special case is illustrated, and the operation instruction 0x0a, 0x0b, 0x0c, OxOd is also an operation instruction pointing to the local variable, but the operation instruction The operation instruction itself has indicated the local variable offset. The operation instruction 0x0a points to the first local variable of the method to which the instruction belongs. The operation instruction 0x0b points to the second local variable of the method to which the instruction belongs. The operation instruction 0x0c points to the instruction to which the instruction belongs. The third local variable of the method, the operation instruction OxOd points to the fourth method of the method to which the instruction belongs. Part variables, therefore, there is no operation parameter after these instructions, according to step 906c operation; when the local variables in the definition method are greater than 4, directly record the original operation instruction and operation parameters, such as ILcode: 0x1104, operation instruction 0x11 points to The fifth local variable in the method is similar to that of ILcode when it is compressed. It should be noted that in steps 906d and 906f, the offset in the offset of the local variable refers to the local variable. The sequence number of all the local variables included in the definition method to which it belongs; Step 906g: Record the operation instruction, and replace the token in the operation parameter with the offset in the compression structure, and perform step 906h; Replace the token pointing to the specific data in the operation parameter with the offset. In the .net file, the token is four bytes, the higher one byte records the metadata table pointed to, and the lower three bytes indicate the pointing to the metadata table. Which line of the example; Example 3⁄4, ILcode in this embodiment: The big end representation method is: Ox 72 1D00007, Ox 72 is the operation instruction, 0xlD00007 is pointed Data token, analysis shows that the high byte OxlD is the metadata table number, pointing to the metadata table FieldRVA, 0x000007 is the number of rows, should be the 7th line, then the IL instruction points to the .net file metadata table FieldRVA 7th Row data, according to the compression structure of the .net file to determine the offset of the row data, such as 0x02, then the original ILcode: 72 1D00007 can be replaced as follows: Ox 72 02; Step 906h: Determine whether all operation instructions and operation parameters of the defined method are read and compressed, if step 906i is performed, if not, return to step 906a; in the .net file, ILcode is recorded in the method header. The length, for example, is 0x0000002F in this embodiment. After reading the ILcode data of the length, all the operation instructions and operation parameters in the ILcode of the method are read and compressed. Step 906: Calculate the definition method. The length of the compressed ILcode; In this embodiment, the data obtained by the ILcode compression in the above defined method is:

[00] [72](02)[0A] [19] [0B] [06] [14] [FE01] [0D] [09] [2D] [06] [06] [72](01)[28 ]( 03) [OA] [06] [ 12] [01] [28] (05)[28](03) [0C] [2B] [00] [08] [2A] For the convenience of explanation, the data will be The operation instruction is indicated by brackets, the operation parameters are represented by parentheses, and the calculation length is 0x0020. Step 908: Determine whether the method headers of all defined methods have been read and completed the compression of the corresponding ILcode, and if so, the execution step 4 910, if not, return to step 4 904, continue to read the next definition method header; in the .net file, as described in step k of step 902, the number of rows defining the method is recorded, that is, the method is defined. The number, in this embodiment, is four definition methods. When all four defined method headers read and complete the corresponding ILcode compression, it is considered that all the defined method headers have been read and completed the corresponding ILcode compression; Step 910: The compressed ILcode, the length of the compressed ILcode, and the local variable offset are organized according to a predetermined format to obtain a compressed method body. In this embodiment, preferably, The predetermined format is shown in Table 10: Table 10 The length of the compressed ILcode The offset of the local variable The compressed ILcode

For example, in this embodiment, the compression result of the method body is:

[2000] [(04)(07)(04)(05)] [00] [72] (02) [0A] [19] [0B] [06] [14] [FE01][0D] [09] [

2D] [06] [06] [72] (01)[28](03)[0A] [06] [ 12] [01] [28](05)[28](03)[0C] [2B] [00] Γ 081 Γ 2A] The compressed method body uses the little end representation method, where 0x2000 identifies the length of the compressed ILcode, and (04)(07)(04)(05) identifies the bias of the four local variables in the metadata table. After the shift, the following data is the compressed ILcode, including the compressed operation instructions and their parameters. The compression result of the method body of the second definition method in this embodiment is given below:

[0400] [] [02] [28] (07) [2 A] The compression format in the above compression result is only an optimal structure, so the corresponding transformation can be performed, for example, the offset of the local variable is put into the compressed Before the length of the IL instruction, or after shifting the offset of the local variable to the compressed IL instruction. The method provided in this embodiment compresses the method body in the .net file, effectively reduces the storage space occupied by the .net file, and can reduce the use of the net file by the storage space, which is beneficial to the .net file. Promote applications on devices with small storage capacity. Embodiment 11 This embodiment provides a method for compressing a namespace in a .NET file. As shown in FIG. 22, the method includes: Step 4: Collecting 1002, obtaining a namespace name of a current type in the .NET file; The method for obtaining the namespace name in the embodiment may be specifically: obtaining a metadata table containing a namespace name offset in the .net file; obtaining a namespace name offset of the current type from the metadata table, according to The offset of the namespace name reads the namespace name in the "#Strings" stream. The .net file contains multiple tables, and the metadata table including the namespace name offset has a definition type or an interface table TypeDef, and a reference type table TypeRef. Step 1004: compress the namespace name according to a predetermined algorithm. In this embodiment, the namespace name is compressed by using the following method: forming the namespace name into a namespace string; and scattering the namespace string. The column operation obtains a hash value; the predetermined byte in the hash value is taken as the compressed namespace name. The algorithm used in the hash operation may be: MD5, SHA-1 or SHA-2. The inclusion of the above namespace names into a namespace string includes: Using a connector to concatenate the public key token of the .net file with the namespace name to get a namespace string. Step 1006, determining a type count corresponding to the namespace name, where the type count refers to the number of types included in the namespace; preferably, the type count can be determined by the following method: When the above namespace name is When obtaining once (that is, the namespace name has not been obtained before), the type count corresponding to the above namespace name is set to 1, and each time the above namespace name is obtained, the type count is incremented by 1 until the above is traversed. Metadata table. Step 1008: Combine the compressed namespace name and the type count according to a predetermined format to obtain a compression result of the namespace corresponding to the namespace name. The predetermined format may be a fixed length byte. The fixed length byte includes two parts, a part of the byte is the above type count, and the other part of the remaining byte is the compressed namespace name. Preferably, the step of obtaining the namespace name of the current type in the .NET file (step 1002) further includes: determining whether the currently obtained namespace name has been obtained, and if not, performing step 1004 above, if The namespace name has been obtained, and the type of the namespace is counted as 1. Preferably, the method for compressing the namespace in the .NET file provided in this embodiment may further include: determining whether the namespace name to which all types belong has been read; if yes, performing the above compression according to a predetermined format. The above-mentioned namespace name and the above-mentioned type count are combined in step 4 (ie, step 4 is gathered 1008); otherwise, the namespace name to which the next type belongs is read (ie, returning step 4 is gathered 1002). In this embodiment, the obtained namespace name is compressed, and the compressed namespace name is combined with the corresponding type count to obtain a compressed namespace, which can effectively reduce . The storage space occupied by the file enables the .net file to be stored and run on 'j, a capacity storage medium (for example, a smart card), thereby enhancing the function of a small-capacity storage medium (for example, a smart card). Embodiment 12 This embodiment provides a method for compressing a namespace in a .NET file. In this method, a file that has not been compressed by a .net file is called a .net file, and is named by a compression program. The compression process of space. As shown in FIG. 23, the method includes: Step 1102: Obtain a metadata table that includes a namespace name offset in a .net file; and include a plurality of metadata tables in the .net file, where the namespace name is offset The metadata table has TypeDef (definition type, interface table), TypeRef (reference type table). The following is an example of obtaining the metadata table TypeDef in the .net file to illustrate the acquisition process of the metadata table; t according to the table method: namespace MyCompany . MyOnCardApp

Public class My Service: MarshalByRefObj ect

Static Version ver = new Version(l, 1, 1, 1); static Int32 callCount = 0; static ClassB classb = new ClassB(); String strResult = Boolean.FalseString; public String My S ampleMethod()

String strHello = "Hello World! return strHello + callCount. ToString(); }

} public class ClassB{} public struct StructB{ } } After the above code is compiled using the .net platform, the helloworldexe file is obtained and stored in binary form on the hard disk. The binary file is a .net file, and the .net file structure is shown in Figure 24. As shown, including: Dos Header, PE features, etc. The process of obtaining the metadata table by the compression program is as follows: a. The compression program locates the Dos header of the .net file, and obtains the Dos header 0x5a4d; b. The compression program skips the first agreed byte from the Dos header and reads the PE feature. In the embodiment, the first agreed byte is 0x003a bytes; c. The compression program locates the PE feature according to the offset address 0x00000080 of the PE feature. Positioning to obtain the PE feature 0x4550; d. Starting from the PE feature, after reading the second predetermined number of bytes, read four bytes. In this embodiment, a 32-bit machine is taken as an example for description, and the second agreed byte is used. After offsetting 0x0074 bytes from the PE feature, the data of 4 bytes is read as 0x00000010. This value indicates that there are 0x10 directories in the binary file, and contains .net data; where the metadata header of the .net file The address is written in the above OxOF directory, and the second agreed byte in the 64-bit machine is 0x0084 bytes; e. The eight bytes are read after shifting the third agreed byte backward from the above data 0x00000010 Data, in this In the embodiment, preferably, the third predetermined number of bytes is 112 bytes, and among the eight bytes of data, the first four bytes are 0x00002008, which is the relative virtual address of the .net data header, and the last four words. The section is 0x00000048, which is the length of the .net data header;

The compression program only obtains the linear address 0x00000208 from the relative virtual address of the net data header. And read the .net header to get the following data:

48000000020005008C210000A0090000 090000000500000600000000000000005 020000080000000000000000000000000

It should be noted that the above data is stored in a small endian. For example, the first four bytes of the data are 0x48000000, and the data is converted to a large end. The storage mode is 0x0000048. In this embodiment, the linear address is .net. The address of the data in the .net file. The relative virtual address is the memory offset relative to the PE load point. The conversion relationship between the linear address and the relative virtual address is: linear address = relative virtual address - relative virtual address of the section + section File offset. In this embodiment, the relative virtual address of the section of the .net data directory in the .net file is 0x00002000, the file offset of the section is 0x00000200, and the linear address=0x00002008 - 0x00002000+0x00000200=0x00000208; The compression program reads 8 bytes of data after shifting from the .net data header backward by the fourth predetermined byte. In this embodiment, the fourth agreed byte is offset backward from the .net data header. After a byte, a total of 8 bytes of data are read. Among the 8 bytes, the first four bytes are 0x0000218c, which is the relative virtual address of the metadata header (MetaData Header), and the last four bytes are 0x000. 009a0, which is the length of the metadata; h. The linear address is obtained from the relative virtual address 0x0000218c of the metadata header.

0x0000038c, the metadata content is obtained according to the linear address and the metadata length; i. The compression program is read backward by the metadata header, and when the flag "#~" is read, the first eight words of the flag "#~" are read. Section, where the first four bytes are "#~,, the address, the "#~" stream is obtained by the address, and the fifth agreed byte in the "#~" stream starts to read the length of 8 bytes. Data, ie 0x0000000920021c57, whose binary form is

100100100000000000100001110001010111; In this embodiment, the fifth agreed byte is the ninth byte starting from the start bit of the "#~"stream; j. The binary data obtained in step i is read from the lower bit. For example, the first bit represents whether the metadata table Module exists. If it is 1, it proves that the metadata table Module exists. If it is 0, the proof does not exist. In this embodiment, there is a metadata table Module, and the second bit is 1, indicating that the metadata table TypeRef exists, and the third bit is 1, indicating that the metadata table TypeDef exists; wherein, in the data obtained in step i, Starting from the lower position, each bit represents whether there is a corresponding table in the .net file; k. The compression program reads the number of data lines of the metadata table TypeDef after shifting the sixth agreed byte after the data 0x0000000920021c57, in this embodiment In the middle, offsetting 16 bytes backwards and reading 4 bytes, the data 0x00000006 is obtained, and it is judged that there are 6 data rows in the metadata table TypeDef; wherein, in the metadata, the data 0x000000092002 lc57 is backward shifted In the data after 8 bytes, the number of data rows of the metadata table existing in the .net file is sequentially stored in units of 4 bytes, and after the data indicating the number of data rows, each of them is sequentially stored. Specific contents data table, the metadata table region; 1. Compress the program reads the content metadata table TypeDef obtained according to the agreed rule.

The rules agreed in this embodiment are as follows. The compression program sequentially reads the data of the number of metadata records after the data 0x000000092002 lc57, that is, 0x00000001 and OxOOOOOOld, and the phase table can be obtained after the metadata table TypeDef. There are 31 data rows in the two metadata tables Module and TypeRef. The data row of the metadata table Module is 10 bytes per row, and the data behavior in the metadata table TypeRef is 6 bytes per row. In the data table area, after shifting backward by 10* 1+6*30=190 bytes, the 191st byte starts as the content of the metadata table TypeDef, and the data row in the metadata table TypeDef acts 14 words. Therefore, the length of the metadata table TypeDef is 14*6=84 bytes, and the data of the metadata table TypeDef is obtained as follows: 000000000100 0000 0000 0100 0100

010010001900 2300 0500 0100 0100

010010003900 2300 0900 0600 0400

010110004000 2300 0D00 0600 0500 010110004000 2300 0D00 0600 0500

000000007102 0000 0900 0700 0700 The byte specified in the above data identifies different information, wherein one data row in each behavior metadata table TypeDef records a type name and an attribute, and for each line, reads from the high position, The first 4 bytes are Flags (definition type identifier), 5, 6 bytes are the offsets of the defined type name relative to the "#Strings" stream, and 7, 8 bytes are the namespace names to which the definition type belongs. The offset of the "#Strings" stream, see Table 11 for details: Table 11

In this embodiment, the metadata table TypeDef and TypeRef are type tables, and the type table includes namespace information, and the compression program needs to obtain namespace information from the metadata tables TypeDef and TypeRef. In this embodiment, the type count of the namespace refers to the number of types existing in the namespace, and the type count of all the namespaces is set to 0 before the compression program starts performing the compression operation. In a .net file, the type count for each namespace is independent, that is, each namespace corresponds to a type count. Step 1104: The compression program obtains a namespace name of a type in the metadata table. In this embodiment, the reading metadata table TypeDef is taken as an example. For example, the compression program reads the second type in the metadata table TypeDef, according to the second type. The structure of the above metadata table reads the offset of the namespace to which it belongs, that is, 0x0023, where the offset of the namespace is an offset from the "#Strings" stream in the metadata, and the compression program is based on The process of getting the namespace name for the offset is as follows: The compression program locates the location of the "#Strings" stream in the metadata, and reads the namespace information by the namespace offset 0x0023, during the reading process, by offset address 0x0023 Read, encounter the first At the end of a 0x00, the namespace name is:

4D79436F6D70616E792E4D794F6E4361726441707000 The ASC II code corresponding to the above namespace is MyCompany.MyOnCardApp, where the compression program reads out a type of namespace name each time; the compression program locates in the metadata "#Strings, the location of the stream is: After obtaining the address 0x0000038c of the metadata header in step h in 1102, it reads backward from the metadata header, and when it finds the tag "" #Strings,,,,, after reading ""#Strings,,,,, 8 bytes, get the data 0x5C0300003C040000, where the upper 4 bytes are the offset of the " #Strings" stream relative to the metadata header, the lower 4 bytes are the length of the " #Strings" stream, and the high 4 bytes are converted. The representation of the big end is 0x0000035 (^氐4 bytes are converted to big end, the representation is 0x0000043c; the compression program is based on the address 0x0000038c of the metadata header, offset 0x0000035c backwards to get the data area of the "#Strings" stream; Step 1106: Determine whether the read namespace name is duplicated with the namespace to which the type that has been read belongs. If yes, go to step 110. 8. If not, step 1110 is performed; because the compression program read in step 1104 is the namespace name of the second type in the metadata table, in this embodiment, the first type in the metadata table TypeDef does not exist. The name of the namespace, so there is no problem with the namespace to which the type already read belongs, and the operation of step 1110 and subsequent steps is continued; step 1108, the type of the above-mentioned repeated namespace is incremented by 1, and step 4 is performed. Step 1110: The namespace name is formed into a namespace string according to the agreed format. In order to distinguish the file to which the namespace belongs and reduce the collision rate of the data, the namespace name obtained in step 1104 needs to be named according to the agreed format. The space string, in this embodiment, preferably, the agreed namespace string format is as shown in Table 12: Table 12

PublicKey Token connector ( . ) Namespace Among them, PublicKeyToken is the public key label. When the .net compiler strongly signs the HelloWorld program, it will generate a HelloWorld.snk file. HelloWorld.snk contains the public and private keys. The above HelloWorld code is compiled by the compiler. After obtaining the PE file, the hash value is calculated for the PE file. The compiler uses the private key to sign the hash value and embed the public key in the PE file. The embedded public key is PublicKey, and the PublicKeyToken is for the PublicKey. The hash operation is obtained by taking the last eight bits. In this embodiment, the PublicKeyToken is 38 05 F8 26 9D 52 A5 B2 as an example. In this embodiment, preferably, the connector is represented by "", The resulting namespace string is 3805F8269D52A5B2. MyCompany.MyOnCardApp; The above connector can also be "-", "_", space, etc., not limited to ",,; In this step, the namespace name is also required. The type count is set to 1 to indicate that there is at least one type in the namespace; Step 1112, hash the namespace string, and take the agreed number of bits as the The compressed namespace name; wherein, the hash operation may use an algorithm such as MD5, SHA-1, SHA-2, etc. In this embodiment, the MD5 algorithm is preferably used, and the namespace string "3805F8269D52A5B2. MyCompany. MyOnCardApp" performs a hash calculation to obtain a 120-bit calculation result; in this embodiment, preferably, the calculation result of the 120 takes the first three bytes as a compression result, and in order to make the data byte alignment, it is also possible to Fill in "00", get the compressed namespace name "ACE6EB00"; the above-mentioned compressed namespace names are arranged in a little endian way, such as the big endian arrangement is 00EBE6AC, the storage in the computer is generally used. Big-end mode arrangement, X86-based smart card chip is arranged in a small endian manner; here, it should be noted that the PublicKeyToken in the namespace string needs to be case-sensitive to avoid the same PublicKeyToken result of hash calculation due to the case of upper and lower case. Inconsistent operation problem; Step 1114, determining whether the namespace names belonging to all types have been read If yes, go to step 1116. If not, read the namespace name of the namespace to which the next type belongs, that is, return step 4 to 1104; determine whether the namespace names to which all types belong have been read. See if After reading all the rows in the metadata table, if you have read it, it means that the namespace names of all types have been read. Otherwise, it means that not all the namespace names to which the type belongs are read and passed; Step 1116, the compression program organizes the compressed namespace name and the type count of the namespace according to the agreed format, and obtains a compression result of the namespace. In this embodiment, preferably, the agreed format, that is, after compression by the compression program The structure of the namespace is:

Table 13

The type count in the type count namespace name table 13 is the type count of the type contained in the namespace; wherein, in step 1114, the namespace names belonging to all types included in the metadata table are read and compressed. After the completion, you can get the compression result of all the namespace names, and get the type count of the types contained in all the namespaces. The compression result of the namespace obtained in step 1112 is taken as an example, where the namespace MyCompany There are 3 types of .MyOnCardApp, and the compressed namespace can be obtained as follows:

0300 ACE6EB00 The above compressed namespace is derived from the little endian representation. The compression structure of the namespace in the above compression result is only an optimal structure, and the structure can be transformed accordingly, for example, the type count of the namespace is placed after the compressed namespace name, or the value of the type count is equal. Coding transformation, etc., will not be described in detail here. The compression process of the namespace in this embodiment is only described by reading a type of namespace in the metadata table. In the actual operation, a .net file may contain one or more namespaces, and Each namespace includes multiple types. In practice, all types in the metadata table should be read one by one for the corresponding namespace, the namespace name should be taken out, and the different named namespace names should be compressed. Type the type of each namespace and get the compressed namespace as described above. The method provided in this embodiment may be used when reading the namespace corresponding to each type in the metadata table in the .net file. The following gives the result of compressing the namespace of a .net file:

Namespace:

(0)0100

D93DEB00//367DB8A346085E5D.System.Runtime.Remoting (1)0100 6E880000

//367DB8A346085E5D.System.Runtime.Remoting.Channels

(2) 0100 1178D900//

367DB8A346085E5D.SmartCard.Runtime.Remoting.Channels.APDU

(3) 0200 00F64D00 //D9E1E811B0CFFB39. System (5) 0100 1C5DD200 //367DB8A346085E5D. System

(6) 0400 00F64D00 //D9E1E811B0CFFB39. System

(A) 0100 1C5DD200〃367DB8A346085E5D.System

(B) 0200 C438E300 //

CB18FlDFA0E7655B.MyCompany.MyOnCardApp (D) 0100 00F64D00 //D9E 1E811B0CFFB39. System The above results are represented by little endian, such as the first compression result, 0100 is the type count of the type contained in the namespace System.Runtime.Remoting. That is, the namespace System.Runtime.Remoting includes 0001 types, that is, one type, and the last 4 bytes are the compression result of the namespace name System.Runtime.Remoting in the .net file, and the composition is named after "//". The space string, the following structures (1) to (D) are not used for explanation. The compression method of the namespace provided by this embodiment obtains the namespace name and compresses it according to the agreed format. The namespace can be better compressed, and the space required for storing the .net file can be saved. Especially when the .net file is run on the smart card, and the data storage of the smart card is limited, the embodiment can be used. The provided compression method implements the operation of the .net file and enhances the performance of the smart card. Embodiment 13 Referring to FIG. 25, this embodiment provides a compression device of a type defined in a .NET file, the device includes: a definition type information obtaining module 1202, configured to acquire information included in a definition type used in a .NET file; And obtaining the specified information and the counting information of the definition type according to the information included in the definition type; the compression module 1204 is configured to compress the specified information acquired by the definition type information acquiring module 1202; and the compression result storage module 1206 is configured to: compress the module 1204 The compressed designation information and the count information acquired by the definition type information acquisition module 1202 are stored as a compression result of the definition type. The specific implementation of the definition type information obtaining module 1202 may be: first reading the metadata table where the definition type in the .NET file is located, that is, the metadata table TypeDef; and obtaining the .net file from the metadata table TypeDef. Define the information that the type contains. The information included in the definition type in this embodiment includes: an identifier of the definition type, an offset of the name of the definition type, and an offset of the method in the definition type; when a field is used in the definition type, The information contained in the definition type may also include an offset of the field in the definition type; the information may be obtained by reading the data in the metadata table TypeDef. In the metadata table TypeDef, each row of data represents a definition type. Each line of data has a total of 14 bytes. The information recorded by these 14 bytes is: The first 4 bytes are Flags (definition type identifier), and 5, 6 bytes are defined type names.

"#Strings,, the offset in the stream, 7, 8 bytes for the namespace name of the definition type in the .net file. The offset in the #Strings" stream, 9, 10 bytes for this definition The offset of the succeeding parent class of the type, 11, 12 bytes is the offset of the field contained in the definition type of the field in the metadata table, 13 and 14 bytes are the methods included in the definition type The offset information in the metadata table. According to the information included in the definition type in the embodiment, the specified information includes: an identifier of the definition type, a name of the definition type, and a field corresponding to the definition type. The information of the name of the definition type can be found in the data stream corresponding to the .net file, and the information corresponding to the field of the definition type can also pass the above words. The offset of the segment is found in the Field table of the metadata table; the counting information includes: method overloading information of the defined type, method count and field count included in the definition type, and the like. When the compression module 1204 of the embodiment compresses the specified information, the compression method may be selected according to the specific object to be compressed. For example, when the identifier of the defined type is compressed, the identifier of the defined type may be first classified into a type identifier, an access identifier, and Descriptive identification; Then, the type identifier, the access identifier, and the descriptive identifier are ORed, and the obtained data is used as the compression result of the identifier of the definition type; when the name of the definition type is compressed, the name of the definition type can be performed. The Greek operation, extracting the agreed byte from the operation result as the compression result of the name of the definition type; when compressing the information corresponding to the field in the definition type (the name of the field, the identifier of the field, and the type of the field), according to the field The corresponding information content is divided into the following three cases:

1) hashing the name of the above field, extracting the agreed byte from the operation result as a compression result of the name of the field; 2) dividing the identifier of the above field into an access identifier and a descriptive identifier, for the above field The access identifier and the descriptive identifier in the identifier are ORed, and the obtained result is used as a compression result of the identifier of the field;

3) The offset of the type of the above field in the compressed type is taken as the compression result of the type of the field. As can be seen from the above, the compressed definition types include: a compression result of the definition type name, a compression result of the type identifier, a field count included in the type, a method count, a method overload information, a field corresponding to the type, and the like. . The information may be arranged in a predetermined format or may be arranged arbitrarily. In this embodiment, by compressing each part of the definition type in the .net file, and storing the compression result of each part according to a predetermined format, the storage space occupied by the .net file can be effectively reduced, so that the .net file can be Storage and operation on small-capacity storage media (for example, smart cards) enhances the functionality of small-capacity storage media such as smart cards. Embodiment 14 Referring to FIG. 26, this embodiment provides a compression method for defining a type in a .NET file. The method is described by using a compression device implemented in Embodiment 13, and the method includes: Step 1302: Defining a type The information obtaining module 1202 obtains the information included in the definition type used in the .NET file. Step 1304: The definition type information obtaining module 1202 obtains the specified information and the counting information of the definition type according to the information included in the definition type. Step 1306: The compression module 1204 Compressing the specified information; Step 1308: The compression result storage module 1206 stores the compressed designation information and the count information as a compression result of the definition type. The information included in the definition type obtained by the definition type information obtaining module 1202 is obtained by: first reading the definition type metadata table in the .net file, that is, the metadata table TypeDef; and then obtaining from the metadata table TypeDef The definition type used in the .net file contains information. The information included in the definition type in this embodiment includes: an identifier of the definition type, an offset of the name of the definition type, and an offset of the method in the definition type; when a field is used in the definition type, The information contained in the definition type may also include an offset of the field in the definition type; the information may be obtained by reading the data in the metadata table TypeDef. In the metadata table TypeDef, each row of data represents a definition type. Each row of data has a total of 14 bytes. The information of the 14 bytes is: The first 4 bytes are Flags (definition type identifier), and the 5th and 6 bytes are defined type names in "#Strings,, stream The offset, 7 or 8 bytes is the offset of the namespace name to which the defined type belongs in the "#Strings" stream in the .net file, and 9, 10 bytes are the succeeded parent of the defined type. The offset of 11, 12 bytes is the offset of the field contained in the definition type, and the 13 and 14 bytes are the offset of the method included in the definition type. The above specified information and counting information and the embodiment 13 Corresponding information Same here not elaborate. Preferably, in this embodiment, the identifier of the defined type is divided into a type identifier, an access identifier, and a descriptive identifier. Accordingly, the step of compressing the specified information by the compression module 1204 in step 1306 includes: The access identifier and the descriptive identifier are ORed, and the obtained data is used as a compression result of the identifier of the definition type; the name of the definition type is hashed, and the agreed byte is extracted from the operation result as the name of the definition type. Compress the result. When the current definition type in the .net file contains a field, the definition type contains information including: an offset of the field in the definition type; correspondingly, the above specified information further includes: a field in the definition type Corresponding information; The counting information also includes: a field count of the defined type. Preferably, the information corresponding to the field in this embodiment includes: a name of the field, an identifier of the field, and a type of the field; wherein, the identifier of the field is divided into an access identifier and a descriptive identifier; and correspondingly, the compression in step 1306 The module 1204 compresses the specified information by: performing a hash operation on the name of the field, extracting the agreed byte from the operation result as a compression result of the name of the field; and accessing the identifier in the identifier of the field The descriptive identifier is ORed, and the result is the compression result of the identifier of the field; the offset of the type of the field in the compressed type is the compression result of the type of the field. Preferably, the information included in the definition type includes: an offset of the parent class inherited by the definition type; correspondingly, the method further includes: determining whether the parent class inherited by the definition type is compressed, and if so, obtaining the inherited Offset of the parent class; otherwise, compressing the succeeded parent class and assigning an offset to the compressed succeeding parent class; correspondingly, the compressed result of the above defined type further includes the compressed The offset of the parent class. Preferably, the method further includes: determining whether the defined type has an inherited interface; if yes, obtaining the inherited by the defined type The offset of the interface and the number of interfaces following the 7th; correspondingly, the compression result of the defined type also includes the offset of the above-mentioned inherited interface and the number of inherited interfaces. Preferably, the method further includes: determining whether the definition type is a nested type, and if yes, obtaining a compressed offset of the type of the definition type; correspondingly, the compression result of the definition type further includes the definition type The type of offset after the type. Through the above method, the data compressed by each definition type is organized in the following format: a hash value defining the type name (the compression result of defining the type name), a compression result of the type identifier, an interface count inherited by the type, and a type parent The offset of the class, the field count contained in the type, the method overload information in the type, the compressed offset of the type where the type is defined, the offset of the type after the 7-port compression, and the information corresponding to the field in the type. Etc.; The offset of the interface inherited by the type, and the information corresponding to the field in the type may have multiple. When there are multiple, the interface offset and the corresponding information of the current definition type are sequentially arranged. In addition, the offset type after the type of the defined type, the offset of the type after the compression of the interface, and the information corresponding to the field in the type may exist or not exist.

In this embodiment, by compressing each part of the definition type in the .net file, and storing the compression result of each part according to a predetermined format, the storage space occupied by the .net file can be effectively reduced, so that the .net file can be Storage and operation on small-capacity storage media (for example, smart cards) enhances the functionality of small-capacity storage media such as smart cards. Embodiment 15 This embodiment provides a compression method for defining a type in a .NET file. The compression method is described by taking a specific application example as an example. In the jtb application instance, the reference type compression in the .NET file is involved. And the stored part, the compression result of the reference type in this example is known content, and can be used directly. This embodiment takes the file compiled by the following code as an example to illustrate the compression method of the type defined in the .net file. Part of the code is as follows: namespace MyCompany. MyOnCardApp Public class My Service: MarshalByRefObject

{

Public String MySampleMethodQ

String strHello = "Hello World!"; return strHello + callCount.ToStringQ;

Public class ClassA

Public class ClassC: ClassB, IA, IB

Static String strField;

Int32 iField;

Public ClassC(String strl, int i)

strField = strl:

iField = i;

Public String TestC() Return null;

}

} private struct StructB { } } public class ClassB

{ > public interface IA { } public interface IB

{ >

} The above code is compiled with the .net platform to get the helloworldexe file, which is stored in binary form on the hard disk. The binary file is a .net file. The .net file can run under Windows environment and is compatible with PE (Portable Executable, portable). Executable) File format, PE format is the format of Windows executable file. The .exe file and .dll file in Windows are all in PE format. See Figure 27, which is a schematic diagram of the structure of a .net file. The file includes a Dos header, a PE feature, and metadata (metadata). The metadata includes a metadata header (MetaData Header), a metadata table (MetaData Tables), and the like. Referring to FIG. 28, the compression method for defining a type in the .NET file provided by this embodiment includes: Step 1401: Locating a starting address of a metadata table (Metadata Tables) in a net file, and acquiring an existing table bit vector; The metadata table is part of the .net file, and the process of locating the metadata table is as follows:

1) Positioning. Net file Dos header, get Dos header i only 0x5a4d; 2) After the Dos header is identified, the first agreed byte is skipped, and the offset address of the PE feature is read to obtain the offset address 0x00000080 of the PE feature. In this embodiment, the first agreed byte is 0x003 a. Bytes;

3) According to the PE feature offset address 0x00000080, the PE feature is located, and the positioning is PE feature 0x00004550;

4) After the PE feature is started, four bytes are read after the second predetermined byte is offset. In this embodiment, a 32-bit machine is taken as an example for description, and the second agreed byte is from the PE feature. After offsetting 0x0074 bytes backward, the read data is 0x00000010. This value indicates that there are 0x10 directories in the binary file and contains .net data. The metadata header address of the .net file is written in the above OxOF. In the directory; if it is in a 64-bit machine, the second agreed byte is 0x0084 bytes;

5) Starting from the above data 0x00000010, the third predetermined byte is read backward by eight bytes of data. In this embodiment, preferably, the third agreed byte is 0x0070 bytes, where In the byte data, the first four bytes are 0x00002008, which is the relative virtual address of the .net data header in the .net file, and the last four bytes are 0x00000048, which is the length of the .net data header; 6). The relative virtual address of the .net data header in the net file is 0x00002008 and the linear address is obtained.

0x00000208 and read the .net data header.

48000000 02000500 0C220000 9C0A0000

09000000 01000006 00000000 00000000

50200000 80000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 It should be noted that the above data is stored in a small endian. For example, the first 4 bytes of the above data 0x48000000 are converted into a big end storage mode of 0x0000048, indicating the length of the data; wherein, according to the .net metadata The length of the header 0x00000048 reads 72 bytes of data. In this embodiment, the linear address is the address of the .net data in the .net file, and the relative virtual address is the memory offset relative to the PE load point. The conversion relationship between the linear address and the relative virtual address is: Linear address=relative Virtual address - section relative virtual address + section file offset, in this embodiment, read The relative virtual address of the section of the .net data directory in the .net file is 0x00002000, and the file offset of the section is 0x00000200, then the linear address

=0x00002008-0x00002000+0x00000200=0x00000208;

7) After the .net data header is shifted backward by the fourth predetermined byte, in the embodiment, the fourth agreed byte is offset from the .net data header by 8 bytes, and then read. A total of 8 bytes of data, among the 8 bytes, the first four bytes are 0x0000220c, which is the relative virtual address of the metadata header (MetaData Header), and the last four bytes are 0x00000a9c, which is the length of the metadata;

8) According to the relative virtual address 0x0000220c of the metadata header, the linear address 0x0000040c is obtained, and the metadata content is read according to the linear address and the metadata length; 9) read backward by the metadata header, when the flag "#~ is read "(0x237E), read the flag "#~" before the eight bytes, where the first four bytes are "#~" stream data relative to the metadata header offset, the last four bytes are "#~ "The length of the stream; the data area of the stream of "#~" is obtained by the relative offset of the stream of "#~", and the data of the length of 8 bytes is read in the fifth contracted byte in the stream of "#~". Obtaining the bit vector of the existing table (MaskValid) In this embodiment, the bit vector value of the existing table is 0x000002092002 lf57, and its binary form is:

100000100100100000000000100001111101010111 In this embodiment, the fifth agreed byte is the ninth byte starting from the start bit of the "#~"stream; the bit vector of the existing table is read from the lower bit, and each bit represents a metadata. Table, if the table exists, the value of the corresponding bit is 1, otherwise 0; for example, starting from the low bit, the first bit represents whether the metadata table Module exists, and if it is 1, it proves that the metadata table Module exists, if If it is 0, the proof does not exist. In this embodiment, there is a metadata table Module, and the second bit is 1, indicating that the metadata table TypeRef exists, and the third bit is 1, indicating that the metadata table TypeDef exists; Step 1402: Positioning The metadata table TypeDef (definition type); according to the bit vector of the existing table read out in step 4 1401, records whether the corresponding metadata table exists in the .net file from the clamp to the high position, wherein, 3 bits represent the existence of the metadata table TypeDef. If the third bit is 1, the metadata table TypeDef exists. If the third bit is 0, the metadata table TypeDef does not exist. In this embodiment, the metadata table TypeDef is stored. ; Starting with the 9th byte after the existing epitope vector 0x000002092002 lf57, the number of data rows contained in the metadata table existing in the .net file is recorded in units of four bytes, skipped in front of TypeDef The two metadata table data row number information, starting to read 4 bytes at the 17th byte after the data 0x000002092002 lf57, get the data 0x0000000a, this data indicates that there are 10 data rows in the metadata table TypeDef; After the data representing the number of data rows, the specific content of each metadata table is sequentially stored as a metadata table area; the process of reading the contents of the metadata table TypeDef is as follows: According to the existing table read in step 1401 The bit vector is known to have a metadata table Module and a metadata table TypeRef before the metadata table TypeDef in the embodiment of the present invention, wherein the metadata table Module has 1 data row and 10 bytes, and the metadata table TypeRef has 31 data. Row, 186 bytes, skip 60 bytes of data representing the number of data rows contained in the metadata table, then skip the metadata table Module and the metadata table TypeRef and read the number of bytes According to the 10 data lines of the TypeDef table, each data line has 14 bytes. The specific data is as follows:

0x0000000001000000000001000100 0x0100100019002200050001000100

0x0100100038002200090002000300

0x0100100042002200050007000600

0x0100100049002200050007000700

0xA100000050002200000007000800 0xA100000053002200000007000800

0x0200100056000000140007000800

0x030110005D0000000D0009000A00

0x00000000C8030000050009000A00 In the metadata table TypeDef, the data in each data row represents a definition type, the first 4 bytes of each data row are Flags (definition type identifier), 5, 6 bytes are defined type names in .net The relative offset in the "#Strings" stream in the file, 7 or 8 bytes is the namespace name to which the definition type belongs The relative offset in the "#Strings" stream, 9, 10 bytes is the information of the succeeding parent class of the defined type, 11, 12 bytes are the first field contained in the definition type in the metadata table The data line number in the Field, 13, 14 bytes is the data line number of the first method contained in the definition type in the metadata table Method. In this embodiment, the length of the data in each data row in each metadata table is fixed, and other elements can be calculated by the method of locating the metadata table according to the existing table bit vector and the number of metadata table rows. The offset address of the data table in the .net file. Step 1403: The identifier and the name of the definition type are read according to the data in the metadata table TypeDef, and the identifier and the name of the definition type are respectively compressed; first, according to the data read into the metadata table TypeDef, read The identifier of the definition type is taken and compressed; the identifier of the definition type of the four bytes is read from the metadata table TypeDef, and the identifier of the definition type is known for each identifier attribute of the definition type; The identifier is divided into three parts: type identifier, access identifier, descriptive identifier, and redefines the values of each identifier attribute. For example, the type identifier includes: predefined type 0x00, value type 0x01, enumeration type 0x02, array type 0x03, Class type 0x04, interface type 0x05, unmanaged pointer type 0x06, etc.; access identifiers include: non-public access type NotPublic (0x00), public access type Public (0x10), if nested type: access modifier identification public embedded Set type NestedPublic ( 0x20 ), private nested type NestedPrivate (0x30), family nested type NestedFamily (0x40) , Assembly nested type NestedAssembly (0x50), assembly and family nested type NestedFamANDAssem (0x60), assembly or family nested type NestedFamORAssem (0x70); Descriptive identifier is used to describe some properties of the field in the current type, such as There is a non-serializable field 0x08, otherwise 0x00. The method for compressing the identifier of the defined type in this embodiment is specifically: performing a OR operation on the type identifier, the access identifier, and the descriptive identifier, and the obtained 1-byte data is Compress the result for the identity of the defined type. For example, the definition type ClassC of the 8th data line of the metadata table TypeDef read in step 1402 is 0x00100002 according to the definition of the first 4 bytes, and the type identifier is 0x04, and the access identifier is NestedPublic ( 0x20 ), the descriptive identifier is 0x00, the value of the above attribute is ORed 0x04|0x20|0x00 to get 0x24, 0x24 as the definition type ClassC's identity compression results. Then, according to the data in the read metadata table TypeDef, the definition type name is read and compressed; that is, the name of the definition type is read according to the relative offset of the definition type name in the "#Strings"stream; for example , in the second data row data in the metadata table TypeDef read out, the value in the 5th and 6th bytes is 0x0019, after positioning the "#Strings" stream of the .net file, skipping 0x0019 bytes. Start reading data, read 0x00 and end, get 0x4D79536572766572, the data is the name of the currently defined type in the metadata table TypeDef MyServer; hash the hash of the read definition type name, from the hash operation result The sixth agreed byte is taken as the result of the compression of the definition type. In the embodiment of the present invention, the sixth agreed byte is the first two bytes of the hash value. The hash algorithm used can be MD5, SHA-1, SHA-2, and so on. For example, in the embodiment of the present invention, the MD5 algorithm is used to hash the MyServer, and the following is obtained: 0x0CBEFBClEF0639BA18485104440F399C, and the sixth agreed byte OxOCBE is taken as the compression result of the currently defined type MyServer name in the metadata table TypeDef. In addition, if - according to the current type of identifier to determine that the current type is a nested type, then read the name of the type of the current type, hash the name of the type of the current type and the name of the current type, from the hash operation The result is the sixth agreed byte as the compression result of the current type; the combined method may be to use the connector to stitch the two together, or directly splicing the two types, or two types of names Math operations such as addition, subtraction, XOR. For example, the code given in this embodiment is taken as an example: The type Class C is nested in the type Class A. Therefore, when class C is compressed, the type name of the Class A is first spliced with the type name of the Class C, and is used in this embodiment. The connector "+" is spliced, hashing the ClassA+ClassC, and then taking the first two bytes of the hash value as the type name compression result of the ClassC, so as to avoid duplication of the compression result of the defined type name; The name of the ClassA is 0x0042, the name of the ClassC is 0x0056, and the hash operation is performed on the ClassA+ClassC using the MD5 algorithm. The result is: 0x9B 8DE23910B330 AD80BDB76E7 AC 19092 , taking the first two bytes 0x9B8D as the currently defined type in the metadata table TypeDef The compression result of the ClassC name. The method for locating the location of the "#Strings" stream in the metadata in the embodiment is: after obtaining the address 0x0000040c of the metadata header in step 1401, reading backward from the metadata header, when the tag is found "# After Strings" (0x23537472696E6773), the 8 bytes of data before "#Strings" are read, and the data 0x0004000080040000 is obtained. The high-order 4 bytes are converted to big end and the representation is 0x00000400, indicating that the "#Strings" stream is relative to the metadata. The offset of the header, the lower 4 bytes are converted to the big end and the representation is 0x00000480, which means the length of the "#Strings" stream, which is 4 bytes lower; from the address 0x0000040c of the metadata header, 0x00000400 words backwards Section gets the data area of the "#Strings" stream. Step 1404: Obtain the method overload information in the current definition type, and obtain the method count and the field count of the method included in the current definition type. The method for obtaining the method count in this embodiment is as follows: Read the current data table TypeDef Defines the data in the 13th and 14th bytes of the data row where the type is located. The data is the data row number of the first method in the metadata table Method defined by the definition type, and then reads the next definition type of the current definition type. Contains the data line number of the first method in the metadata table Method, the data line number of the first method contained in the next definition type minus the data line number of the first method contained in the current definition type. The result is the count of all the methods contained in the current type. The method for obtaining all the method counts contained in the last data row in the metadata table TypeDef is: The number of data rows in the metadata table Method minus the data row number of the first method included in the last defined type data row, The result is the count of all the methods contained in the last data row in the metadata table TypeDef. In the metadata table TypeDef read in this embodiment, the first method included in the type Class C is defined in the metadata table Method. The data line number in the metadata table is 0x0008, and the definition type of the type ClassC is included in the definition of the type StructB. The first method in the metadata table Method is the data line number OxOOOA. As can be seen from OxOOOA - 0x0008, the number of methods included in the definition type ClassC is 0x0002. The method overloaded information of the defined type is used to describe whether there is a virtual method in the current type. If it exists, the method overload information is incremented by 1, wherein the initial value of the overloaded information of each defined type method is 0. First, locate the metadata table Method; the specific method is similar to the process of locating the metadata table TypeDef in step 1402, which is briefly described as follows: According to the bit vector of the existing table read in step 1401, whether the corresponding metadata table exists in the .net file is sequentially recorded from the lower to the upper, wherein the seventh bit represents whether the metadata table Method exists, in this embodiment. In the middle, the data of the 7th bit is 1, and the metadata table Method exists; the ninth byte after the existing epitope vector 0x000002092002 lf57 starts, and the four bytes are recorded as one unit corresponding to the record in the .net file. The number of data rows included in the metadata table. According to the existing table vector, there are four other metadata tables before the metadata table Method. The four metadata tables in front of the Method are skipped. After the data 0x000002092002 lf57 The 25th byte starts to read 4 bytes, and the data 0x00000009 is obtained. This data indicates that there are 9 data rows in the metadata table Method; the contents of the metadata table Method are read: According to the bit vector of the existing table and The data indicating the number of rows of the metadata table can be known. In the present embodiment, the metadata table Module has 10 bytes before the metadata table Method, and the metadata table TypeRef has 186 bytes. Data Sheet TypeDef 140 bytes and metadata table byte Field 54, after skipping the foregoing metadata table 3, Method read metadata table 9 data lines of 126 bytes. Then, according to the data line number of the first method included in the current definition type in the metadata table Method, the data of the corresponding data row is read from the metadata table Method, and the seventh and eighth of each data row in the metadata table Method The byte is the method identifier. According to the method identifier, it is determined whether the method in the current type is a virtual method. If yes, the method overload information is incremented by one; if the method count of the currently defined type is greater than 1, then the metadata table continues. Read the next data line and perform the operation according to the above method. Until all the methods included in the current definition type are read and judged; specifically, the method for determining whether the method in the current type is a virtual method and needs to open a new storage slot is: reading the identifier of the method in the current type, The ID is used to perform the AND operation with 0x0100. If the result of the operation is 0x0100, it can be determined that the method in the current type is a virtual method and a new storage slot needs to be opened. Obtaining the field count included in the current definition type is similar to the method of obtaining the method count included in the current type. The simple description is as follows: Read the data stored in the 11th and 12th bytes of the row of the currently defined type in the metadata table TypeDef, Get the data row number of the first field contained in the current definition type in the metadata table Field, and then read the next definition type of the current definition type stored in the 11th and 12th bytes in the next data row. The first field is the data line number in the metadata table Field, and the latter is the data line number minus The result of going to the former data line number is the field count contained in the current type. In the metadata table TypeDef read in this embodiment, the first field included in the type Class C is defined in the data table Field. The data line number in the metadata table Field is 0x0007, and the first definition type of the type ClassC is defined as the first type included in the StructB. The field data line number is 0x0009. It can be seen from 0x0009 - 0x0007 that the number of fields included in the current definition type ClassC is 0x0002, that is, the field count of the defined type ClassC is 0x0002. Step 1405: Acquire information corresponding to the field in the currently defined type and compress it. The method of reading the metadata table Field is similar to step 1402; the length of each data row in the metadata table Field is 6 bytes; wherein the first and second bytes are stored in the data row in the metadata table Field The Flags of the field (field identifier;), the 3rd and 4th bytes store the name of the field (field name), and the 5th and 6th bytes store the Signature information of the field. The process of compressing the information corresponding to the fields in the currently defined type is as follows:

1) Get the field name and compress it; perform the hash operation on the name of the read field (the field name), and take the seventh agreed byte in the hash value as the compression result of the field name (field name). In this embodiment, the seventh agreed byte is the first two bytes of the hash value; in this embodiment, Class C includes two fields, and the name (field name) is strField and iField respectively, and the field name of the field strField The "strField" is compressed as an example. The hash value obtained after compression is: 0x846461722F82E1CAB3D95632E8424089 The first two bytes of the hash value 0x8464 are taken as the compression result of the field name "strField".

2) compressing the identifier of the field; according to the Flags (field identifier;) of the field read in the metadata table Field, the flag information of the field can be determined according to the Flags of the field, and the field is in this embodiment. The identification information is divided into two types: an access identifier and a descriptive identifier; performing an OR operation on the value of the access identifier and the descriptive identifier of the field to obtain a compression result of the flag Flags; wherein, the access identifier includes: Private range type Privates cope=0x00 Private type Private=0x01 Family and assembly type FamANDAssem=0x02 Assembly type Assembly=0x03 Family type Family=0x04 Family or assembly type FamORAssem=0x05 Public type Public=0x06 Descriptive identifiers are: Static Type Static=0xl0 Initialization InitOnly=0x20 Unsequence 4匕NotSerialized=0x80 In this embodiment, the definition type ClassC contains two fields, strField and iField respectively, and analyzes the Flags (field identifier) when compressing the strField field identifier. The access identifier of the field is Private=0x01, the descriptive identifier is Static=0xl0, and the OR operation of 0x01 and 0x10 is 0x11, and the result of the strField field is 0x11.

3) Get the type of the field; the type of the field is stored in the "#Blob" stream, and the Signature information of the 4th byte of the current line in the metadata table Field is read. The information is the type information of the field in the "#Blob" stream. The relative offset address in the data, the corresponding data is read in the "#Blob" stream according to the relative offset address; wherein, the data of the first byte read indicates the length of the data after, the second word The section indicates the type of data. If the second byte is 0x06, it indicates that the data is the type of the field, the third byte data indicates the field type, or the field type information is included in the fourth byte; according to the third byte The field type shown finds the corresponding type in the metadata table, or parses the field type information contained in the _4th byte to get the corresponding type of the field in the metadata table, and compresses the type in the metadata table. The offset is saved as the type of the field. Wherein, the method of locating the "#Blob" stream position is located in the metadata in step 41402 "#Strings,, the method of the location of the stream is similar: after the address 0x0000040c of the metadata header is obtained in step 1401, the backward reading is started from the metadata header, and when the tag "#Blob" (0x23426C6F6) is found, the read is performed. The 8 bytes of data before "#Blob" get the data 0xD4080000C8010000, where the high 4 bytes are converted to big end and the representation is 0x000008D4, which means the offset of the "#Blob" stream relative to the metadata header, 4 words lower The representation of the section converted to big end is 0x0001C8, which means the length of the "#Blob" stream, and the data area of the "#Blob" stream is obtained by offsetting 0x0000040c4 from the address of the metadata header to 0x000008D4. In this embodiment, The method for defining the field type of the field strField contained in the type ClassC is as follows: Read the data of the 4th byte of strField in the metadata table Field to get OxOOOA, and then offset in the data area of the "#Blob" stream. The data is read at OxOOOA, and the data 0x02 of the first byte is read, indicating that it is necessary to read data of 2 bytes in length after the data, and ΟχΟόΟΕ, where the second byte is 0x06, indicating the word. Post-holiday data Shows the field type, continues to read the third byte to get the data ΟχΟΕ, according to the language specification, ΟχΟΕ indicates that the field type is string type, find the offset of the string type compressed in the metadata table TypeRef, the result of the search is 0x03, save 0x03 as the field type of the field strField. This embodiment defines that the information corresponding to the compressed field contains three parts: 2 bytes of length name (field name) Compressed value, 1 byte Flags (Field ID) Compressed value and 1-byte Signature information compression value; if the current type contains multiple fields, each field is compressed and saved in order. According to the method shown above, the ClassC contains The information of the fields strField and iField is compressed: 0x84641103 F1EC0106. If there is no defined field in the currently defined type, the item does not exist in the compressed definition type. Step 1406: Determine whether the current definition type has a parent class, if If there is a parent class and its parent class is uncompressed, then step 4 is aggregated 1403, and the parent class of the current class is compressed by a recursive method. Otherwise, step 1407 is performed; data is read from the 9th and 10th bytes of the data line of the current type in the metadata table TypeDef; if the read data is 0x0000, the current type has no parent class, and the execution step 4 is 1407; The data read from the 9th and 10th bytes of the data line of the current type in the metadata table TypeDef is not 0x0000, and the read data stored in the little endian storage mode is converted into the format of the big endian storage, that is, the conversion After the high byte is in the front, the low byte is in the back form, and then the data is converted into binary The system number is shifted to the right by two digits, and the data row number of the parent class of the current type in the metadata table TypeRef or TypeDef is obtained; the data row number obtained after the shift is ANDed with 0x03, and if the operation result is 0, the current type is In the metadata table TypeRef, the parent class performs step 1407; if the operation result is 1, it can be seen that the parent class of the current type is in the metadata table TypeDef, and the type of the data row corresponding to the data row number in the metadata table TypeDef is found. If it is already compressed, go to step 1407, otherwise, go to step 1403. Step 1407: Obtain the compressed type of the type of the parent class of the definition type 7; read the data from the 9th and 10th bytes of the data line of the current type in the metadata table TypeDef, if the read data is 0x0000, the current type has no parent class, save OxFF means that the current type has no parent type; if the data read from the 9th and 10th bytes of the data line of the current type in the metadata table TypeDef is not 0x0000, it will be read The data saved in the little endian storage mode is converted into a big endian storage format, that is, the high byte first and the low byte are after the conversion, and then the binary number of the converted data is shifted to the right by two, to obtain the current The data row number of the parent class of the type in the metadata table TypeRef or TypeDef; the data row number obtained after the shift is ANDed with 0x03, if the operation result is 0, the parent class of the current type is in the metadata table TypeRef, Find the offset of the type of the data row corresponding to the data row number in the metadata table TypeRef, and store it as the offset of the parent class of the current type; if the operation result is 1, the current type is known In the parent TypeDef metadata table, find the offset metadata table TypeDef row corresponding to the type of data compression and the line number data, and stores it as an offset down the current type of the parent class. For example, in this embodiment, the acquisition process of the parent class of ClassC is as follows: Read the 9th and 10th bytes of the data row of the ClassC in the metadata table TypeDef, and obtain the data converted to the big end storage format and then 0x0014, converted into binary For: 10100, shifting the binary number 10100 to the right by 2 bits to get 101 is 0x05. Since the result of the AND operation between 0x05 and 0x03 is 0x01, it can be seen that the parent class of ClassC is 0x05 data lines in the metadata table TypeDef, and then finds the element. The compressed offset of the 0x05 data row of the data table TypeDef is stored as the offset of the ClassC parent class. Step 1408: Assign an offset to the currently defined type; after compressing each defined type according to the method described in the above step, obtain the .net file. The compression information of the metadata table TypeRef (reference type) continues to reference the type-compressed offset to continuously assign an offset to the definition type. For example: If the offset of the last type after the reference type compression in the .net file is OxlA, the offset of the first type in the compressed definition type is OxlB, and the offset of the second defined type after compression is 0xlC. Step 1409: Determine whether there is a definition type waiting for the parent class offset in the cache, if yes, execute step 4 to gather 1407, otherwise execute step 4 to gather 1410; Step 1410: Determine whether all the defined types of data are analyzed, if Then, step 1411 is performed. Otherwise, step 1403 is executed to continue compressing the remaining definition types in the metadata table TypeDef. Step 1411: Obtain the interface offset and the number of inherited interfaces inherited by the currently defined type; when all the defined types of data are After the above processing, you can query the metadata table.

The data in Interfacelmpl gets the interface offset and the number of interfaces inherited by each defined type. According to the existing table vector, the metadata table Interfacelmpl (interface class) is used. The method of reading the metadata table is similar to step 1402. ; Read the metadata table Interfacelmpl. In the metadata table Interfacelmpl, each row has 4 bytes, the first and second bytes of Class indicate that the type of the interface inheriting the interface is in the data row of the metadata table TypeDef, and the value conversion in the third and fourth byte Interface The value obtained by shifting the binary number to the right by 2 bits is the data row of the interface class in the metadata table TypeDef. According to the information read in the metadata table Interfacelmpl, the interface class of each definition type in the metadata table TypeDef and the number of interfaces of the succeeding 7 are obtained; wherein, the compressed offset of the corresponding interface class is also obtained. If the current definition type does not inherit any interface, the number of interfaces in the compressed definition type is 0x00, and the information corresponding to the interface does not exist. Step 1412: Obtain the compressed offset of the type of the nested type. Determine whether the current type is a nested type according to the identifier information of the currently defined type. If the type is a nested type, obtain the offset of the type of the current nested type. Quantity; if it is determined that the current type is not a nested type, the item does not exist in the compressed definition type. According to the definition type identification information of reading four bytes in the metadata table TypeDef in step 1403, it is judged whether the current type is a nested type, and if it is a nested type, it is also read in the metadata table NestedClass (nested type). The information is based on the existing epitope vector positioning metadata table NestedClass, the specific method is similar to step 1402; read the metadata table NestedClass. There are 4 bytes in each row in the metadata table NestedClass, the first and second bytes are NestedClass, which indicates the data row of the current nested type in the metadata table TypeDef, and the 3rd and 4th bytes are EnclosingClass indicating the currently defined type. The data type in which the type is in the metadata table TypeDef. Find the data row of the type of the current type in the metadata table TypeDef, obtain the compressed offset of the type of the current type, and use it as the type of the current nested type; Step 1413: Organize and store the compressed Define type data. The compressed data for each defined type is organized in the following format: the hash value that defines the type name, the compression result of the type identifier, the interface count inherited by the type, the offset of the type parent class, and the fields contained in the type. Count, the method overload information in the type, the offset of the type of the nested type, the offset of the interface where the type is located, and the information corresponding to the field in the type; where, the offset of the interface of the type, the information corresponding to the field in the type There may be more than one, when there are multiple, the interface offset and field information in the currently defined type are arranged in turn; in addition, the offset of the type of the nested type, the offset of the interface inherited by the type, and the type The information corresponding to the field may or may not exist in the three parts. If it does not exist, the information is not written in the compression result. For example, in the code provided in this embodiment, the result of defining the type ClassC is:

0x9B8D240216020200171819F 1EC010684641103 In order to make the above compression result seem clearer and more intuitive, the above data is stored in the form of Table 14. See Table 14. Definition Type The resolution structure of the result after ClassC compression is: Table 14

Following the interface count of 7 02 follows the offset of the parent class of 7 16 Defines the type contained in the field count 02 Defines the type in the method count 02 Method overload information 00 The type of the nested type is offset 17 Follow the interface offset The quantity 18, 19 defines the corresponding information of the field F1EC 01 06, 8464 11 03 After the compression of each defined type in the .net file is completed, it is stored sequentially according to the offset allocated after compression. The data to be compressed in the embodiment is the binary data that is compiled after the code written in the .NET structure, and the compression rate of the defined type can be up to 30% by the method provided in this embodiment, thereby effectively Reduce the storage space occupied by .net files, so that .net files can be stored and run on small-capacity storage media (such as smart cards), which enhances the function of small-capacity storage media (such as smart cards). The compression method or the compression device provided by the above embodiments effectively reduces the storage space occupied by the .net file, which facilitates the use of .net files on various devices, and also saves system resources and improves resource utilization. Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device so that they may be stored in the storage device by the computing device, or they may be separately fabricated into individual integrated circuit modules, or Multiple modules or steps are made into a single integrated circuit module. Thus, the invention is not limited to any specific combination of hardware and software. The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modification, equivalent substitution, improvement, etc. made within the "God and Principles" of the present invention shall be included in the protection of the present invention. Within the scope.

Claims

A method for compressing .net files, characterized in that the method comprises at least one of the following steps: obtaining a reference type in a .net file, compressing the reference type; obtaining a .net file a method for defining, compressing the defined method; obtaining a method body of the defined method in the .NET file, compressing the method body; obtaining a namespace in the .net file, and compressing the namespace; The definition type in the .net file, which is compressed for the definition type.

2. The method according to claim 1, wherein the step of obtaining a reference type in the .net file and compressing the reference type comprises:

Get the name of the reference type used in the .net file and compress it to get the name of the compressed reference type;

Counting method counts and field counts for the reference type;

The compressed reference type name, the method count, and the field count are combined in a predetermined format to obtain a compressed result of the reference type.

3. The method according to claim 2, wherein the step of obtaining the name of the reference type used in the .net file comprises:

Get the first metadata table in the .net file;

Reading address information of a name of a reference type used in the .net file from the first metadata table;

The name of the reference type is read according to the address information.

The method according to claim 2, wherein the step of obtaining the name of the reference type used in the .net file and compressing comprises:

Get the name of the reference type used in the .net file;

After the reference type name string is generated according to the name of the obtained reference type, the compression is performed; The step of generating a reference type name string according to the name of the obtained reference type includes:

Converting the name of the obtained reference type into a predetermined encoding format, and generating a reference type name string;

Or

Obtaining a namespace name to which the reference type belongs, combining the namespace name with a name of the reference type, and generating a reference type name string;

The step of compressing the reference type name string includes:

Hashing the name string of the reference type to obtain a hash value;

A predetermined byte of the hash value is taken as the name of the compressed reference type. The method according to claim 2, wherein the step of counting the method count and the field count of the reference type comprises:

Obtaining a second metadata table; performing the following operations on each row of data of the second metadata table:

Reading a reference type pointed to by the current row data in the second metadata table;

When the name of the reference type pointed to by the current row data is consistent with the name of the obtained reference type, determining whether the current row data record is a method according to the feature identifier value of the current row data, and if yes, The method count of the reference type is incremented by one; otherwise, the field count of the reference type is incremented by one. The method according to claim 2, wherein the predetermined format is a fixed length byte, and the fixed length byte comprises three parts, wherein the first part is the compressed reference type Name, the second part is the method count, and the third part is the field count. The method according to claim 1, wherein the obtaining method in the .net file is obtained, and the step of compressing the defining method comprises:

Navigate to the .net file;

According to the .net file, the definition method table and related stream in the metadata table in the .net file are located; Forming a character string for the content of the corresponding data item of each of the defined methods in the stream according to the definition method table, and the content of the data item includes a parameter count;

Hashing the string to convert to a name hash value;

Compressing the execution identifier and the access identifier of the defined method;

Compressing a parameter table of the defined method in the stream;

The name hash value, the compressed execution identifier and the access identifier, the parameter count, and the compressed parameter table are organized according to a preset rule to obtain a compressed structure. The method according to claim 7, wherein: - according to the .net file, the definition method table and related flows in the metadata table located in the .net file include:

The content in the header of the .net file is located to the address and size of each stream in the .net file;

The bit vector in the metadata header of the metadata stream and the contents of the table record count are located to define the offset address of the method table data block in the metadata stream. The method according to claim 7, wherein the content construction string of the corresponding data item of each of the definition methods in the stream according to the definition method table comprises: reading a value of a name item in the data item And reading the value in the stream of the string in the stream to obtain the name of the defined method;

Reading the value of the signature item in the data item, and reading the data in the Blob stream in the stream according to the value, and analyzing the parameter information of the definition method and the type of the return value according to the data; Defining the type information pointed to by the type of the return value in the definition type table or the reference type table of the metadata table, and recording the offset of the corresponding name item and the namespace item in the data item table of the type in the string The stream reads information about the type name and namespace name of the type;

Applying the namespace name and the type name to form a full-name string of the return value; respectively, reading the type name and the namespace name of the parameter according to the parameter type in the obtained parameter information, and the obtained data constitutes a parameter full name string;

The obtained return value full name string, the obtained name of the definition method, and the parameter full name string constitute the character string;

Compressing the parameter table of the defined method includes: And positioning, according to the value in the parameter table item in the data item, a parameter row corresponding to the parameter table of the metadata table;

Read the corresponding parameter line information, which includes: 2-byte Flags item, Sequence item and Name item;

Compressing the parameter row information, specifically discarding the Sequence item and the Name item, and compressing the contents of the Flags item into one byte;

The identifier of the parameter line is analyzed from the value of the Flags item;

Combining the identifier and the parameter type in the data item in the type storage area in the compressed file into parameter information;

Parameter information is added to the compression structure.

10. The method according to claim 7, wherein the hashing of the character string to be converted into a name hash value comprises:

Hashing the string;

Take the first two bits of the result of the operation, convert it to a value type store, and store the data as the name hash value of the defined method.

11. The method according to claim 7, wherein compressing the execution identifier and the access identifier of the defining method comprises:

Reconstructing the data items in the execution identifier and the access identifier, discarding some of the data items, and finally combining the execution identifier and the access identifier from 4 bytes into 2 bytes.

12. The method according to claim 7, wherein the compressing the definition in the .net file further comprises:

Determining that the definition method is a big method;

Compressing local variables of the big header method;

Adding a local variable count and the compressed local variable to the compression structure; compressing the local variable of the large header method includes:

The type information of the big head method is analyzed to obtain a maximum stack size and a big header method identifier; Compressing data describing the maximum stack size includes: taking a lower 8 bits of the data of 16-bit bytes, and discarding the upper 8 bits;

The big head method identifier is analyzed, and the local variable signature identifier is obtained to obtain the number of local variables;

Analyzing the big head method identifier, obtaining an abnormal structure count and abnormal information, and compressing the abnormal information therein;

If the big header method has a structured exception handling table after the IL code, then compressing the exception information therein includes:

Determining the method header size of the big header method and the size of the code by analyzing the method identification information of the big header method;

Locating the structured exception handling table according to the method header byte width and the size of the code;

The content of the segment is located in the segment according to the offset address of the storage area stored in the exception structure processing segment; the process of compressing each segment is as follows: If the exception structure of the current segment is in the big header format, the exception structure in the current segment is occupied. The storage space size is the first length, the data item in the method body segment is read, the HandlerLength item is discarded, and the values of the TryOf set item, the TryLength item, and the HandlerOffset item are all compressed to 2 bytes, and the compression method is to discard the high position. The lower order is reserved; the four bytes of data in the ClassToken are compressed into one byte, and the compression method is to discard the upper bits, leaving only 8 bits; if the exception structure of the current segment is in the form of a small header, the exception structure in the current segment is occupied. The size of the storage space is the second length, and the data item in the method body segment is read, and the HandlerLength item in the method is discarded;

The ClassToken obtained by the above step 4 finds the corresponding exception type information in the definition type and the reference type table in the metadata table;

After compressing the local variable of the big header method, the method further includes: obtaining a garbage collection identifier of the big header method and a Finally count; and determining the garbage collection identifier, the maximum stack size, the Finally count, and the abnormal structure according to the garbage collection identifier Counting and the compressed abnormality information are organized into a large-head method structure table; and the organized large-head method structure table is added to the compressed structure.

The method according to claim 1, wherein the method for obtaining a method for defining a method in a .NET file, the step of compressing the method body comprises: Get the method header of the defined method used in the .net file;

Compressing the method body in the defining method to obtain a compression result of the method body; the method further includes:

Determine whether the method headers of all defined methods used in the .net file have been read and complete the compression of the method body. If not, continue reading the method header of the next defined method; otherwise, end the compression. The method according to claim 13, wherein the step of compressing the method body in the defining method comprises:

Obtaining a local variable of the defined method according to the method header, and determining a deviation of the local variable according to a type of the local variable, where the offset of the local variable refers to the local variable in the .net The offset in the compressed structure corresponding to the file;

Reading the ILcode of the defined method according to the method header, and compressing the ILcode to calculate the length of the compressed ILcode;

Combining the length of the compressed ILcode, the offset of the local variable, and the compressed ILcode according to a predetermined format to obtain a compression result of the method body;

The step of obtaining the local variable of the method by the method header includes: reading a first byte of the method header, and determining, according to the first byte, whether the definition method is a big header method or a small header The method, if it is a big-head method, obtains a local variable according to the identifier token of the local variable in the big-head method; if it is a small-head method, the local variable is set. The data in the compressed structure corresponding to the net file is arranged in order, The offset of each row of data corresponds to the identifier token of the row of data;

The step of reading the ILcode of the definition method according to the method header includes: determining the length of the ILcode of the definition method according to the information in the method header; determining the length of the ILcode according to the determination Reading the ILcode;

The step of compressing the ILcode includes:

Reading an operation instruction in the ILcode, and checking whether there is an operation parameter after the operation instruction;

If not, directly record the operation instruction; Otherwise, determining the type of the operating parameter;

When the operation parameter is an offset of the jump, determining the skipped ILcode according to the offset of the jump, and recalculating the offset of the jump by the skipped ILcode, recording The operation instruction and the offset of the recalculated jump;

Recording the operation instruction and the operation parameter when the operation parameter is an offset to the local variable in the method body;

And determining, when the operation parameter is the identifier token, a corresponding offset of the identifier token in the compression structure, and recording the operation instruction and the determined offset;

The step of compressing the ILcode includes:

Determining whether all operation instructions and operation parameters in the ILcode are read and compressed, and if so, performing the step of calculating the length of the compressed ILcode; otherwise, reading the next operation instruction and compressing;

The predetermined format refers to sequentially arranging the length of the compressed ILcode, the offset of the local variable, and the compressed ILcode.

15. The method according to claim 13, wherein the step of assembling the method header of the definition method used in the .net file comprises:

Get the metadata table in the .net file MethodDef;

Reading the address information of the method header of the definition method used in the .net file from the metadata table MethodDef;

The method header of the defined method is read according to the address information.

The method according to claim 1, wherein the obtaining a namespace in the .net file, and compressing the namespace includes:

Get the namespace name of the current type in the .net file;

Compressing the namespace name according to a predetermined algorithm;

Determining a type count corresponding to the namespace name, where the type count refers to a number of types included in the namespace;

Combining the compressed namespace name and the type count according to a predetermined format to obtain a compression result of the namespace corresponding to the namespace name; The step of obtaining the namespace name to which the current type belongs in the .net file further includes:

Determining whether the currently obtained namespace name has been obtained, and if not, performing the step of compressing the namespace name according to a predetermined algorithm;

The method further includes:

Determining whether the namespace names to which all types belong have been read; if yes, performing the step of combining the compressed namespace names and the type counts according to a predetermined format;

Otherwise, read the namespace name to which the next type belongs.

The method according to claim 16, wherein the step of obtaining the namespace name to which the current type belongs in the .net file comprises:

Get the metadata table containing the namespace name offset in the .net file;

Obtaining, from the metadata table, a namespace name offset to which the current type belongs; reading the namespace name from the stream according to the namespace name offset from "#Strings,";

The determining the type count corresponding to the namespace name includes:

When the namespace name is acquired for the first time, the type count corresponding to the namespace name is set to 1, and each time the namespace name is acquired, the type count is incremented by 1 until the element is traversed. data sheet;

The metadata table includes:

Define type or interface table TypeDef, reference type table TypeRef„

18. The method of claim 16, wherein the step of compressing the namespace name according to a predetermined algorithm comprises:

The namespace names are grouped into a namespace string;

Hashing the namespace string to obtain a hash value;

Taking a predetermined byte of the hash value as the compressed namespace name; The forming the namespace name into a namespace string includes: using a connector to connect the public key tag of the .net file with the namespace name to obtain a namespace string.

The method according to claim 16, wherein the predetermined format is a fixed length byte, and a part of bytes of the fixed length byte is the type count, and the remaining bytes are The compressed namespace name;

The type count is located before the compressed namespace name.

20. The method according to claim 1, wherein the definition type in the .net file is obtained, and the step of compressing the definition type comprises:

Get the information contained in the definition type used in the .net file;

Obtaining specified information and counting information of the definition type according to information included in the definition type;

Compressing the specified information;

The compressed designation information and the count information are stored as a compression result of the definition type.

The method according to claim 20, wherein the step of acquiring information included in a definition type used in the .net file comprises:

Reading the metadata table of the definition type in the .net file;

Get the information contained in the definition type used in the .net file from the metadata table in which the definition type is located.

The method according to claim 20, wherein the information included in the definition type comprises: an identifier of the definition type, an offset of a name of the definition type, and a method in the definition type Offset;

Correspondingly, the specifying information includes: an identifier of the defined type and a name of the defined type;

The counting information includes: method overloading information of the defined type and a method count included in the definition type;

The identifier of the definition type is divided into a type identifier, an access identifier, and a descriptive identifier. Correspondingly, the step of compressing the specified information includes: Performing an OR operation on the type identifier, the access identifier, and the descriptive identifier, and using the obtained data as a compression result of the identifier of the definition type;

Hashing the name of the defined type, extracting the agreed byte from the operation result as a compression result of the name of the defined type;

The information included in the definition type further includes: an offset of the field in the definition type; correspondingly, the specified information further includes: information corresponding to the field in the definition type; the counting information further includes: a field count of the defined type;

The information corresponding to the field in the definition type includes: a name of the field, an identifier of the field, and a type of the field; where the identifier of the field is divided into an access identifier and a descriptive identifier; and correspondingly, the specified information is The steps to compress include:

Hashing the name of the field, extracting the agreed byte from the operation result as a compression result of the name of the field;

Performing an OR operation on the access identifier and the descriptive identifier in the identifier of the field, and using the obtained result as a compression result of the identifier of the field;

The type-compressed offset corresponding to the type of the field is used as the compression result of the type of the field.

The method according to claim 20, wherein the definition type includes information: an offset of a parent class inherited by the definition type;

Correspondingly, the method further includes:

Determining whether the parent class inherited by the definition type is compressed, and if so, obtaining an offset of the parent class; otherwise, compressing the parent class and assigning an offset to the compressed parent class ;

Correspondingly, the compression result of the defined type further includes the offset amount of the compressed parent class.

The method according to claim 20, wherein the method further comprises:

Determining whether the definition type has an inherited interface; if so, obtaining the offset of the interface of the definition type and the number of subsequent interfaces;

Correspondingly, the compression result of the defined type further includes the offset of the succeeded interface and the number of inherited interfaces. The method according to claim 20, wherein the method further comprises: determining whether the defined type is a nested type, and if so, obtaining a compressed offset of the type of the defined type;

Correspondingly, the compressed result of the defined type further includes the type-compressed offset of the nested type.