Program conversion method and device based on difference table and terminal equipment
By using a difference table to convert source code files, the problem of coarse conversion granularity and high maintenance cost in existing technologies is solved, achieving efficient and accurate program conversion.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-30
- Publication Date
- 2026-04-07
AI Technical Summary
Existing program conversion methods have coarse conversion granularity, making it difficult to cope with the differences in interfaces and components brought about by rapid iterations between different platforms. They are also costly to maintain, highly dependent on developer experience, and inefficient.
By acquiring the project file set and the set of difference tables, the source code files are transformed based on the difference tables, including parsing them into an abstract syntax tree and applying the transformation rules of the difference tables. After integration and processing, the target lightweight program is generated.
Significantly reduces maintenance costs, improves conversion efficiency and accuracy, reduces manual intervention, adapts to platform iterations and changes, and avoids code errors.
Smart Images

Figure CN121807309A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computers, and more particularly to a program conversion method, apparatus, and terminal device based on a difference table. Background Technology
[0002] In existing technologies, program conversion often relies on simple rule file replacement combined with manual migration. Simple rule-based file replacement can only perform global search and replacement of specific keywords in the source code. For complex differences that simple rules cannot cover, developers still need to manually compare, rewrite code and test according to official migration documentation.
[0003] However, existing program conversion methods have coarse-grained conversion, rigid replacement mechanisms, and lack of scalability. They struggle to cope with the rapid iterations between different platforms that lead to differences in interfaces and components, resulting in high maintenance costs. Furthermore, numerous manual intervention steps make the conversion process inefficient and highly dependent on the developer's experience. Summary of the Invention
[0004] This application provides a program conversion method, apparatus, and terminal device based on a difference table, which solves the technical problems of low efficiency and low accuracy of lightweight program conversion in the prior art.
[0005] In one aspect, this application provides a procedure conversion method based on a difference table, comprising the following steps: Obtain the set of project files and the set of difference tables for the lightweight program to be converted; Based on the file types of the source code files in the project file set, determine the first source code file and the second source code file; The first source code file is transformed based on the set of differences; The second source code file is parsed into an abstract syntax tree, and a transformation process is performed on the abstract syntax tree based on the set of difference tables; The first source code file and the processed abstract syntax tree are integrated to obtain the target lightweight program.
[0006] in, The conversion process performed on the first source code file based on the difference table set includes: Based on the preset file suffix difference table in the difference table set, the file suffix of the first source code file is adjusted.
[0007] Wherein, if the first source code file includes a page view file, the step of performing transformation processing on the first source code file based on the difference table set further includes: The page view file is parsed into a content object model; Based on the component difference table in the difference table set, modify the tags and attributes in the content object model; Adjust the modified content object model to the new page view file.
[0008] Wherein, if the first source code file includes a target source code file for configuring interface styles and auxiliary view processing, the step of performing transformation processing on the first source code file based on the difference table set further includes: Identify target statements in the target source code file that are used to import external resources; Based on the file suffix difference table, the file path suffix in the target statement corresponding to the external resource is adjusted to the target path suffix.
[0009] The second source code file includes at least a custom script file containing interface calls; The transformation process performed on the abstract syntax tree based on the set of difference tables includes: Based on the interface difference table in the difference table set, the interface call nodes in the abstract syntax tree are transformed.
[0010] The step of transforming the interface call nodes in the abstract syntax tree based on the interface difference table in the difference table set includes: Traverse the abstract syntax tree to identify interface call nodes and extract the interface call information corresponding to the interface call nodes; The interface call information is matched with the interface difference table in the difference table set to determine the difference type; The interface call information is transformed according to the difference type, and the transformed interface call node in the abstract syntax tree is updated.
[0011] The process includes, after matching the interface call information with the interface difference table in the difference table set to determine the difference type, and before performing a conversion operation on the interface call information based on the difference type, the following steps are also included: If the interface call information does not match the corresponding target interface call node in the interface difference table, determine whether there is a replaceable interface; In the case of a first interface calling node with the replaceable interface, the interface name of the first interface calling node is modified according to the replaceable interface and the replacement rules in the interface difference table, and the difference type is re-determined based on the modified interface information. If there is no second interface call node for the replaceable interface, record the missing interface information.
[0012] The step of performing a conversion operation on the interface call information based on the difference type includes: For differences in interface names, replace the interface name in the interface call information with the target interface name corresponding to the interface difference table; To address differences in interface parameters, adaptation processing is performed on the input parameters in the interface call information based on the interface difference table.
[0013] The step of performing adaptation processing on the input parameters in the interface call information based on the interface difference table includes: Based on the parameter verification rules recorded in the interface difference table, the input parameters in the interface call information are verified. The parameter verification rules include at least one of parameter naming verification, parameter valid value verification, and parameter type verification. If a naming difference is detected in the parameter naming check and a corresponding naming replacement rule exists in the interface difference table, the name of the input parameter is modified according to the naming replacement rule and the abstract syntax tree is updated synchronously. If the parameter value of the input parameter is found to be within the range of supported valid parameter values during the parameter validity check, the parameter value is retained. If the parameter type of the input parameter is detected to be a supported target parameter type during the parameter type verification, the original parameter type of the input parameter shall be maintained.
[0014] This also includes: When a parameter of an unsupported type is passed in, record the parameter information for the unsupported parameter. Add a first comment marker indicating that the parameter is not supported at the parameter node corresponding to the abstract syntax tree; If the input parameter value is not within the range of supported valid parameter values, record the parameter value and the corresponding interface information, and add a second annotation mark indicating that the parameter value is not supported in the abstract syntax tree.
[0015] Secondly, this application provides a program conversion apparatus based on a difference table, the apparatus comprising: The data acquisition module is used to acquire the project file set and the difference table set of the lightweight program to be converted; The file partitioning module is used to determine the first source code file and the second source code file based on the file type of the source code files in the project file set. The first conversion processing module is used to perform conversion processing on the first source code file based on the difference table set; The second conversion processing module is used to parse the second source code file into an abstract syntax tree and perform conversion processing on the abstract syntax tree based on the set of difference tables. The target program output module is used to integrate the processed first source code file and the processed abstract syntax tree to obtain the target lightweight program.
[0016] Thirdly, this application provides a terminal device, which includes a processor and a memory; The memory is used to store computer programs and to transfer the computer programs to the processor; The processor is configured to execute the program conversion method based on the difference table as described in the first aspect, according to instructions in the computer program.
[0017] This application provides a program conversion method, apparatus, and terminal device based on a difference table. This application obtains a project file set and a difference table set, then divides the project file set into first and second source code files according to file type. The first source code file is directly converted based on preset conversion rules in the difference table. The second source code file is parsed into an abstract syntax tree and then directly converted based on the preset conversion rules in the difference table. Finally, the two are integrated to obtain the target lightweight program. This embodiment effectively avoids the errors in the converted code caused by simple string replacement in existing technologies by encapsulating conversion rules in a difference table. At the same time, the unified difference table management mechanism breaks the rigidity of existing rule-driven replacements, allowing for rapid adaptation to platform iterations through difference table updates, significantly reducing maintenance costs. Furthermore, the automated conversion method based on the difference table greatly reduces manual intervention, improving conversion efficiency and eliminating reliance on developer experience, significantly improving the efficiency and accuracy of lightweight program conversion. Attached Figure Description
[0018] Figure 1 This is a flowchart illustrating a program conversion method based on a difference table, provided as an embodiment of the present invention.
[0019] Figure 2 This is a schematic diagram illustrating the conversion process of a second source code file, as provided in an embodiment of the present invention.
[0020] Figure 3 This is a schematic diagram illustrating the framework of a program conversion method based on a difference table, provided in an embodiment of the present invention.
[0021] Figure 4 This is a schematic diagram illustrating the conversion of a page view file according to an embodiment of the present invention.
[0022] Figure 5This is a flowchart illustrating another program conversion method based on a difference table provided in an embodiment of the present invention.
[0023] Figure 6 This is a schematic diagram of an interface replacement process provided in an embodiment of the present invention.
[0024] Figure 7 This is a schematic diagram of a program conversion device based on a difference table, provided in an embodiment of the present invention.
[0025] Figure 8 This is a schematic diagram of the frame of a terminal device provided in an embodiment of the present invention. Detailed Implementation
[0026] The following description and accompanying drawings fully illustrate specific embodiments of this application to enable those skilled in the art to practice them. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. The scope of embodiments of this application includes the entire scope of the claims and all available equivalents of the claims. In this document, each embodiment may be referred to individually or collectively by the term "invention," which is merely for convenience and is not intended to automatically limit the scope of the application to any single invention or inventive concept if more than one invention is disclosed. Relational terms such as "first" and "second" are used herein only to distinguish one entity or operation from another, without requiring or implying any actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed. The various embodiments in this document are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the structures, products, etc., disclosed in the embodiments, since they correspond to the disclosed parts, the descriptions are relatively simple; relevant details can be found in the method section.
[0027] In existing technologies, program conversion often relies on simple rule file replacement combined with manual migration. Simple rule-based file replacement can only perform global search and replacement of specific keywords in the source code. For complex differences that simple rules cannot cover, developers still need to manually compare, rewrite code and test according to official migration documentation.
[0028] However, existing program conversion methods have significant limitations and defects. First, the granularity of existing technologies is relatively coarse, failing to accurately handle complex logical scenarios such as differences in interface parameters, changes in callback functions, and unequal return object structures, leading to hidden errors or functional abnormalities in the converted code. Second, rule-driven replacement mechanisms are rigid, lack extensibility, and struggle to cope with the rapid iterations between different platforms that result in differences in interfaces and components, leading to high maintenance costs. Finally, significant manual intervention makes the entire conversion process inefficient and highly dependent on developer experience, easily introducing human error and making it difficult to systematically guarantee conversion quality and stability.
[0029] Therefore, in order to solve the above-mentioned technical problems, embodiments of the present invention provide a program conversion method based on a difference table, such as... Figure 1 As shown, Figure 1 This is a flowchart illustrating a program conversion method based on a difference table, provided in an embodiment of the present invention. The program conversion method based on a difference table provided in this embodiment can be executed by a terminal device, which can be implemented through software and / or hardware. The terminal device can consist of two or more physical entities, or it can consist of a single physical entity. For example, the terminal device can be a computer or a server. The program conversion method based on a difference table provided in this embodiment includes the following steps: Step 101: Obtain the project file set and the difference table set of the lightweight program to be converted.
[0030] In this embodiment, the terminal device first needs to obtain the project file set and the difference table set of the lightweight program to be converted. The project file set can be obtained from the storage path where the lightweight program to be converted is stored. For example, when performing a lightweight program conversion, the user needs to input conversion parameters, including the input path of the lightweight program to be converted (i.e., the storage location of the source code files of the lightweight program to be converted) and the target output path (i.e., the storage location of the source code files of the converted target lightweight program). After receiving the conversion parameters, the terminal device can use the Node.js CLI tool to parse the user parameters through the CLI scaffolding, establish the association between the input path / output path and the project file set, and realize convenient conversion invocation. Then, the terminal device can read all the source lightweight program files under the input path from the input path and target output path parsed from the conversion parameters to form the project file set. The project file set includes source code files of various file types, such as page views, styles, scripts, and global configuration files. Simultaneously with obtaining the project file set, the terminal device needs to load the corresponding difference table set from a preset resource library. The difference table set includes multiple difference tables. Each difference table defines the code differences between the lightweight program to be converted and the target lightweight program, as well as general conversion rules, and defines complex and personalized conversion scenarios (i.e. specific code differences) that the difference table cannot cover. The difference table can provide general and directly callable basic rules for lightweight program conversion, supporting most conversion scenarios that do not require special processing, reducing additional code intervention in the conversion process. For example, the difference table set includes difference tables such as file suffix difference table, interface difference table, component difference table, and configuration difference table. The predefined conversion strategy field of each difference table is used to identify conversion strategies such as direct conversion, renaming conversion, detection conversion, or removal conversion.
[0031] Step 102: Based on the file types of the source code files in the project file set, determine the first source code file and the second source code file.
[0032] After acquiring the project file set, the terminal device needs to divide the source code files in the project file set into first source code files and second source code files based on their file types. The core basis for this division is the conversion method for different file types. Files that can be directly converted using a difference table are classified as first source code files, while files that require conversion into an abstract syntax tree (AST) before conversion are classified as second source code files. For example, the terminal device can traverse the project file set and identify file types using file extensions (such as .ttml, .ttss, .js, app.json). Page view files (such as .ttml), style files (such as .ttss), and global configuration files (app.json) are classified as first source code files, which can be directly converted using a difference table. Custom script files containing API calls (such as .js) are classified as second source code files, which require parsing into an AST first and then using a difference table to convert the nodes in the AST. After the terminal device completes the division, it can mark the first and second source code files with corresponding conversion link identifiers to ensure accurate matching of the required difference table during subsequent conversions and avoid confusion in conversion logic.
[0033] Step 103: Perform conversion processing on the first source code file based on the difference table set.
[0034] For the first source code file, the terminal device needs to perform a transformation process based on the difference table set. This transformation process relies on the transformation rules provided by the difference table. For example, for the page view file in the first source code file, the terminal device can first call the component difference table in the difference table set to parse the page view file into a content object model. Then, based on the mapping rules between the source lightweight program tags and the target lightweight program tags in the component difference table (such as...), the transformation is performed... <sjs> → <wxs>The process involves modifying tags and attributes in the Content Object Model (CEM) using the syntax `tt:if → wx:if`, and then serializing the modified CEM into a new page view file. For style files in the first source code file (e.g., pages / index / index.ttss), the terminal device can call the file suffix difference table in the difference table set to identify statements that import external resources. Following the replacement rules for source and target suffixes in the file suffix difference table, the device replaces the file path suffix of the external resources in the statements, resulting in the converted style file. In essence, the conversion process for the first source code file can be completed solely through the conversion rules provided by the difference table set.
[0035] Step 104: Parse the second source code file into an abstract syntax tree, and perform a transformation process on the abstract syntax tree based on the set of difference tables.
[0036] For the second source code file, the terminal device needs to first parse the second source code file into an Abstract Syntax Tree (AST), and then perform transformation processing on the nodes in the AST based on the difference table set. The AST is an abstract representation of the source code's syntactic structure; it presents the code's syntactic structure as a tree-like data structure, with each node corresponding to a syntactic component in the source code, such as variable declarations, function calls, or expressions. For example, ... Figure 2 As shown, Figure 2 This is a schematic diagram illustrating the conversion process of a second source code file according to an embodiment of the present invention. Taking a custom script file containing interface calls as an example, the process is as follows: First, the terminal device reads the contents of the custom script file, then uses the Babel tool to parse the custom script file into an abstract syntax tree (AST). The tree structure is traversed to identify nodes, and the nodes in the AST are modified according to the conversion rules in the difference table. Finally, a source code file conforming to the syntax specification of the target lightweight program is generated based on the modified AST.
[0037] Step 105: Integrate the processed first source code file and the processed abstract syntax tree to obtain the target lightweight program.
[0038] After converting the first and second source code files, the terminal device needs to integrate them to generate a runnable lightweight target program. For example, the terminal device first verifies file integrity and syntax compliance. If problems are found, a log message is displayed. If the verification passes, the processed first source code file and the processed abstract syntax tree are categorized and stored according to the standard directory structure of the lightweight target program. Finally, the categorized and stored file set is output to the user-specified target output path, forming a lightweight target program that can be directly run in the lightweight target program development tool, completing the entire conversion process. Figure 3 As shown, Figure 3 This is a schematic diagram illustrating the framework of a program conversion method based on a difference table, provided by an embodiment of the present invention. In another embodiment, the first source code file further includes a global configuration file, and the difference table set further includes a configuration difference table for defining the global configuration conversion rules of the lightweight program. The terminal device can also convert the global configuration file of the lightweight program based on the configuration difference table. Finally, the processed first source code file and the processed abstract syntax tree are integrated to obtain the target lightweight program.
[0039] This invention provides a program conversion method based on a difference table. The method involves acquiring a project file set and a difference table set, then dividing the project file set into first and second source code files according to file type. The first source code file is directly converted based on preset conversion rules in the difference table. The second source code file is parsed into an abstract syntax tree and then directly converted based on the preset conversion rules in the difference table. Finally, the two source code files are integrated to obtain the target lightweight program. This embodiment effectively avoids the errors in the converted code caused by simple string replacement in existing technologies by encapsulating conversion rules in a difference table. Furthermore, the unified difference table management mechanism breaks the rigidity of existing rule-driven replacement methods, allowing for rapid adaptation to platform iterations through difference table updates, significantly reducing maintenance costs. In addition, the automated conversion method based on the difference table greatly reduces manual intervention, improving conversion efficiency and eliminating reliance on developer experience, thus significantly improving the efficiency and accuracy of lightweight program conversion.
[0040] Based on the above embodiments, the first source code file includes at least one of a page view file, a style file, and an SJS script file; Step 103 involves performing a transformation process based on the first source code file of the difference table set, including: Step 1031: Adjust the file extension of the first source code file based on the preset file extension difference table in the difference table set.
[0041] In this embodiment, the first source code file includes a page view file, a style file, and an SJS script file. The page view file is the core carrier of the lightweight program's view layer, used to define the page's UI structure, component layout, and data binding relationships. The style file controls the visual presentation of the page view file, defining the layout, color, font, and other style attributes of page elements. The SJS script file is a lightweight logic processing carrier of the lightweight program's view layer, used to perform simple data processing or logical judgments within the view layer.
[0042] When a terminal device performs lightweight program conversion, it inputs conversion parameters through the Node.js CLI tool, including the input path of the lightweight program to be converted (i.e., the storage path of the first source code file, such as . / source-tt) and the target output path (i.e., the storage path of the processed first source code file, such as . / target-xz). Then, it filters out the first source code files from the input path, specifically including page view files (storage path: . / source-tt / pages / index / index.ttml), style files (storage path: . / source-tt / pages / index / index.ttss), and SJS script files (storage path: . / source-tt / common / tools.sjs). When converting the first source code file based on the difference table set, it first needs to call the file suffix difference table in the difference table set. The file suffix difference table predefines the suffix mapping rules between the lightweight program and the target lightweight program for the first source code files. For example, the suffix mapping rules are as follows: the .ttml suffix of page view files corresponds to the target suffix .xzml, the .ttss suffix of style files corresponds to the target suffix .xzss, and the .sjs suffix of SJS script files corresponds to the target suffix .xzs. Then, the terminal device performs suffix replacement on the first source code file based on the file suffix difference table. For example, . / source-tt / pages / index / index.ttml is replaced with . / target-xz / pages / index / index.xzml, . / source-tt / pages / index / index.ttss is replaced with . / target-xz / pages / index / index.xzss, and . / source-tt / common / tools.sjs is replaced with . / target-xz / common / tools.xzs, thus completing the suffix conversion. In another embodiment, the terminal device can also perform the suffix replacement operation synchronously while copying the first source code file from the input path to the target output path.
[0043] As described above, the embodiments of the present invention, based on a preset file suffix difference table in the difference table set, realize batch and accurate adaptation of multiple types of first source code file suffixes, and complete the basic format conversion without manual intervention. Compared with the existing technology, which relies on simple string global replacement or manual modification for suffix conversion, it can improve conversion efficiency and accuracy.
[0044] Based on the above embodiments, when the first source code file includes a page view file, step 103, which involves performing conversion processing based on the first source code file with a set of difference tables, further includes: Step 1032: Parse the page view file into a content object model.
[0045] In this embodiment, after processing in step 1031, the page view file has been replaced from the source format (e.g., .ttml) to the target format (e.g., .xzml), but its platform-specific tags and attributes still need further conversion and adaptation. First, the terminal device needs to parse the page view file into a Content Object Model (DOM), where the DOM is the core structured data format used to process the page view file during the conversion process. The terminal device can import the unified library and the stricter-htmlparser2 parsing plugin to parse the page view file into a DOM. For example, as shown... Figure 4 As shown, Figure 4 This is a schematic diagram illustrating the conversion of a page view file according to an embodiment of the present invention. Figure 4 In this process, the terminal device reads the page view file (such as . / source-tt / pages / index / index.ttml) through the vfile module. After constructing a structured representation of the file, it calls the unified library to execute a processing chain of parsing, custom transformation (ttmlToXxml), and serialization (stringify), realizing the transformation from the source file to the target DOM structure and the new file. The specific process is as follows: Parsing Phase: The stricter-htmlparser2 plugin is used to parse the text content of the page view file into a Content Object Model (DOM). For example, for...<importsrc=".. / .. / .. / common / head.ttml" / > After parsing, the DOM structure of the tag will contain fields such as type:'tag' (tag type), name:'import' (tag name), attribs:{src:'.. / .. / .. / common / head.ttml'} (tag attributes), and children:[] (child elements), clearly presenting the hierarchy and content composition of the page view.
[0046] Conversion Phase: A custom `ttmlToXxml` conversion function is used (this function, based on the component difference table, defines the mapping rules between source lightweight application tags and target lightweight application tags, such as...). <sjs>Replace with <xzs>Replace tt:if with xz:if), traverse and modify tags and attributes in the DOM to complete the syntax adaptation.
[0047] Serialization stage: The stringify plugin of unified is called to serialize the modified DOM structure into text content, and finally the content is saved as the page view file of the target lightweight program (such as . / target-xz / pages / index / index.xzml).
[0048] Step 1033: Based on the component difference table in the difference table collection, modify the tags and attributes in the content object model.
[0049] After converting the page view file into a content object model, the terminal device needs to modify the tags and attributes in the content object model based on the component difference table in the difference table set. The component difference table in the difference table set predefines the tag mapping rules (such as tag replacement, component attribute adjustment, etc.), tag attribute processing rules (such as src path suffix adaptation), and special syntax conversion rules (such as conditional rendering syntax replacement) between the lightweight application and the target lightweight application's page view files. It is the core basis for the specific conversion of the page view file. For example, this page view file includes unique tags.<sjssrc=". / utils.sjs" / > Conditional rendering syntax tt:if="{{show}}" and importing external view files<importsrc=".. / .. / .. / common / head.ttml" / > Tags. Terminal devices can access the component difference table and process different tags according to the conversion rules in the component difference table: (1) To <import>The tag replaces the remaining source lightweight program suffix ".ttml" in its src attribute with the target suffix ".xzml". After processing, the src path is .. / .. / .. / common / head.xzml.
[0050] (2) To <sjs>Tags, replaced with the target lightweight program's tags according to the component difference table rules. <xzs>The tag is replaced by <xzssrc=". / utils.xzs" / > after the processing.
[0051] As for the tt:if condition rendering syntax in the page view file, it is replaced by xz:if of the target lightweight program according to the conversion rule in the component difference table, and the processed syntax becomes xz:if="{{show}}". In addition, if the page view file includes a unique component recorded in the component difference table, the terminal device will further replace it with the corresponding component of the target lightweight program according to the rule in the table, and adjust the attribute mapping of the component.
[0052] Step 1034, adjusting the modified content object model to a new page view file.
[0053] After the modification of the tags and attributes of the content object model is completed, the terminal device can serialize the processed content object model into a new page view file through the stringify plug-in of the unified library, and use the new page view file to overwrite the original page view file.
[0054] By combining the component difference table and the content object model, the above achieves the depth conversion of the content adaptation of the page view file, avoids the tedious operation of manually modifying the tags and attributes one by one in the prior art, improves the conversion accuracy of the page view file, further reduces the manual intervention link, and improves the conversion efficiency.
[0055] On the basis of the above embodiment, in the case where the first source code file includes a target source code file for configuring the interface style and auxiliary view processing, the conversion processing of the first source code file based on the difference table set in step 103 further includes: Step 1035, identifying a target statement for importing external resources in the file content of the target source code file.
[0056] In this embodiment, after the replacement of the file suffix, the path of the external resource introduced by the specific syntax in the file still retains the file suffix of the source lightweight program, and needs to be further adapted to the target lightweight program format. The external resource is a resource file that needs to be loaded from the outside to support the function of the target lightweight program. Based on this, the terminal device also needs to further identify the target statement for introducing the external resource in the style file and / or SJS script file after the suffix replacement. In one embodiment, the target statement refers to the statement for introducing the external style file through the @import keyword in the style file, and the statement for introducing the external SJS script file through the require keyword in the SJS script file. The terminal device can locate the target statement of the style file and the SJS script file through text analysis technology, that is, for the style file, the target statement containing the @import keyword followed by the file path is identified; for the SJS script file, the target statement containing the require keyword followed by the file path is identified.
[0057] Step 1036, based on the file suffix difference table, the file path suffix corresponding to the external resource in the target statement is adjusted to the target path suffix.
[0058] After identifying the target statement in the target source code file, the file path suffix corresponding to the external resource in the target statement needs to be replaced by the target path suffix based on the file suffix difference table. In this embodiment, the file suffix difference table also defines the suffix mapping rule of the external resource file between the source lightweight program and the target lightweight program in advance. For example, for the target statement @import".. / .. / common / base.ttss" in the style file, the file path suffix.ttss is extracted, and according to the replacement rule of the source suffix.ttss→target suffix.xzss in the file suffix difference table, the file path is replaced by".. / .. / common / base.xzss", and the processed target statement is @import".. / .. / common / base.xzss". For the target statement const utils = require(. / utils.sjs) in the SJS script file, the file path suffix.sjs is extracted, and according to the replacement rule of the source suffix.sjs→target suffix.xzss in the file suffix difference table, the file path is replaced by. / utils.xzs, and the processed target statement is const utils = require(. / utils.xzs.
[0059] In one embodiment, if the style file contains multiple external style import statements, the terminal device can batch identify all the @import statements and uniformly replace the file path suffix; if the external resource path introduced by the SJS script file contains multiple directories (such as require (“.. / lib / helper.sjs”)), only the.sjs suffix at the end of the path is extracted for replacement, and the path hierarchy is maintained.
[0060] By the above method of replacing the file path suffix of the external resource based on the target statement for introducing the external resource and the file suffix difference table, it is not necessary to manually find and modify the path suffix of the external resource one by one, the problem of failure of loading of the lightweight program resource caused by mismatch of the path suffix is avoided, the complete adaptation of the first source code file is ensured, and the efficiency and accuracy of the conversion of the lightweight program are improved.
[0061] The embodiment of the application further provides another program conversion method based on a difference table, as shown in Figure 5 Figure 5 The flowchart of another program conversion method based on a difference table provided by the embodiment of the application is shown in Figure 5 The program conversion method based on a difference table shown in the above is a specific embodiment of the program conversion method based on a difference table, and the program conversion method based on a difference table provided by the embodiment of the application includes the following steps. Step 201: acquiring a project file set and a difference table set of a lightweight program to be converted.
[0062] Step 202: determining a first source code file and a second source code file based on the file type of the source code file in the project file set.
[0063] Step 203: performing conversion processing on the first source code file based on the difference table set.
[0064] Step 204: parsing a custom script file into an abstract syntax tree, and performing conversion processing on an interface call node in the abstract syntax tree based on an interface difference table in the difference table set.
[0065] In this embodiment, the second source code file at least includes a custom script file containing interface calls. When processing the custom script file, the terminal device first needs to convert the custom script file into an abstract syntax tree. For example, the terminal device can parse the file content of the custom script file into an abstract syntax tree (AST, Abstract Syntax Tree) through the babel tool. Taking the custom script file. / source-tt / pages / index / index.js as an example, it contains interface call statements such as tt.getSystemInfo and tt.onError. After the terminal device reads the custom script file content through the fs module of Node.js, it parses the file into an abstract syntax tree through the babel tool. For example, for the interface call statement tt.getSystemInfo({success:(res)=>{console.log(res.pageOrientation)}}, the babel parses it into an AST structure containing ExpressionStatement, CallExpression, and MemberExpression. The object of MemberExpression is an Identifier node with name: "tt", the property is an Identifier node with name: "getSystemInfo", and the arguments node of CallExpression contains callback function related structures, which are consistent with the syntax logic of the interface call. It can be understood that if the custom script file contains multiple interface call statements, the terminal device can batch parse all code segments containing interface calls into corresponding AST nodes.
[0066] After obtaining the abstract syntax tree, the terminal device can convert the interface call node in the abstract syntax tree based on the interface difference table in the difference table set. The terminal device calls the interface difference table in the difference table set, and the interface difference table predefines the name mapping rule of the interface between the source lightweight program and the target lightweight program, the parameter difference rule, and the state identifier, etc. The interface difference table is used to perform conversion processing on the interface call node in the AST. For example, the interface difference table includes an I interface DiffItem interface definition, wherein the type field records the interface difference type, the status field identifies the detailed difference state, and the replace field stores the target interface name or the parameter replacement value. For example, for the tt.getSystemInfo call node, the status of the interface in the interface difference table is DIFF_NAME, and the replace field is wx.getSystemInfo. The terminal device modifies the object (from name: "tt" to name: "wx") of the MemberExpression node in the AST according to this, and completes the interface name conversion. For the tt.onError call node, if the parameter errMsg is marked as DIFF_PARAM in the interface difference table and the replace field is message, the terminal device further modifies the AST node corresponding to err.errMsg in the callback function, and replaces errMsg with message.
[0067] The above, by parsing the custom script file into an abstract syntax tree, relying on the interface difference table to realize the conversion of the interface call node, not only ensures the accuracy and integrity of the interface conversion, but also avoids the tedious operation of manually positioning and modifying the interface call and special difference one by one, further improves the overall efficiency of the lightweight program conversion, and reduces the risk of functional abnormalities caused by improper interface adaptation.
[0068] On the basis of the above embodiment, the step 204 of converting the interface call node in the abstract syntax tree based on the interface difference table in the difference table set comprises: Step 2041, traversing the abstract syntax tree to identify the interface call node, and extracting the interface call information corresponding to the interface call node.
[0069] In this embodiment, when processing the abstract syntax tree based on the interface difference table, after traversing the abstract syntax tree to identify the interface call nodes, it is necessary to further extract the interface call information corresponding to the interface call nodes. The interface call information may include the interface name and input parameters. The input parameters include key information passed through the command line or scaffolding during the lightweight program conversion process, used to specify the core configurations such as the path and type required for the conversion. For example, the terminal device traverses the abstract syntax tree using the Babel tool, locating all interface call nodes through two key node types: CallExpression and MemberExpression. In the MemberExpression node, the object field (e.g., name: "tt") is the interface prefix, the property field (e.g., name: "getSystemInfo") is the specific interface name, and the arguments field of the CallExpression node contains the input parameters. For example, the node corresponding to `tt.getSystemInfo({success:(res)=>{console.log(res.pageOrientation)}})` in the AST is identified as a `CallExpression` node, its `callee` property is of type `MemberExpression`, and the interface name is extracted as `tt.getSystemInfo`; the input parameters in the `arguments` field are extracted, including the `success` callback function; similarly, the interface name `tt.onError` and the input parameter `err` callback function are extracted for the node `tt.onError((err)=>{console.log(err.errMsg)})`.
[0070] Step 2042: Match the interface call information with the interface difference table in the difference table set to determine the difference type.
[0071] Next, the terminal device matches the extracted interface call information with the interface difference table one by one, and determines the difference type based on the type and status fields of the interface difference table. The difference types include: (1) Difference in interface name: status is DIFF_NAME, indicating that the interface names are different; (2) Differences in interface parameters: if status is DIFF_PARAM, it means that the parameter name, supported values or callback parameters are different; For example, when matching tt.getSystemInfo, the status of this interface in the interface difference table is DIFF_NAME, the replace field is wx.getSystemInfo, and the difference type is determined to be "interface name difference". When matching tt.onError, the params field of this interface in the interface difference table records that the errMsg parameter needs to be replaced with message, the status is DIFF_PARAM, and the difference type is determined to be "interface parameter difference".
[0072] Step 2043: Perform a transformation operation on the interface call information according to the difference type, and update the transformed interface call node in the abstract syntax tree.
[0073] After determining the difference type, a transformation operation can be performed on the interface call information according to the difference type. For example, for interface name differences, the interface name in the interface call node can be replaced; for interface parameter differences, the callback parameters can be replaced. After the transformation operation is completed, the corresponding interface call node in the Abstract Syntax Tree (AST) is updated. In one embodiment, performing a transformation operation on the interface call information according to the difference type includes: Step 20431: For interface name differences, replace the interface name in the interface call information with the corresponding target interface name in the interface difference table.
[0074] Specifically, the terminal device needs to replace the interface name of the interface call node in the Abstract Syntax Tree (AST) according to the target interface name recorded in the replace field of the interface difference table. For example, the terminal device matches tt.getSystemInfo from the interface difference table and obtains its replace field value as wx.getSystemInfo. Then, it uses the Babel tool to locate the corresponding MemberExpression node in the AST for this interface call. This node's object is the Identifier node with name: "tt", and its property is the Identifier node with name: "getSystemInfo". The terminal device modifies the object property of the MemberExpression node: changing name: "tt" to name: "wx", while keeping the property unchanged, thus completing the replacement of the interface name from tt.getSystemInfo to wx.getSystemInfo. After the replacement is completed, the interface call node in the AST is updated synchronously. When the difference type is interface parameter difference, adaptation processing is performed on the input parameters based on the interface difference table.
[0075] Step 20432: For differences in interface parameters, perform adaptation processing on the input parameters in the interface call information based on the interface difference table.
[0076] When the difference type is an interface parameter difference, the extracted input parameters need to be processed according to the parameter mapping rules defined in the `params` field of the interface difference table. For example, the terminal device can call the interface difference table in the difference table set, locate the `params` field corresponding to the current interface, extract the preset parameter verification rules and processing rules, and determine the adaptation direction and standard. For example, parameter verification rules include parameter naming verification, parameter valid value verification, and parameter type verification. In parameter naming verification, if a naming difference is detected and a naming replacement rule is recorded in the `replace` field, the parameter name is modified according to the naming replacement rule. In parameter valid value verification, if the parameter value is within the range of valid values recorded in the `extra` field, the original parameter value is retained. In parameter type verification, if the parameter type belongs to the supported target parameter type, the original parameter configuration is maintained. After all adaptation operations are completed, the corresponding parameter node in the abstract syntax tree is directly modified to ensure that the adapted parameter information is synchronously updated to the AST.
[0077] Based on the above embodiments, step 20432 performs adaptation processing on the input parameters in the interface call information based on the interface difference table, including: Based on the parameter verification rules recorded in the interface difference table, the input parameters in the interface call information are verified. The parameter verification rules include at least one of parameter naming verification, parameter valid value verification, and parameter type verification. If a naming difference is detected in the parameter naming check and a corresponding naming replacement rule exists in the interface difference table, the name of the input parameter is modified according to the naming replacement rule and the abstract syntax tree is updated synchronously. If the parameter value is found to be within the range of supported valid parameters during the parameter validity check, the parameter value is retained. If the parameter type of the input parameter is detected to be a supported target parameter type during parameter type verification, the original parameter type of the input parameter shall be maintained.
[0078] In this embodiment, the parameter verification rules are composed of the type field (marking the verification type), the extra field (storing the list of legal values / supported types), and the replace field (storing the naming replacement rules) of the IPAramDiff in the interface difference table. After the terminal device extracts the input parameters, it first calls the interface difference table to perform the verification to determine whether the parameters need to be adjusted.
[0079] For example, when parameter naming validation detects a naming difference in the input parameter, and a corresponding naming replacement rule exists in the interface difference table, the name of the input parameter is modified according to the naming replacement rule, and the abstract syntax tree is updated synchronously. For instance, for the input parameter `duration` in `tt.showToast({title:'Prompt', duration:2000})`, the terminal device extracts the parameter name `duration` and matches it with the `params` field of `tt.showToast` in the interface difference table, determining that `duration` is a naming difference and `replace` is `timeout`. Then, by locating the Property node (key: "duration") corresponding to `duration` in the AST using Babel, the key attribute `name` of that node is changed from `duration` to `timeout`, and the abstract syntax tree is updated synchronously.
[0080] When the parameter validity check detects that the value of the input parameter is within the range of valid values supported by the interface difference table, the parameter value is retained. For example, for the `icon` parameter of `tt.showToast({title:'Prompt',icon:'none'})`, the parameter value "none" is extracted and matched against the `params.icon.extra` field of `tt.showToast` in the interface difference table (which stores supported values such as ["none", "success"]). Since "none" is detected to be within the supported range, the parameter value does not need to be modified, and the original configuration is directly retained.
[0081] When the parameter type check detects that the type of the input parameter is a supported target parameter type preset in the interface difference table, the original parameter configuration is maintained. For example, for the data parameter of tt.request({url:' / api',data:{id:1}}): the data parameter type is identified as "Object", and the params.data.extra field of tt.request in the interface difference table (which stores supported types such as ["Object", "string"]); if it is confirmed that the "Object" type is within the supported range, the original configuration of data:{id:1} is maintained, and no adjustment to the AST node is required.
[0082] The above-mentioned automatic verification and adaptation are performed by pre-setting parameter verification rules and relying on the interface difference table, avoiding the tedious operation of manually judging the rationality of parameters. This ensures that the input parameters conform to the target lightweight program specifications in terms of naming, value and type, and further improves the accuracy and efficiency of interface parameter conversion.
[0083] Based on the above embodiments, it also includes: When a parameter of an unsupported type is passed in, record the parameter information for the unsupported parameter.
[0084] Add a first comment marker indicating that the parameter is not supported at the corresponding parameter node in the abstract syntax tree.
[0085] If a parameter value is passed in that is not within the range of supported valid parameter values, the parameter value and the corresponding interface information are recorded, and a second annotation mark indicating that the parameter value is not supported is added to the abstract syntax tree.
[0086] In this embodiment, when the terminal device detects that the input parameter type is unsupported, it records the parameter name, the interface identifier, and the reason for the difference. Simultaneously, it adds a first comment marker indicating that the parameter is unsupported at the parameter node corresponding to the abstract syntax tree. For example, when the terminal device detects that the input parameter type does not belong to the preset supported types of the `params` field `extra` in the interface difference table, it calls the log module to record key information, including the parameter name, the interface identifier, and the reason for the difference, ensuring subsequent traceability. At the same time, it uses Babel to locate the Property node corresponding to the parameter in the AST and adds a comment next to the node (e.g., / / [Unsupported parameter type] Parameter name: data, Interface: tt.request, Reason: Array type not supported), clearly marking the location and cause of the problem.
[0087] If a parameter value is detected to be outside the supported range of valid values, the parameter value and its corresponding interface information can be recorded. Simultaneously, a second comment indicating that the parameter value is not supported can be added to the abstract syntax tree. For example, when the terminal device detects that the input parameter value is outside the preset range of valid values in the `extra` field of the interface difference table `params`, it calls the logging module to record the parameter value and its corresponding interface information. At the same time, it locates the node corresponding to the parameter value in the AST and adds a comment next to the node, indicating both the unsupported value and the valid range.
[0088] The above-mentioned methods, through information recording and AST annotation, enable the visual traceability of unsupported parameters, ensuring that subsequent manual verification or secondary processing can be carried out efficiently.
[0089] Based on the above embodiments, after matching the interface call information with the interface difference table in the difference table set to determine the difference type, and before performing a conversion operation on the interface call information according to the difference type, the method further includes: Step 2044: If the interface call information does not match the corresponding target interface call node in the interface difference table, determine whether there is a replaceable interface.
[0090] Step 2045: If there is a first interface call node with a replaceable interface, modify the interface information of the first interface call node according to the replaceable interface and the replacement rules in the interface difference table, and redetermine the difference type based on the modified interface information.
[0091] Step 2046: If there is no second interface call node with a replaceable interface, record the missing interface information.
[0092] For example, such as Figure 6 As shown, Figure 6 This is a schematic diagram of an interface replacement process provided in an embodiment of the present invention. Figure 6 In this process, when the terminal device matches the extracted interface call information with the interface difference table, if no corresponding target interface is found, it can determine whether a replacement option exists by checking the status field (marking the status) and the replace field (storing the replaceable interface name) of the interface in the interface difference table. If a replaceable interface is found (the replace field in the difference table has a value), the interface information of the interface call node in the AST is modified according to the replacement rules. For example, if the replace field of the tt.old interface is wx.new, the terminal device locates the MemberExpression node in the AST, changes object (tt) to wx, and property (old interface) to new interface, and updates the AST synchronously. Then, the difference type is re-determined based on the modified interface information. If no replaceable interface is found (the replace field in the difference table is empty, and the status is marked "missing"), the missing interface information is recorded.
[0093] After the abstract syntax tree is modified, the terminal device can reserialize the modified abstract syntax tree into a source code file that conforms to the target lightweight program syntax specification.
[0094] Step 205: Integrate the processed first source code file and the processed abstract syntax tree to obtain the target lightweight program.
[0095] This invention provides a program conversion method based on a difference table. The method involves acquiring a project file set and a difference table set, then dividing the project file set into first and second source code files according to file type. The first source code file is directly converted based on preset conversion rules in the difference table. The second source code file is parsed into an abstract syntax tree and then directly converted based on the preset conversion rules in the difference table. Finally, the two source code files are integrated to obtain the target lightweight program. This embodiment effectively avoids the errors in the converted code caused by simple string replacement in existing technologies by encapsulating conversion rules in a difference table. Furthermore, the unified difference table management mechanism breaks the rigidity of existing rule-driven replacement methods, allowing for rapid adaptation to platform iterations through difference table updates, significantly reducing maintenance costs. In addition, the fully automated conversion based on the difference table greatly reduces manual intervention, improving conversion efficiency and eliminating reliance on developer experience, significantly improving the efficiency and accuracy of lightweight program conversion.
[0096] This invention also provides a program conversion device based on a difference table, such as... Figure 7 As shown, Figure 7 This is a schematic diagram of a program conversion device based on a difference table, provided in an embodiment of the present invention. The program conversion device based on a difference table provided in this embodiment of the present invention includes: The data acquisition module 301 is used to acquire the project file set and the difference table set of the lightweight program to be converted; File partitioning module 302 is used to determine the first source code file and the second source code file based on the file type of the source code files in the project file set. The first conversion processing module 303 is used to perform conversion processing on the first source code file based on the difference table set; The second conversion processing module 304 is used to parse the second source code file into an abstract syntax tree and perform conversion processing on the abstract syntax tree based on the set of difference tables. The target program output module 305 is used to integrate the processed first source code file and the processed abstract syntax tree to obtain the target lightweight program.
[0097] in, The first conversion processing module 303 is specifically used to adjust the file extension of the first source code file based on a preset file extension difference table in the difference table set.
[0098] Where the first source code file includes a page view file, the first conversion processing module 303 further includes: The model parsing submodule is used to parse page view files into content object models; The Model Modification submodule is used to modify the tags and attributes in the Content Object Model based on the component difference table in the Difference Table Collection. The Model Serialization submodule is used to adapt the modified content object model into a new page view file.
[0099] Where the first source code file includes a target source code file for configuring interface styles and auxiliary view processing, the first conversion processing module 303 further includes: The external resource identification submodule is used to identify target statements in the content of the target source code file that are used to import external resources. The suffix replacement submodule is used to adjust the file path suffix in the target statement corresponding to the external resource to the target path suffix based on the file suffix difference table.
[0100] The second source code file includes at least a custom script file containing interface calls; The second conversion processing module 304 is specifically used to perform conversion processing on the interface call nodes in the abstract syntax tree based on the interface difference table in the difference table set.
[0101] The second conversion processing module 304 includes: The syntax tree traversal submodule is used to traverse the abstract syntax tree to identify API call nodes and extract the API call information corresponding to the API call nodes. The difference type determination submodule is used to match the interface call information with the interface difference table in the difference table set to determine the difference type; The information conversion submodule is used to perform conversion operations on the interface call information according to the difference type and update the converted interface call nodes in the abstract syntax tree.
[0102] The program conversion device based on the difference table also includes: The interface replacement judgment submodule is used to determine whether there is a replaceable interface after matching the interface call information with the interface difference table in the difference table set and determining the difference type, and before performing the conversion operation on the interface call information according to the difference type, if the interface call information does not match the corresponding target interface interface call node in the interface difference table. The interface replacement submodule is used to modify the interface information of the first interface call node when there is a replaceable interface, according to the replaceable interface and the replacement rules in the interface difference table, and redetermine the difference type based on the modified interface information. The Interface Missing Record submodule is used to record interface missing information when there is no second interface call node that can replace the interface.
[0103] Specifically, the information conversion submodule is used to replace the interface name in the interface call information with the corresponding target interface name in the interface difference table for interface name differences; and to perform adaptation processing on the input parameters in the interface call information based on the interface difference table for interface parameter differences.
[0104] Specifically, the information conversion submodule is used to verify the input parameters in the interface call information based on the parameter verification rules recorded in the interface difference table. The parameter verification rules include at least one of parameter naming verification, parameter validity value verification, and parameter type verification. If the parameter naming verification detects a naming difference in the input parameter and there is a corresponding naming replacement rule in the interface difference table, the name of the input parameter is modified according to the naming replacement rule and the abstract syntax tree is updated synchronously. If the parameter validity value verification detects that the parameter value of the input parameter is within the range of supported parameter validity values, the parameter value is retained. If the parameter type verification detects that the parameter type of the input parameter is a supported target parameter type, the original parameter type of the input parameter is maintained.
[0105] Specifically, the information conversion submodule is used to record the parameter information of unsupported parameters when the parameter type is an input parameter; add a first comment mark indicating that the parameter is not supported at the corresponding parameter node in the abstract syntax tree; and record the parameter value and the corresponding interface information when the input parameter value is not within the range of supported parameter values, and add a second comment mark indicating that the parameter value is not supported in the abstract syntax tree.
[0106] The program conversion device based on the difference table provided in this embodiment of the invention is included in a terminal device and can be used to execute the program conversion method based on the difference table provided in the above embodiment, and has corresponding functions and beneficial effects.
[0107] It is worth noting that in the above embodiments of the program conversion device based on the difference table, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the scope of protection of the present invention.
[0108] This invention also provides a terminal device, such as... Figure 8 As shown, Figure 8 This is a schematic diagram of the frame of a terminal device provided in an embodiment of the present invention. Figure 8 In the terminal device 40, a processor 400 and a memory 401 are included; Memory 401 is used to store computer program 402 and transfer computer program 402 to processor 400; The processor 400 is used to execute the steps in the above embodiment of a program conversion method based on a difference table, according to the instructions in the computer program 402.
[0109] For example, computer program 402 may be divided into one or more modules / units, one or more of which are stored in memory 401 and executed by processor 400 to complete this application. One or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 402 in terminal device 40.
[0110] Terminal device 40 may be a computing device such as a desktop computer, laptop, or server. Terminal device 40 may include, but is not limited to, processor 400 and memory 401. Those skilled in the art will understand that... Figure 8 This is merely an example of terminal device 40 and does not constitute a limitation on terminal device 40. It may include more or fewer components than shown, or combine certain components, or different components. For example, terminal device 40 may also include input / output devices, network access devices, buses, etc.
[0111] The processor 400 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.
[0112] The memory 401 can be an internal storage unit of the terminal device 40, such as a hard disk or RAM of the terminal device 40. The memory 401 can also be an external storage device of the terminal device 40, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or FlashCard equipped on the terminal device 40. Furthermore, the memory 401 can include both internal and external storage units of the terminal device 40. The memory 401 is used to store computer programs and other programs and data required by the terminal device 40. The memory 401 can also be used to temporarily store data that has been output or will be output.
[0113] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0114] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.
[0115] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0116] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0117] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing computer programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0118] This invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform a program conversion method based on a difference table. The method includes the following steps: Obtain the set of project files and the set of difference tables for the lightweight program to be converted; Based on the file types of the source code files in the project file set, determine the first source code file and the second source code file; The first source code file is transformed based on the set of differences. The second source code file is parsed into an abstract syntax tree, and a transformation process is performed on the abstract syntax tree based on the set of difference tables. The first source code file and the processed abstract syntax tree are integrated to obtain the target lightweight program.
[0119] Note that the above are merely preferred embodiments and the technical principles applied in this invention. Those skilled in the art will understand that the embodiments of this invention are not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the protection scope of this invention. Therefore, although the embodiments of this invention have been described in detail above, the embodiments of this invention are not limited to the above embodiments. More other equivalent embodiments may be included without departing from the concept of the embodiments of this invention, and the scope of the embodiments of this invention is determined by the scope of the appended claims.< / xzs> < / sjs> < / import> < / xzs> < / sjs> < / wxs> < / sjs>
Claims
1. A program conversion method based on a difference table, characterized in that, Includes the following steps: Obtain the set of project files and the set of difference tables for the lightweight program to be converted; Based on the file types of the source code files in the project file set, determine the first source code file and the second source code file; The first source code file is transformed based on the set of differences; The second source code file is parsed into an abstract syntax tree, and a transformation process is performed on the abstract syntax tree based on the set of difference tables; The first source code file and the processed abstract syntax tree are integrated to obtain the target lightweight program.
2. The program conversion method based on a difference table according to claim 1, characterized in that, The conversion process performed on the first source code file based on the difference table set includes: Based on the preset file suffix difference table in the difference table set, the file suffix of the first source code file is adjusted.
3. The program conversion method based on a difference table according to claim 2, characterized in that, When the first source code file includes a page view file, the step of performing transformation processing on the first source code file based on the difference table set further includes: The page view file is parsed into a content object model; Based on the component difference table in the difference table set, modify the tags and attributes in the content object model; Adjust the modified content object model to the new page view file.
4. The program conversion method based on a difference table according to claim 2, characterized in that, When the first source code file includes a target source code file for configuring interface styles and auxiliary view processing, the step of performing transformation processing on the first source code file based on the difference table set further includes: Identify the target statements in the file content of the target source code file used to import external resources; Based on the file suffix difference table, the file path suffix in the target statement corresponding to the external resource is adjusted to the target path suffix.
5. The program conversion method based on a difference table according to claim 1, characterized in that, The second source code file includes at least a custom script file containing interface calls; The transformation process performed on the abstract syntax tree based on the set of difference tables includes: Based on the interface difference table in the difference table set, the interface call nodes in the abstract syntax tree are transformed.
6. The program conversion method based on a difference table according to claim 5, characterized in that, The process of transforming the interface call nodes in the abstract syntax tree based on the interface difference table in the difference table set includes: Traverse the abstract syntax tree to identify interface call nodes and extract the interface call information corresponding to the interface call nodes; The interface call information is matched with the interface difference table in the difference table set to determine the difference type; The interface call information is transformed according to the difference type, and the transformed interface call node in the abstract syntax tree is updated.
7. The program conversion method based on a difference table according to claim 6, characterized in that, After matching the interface call information with the interface difference table in the difference table set to determine the difference type, and before performing a conversion operation on the interface call information according to the difference type, the method further includes: If the interface call information does not match the corresponding target interface call node in the interface difference table, determine whether there is a replaceable interface; In the case of a first interface calling node with a replaceable interface, the interface information of the first interface calling node is modified according to the replaceable interface and the replacement rules in the interface difference table, and the difference type is re-determined based on the modified interface information. If there is no second interface call node for the replaceable interface, record the missing interface information.
8. The program conversion method based on a difference table according to claim 6, characterized in that, The step of performing a conversion operation on the interface call information based on the difference type includes: For differences in interface names, replace the interface name in the interface call information with the target interface name corresponding to the interface difference table; To address differences in interface parameters, adaptation processing is performed on the input parameters in the interface call information based on the interface difference table.
9. The program conversion method based on a difference table according to claim 8, characterized in that, The adaptation processing of the input parameters in the interface call information based on the interface difference table includes: Based on the parameter verification rules recorded in the interface difference table, the input parameters in the interface call information are verified. The parameter verification rules include at least one of parameter naming verification, parameter valid value verification, and parameter type verification. If a naming difference is detected in the parameter naming check and a corresponding naming replacement rule exists in the interface difference table, the name of the input parameter is modified according to the naming replacement rule and the abstract syntax tree is updated synchronously. If the parameter value of the input parameter is found to be within the range of supported valid parameter values during the parameter validity check, the parameter value is retained. If the parameter type of the input parameter is detected to be a supported target parameter type during the parameter type verification, the original parameter type of the input parameter shall be maintained.
10. The program conversion method based on a difference table according to claim 9, characterized in that, Also includes: In the case of input parameters of an unsupported parameter type, record the parameter information of the unsupported parameter; Add a first comment marker indicating that the parameter is not supported at the parameter node corresponding to the abstract syntax tree; If the input parameter value is not within the range of supported valid parameter values, record the parameter value and the corresponding interface information, and add a second annotation mark indicating that the parameter value is not supported in the abstract syntax tree.
11. A program conversion device based on a difference table, characterized in that, The device includes: The data acquisition module is used to acquire the project file set and the difference table set of the lightweight program to be converted; The file partitioning module is used to determine the first source code file and the second source code file based on the file type of the source code files in the project file set. The first conversion processing module is used to perform conversion processing on the first source code file based on the difference table set; The second conversion processing module is used to parse the second source code file into an abstract syntax tree and perform conversion processing on the abstract syntax tree based on the set of difference tables. The target lightweight program output module is used to integrate the processed first source code file and the processed abstract syntax tree to obtain the target lightweight program.
12. A terminal device, characterized in that, The terminal device includes a processor and a memory; The memory is used to store computer programs and to transfer the computer programs to the processor; The processor is configured to execute the program conversion method based on the difference table as described in any one of the claims 1-10, according to the instructions in the computer program.