Method and system for merging customized content in a tag-based cross-language code conversion
By using pairing tags and caching mechanisms in cross-language code conversion, the problem of easy loss of custom code is solved, and automatic merging and management are achieved in the cross-language conversion process, improving conversion efficiency and system migration reliability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SHANDONG CITY COMMERCIAL BANK COOP ALLIANCE CO LTD
- Filing Date
- 2026-04-16
- Publication Date
- 2026-06-23
AI Technical Summary
Customized code snippets are easily lost during cross-language code conversion, manual maintenance and synchronization are inefficient, and there is a lack of effective mechanisms to identify and protect them.
A tag-based cross-language code conversion method is adopted. By adding paired tags to the source and target language codes and combining historical version customized content caching, the customized content is automatically retained and merged. The replacement and deletion tags share a numbering system to ensure full lifecycle management.
It enables the automatic retention and merging of customized content during cross-language conversion, avoiding repeated manual modifications, improving conversion efficiency, ensuring that customized content is not lost, and enhancing the reliability and maintainability of large-scale legacy system migration.
Smart Images
Figure CN122044567B_ABST
Abstract
Description
Technical Field
[0001] This application relates to a method and system for custom content merging in tag-based cross-language code conversion, belonging to the field of computer software development technology. Background Technology
[0002] With the development of information technology, many enterprises need to migrate their legacy COBOL systems to modern Java platforms. During this migration process, code conversion tools are typically used to automatically convert COBOL code into Java code. However, due to the complexity of business logic and specific requirements, fully automated conversion often cannot meet all needs. For example, some COBOL implementations may need to be replaced by new implementations in Java, or the converted code may require customized modifications to adapt to the new system architecture.
[0003] In existing technologies, customized requirements are typically handled by manually modifying the code after a fully automated conversion. However, during multiple iterations of the conversion process, manually modified content is easily overwritten by newly generated code; there is a lack of effective mechanisms to identify and protect customized code snippets that need to be retained; and manually maintaining and synchronizing changes between different versions is inefficient and prone to errors.
[0004] Although there are some merge tagging methods based on code comments (such as Chinese patent document CN102279749A), they are mainly for merging different versions of branches of the same programming language, do not involve cross-language conversion scenarios, and do not solve the problem of how to automatically retain customized content when repeatedly regenerating target code. Summary of the Invention
[0005] This application provides a tag-based method and system for merging custom content in cross-language code conversion, aiming to solve the problems of easy loss and low maintenance efficiency of manually customized content in existing cross-language code conversion processes.
[0006] The technical solution adopted by this application to solve its technical problem is:
[0007] On the one hand, a method for merging customized content in cross-language code conversion based on tags is provided, including the following steps: Step 1, in the source language code, add start tags and end tags to the code ranges that need to be customized, the start tags and end tags containing the same unique number to identify the corresponding code ranges; Step 2, in the target language code, add corresponding start tags and end tags at the positions corresponding to the code ranges in the source language code, the tag numbers in the target language code are consistent with the tag numbers in the source language code; Step 3, before performing a new code conversion, obtain the customized content located between the corresponding tags in the historical version of the target language code and store it in a cache; Step 4, perform code conversion to convert the source language code into the target language code, and retain the tag information during the conversion process; Step 5, when generating new target language code, obtain the corresponding customized content from the cache according to the tag number and automatically replace it between the corresponding tag positions in the new converted code; Step 6, perform consistency verification on the addition and removal of tags in the source language code and the target language code, and if the verification fails, output an alarm message or suspend the conversion.
[0008] Preferably, the markers in step 1 include replacement markers and deletion markers, wherein the replacement markers are used to identify the code ranges that need to be retained and restored, and the deletion markers are used to identify the code ranges that are no longer needed in the new version.
[0009] Preferably, the replacement marker includes a start marker "X_NEW_REPLACE_BEGIN_number" and an end marker "X_NEW_REPLACE_END_number", and the deletion marker includes a start marker "X_NEW_DELETE_BEGIN_number" and an end marker "X_NEW_DELETE_END_number". The number of the deletion marker is used to uniquely identify the corresponding deletion range.
[0010] Preferably, the start and end markers in the replacement markers are paired by numbering, which is globally unique throughout the project, or uniqueness is ensured by prefixing with a file identifier.
[0011] Preferably, the tags in the target language code have the same number and type as the tags in the source language code, and their relative positions in the code structure remain consistent, so as to ensure that the scope of the customized content can be accurately located after conversion.
[0012] Preferably, the cache uses a key-value pair data structure, with the tag number as the key and the customized code block and its metadata as the value. The metadata includes the file path where the code block is located, the start line number, the end line number, and the version timestamp.
[0013] Preferably, the code conversion is performed by a cross-language conversion tool, which identifies the markers in the source language code during the conversion process and outputs them as is to the corresponding positions in the target language code without parsing the internal content of the markers.
[0014] Preferably, the step of retrieving the corresponding customized content from the cache based on the tag number specifically includes: when generating new target language code, traversing the replacement tags in the code, querying the cache with the tag number as the key, if a match is found, replacing the customized content between the corresponding tag positions, and if no match is found, retaining the original tag and marking it as pending processing.
[0015] Preferably, the consistency check specifically includes: extracting the set of all marker numbers in the source language code and the set of all marker numbers in the target language code respectively, calculating the difference between the two sets, and if the difference is not empty, recording the mismatched marker numbers and generating a difference report.
[0016] On the other hand, a custom content merging system for cross-language code conversion based on tags is provided, including a first tag adding module, a second tag adding module, a cache management module, a code conversion module, a code merging module, and a consistency verification module, which are used to implement the steps of the above method, respectively.
[0017] One of the above technical solutions has the following advantages or beneficial effects:
[0018] By setting pairing tags in both source and target language codes and combining this with a historical version-based custom content caching and replacement mechanism, the invention achieves automatic retention and merging of custom content during cross-language conversion, avoiding manual repetitive modifications. Specifically, this invention incorporates both replacement and deletion tags into a unified numbering system, ensuring traceability and verifiability for deletion operations. This guarantees that regardless of whether custom content is retained, modified, or deleted, it can be managed throughout its entire lifecycle through numbering, avoiding the consistency verification failure problem caused by the disconnect between deletion tags and the numbering system in traditional solutions. The synergistic effect of replacement and deletion tags within the numbering system enables the entire custom content merging process to uniformly handle all modification types, significantly improving conversion efficiency and ensuring zero loss of custom content. This solves the pain point of custom content being easily overwritten after multiple conversions in existing technologies, demonstrating outstanding substantive features and significant progress.
[0019] Furthermore, in the technical solution of this invention, the replacement mark and the deletion mark share the same numbering allocation and verification mechanism. The two are not simply superimposed, but are deeply coupled through the core link of "marking number": the replacement mark retains historical customized code through a caching mechanism, and the deletion mark ensures the consistency of the deletion range between the source language code and the target language code through number verification. The two cooperate with each other in the conversion process to form a complete safety net, avoiding the conflicts or omissions that may occur between deletion and retention operations under a single marking scheme. This produces unexpected technical effects, namely, achieving full-coverage automated management of any customized modification type, and significantly improving the reliability and maintainability of large-scale legacy system migration. Attached Figure Description
[0020] Figure 1 This is a flowchart illustrating a custom content merging method in tag-based cross-language code conversion according to an exemplary embodiment;
[0021] Figure 2 This is a schematic diagram illustrating the structure of a custom content merging system in tag-based cross-language code conversion, according to an exemplary embodiment.
[0022] Figure 3 This is a schematic diagram illustrating a specific implementation architecture of a custom content merging system in tag-based cross-language code conversion, according to an exemplary embodiment.
[0023] Figure 4 This is a flowchart illustrating a specific implementation of a method for a custom content merging system in tag-based cross-language code conversion, according to an exemplary embodiment. Detailed Implementation
[0024] To more clearly illustrate the technical features of this application, the following detailed description is provided through specific embodiments and in conjunction with the accompanying drawings.
[0025] Example 1
[0026] like Figure 1 As shown in this embodiment, a method for customizing content merging in tag-based cross-language code conversion includes the following steps:
[0027] Step 1: In the source language code, add start and end markers to the code ranges that need to be customized. The start and end markers contain the same unique number to identify the corresponding code ranges.
[0028] Specifically, the markers in this embodiment include replacement markers and deletion markers. Replacement markers identify the code ranges that need to be retained and restored, while deletion markers identify the code ranges that are no longer needed in the new version. The replacement marker includes a start marker "X_NEW_REPLACE_BEGIN_number" and an end marker "X_NEW_REPLACE_END_number", and the deletion marker includes a start marker "X_NEW_DELETE_BEGIN_number" and an end marker "X_NEW_DELETE_END_number". The numbers of the deletion markers are used to uniquely identify the corresponding deletion range. The start and end markers in the replacement markers are paired using numbers, which are globally unique throughout the entire project, or their uniqueness is ensured by using a prefix plus a file identifier.
[0029] In this embodiment, the tags support nested structures. When nested tags exist, the system parses them according to a preset nesting processing priority strategy. The nesting processing priority strategy includes:
[0030] Innermost layer priority merging: When multiple tags are nested, the content between the innermost tags is processed first, and then the processing is extended to the outermost tags after merging.
[0031] Outermost layer priority merging: The content between the outermost tags is processed first, and the inner tags are treated as a whole. After merging, the inner tags are processed.
[0032] The priority strategy is preset by the user in the system configuration or specified in the conversion request. The system recursively parses the tag structure according to the strategy to ensure that the content of nested tags is processed correctly.
[0033] The start and end markers are added in at least one of the following forms: code comments, pre-compilation directives, or programming language attribute annotations, to adapt to the syntactic environment of different source language codes.
[0034] The unique number can be generated by combining a timestamp, file path, and auto-incrementing serial number, or by being manually specified by the developer, to ensure that the number is not repeated in multi-file conversion scenarios.
[0035] Step 2: In the target language code, add corresponding start and end marks at positions corresponding to the code range in the source language code, and ensure that the mark numbers in the target language code are consistent with the mark numbers in the source language code.
[0036] Specifically, the tags in the target language code have the same number and type as the tags in the source language code, and their relative positions in the code structure remain consistent to ensure that the scope of the customized content can be accurately located after conversion.
[0037] The markers in the target language code have existed in historical versions and have remained unchanged during multiple iterative conversions, serving as anchor points for custom content extraction.
[0038] The tags in the target language code adopt a form adapted to the tag syntax of the source language code, including comment statements, preprocessing directives, or framework-specific annotations, to ensure compatibility with the lexical and syntactic rules of the target language code.
[0039] The location where the target language code marker is added corresponds functionally to the code range corresponding to the source language code marker. When the marker in the source language code corresponds to a function or procedure, the marker in the target language code corresponds to the converted synonym function or method body.
[0040] Step 3: Before performing the new code conversion, retrieve the custom content located between the corresponding tags in the historical version of the target language code and store it in the cache.
[0041] Specifically, the cache adopts a key-value pair data structure, with the tag number as the key and the customized code block and its metadata as the value. The metadata includes the file path where the code block is located, the start line number, the end line number, and the version timestamp.
[0042] The cache supports incremental updates. When the customized content with the same number in the target language code of a historical version changes, the cache management module overwrites the old version with the latest version of the customized content and records the change history.
[0043] The process of obtaining customized content located between corresponding tags in the target language code of the historical version specifically includes: matching the tag string using regular expressions, extracting the code segment between the start tag and the end tag, and storing it in association with the tag number.
[0044] The customized content includes at least one of code snippets, configuration information, business logic descriptions, or comments, and supports multi-line text, structured data, or script fragments.
[0045] It is automatically triggered before performing new code conversions without manual intervention, and skips the cache extraction step and logs when the target language code of the historical version does not exist or the corresponding mark is not detected.
[0046] Step 4: Perform code conversion, converting the source language code into the target language code, and retaining the markup information during the conversion process.
[0047] Specifically, the code conversion is performed by a cross-language conversion tool, which identifies the markers in the source language code during the conversion process and outputs them as is to the corresponding positions in the target language code without parsing the internal content of the markers.
[0048] Before performing the code conversion, the method further includes: removing the code segments marked for deletion in the source language code from the conversion input according to the deletion markers, so that they do not participate in the conversion and are not output to the target language code.
[0049] Specifically, the retained tag information is as follows: in the target language code abstract syntax tree or intermediate representation generated by the conversion, the tag is retained as an independent node and a mapping relationship is established with the source language code tag number.
[0050] The code conversion supports batch file processing. The conversion tool maintains a global tag mapping table simultaneously when converting each file. This table uses a key-value pair data structure, with the tag number as the key and the file path, tag type (replacement or deletion), and the corresponding code location information in the source language code as the value. When converting multiple files, the system first queries the global tag mapping table. If the tag number for the current file already exists in the table, it verifies whether the tag type and location information are consistent; if inconsistent, a consistency check alarm is triggered. This table is initialized at the start of the conversion and updated after tag extraction for each file is completed, ensuring the global uniqueness and consistency of tag numbers across file scenarios.
[0051] Step 5: When generating new target language code, retrieve the corresponding customized content from the cache according to the tag number and automatically replace it between the corresponding tag positions in the new conversion code.
[0052] Specifically, the step of retrieving the corresponding customized content from the cache based on the tag number includes: when generating new target language code, traversing the replacement tags in the code, querying the cache with the tag number as the key, and if a match is found, replacing the customized content between the corresponding tag positions; if no match is found, retaining the original tag and marking it as pending processing.
[0053] The unprocessed tags are retained in the final output target code as specific comments for developers to manually process later.
[0054] The automatic replacement process supports multiple iterations: when the same tag number appears in multiple conversion processes, the system always uses the latest cached customized content as the basis for replacement, ensuring the continuity of customized content.
[0055] The automatic replacement also includes: when the customized content contains nested tags, the system first parses the nested structure before replacement and decides whether to retain or overwrite the internal tags according to the preset nesting processing strategy.
[0056] After the automatic replacement is completed, the system updates the version information of the customized content corresponding to the tag number in the cache and records this replacement operation in the conversion log.
[0057] Step 6: Perform a consistency check on the addition or removal of markers in the source language code and the target language code. If the check fails, output an alarm message or pause the conversion.
[0058] Specifically, the consistency check includes: extracting the set of all tag numbers in the source language code and the set of all tag numbers in the target language code respectively, calculating the difference between the two sets, and if the difference is not empty, recording the mismatched tag numbers and generating a difference report.
[0059] The discrepancy report includes the mismatched tag number, the file path, the tag type, and suggested handling methods, and is output in a structured format for developers to review.
[0060] The output alarm information or pause conversion includes: when the verification fails, the system automatically issues an audible and visual alarm, sends an email notification, or prompts the user through an integrated development environment plugin, and selects to automatically pause the conversion process or continue execution but mark the risk point according to the preset strategy.
[0061] The consistency check is automatically performed at the end of each conversion process and serves as a prerequisite for the final output of the target language code. The final code can only be output after the check passes.
[0062] The consistency check also supports manual triggering. Developers can actively execute the check by calling the check interface before or after the conversion to verify the correctness of the tag configuration.
[0063] This embodiment effectively solves the problem of manual customization being easily overwritten during cross-language conversion by using a two-way marking and cache replacement mechanism, thereby improving conversion efficiency and accuracy, reducing manual intervention costs, and making it suitable for large-scale legacy system migration scenarios.
[0064] Example 2
[0065] like Figure 2 As shown in this embodiment, a custom content merging system for tag-based cross-language code conversion includes:
[0066] The first marker adding module is used to add start markers and end markers to the code ranges that need to be customized in the source language code. The start markers and end markers contain the same unique number to identify the corresponding code ranges.
[0067] The second marker adding module is used to add corresponding start and end markers in the target language code at positions corresponding to the code range in the source language code, wherein the marker numbers in the target language code are consistent with the marker numbers in the source language code;
[0068] The cache management module is used to retrieve the customized content located between corresponding tags in the historical version of the target language code before performing a new code transformation, and store it in the cache;
[0069] The code conversion module is used to perform code conversion, converting the source language code into the target language code, and retaining the markup information during the conversion process;
[0070] The code merging module is used to retrieve the corresponding customized content from the cache according to the tag number when generating new target language code, and automatically replace it between the corresponding tag positions in the new converted code;
[0071] The consistency verification module is used to verify the consistency of the addition or removal of markers in the source language code and the target language code. If the verification fails, an alarm message will be output or the conversion will be paused.
[0072] The cache management module is also used to record the version timestamp of customized content and to implement incremental updates in multiple rounds of conversion.
[0073] The consistency verification module performs a fast verification by calculating the hash value of the tag number set in the source language code and the target language code. If the hash values are inconsistent, a detailed difference analysis is triggered.
[0074] Both the first and second marker addition modules support the identification of replacement and deletion markers, and output them to the code conversion module and code merging module, respectively.
[0075] Example 3
[0076] like Figure 3 As shown, this embodiment presents another custom content merging system in tag-based cross-language code conversion. Figure 3 The system's various functional modules and their interrelationships are illustrated. The system mainly consists of an input source component, a processing module, a tag buffer module, and an output component.
[0077] The input source components include COBOL source code and historical Java versions;
[0078] The code processing module includes: a code conversion module, a code deletion module, a code replacement module, and a replacement cache generation module. The code conversion module is primarily responsible for converting COBOL code into Java code; the code deletion module processes deletion markers in the COBOL source code; the replacement cache generation module extracts replacement markers from historical Java source code versions and stores them in a marker cache module; the code replacement module processes intermediate Java source code files, replacing the corresponding markers in the intermediate Java source code with the content from the marker cache module, generating the final version of the Java source code.
[0079] The tag cache module is used to store replacement tag content in Java history versions.
[0080] Output component: The final Java source code.
[0081] Example 4
[0082] like Figure 4 As shown in this embodiment, another method for custom content merging in tag-based cross-language code conversion is presented.
[0083] Figure 4 This is a flowchart illustrating a specific implementation of this application, describing its workflow. It includes: identifying customizable areas by adding specific markers to the source code; executing a code conversion tool to convert the source code into target language code; automatically identifying and saving user-defined content in the target code; automatically restoring this customized content when regenerating the code; and finally ensuring the integrity of the conversion process through marker consistency verification and outputting the final target code incorporating user-defined content.
[0084] 1. Add source language code tags:
[0085] In the source language code, marks are added to the code ranges that need to be customized; among them, replacement marks are added to the code ranges that need to be retained and restored. The replacement marks include start marks and end marks, which contain the same unique number to identify the corresponding code ranges; deletion marks are added to the code ranges that are no longer needed in the new version, providing an identification basis for subsequent code conversion and customized content protection.
[0086] Replacement markers: Used to identify the range of code that needs to be retained and restored. The start marker is X_NEW_REPLACE_BEGIN_number, and the end marker is X_NEW_REPLACE_END_number;
[0087] Deletion markers: Used to identify code ranges that are no longer needed in the new version. The start marker is designated by the number X_NEW_DELETE_BEGIN_, and the end marker is designated by the number X_NEW_DELETE_END_.
[0088] 2. Execute code conversion:
[0089] Run the code conversion tool to convert the marked source language code (COBOL) into the target language code (JAVA). This achieves the basic conversion from source language code to target language code while preserving the integrity of the marked information.
[0090] The preprocessing step involves removing code marked for deletion from the COBOL source code.
[0091] Convert COBOL language to Java language;
[0092] Replacement tag information is preserved during the conversion process to ensure that the tags can be correctly mapped to the target language code.
[0093] 3. Does the target file exist?
[0094] Determine if the target language code file already exists:
[0095] Yes (true): The target file already exists, and historical customized content needs to be processed;
[0096] No (false): The target file does not exist; a new file will be created. Whether the target file exists determines the subsequent processing strategy. Details are as follows:
[0097] 31. Read the tags in the target file's historical versions:
[0098] Identify replacement markers (X_NEW_REPLACE) in the target file, read marker information from historical versions of the target file, and prepare for extracting customized content;
[0099] Synchronously identify deletion markers in the target file and verify the consistency between the marker number and type.
[0100] 32. Extract customized content between tags:
[0101] Extract user-customized content located between tags; this content represents manual modifications made based on previous transformations. Establish a cache based on tag numbers to ensure that customized content across different tag ranges is correctly distinguished and stored.
[0102] 33. Cache Customization:
[0103] The extracted customized content is cached and stored according to the tag number, providing a content source for subsequent newly generated code. A mapping relationship of "tag number -> customized content" is established and stored in the cache.
[0104] 34. Create a new file:
[0105] Create a new target language code file to store the converted content. Provide the basic file structure for the first conversion or a completely new target file.
[0106] 35. Identify marker locations in the newly generated code:
[0107] In the new target language code generated by the code conversion tool, identify the positions corresponding to the replacement marks in the source language code.
[0108] 4. Find the matching cached content:
[0109] Determine if custom content matching the tags in the newly generated code exists in the cache:
[0110] Yes (true): Matching cached content was found and can be merged;
[0111] No (false): No matching cached content was found, requiring special handling.
[0112] 41. Merge the cached content into the corresponding marked position:
[0113] Retrieve the corresponding customized content from the cache database based on the tag number, and replace the content between the corresponding tags in the newly generated code.
[0114] 42. Keep the mark and mark it as pending:
[0115] Retain the tags in the newly generated code, but mark them as pending to provide an identifier for subsequent manual processing and ensure that no tags that need to be processed are missed.
[0116] 5. Perform a tag consistency check:
[0117] Perform consistency checks on the tags in the source language code and the target language code to check for any missing or mismatched tags, ensuring the completeness and correctness of the tags.
[0118] 6. Output the final target code:
[0119] The target code, after all processing steps, is written to a file, generating the final target language code file. This final target code file contains both automatically generated code and historically customized content, making it a complete target file.
[0120] Based on the method described in this embodiment, the specific process of converting COBOL to Java code is as follows:
[0121] 1. In the COBOL source code, developers identify code segments that require special handling and add a replacement start marker before and after them: "X_NEW_REPLACE_BEGIN_number", such as "X_NEW_REPLACE_BEGIN_0001" and a replacement end marker: "X_NEW_REPLACE_END_number", such as "X_NEW_REPLACE_END_0001".
[0122] 2. Add corresponding replacement tags in the existing Java code, and write Java code adapted to the new system between the tags;
[0123] 3. In COBOL code, for code segments no longer needed in the new kernel system, add a deletion start marker: "X_NEW_DELETE_BEGIN_number" and a deletion end marker: "X_NEW_DELETE_END_number";
[0124] 4. Use a code conversion tool to convert the marked COBOL code into Java code:
[0125] 1) Before conversion, delete the code marked with a deletion flag in COBOL.
[0126] 2) Perform code conversion, retaining replacement markers during the conversion process.
[0127] 3) The system reads historical Java files, extracts the code content between the X_NEW_REPLACE tags, and establishes a cache.
[0128] 4) Process the converted Java files. When encountering a marker with the same number, automatically insert the cached custom code into the newly generated Java file;
[0129] By applying this method, in a task of converting 10,000 COBOL code files, processing 73 deletion markers in 15 files and 1,750 replacement markers in 374 files only takes 7 minutes.
[0130] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and not to limit them. Although this application has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation methods of this application. Any modifications or equivalent substitutions that do not depart from the spirit and scope of this application should be covered within the protection scope of the claims of this application.
Claims
1. A method for merging customized content in markup-based cross-language code conversion, characterized in that, Includes the following steps: Step 1: In the source language code, add start and end markers to the code ranges that need to be customized. The start and end markers contain the same unique number to identify the corresponding code ranges. Step 2: In the target language code, add corresponding start and end marks at positions corresponding to the code range in the source language code, and ensure that the mark numbers in the target language code are consistent with the mark numbers in the source language code; Step 3: Before performing the new code conversion, retrieve the customized content located between the corresponding tags in the historical version of the target language code and store it in the cache; Step 4: Perform code conversion, converting the source language code into the target language code, and retaining the markup information during the conversion process; Step 5: When generating new target language code, retrieve the corresponding customized content from the cache according to the tag number and automatically replace it between the corresponding tag positions in the new conversion code; Step 6: Perform a consistency check on the addition or removal of markers in the source language code and the target language code. If the check fails, output an alarm message or pause the conversion.
2. The method for merging customized content in tag-based cross-language code conversion according to claim 1, characterized in that, The markers in step 1 include replacement markers and deletion markers. Replacement markers are used to identify code ranges that need to be retained and restored, while deletion markers are used to identify code ranges that are no longer needed in the new version.
3. The method for merging customized content in tag-based cross-language code conversion according to claim 2, characterized in that, The replacement markers include a start marker "X_NEW_REPLACE_BEGIN_number" and an end marker "X_NEW_REPLACE_END_number", and the deletion markers include a start marker "X_NEW_DELETE_BEGIN_number" and an end marker "X_NEW_DELETE_END_number".
4. The method for merging customized content in tag-based cross-language code conversion according to claim 3, characterized in that, The start and end markers in the replacement markers are paired by number, which is globally unique throughout the project, or unique by prefixing with a file identifier.
5. The method for merging customized content in tag-based cross-language code conversion according to claim 1, characterized in that, The tags in the target language code have the same number and type as the tags in the source language code, and their relative positions in the code structure remain consistent to ensure that the scope of the customized content can be accurately located after conversion.
6. The method for merging customized content in tag-based cross-language code conversion according to claim 1, characterized in that, The cache uses a key-value pair data structure, with the tag number as the key and the custom code block and its metadata as the value. The metadata includes the file path where the code block is located, the start line number, the end line number, and the version timestamp.
7. The method for merging customized content in tag-based cross-language code conversion according to claim 1, characterized in that, The code conversion is performed by a cross-language conversion tool, which identifies the markers in the source language code during the conversion process and outputs them as is to the corresponding positions in the target language code, without parsing the internal content of the markers.
8. The method for merging customized content in tag-based cross-language code conversion according to claim 1, characterized in that, The step of retrieving the corresponding customized content from the cache based on the tag number specifically includes: when generating new target language code, traversing the replacement tags in the code, querying the cache with the tag number as the key, if a match is found, replacing the customized content between the corresponding tag positions, and if no match is found, retaining the original tag and marking it as pending processing.
9. The method for merging customized content in tag-based cross-language code conversion according to any one of claims 1-8, characterized in that, The consistency check specifically includes: extracting the set of all marker numbers in the source language code and the set of all marker numbers in the target language code respectively, calculating the difference between the two sets, and if the difference is not empty, recording the mismatched marker numbers and generating a difference report.
10. A custom content merging system for tag-based cross-language code conversion, characterized in that, include: The first marker adding module is used to add start markers and end markers to the code ranges that need to be customized in the source language code. The start markers and end markers contain the same unique number to identify the corresponding code ranges. The second marker adding module is used to add corresponding start and end markers in the target language code at positions corresponding to the code range in the source language code, wherein the marker numbers in the target language code are consistent with the marker numbers in the source language code; The cache management module is used to retrieve the customized content located between corresponding tags in the historical version of the target language code before performing a new code transformation, and store it in the cache; The code conversion module is used to perform code conversion, converting the source language code into the target language code, and retaining the markup information during the conversion process; The code merging module is used to retrieve the corresponding customized content from the cache according to the tag number when generating new target language code, and automatically replace it between the corresponding tag positions in the new converted code; The consistency verification module is used to verify the consistency of the addition or removal of markers in the source language code and the target language code. If the verification fails, an alarm message will be output or the conversion will be paused.