Extensible markup language file storage method and related apparatus

Abstract

This invention discloses a method and related apparatus for storing Extensible Markup Language (XML) files. The method includes: first, obtaining XML file storage instructions for n vehicle models adapted to k preset language types; then, obtaining n diagnostic datasets corresponding to the n vehicle models from a diagnostic database; next, determining the XML files corresponding to the k preset language types based on the n diagnostic datasets, resulting in n×k XML files; and finally, determining a first target spreadsheet based on the n×k XML files, whereby the first target spreadsheet is used to partition and store the n×k XML files. The implementation method of this application improves the efficiency of managing vehicle diagnostic data.

Description

Technical Field

[0001] This invention relates to the field of vehicle diagnostic technology, and in particular to an extensible markup language file storage method and related apparatus. Background Technology

[0002] In the field of automotive diagnostics, with the diversification of vehicle models and the globalization of the market, the need for managing multi-vehicle and multi-language diagnostic data is becoming increasingly prominent. Extensible markup language files, as a structured data carrier, have the characteristics of standardized format, cross-platform compatibility, and clear hierarchical relationships. They can accurately encapsulate the field attributes and logical relationships of diagnostic data. However, in traditional technologies, diagnostic data is often stored in compressed packages in a mixed form of unstructured or semi-structured formats. This means that when extracting diagnostic data for a specific vehicle model and language in a multi-language scenario, it is necessary to traverse the entire compressed package, which can easily lead to data parsing errors and format incompatibility issues. How to improve the management efficiency of automotive diagnostic data is an urgent problem to be solved. Summary of the Invention

[0003] This application provides an extensible markup language file storage method and related apparatus, which improves the efficiency of managing automotive diagnostic data.

[0004] In a first aspect, embodiments of this application provide an extensible markup language file storage method, including: Retrieve instructions for storing Extensible Markup Language (Extreme Markup Language) files that adapt to k preset language types for n vehicle models; n is an integer greater than 1, k is an integer greater than 1, and each vehicle model corresponds to k preset language types; Obtain n diagnostic datasets corresponding to the n vehicle models from the diagnostic database; the diagnostic database pre-stores multiple diagnostic datasets, each diagnostic dataset corresponding to one vehicle model; Based on the n diagnostic datasets, the k preset language types are determined to produce n×k extensible markup language files; each vehicle model corresponds to k extensible markup language files. A first target spreadsheet is determined based on the n×k Extensible Markup Language (XML) files; the first target spreadsheet is used to partition and store the n×k XML files.

[0005] Secondly, embodiments of this application provide an extensible markup language file storage device, the device comprising: an acquisition unit and a processing unit; The acquisition unit is used to acquire storage instructions for Extensible Markup Language (EXPLAIN) files that are adapted to k preset language types for n vehicle models; n is an integer greater than 1, k is an integer greater than 1, and each vehicle model corresponds to k preset language types. The processing unit is used to obtain n diagnostic datasets corresponding to the n vehicle models from the diagnostic database; the diagnostic database pre-stores multiple diagnostic datasets, each diagnostic dataset corresponding to one vehicle model. Based on the n diagnostic datasets, the k preset language types are determined to produce n×k extensible markup language files; each vehicle model corresponds to k extensible markup language files. A first target spreadsheet is determined based on the n×k Extensible Markup Language (XML) files; the first target spreadsheet is used to partition and store the n×k XML files.

[0006] Thirdly, embodiments of the present invention provide an electronic device, including: a processor, a memory, a communication interface, and one or n programs, wherein the one or n programs are stored in the memory and configured to be executed by the processor so that the electronic device performs the method as described in the first aspect.

[0007] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program that is executed by a processor to implement the method as described in the first aspect.

[0008] Fifthly, embodiments of the present invention provide a computer program product including a non-transitory computer-readable storage medium storing a computer program, such that a computer performs the method as described in the first aspect.

[0009] Implementing the embodiments of the present invention has the following beneficial effects: As can be seen, the Extensible Markup Language (XML) file storage method described in this embodiment of the invention first obtains XML file storage instructions for n vehicle models and k preset language types. Then, it retrieves n diagnostic datasets corresponding to the n vehicle models from a diagnostic database. Next, based on the n diagnostic datasets, it determines the XML files corresponding to the k preset language types, resulting in n×k XML files. Finally, it determines a first target spreadsheet based on the n×k XML files, which is used to partition and store the n×k XML files. This embodiment of the invention improves the efficiency of managing vehicle diagnostic data. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application or the background art, the accompanying drawings used in the embodiments of this application or the background art will be described below.

[0011] Figure 1This is a flowchart of an Extensible Markup Language (EXPLAIN) file storage method provided in an embodiment of this application; Figure 2 This is a flowchart illustrating how to determine n×k Extensible Markup Language (EXPLAIN) files according to an embodiment of this application; Figure 3 This is a flowchart of a method for determining a target spreadsheet provided in an embodiment of this application; Figure 4 This is a flowchart illustrating how to locate Extensible Markup Language (XML) files according to an embodiment of this application; Figure 5 This is a flowchart illustrating another method for finding Extensible Markup Language (XML) files provided in this application. Figure 6 This is a flowchart of another method for determining a target spreadsheet provided in this application. Figure 7 This is a schematic diagram of the structure of an extensible markup language file storage device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present application.

[0013] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0014] In this document, the term "implementation" means that a specific feature, structure, or characteristic described in connection with an implementation may be included in at least one implementation of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same implementation, nor is it a separate or alternative implementation mutually exclusive with other implementations. It will be explicitly and implicitly understood by those skilled in the art that the implementations described herein can be combined with other implementations.

[0015] First, the relevant terms used in this application will be explained: XML: Extensible Markup Language (XML) is a markup language used to mark up electronic documents to give them structure. It supports user-defined tags and has good scalability, cross-platform compatibility, and readability. It is often used to store and transmit structured data. In the field of vehicle diagnostics, it can be used to encapsulate diagnostic dataset information corresponding to different vehicle models and languages, so as to achieve standardized storage and efficient interaction of diagnostic data.

[0016] TI: Text Identifier (TI) is a feature code or symbol used to uniquely identify specific text information. In the field of vehicle diagnostic technology, it is usually associated with vehicle model, diagnostic dataset, or Extensible Markup Language (Extreme Markup Language) file. Through this identifier, the diagnostic text data, multilingual version configuration information, and other content of the corresponding vehicle model can be quickly located, which can improve the efficiency of diagnostic data retrieval and management.

[0017] PDX files: Portable Diagnostic eXchange (PDX) files are mainly used to package and transmit vehicle diagnostic-related configuration data, protocol parameters, fault code definitions, and other information between different diagnostic devices, software platforms, or vehicle manufacturer systems. They feature strong cross-platform compatibility and a clear data structure, which can simplify the process of sharing and reusing diagnostic data.

[0018] EXCEL (Electronic Spreadsheet Software) is a powerful spreadsheet processing tool that supports data entry, storage, calculation, sorting, filtering, and visualization. It organizes data through a cell matrix composed of rows and columns. In the field of vehicle diagnostic technology, it is often used to build target spreadsheets to achieve structured collection of Scalable Markup Language (SML) file information corresponding to multiple vehicle models and languages. It can also integrate text mapping relationships, text identifiers, and other data to facilitate the rapid query, management, and retrieval of diagnostic data.

[0019] Please see Figure 1 , Figure 1 This is a flowchart of an Extensible Markup Language (Extreme Markup Language) file storage method provided in an embodiment of this application, including but not limited to the following steps: S101: Instructions for retrieving and storing extensible markup language files that adapt to k preset language types for n vehicle models.

[0020] In this embodiment, n is an integer greater than 1, k is an integer greater than 1, and each vehicle model corresponds to k preset language types.

[0021] The core requirement of the instruction for storing extensible markup language files adapted to k preset languages ​​for n vehicle models is to generate and store extensible markup language files adapted to k preset languages ​​for each of the specified n different vehicle models. This ensures that each vehicle model can correspond to files in k different languages. Subsequently, the diagnostic dataset for the corresponding vehicle model can be determined based on this instruction, thereby generating extensible markup language files that meet the quantity and language adaptation requirements, and ultimately achieving standardized storage and management of these files.

[0022] It should be noted that the k preset language types are multiple language types pre-selected based on the actual application scenarios of vehicle diagnostic data, target market distribution, and the language usage needs of user groups. They typically cover mainstream international languages ​​and official languages ​​of target sales regions, such as Chinese, English, German, French, Spanish, Japanese, and Korean. The determination of these language types needs to be combined with the global layout of the automotive brand, the service scope of the aftermarket, and the regulatory requirements of different countries and regions to ensure that the generated multilingual scalable markup language files can meet the needs of users in different regions for reading, parsing, and using diagnostic data, while also adapting to local technical document specifications and language expression habits.

[0023] S102: Obtain the n diagnostic datasets corresponding to the n vehicle models from the diagnostic database.

[0024] In this embodiment, the diagnostic database pre-stores multiple diagnostic datasets, each corresponding to a vehicle model. The diagnostic database is a pre-established structured storage system specifically designed to store vehicle diagnostic-related data. The core storage unit of the diagnostic database is the diagnostic dataset, and the database follows a storage rule of one vehicle model corresponding to one dedicated diagnostic dataset. Each diagnostic dataset integrates the core diagnostic information of the corresponding vehicle model, including fault code definitions, electronic control unit communication parameters, diagnostic process specifications, and other key information.

[0025] In this embodiment, the Diagnostic Data Packet Exchange Format (DDSSE) is a standardized data organization and transmission specification used to structurally encapsulate vehicle diagnostic-related data. The diagnostic database is a carrier for centrally storing diagnostic datasets corresponding to different vehicle models. The diagnostic datasets of each vehicle model stored in the diagnostic database can be organized, converted, and packaged according to the DDSSE specification to form diagnostic data files that conform to common standards. This facilitates efficient transmission and sharing between different diagnostic systems, devices, or platforms. At the same time, diagnostic data that follows this format can be stored in the diagnostic database in a more standardized manner, improving the consistency and readability of the data within the database.

[0026] It should be noted that the n diagnostic datasets corresponding to the n vehicle models can also be obtained from the diagnostic data packet exchange file.

[0027] S103: Based on the n diagnostic datasets, determine the extensible markup language files corresponding to the k preset language types to obtain n×k extensible markup language files.

[0028] In this embodiment, each vehicle model corresponds to k Extensible Markup Language (XML) files. When each of the n diagnostic datasets is a compressed diagnostic dataset, it is necessary to first decompress any one of the n compressed diagnostic datasets to obtain the decompressed first diagnostic dataset. Then, according to k preset language types, language text conversion is performed on the decompressed first diagnostic dataset to generate k diagnostic datasets corresponding to each preset language type. Next, the XML encapsulation format corresponding to each of the k preset language types is determined, and k XML encapsulation formats are obtained. Finally, the k diagnostic datasets obtained after conversion are encapsulated according to these k XML encapsulation formats to form k XML files corresponding to the first diagnostic dataset. Afterwards, the same process is followed to complete the decompression, language conversion, encapsulation format determination, and encapsulation operation for each of the n compressed diagnostic datasets, and finally, n×k XML files are obtained.

[0029] Alternatively, you can first batch decompress n compressed diagnostic datasets to obtain n decompressed diagnostic datasets. Then, based on a preset multilingual text mapping library, you can simultaneously perform text conversion for k preset languages ​​on these n decompressed diagnostic datasets to generate n sets of diagnostic datasets, each containing k different language versions. Next, you can uniformly call up k preset Extensible Markup Language (Extreme Markup Language) encapsulation format templates and automatically encapsulate each language version of the diagnostic dataset in the n sets of diagnostic datasets according to the rule of one language corresponding to one encapsulation format. Finally, you can summarize all the encapsulated files to obtain n×k Extreme Markup Language files.

[0030] S104: Determine the first target spreadsheet based on the n×k Extensible Markup Language files.

[0031] In this embodiment, the first target spreadsheet is used to partition and store the n×k Extensible Markup Language files.

[0032] First, text identifiers can be determined for each of the n vehicle models to identify their feature codes, thereby generating corresponding n vehicle model indices. Then, k language indexes can be determined based on k preset language types. Subsequently, the n vehicle model indices are set as the vehicle model index rows of a spreadsheet, and the k language indexes are set as the language index columns of the spreadsheet. Next, the core data area of ​​the spreadsheet is constructed based on n×k Extensible Markup Language (XML) files. This data area has an n-row, k-column structure, where each row corresponds to a vehicle model and its k XML files in the k preset language types, and each column corresponds to a preset language type and its n XML files in the n vehicle models. Finally, by integrating the vehicle model index rows, language index columns, and the n-row, k-column data area, the first target spreadsheet can be determined.

[0033] Alternatively, n×k Extensible Markup Language (XML) files can be first classified and archived by vehicle type and language type. A unique feature code is assigned to each vehicle type and a vehicle type classification label is generated. A corresponding language classification label is generated for each preset language type. Then, a table row structure is constructed with the vehicle type classification label as the vertical dimension and a table column structure is constructed with the language classification label as the horizontal dimension. Subsequently, key information such as the storage path, file version, and update time of the XML files corresponding to each vehicle type and each language is filled into the corresponding row and column intersection cells in the table. At the same time, a file retrieval function module is set at the top of the table. Finally, by integrating the row and column structure, file information, and retrieval module, the first target spreadsheet is determined.

[0034] In this embodiment, the first target spreadsheet is a structured data management spreadsheet built around vehicle models and preset language types as core dimensions. It is constructed based on n×k Extensible Markup Language (XML) files and includes three core parts: vehicle model index rows, language type index columns, and an n-row k-column data area. The vehicle model index rows are generated based on text identifiers corresponding to n vehicle models and are used to identify the affiliation of different vehicle models in the spreadsheet. The language type index columns are generated based on k preset language types and are used to distinguish the file categories of different language versions in the spreadsheet. Each cell in the n-row k-column data area corresponds to an XML file of a vehicle model under a certain preset language type. This clearly presents the storage association relationship of different language versions of files for each vehicle model, enabling systematic classification, efficient retrieval, and convenient management of multiple vehicle models and multiple language XML files.

[0035] As can be seen, firstly, by obtaining explicit instructions for storing extensible markup language (EXPLAIN) files that are adapted to k preset language types for n vehicle models, the target scope and core requirements for file storage can be precisely defined, avoiding directional deviations in subsequent operations and ensuring that each vehicle model corresponds to files in all preset language types, meeting the usage needs in multilingual scenarios. Secondly, obtaining diagnostic datasets for n vehicle models from a pre-stored diagnostic database that corresponds one-to-one with each vehicle model ensures the accuracy and authority of the data source, providing a reliable data foundation for the subsequent generation of extensible markup language files and effectively reducing file failure issues caused by data errors. Then, based on the diagnostic dataset, n×k extensible markup language files are generated. The language files enable structured encapsulation of diagnostic data, providing a unified format standard for diagnostic data from different vehicle models and language versions. This improves data readability and compatibility, facilitating transmission and sharing across different diagnostic systems or platforms. Finally, using FirstTarget Spreadsheets to partition and store these files, a clear file management system based on vehicle model and language is established. This allows users to quickly locate the corresponding file based on vehicle model and language, significantly improving the efficiency of file retrieval and retrieval. It also facilitates unified file maintenance and updates, reducing subsequent management costs and ensuring a complete closed loop from diagnostic data acquisition to scalable markup language file generation and efficient management.

[0036] Please see Figure 2 , Figure 2 This application provides a flowchart for determining n×k Extensible Markup Language (EXPLAIN) files, including but not limited to the following steps: S201: Decompress the first diagnostic dataset to obtain the first diagnostic dataset.

[0037] In this embodiment, each of the n diagnostic datasets is a compressed diagnostic dataset, and the first diagnostic dataset is any one of the n diagnostic datasets.

[0038] First, determine the compression algorithm type used in the first diagnostic dataset. Then, call the decompression tool or function that matches the compression algorithm, input the first diagnostic dataset into the decompression tool or function, and set the decompression parameters corresponding to the compression parameters. Then, start the decompression process, and use the decompression tool or function to unpack and restore the compressed data of the first diagnostic dataset, removing redundant encoding and format identifiers added during the compression process. Finally, obtain a complete and structured first diagnostic dataset that can be directly used for subsequent language text conversion.

[0039] In this embodiment, since the first diagnostic dataset is any one of the n diagnostic datasets, the method for determining the n×k Extensible Markup Language (XML) files corresponding to the n diagnostic datasets is the same as the method for determining the k XML files corresponding to the first diagnostic dataset. Therefore, the n×k XML files corresponding to the n diagnostic datasets can be determined according to the method for determining the k XML files corresponding to the first diagnostic dataset.

[0040] S202: Based on the k preset language types, the first diagnostic dataset is converted into language text to obtain k diagnostic datasets.

[0041] In this implementation, each diagnostic dataset corresponds to a preset language. The language-to-text conversion relies on standardized multilingual resources in the diagnostic field and a rigorous conversion process. First, a vehicle diagnostic terminology mapping library covering k preset language categories is built. This library must include multilingual entries for core texts such as fault code definitions, electronic control unit parameter descriptions, diagnostic process specifications, and data field names. Simultaneously, text conversion rules are clearly defined, including terminology matching priorities, non-standard text processing schemes, and data format consistency requirements. Second, all textual information in the first diagnostic dataset is extracted, and standardized terms in the mapping library are preferentially matched according to preset rules to achieve accurate translation. For special text content not covered by the mapping library, a dedicated diagnostic translation interface is used for preliminary conversion, and professional personnel manually proofread the translations to ensure they conform to industry standards and language expression habits. Then, during the conversion process, the non-textual data corresponding to each language version is strictly kept completely consistent with the original dataset to avoid data tampering or format deviations. Finally, the converted text information and corresponding non-textual data for each preset language category are re-integrated and packaged.

[0042] In this embodiment, translation software that integrates a professional terminology database for vehicle diagnostics can also be used to complete the multilingual conversion of the first diagnostic dataset. Examples include Deepin Translation Professional Edition, which supports custom deployment of industry terminology; Baidu Translation Professional Edition, which has a professional domain model; Google Translate Enterprise Edition, which can access a diagnostic terminology mapping library; and Tados, which focuses on translating engineering and technical documents. These software programs can process the regular text content in the dataset through their built-in general translation capabilities, and can also accurately convert core professional texts such as fault code definitions, electronic control unit parameter descriptions, and diagnostic process specifications by importing pre-built vehicle diagnostic terminology lookup tables. Some software programs also support batch processing, allowing for parallel conversion of k preset language types on the decompressed first diagnostic dataset at once. After conversion, simply re-integrate the text content of each language version with the non-text data in the original dataset to obtain k diagnostic datasets corresponding to different preset language types.

[0043] Specifically, a multilingual mapping library of vehicle diagnostic terminology covering k preset language categories can be constructed first. This mapping library needs to include standardized multilingual entries for core texts such as fault code definitions, electronic control unit communication parameter descriptions, diagnostic process specifications, and data field names. Clear language conversion rules should also be established, specifying text conversion priorities, terminology consistency requirements, handling methods for non-standard texts, and data format preservation criteria. Then, all textual information in the first diagnostic dataset is extracted, and the corresponding terms in the mapping library are matched sequentially according to the preset rules. Accurate translations are performed for different language versions. For special text content not covered in the mapping library, a preset diagnostic-specific translation interface is called, combined with manual proofreading for supplementary conversion. During the conversion process, it is crucial to ensure that the non-textual data (such as values, codes, and data structures) corresponding to each language version is completely consistent with the original dataset, without any tampering or deviation. Finally, the converted text information and corresponding non-textual data under each preset language category are re-integrated and encapsulated to generate k diagnostic datasets, each corresponding to a preset language category, with a unified data structure, accurate content, and compliance with language usage standards.

[0044] S203: Determine the Extensible Markup Language (Extreme Markup Language) encapsulation format corresponding to each of the k preset language types to obtain k Extreme Markup Language (Extreme Markup Language) encapsulation formats.

[0045] In this implementation, the Extensible Markup Language (XML) encapsulation format corresponding to each preset language type is a structured data encapsulation specification customized by combining the text encoding characteristics, grammatical expression rules, and storage and parsing requirements of the corresponding language. It clarifies the core elements when encapsulating diagnostic datasets into XML files, including language-adaptive tag naming rules that require tag names to be concise and conform to the terminology of the corresponding language for easy subsequent retrieval and identification; hierarchical division rules for data nodes that require a clear node hierarchy based on the logical relationships of the diagnostic data to ensure consistent node structure across different language versions; text content encoding formats that adapt to the character set requirements of the corresponding language to avoid garbled characters; and attribute information setting rules that specify the attribute parameters that each data node must carry, such as file version number, generation time, and corresponding vehicle model code. This format also specifies the storage method for non-text data to ensure consistency of numerical values, codes, and other content across different language versions. Overall, the encapsulation format corresponding to each language type not only follows the general syntax standards of XML but is also optimized for the specific language's usage requirements, ensuring that the encapsulated file has good readability, compatibility, and parsability.

[0046] First, we can analyze the text encoding characteristics and language expression standards of each preset language. Then, combined with the syntax rules of Extensible Markup Language (XML) and the storage requirements of vehicle diagnostic data, we can clarify the encapsulation structure requirements corresponding to different language versions of diagnostic datasets. Specifically, this includes core elements such as label naming rules, data node hierarchy, attribute information settings, and text content encoding format adaptation. Subsequently, for each preset language, based on its unique text characteristics and diagnostic data presentation requirements, we can develop a matching exclusive encapsulation format to ensure that the encapsulated file not only conforms to the general standards of XML but also adapts to the text storage and parsing requirements of the corresponding language. Finally, by summarizing the customized encapsulation formats for each preset language, we can obtain k XML encapsulation formats corresponding to different preset language types.

[0047] S204: Encapsulate the k diagnostic datasets based on the k extensible markup language encapsulation formats to obtain the k extensible markup language files corresponding to the first diagnostic dataset.

[0048] In this embodiment, the Extensible Markup Language (XML) encapsulation format corresponding to each of the k preset language types is determined. After obtaining the k XML encapsulation formats, the text content and non-text content in the diagnostic dataset are filled into the corresponding marker nodes according to the tag naming rules, data node hierarchy requirements, text encoding standards, and attribute information setting specifications specified in the corresponding encapsulation formats. At the same time, preset attribute information such as file version number, vehicle model code, and generation time are added to each data node. During the filling process, the logical structure requirements of the encapsulation format must be strictly followed to ensure that data nodes at different levels are nested in an orderly manner, the text content conforms to the character set adaptation standard of the corresponding language, and the storage format and numerical precision of non-text data are consistent. After completing the filling and node construction of a single diagnostic dataset, the files are integrated and verified according to the general syntax rules of the XML. After confirming that there are no syntax errors and data omissions, a single-language version of the XML file is generated. Then, the above matching, filling, integration, and verification operations are performed on the k diagnostic datasets in sequence, and finally, the k XML files corresponding to the first diagnostic dataset are obtained.

[0049] As can be seen, decompressing any compressed diagnostic dataset first can restore complete and directly editable diagnostic data, providing a foundation for subsequent language conversion and encapsulation operations. This avoids the compression format hindering data reading and processing. Then, based on multiple preset language categories, language text conversion is performed on the decompressed diagnostic dataset, generating diagnostic datasets adapted to different language environments. This meets the language usage needs of users in different regions, improving the universality and applicability of the diagnostic data. Finally, determining the Extensible Markup Language (Extreme Markup Language) encapsulation format corresponding to each language category allows for standardized encapsulation specifications for different language versions of diagnostic datasets, ensuring a unified and compliant file structure after encapsulation. The extended markup language syntax requirements facilitate file parsing and calling by different systems or platforms. Finally, the diagnostic datasets for each language version are encapsulated according to the corresponding encapsulation format, generating Scalable Markup Language files that correspond one-to-one with the language type. This ensures that the content and format of each file are adapted to the usage scenario of the corresponding language. Furthermore, by completing the above-mentioned full-process operation on a single diagnostic dataset, a standardized processing paradigm can be formed. Subsequently, this paradigm can be applied to all diagnostic datasets to efficiently generate Scalable Markup Language files for all vehicle models and all language types. The overall process steps are clear and logically rigorous, ensuring both the accuracy and standardization of data processing and improving the efficiency and quality of file generation.

[0050] Please see Figure 3 , Figure 3 This is a flowchart of a method for determining a target spreadsheet according to an embodiment of this application, including but not limited to the following steps: S301: Determine the text identifier corresponding to each of the n vehicle models to obtain n text identifiers.

[0051] In this embodiment, each text identifier is used to identify the feature code of the corresponding vehicle model. First, the core feature information of n vehicle models is determined, including key parameters such as the production year, power type, chassis model, body structure, and electronic control system version. Then, a unique feature code is generated based on these feature parameters. This code must be able to accurately distinguish the technical differences between different vehicle models. Subsequently, according to the preset encoding conversion rules, the feature codes of each vehicle model are converted into text identifiers that conform to the spreadsheet indexing specification. During the conversion process, it is necessary to ensure that the text identifiers have a uniform format and length, and contain key characters that can intuitively reflect the characteristics of the vehicle model. Finally, the above feature sorting, encoding generation, and text conversion operations are completed for all vehicle models, resulting in n text identifiers that correspond to each vehicle model and can effectively identify its feature code.

[0052] S302: Determine n vehicle model indices based on the n text identifiers.

[0053] In this implementation, the format specifications and construction standards of the spreadsheet index are first defined to ensure that the index is unique, readable, and searchable. Then, the text identifier corresponding to each vehicle model is used as the basic material and is processed in a structured manner according to the preset index generation rules. For example, the text identifier is standardized in format, redundant characters are removed, character length and arrangement are unified, or hierarchical identifiers are added in combination with the classification attributes of the vehicle model. Next, the processed text identifier is assigned a corresponding index number or hierarchical label so that each vehicle model index can correspond one-to-one with the original text identifier and can be directly associated with the feature coding information of the vehicle model. Finally, all the processed vehicle model identifier information is summarized and organized to form n vehicle model indexes that meet the requirements of the spreadsheet index row construction.

[0054] S303: Determine k language indexes based on the k preset language categories.

[0055] In this implementation, the construction rules and format requirements of the spreadsheet index are first clarified to ensure that the index is concise, unique, and easily identifiable. Then, the k preset language types are standardized and sorted out, clarifying the official names, usage areas, and other core attributes of each language. Next, each language type is converted into a corresponding index identifier according to the preset encoding rules. During the conversion process, language name abbreviations, serial number encoding, or hierarchical classification can be used to ensure that the indexes of different language types are not duplicated, while intuitively reflecting the characteristics of the language type. Then, the generated index is format-validated to ensure that it conforms to the layout specifications of spreadsheet column indexes and avoids problems such as format confusion or unrecognizable information. Finally, all the validated language identifier information is summarized and organized to form a k language type index that corresponds one-to-one with the k preset language types.

[0056] S304: Determine the vehicle index row based on the n vehicle indexes, and determine the language index column based on the k language indexes.

[0057] In this implementation, the generated n vehicle model indexes are arranged in an orderly manner according to a preset sorting rule. The sorting criteria can be determined by combining attributes such as vehicle brand affiliation, launch date, and technical classification to ensure that the vehicle model identifiers within the index rows have a clear logical order. Then, the arranged n vehicle model indexes are sequentially filled into the first row or a specified row area of ​​the spreadsheet to form a vehicle model index row that can cover all vehicle models. This row serves as the horizontal core identifier dimension of the spreadsheet and can be directly associated with the extensible markup language file information of the corresponding vehicle model in the subsequent data area. At the same time, the k language type indexes are organized according to a unified sorting standard. The sorting method can refer to factors such as the frequency of language use, international universality, or target market area division. Subsequently, the organized k language type indexes are sequentially filled into the first column or a specified column area of ​​the spreadsheet to form a language type index column that can cover all preset language types. This column serves as the vertical core identifier dimension of the spreadsheet and can work together with the vehicle model index row to jointly build the basic framework of the spreadsheet, providing clear dimensional guidance for the construction of the subsequent n rows and k columns of data area and the filling of file information.

[0058] S305: Determine an n-row, k-column data area based on the n×k Extensible Markup Language files.

[0059] In this embodiment, each row corresponds to a vehicle model and k extensible markup language files for that vehicle model under the k preset language categories, and each column corresponds to a preset language category and n extensible markup language files corresponding to the n vehicle models under that preset language category.

[0060] First, all Extensible Markup Language (XML) files are categorized and organized according to their respective vehicle models and the corresponding preset language types, clearly defining the vehicle model affiliation and language type for each file. Then, based on the dimensional framework of the constructed vehicle model index rows and language type index columns, a cell range is defined in the spreadsheet that perfectly matches the number of vehicle model indexes and the number of language type indexes. The number of rows in this range is consistent with the number of vehicle models, and the number of columns is consistent with the number of preset language types. Subsequently, following the rule of one row corresponding to one vehicle model, all XML files for each vehicle model under all preset language types are sequentially filled into the cells of the corresponding row for that vehicle model. At the same time, following the requirement of one column corresponding to one preset language type, it is ensured that all cells in the column are filled with XML files for all vehicle models under the corresponding language type. The final n-row k-column data area can clearly establish the correspondence between vehicle model language types and XML files.

[0061] S306: Determine the first target spreadsheet based on the vehicle type index row, the language type index column, and the n rows and k columns data area.

[0062] In this implementation, the vehicle model index row is first used as the horizontal core identifier dimension of the table and fixed in a designated row position according to a preset sorting logic. Then, the language type index column is used as the vertical core identifier dimension and fixed in a designated column position, forming an intersecting coordinate system. Subsequently, the n-row, k-column data area is precisely embedded into this coordinate system, ensuring that each row of the data area is fully aligned with the corresponding vehicle model identifier in the vehicle model index row and each column of the data area is fully matched with the corresponding language identifier in the language type index column. Next, the table format is standardized, including adjusting the row height and column width of the cells, setting the distinction style between the index area and the data area, and standardizing the presentation format of the file information. Finally, the overall structure of the table and the data correspondence are fully verified to confirm that there are no misalignments or omissions in the vehicle model index, language type index, and file information in the data area. Finally, the data is integrated to form a first target spreadsheet with a clear structure and rigorous logic.

[0063] As can be seen, by configuring a unique text identifier for each vehicle model and converting it into a vehicle model index, a precise vehicle model identification dimension is constructed for the spreadsheet, enabling rapid differentiation of the characteristic information of different vehicle models. Combined with a language type index generated from preset language types, a clear language classification dimension is formed. The vehicle model index rows and language type index columns built by combining the two provide a structured framework for the subsequent construction of the data area. Based on this framework, n×k Extensible Markup Language (XML) files are orderly filled into the n-row k-column data area, realizing a two-way precise association between vehicle models and language types. This allows each row to fully present the various language versions of XML files for a single vehicle model, and each column to systematically collect all vehicle model files for a single language type. Finally, the first target spreadsheet formed by integrating all parts has a clear structure and rigorous logic, facilitating rapid retrieval and location of XML files for any vehicle model and any language version, thus improving file management efficiency.

[0064] Please see Figure 4 , Figure 4 This is a flowchart illustrating how to locate Extensible Markup Language (XML) files according to an embodiment of this application, including but not limited to the following steps: S401: Obtain the Extensible Markup Language (EXPLAIN) file extraction command for the target language of the target vehicle.

[0065] In this embodiment, the instruction for extracting Extensible Markup Language (XML) files for the target vehicle in a compatible target language guides the vehicle diagnostic system to retrieve XML files that meet specific conditions from a pre-built first target spreadsheet. This instruction must contain two types of key information: one is the precise identification information of the target vehicle, specifically covering characteristic parameters that uniquely identify its model, such as brand, model, production year, and chassis number; the other is the explicit requirement for the target language, i.e., the language type corresponding to the required file. Simultaneously, the instruction must also specify the file extraction operation rules, including the search path, matching priority, and result verification standards, ensuring that the vehicle diagnostic system can quickly locate the text identifier corresponding to the target vehicle and the index column corresponding to the target language according to the instruction requirements, thereby accurately extracting the compatible XML file.

[0066] S402: Determine the target vehicle model corresponding to the target vehicle.

[0067] In this embodiment, the specific vehicle model corresponding to the target vehicle can be determined based on the core characteristic information such as the brand, model, production year, and technical configuration of the target vehicle.

[0068] S403: Determine the text identifier corresponding to the target vehicle based on the target vehicle model, and obtain the target text identifier.

[0069] In this embodiment, the core feature information corresponding to the target vehicle model is first determined, including key parameters such as the production year, power type, chassis model, body structure, and electronic control system version of the target vehicle model. Then, a unique feature code is generated based on these feature parameters. Subsequently, the feature code of the target vehicle model is converted into a text identifier that conforms to the spreadsheet index specification according to the preset encoding conversion rules, thereby obtaining the target text identifier.

[0070] S404: If the first target spreadsheet includes the target text identifier, then based on the target text identifier, extract the Extensible Markup Language (XML) file corresponding to the target vehicle and adapted to the target language from the first target spreadsheet to obtain the first target XML file.

[0071] In this embodiment, if the first target spreadsheet includes the target text identifier, an Extensible Markup Language (XML) file corresponding to the target vehicle and adapted to the target language type is extracted from the first target spreadsheet based on the target text identifier to obtain the first target XML file. First, a database of one-to-one correspondences between text identifiers and vehicle models established for all vehicle models is retrieved. The identified target vehicle model is precisely matched with the vehicle model entries in the database to filter out the unique identifier information corresponding to the target vehicle model, i.e., the target text identifier. This identifier is the core positioning basis for the target vehicle model in the first target spreadsheet. Then, it is checked whether the vehicle model index row of the first target spreadsheet contains the target text identifier. If the check result is yes, the target text identifier is used as the horizontal positioning coordinate to lock the entire row of data corresponding to the target vehicle model in the table. Then, the target language type is used as the vertical positioning coordinate to match the corresponding language type index column in the table. Through the cross-positioning of the horizontal and vertical coordinates, the corresponding cell is found. This cell stores information related to the XML file adapted to the target vehicle and meeting the target language type requirements. Finally, the corresponding file is extracted from this cell to obtain the first target XML file.

[0072] Please see Figure 5 , Figure 5 This is another flowchart for finding Extensible Markup Language (XML) files provided in this application, including but not limited to the following steps: S501: If the first target spreadsheet does not include the target text identifier, then obtain the diagnostic dataset corresponding to the target vehicle model from the diagnostic database to obtain the target diagnostic dataset.

[0073] In this embodiment, when the target text identifier corresponding to the target vehicle is not found in the vehicle model index row of the first target spreadsheet, it indicates that the first target spreadsheet does not yet store the Extensible Markup Language file that is compatible with the target language for the target vehicle model. At this time, the backup acquisition process needs to be started to retrieve the diagnostic dataset that is completely matched with the target vehicle model from the pre-built diagnostic database. The diagnostic dataset contains complete diagnostic-related data for the target vehicle model.

[0074] S502: Decompress the target diagnostic dataset to obtain the target diagnostic dataset.

[0075] In this embodiment, since the datasets stored in the diagnostic database are usually in compressed format, the purpose is to save storage resources and improve transmission efficiency. Decompression can restore the complete and directly editable target diagnostic dataset, eliminating the obstruction of the compression format to subsequent language conversion, encapsulation and other operations, and ensuring that the data can be read and processed normally.

[0076] S503: Perform language-text conversion on the target diagnostic dataset based on the target language type to obtain a diagnostic dataset corresponding to the target language type.

[0077] In this embodiment, based on the preset target language, the decompressed target diagnostic dataset is converted into language text. The conversion process requires the use of translation tools adapted to the vehicle diagnostic field, combined with a pre-built diagnostic terminology database, to accurately convert all text content in the dataset into the target language, while ensuring that the format and values ​​of non-text data are not affected, and finally generating diagnostic data that is completely matched with the target language.

[0078] S504: Determine the Extensible Markup Language (XML) encapsulation format corresponding to the target language type to obtain the target XML encapsulation format.

[0079] In this embodiment, by combining the text encoding characteristics, grammatical expression norms, and storage and parsing requirements of the target language, the core elements such as label naming rules, data node hierarchy division, text encoding standards, and attribute information settings are clarified. An extensible markup language encapsulation format that conforms to the general grammatical standards of extensible markup language and can adapt to the text storage and parsing requirements of the target language is determined, thereby obtaining the target extensible markup language encapsulation format.

[0080] S505: Based on the target extensible markup language encapsulation format, encapsulate the diagnostic dataset corresponding to the target language type to obtain a second extensible markup language file that corresponds to the target vehicle and is adapted to the target language type.

[0081] In this embodiment, the target language diagnostic dataset is structurally encapsulated according to the determined target extensible markup language encapsulation format. The text content and non-text content in the dataset are filled into the corresponding markup nodes. Attribute information such as vehicle model code, file version, and generation time are added to each data node. After filling, the data is integrated and verified according to the syntax rules of extensible markup language. After confirming that there are no syntax errors and no data omissions, a second extensible markup language file that corresponds to the target vehicle and is adapted to the target language is generated.

[0082] As can be seen, when the first target spreadsheet does not contain the text identifier corresponding to the target vehicle model, and it is impossible to directly extract the Scalable Markup Language (SML) file adapted to the target language, a complete backup solution for file generation can be formed by retrieving the diagnostic dataset corresponding to the target vehicle model from the diagnostic database and initiating the subsequent processing flow. This effectively avoids the problem of file extraction failure due to missing spreadsheet data, ensuring the continuity and integrity of automotive diagnostic data services. Decompressing the target diagnostic dataset restores the original editable data, laying the foundation for subsequent operations. The text conversion work based on the target language ensures that the generated dataset is adapted to the specific language environment, meeting the usage needs of users in different regions. The SML encapsulation format determined by the characteristics of the target language not only conforms to the general syntax standard but also adapts to the storage and parsing requirements of the language text. The final encapsulated second SML file can accurately match the dual needs of the target vehicle and the target language.

[0083] Please see Figure 6 , Figure 6 This is another flowchart for determining a target spreadsheet provided in this application, including but not limited to the following steps: S601: Determine k-1 preset language types other than the target language type from the k preset language types.

[0084] In this embodiment, among the pre-set k preset language types, the target language types for which the files have been generated are excluded, and the remaining k-1 preset language types are selected to identify other language types that need to be adapted to the target vehicle model.

[0085] S602: Determine the extensible markup language files that are compatible with the k-1 preset language types corresponding to the target vehicle model, and obtain k-1 extensible markup language files.

[0086] In this embodiment, based on the extensible markup language encapsulation format previously defined for k-1 preset language types, the decompressed target diagnostic dataset is sequentially subjected to text conversion and format encapsulation operations in the corresponding languages ​​to generate extensible markup language files for the target vehicle model that are compatible with these k-1 preset language types, and finally, k-1 extensible markup language files are obtained.

[0087] S603: Based on the k-1 extensible markup language files and the second extensible markup language file, adjust the n-row k-column data area to obtain an n+1-row k-column data area.

[0088] In this embodiment, the generated k-1 Extensible Markup Language (EXPLAIN) files are integrated with the second EXPLAIN file to form a complete row of data corresponding to the target vehicle model. This row of data is then added to the end of the original n-row k-column data area, increasing the number of rows in the data area from n to n+1, while keeping the number of columns unchanged at k, resulting in an updated n+1-row k-column data area.

[0089] S604: Determine the target vehicle model index based on the target text identifier.

[0090] In this embodiment, following the unified rules for constructing vehicle model indexes, the target text identifier corresponding to the target vehicle model is converted into a target vehicle model index that conforms to the spreadsheet index specification, ensuring that the format and encoding logic of the index are consistent with the original n vehicle model indexes.

[0091] S605: Adjust the vehicle index row based on the target vehicle index to obtain the target vehicle index row.

[0092] In this embodiment, the target vehicle index row includes the n vehicle indexes and the target vehicle index.

[0093] The newly generated target vehicle index is added to the end of the original vehicle index row, so that the expanded target vehicle index row contains the original n vehicle indexes and the newly added target vehicle index. The length of the index row is updated accordingly to ensure that the identifier of the index row matches the number of rows in the expanded data area.

[0094] S606: Determine the second target spreadsheet based on the target vehicle index row, the language index column, and the n+1 row k column data area.

[0095] In this embodiment, the updated target vehicle index row, the unadjusted language index column, and the expanded n+1 row and k column data area are organically integrated. The row height, column width, area style, and data presentation format are uniformly adjusted according to the original table format specifications, and finally a second target spreadsheet containing the full language version file information of the target vehicle is formed.

[0096] As can be seen, after generating the second extensible markup language file adapted to the target vehicle model and target language, further supplementing the vehicle model with files adapted to the remaining k-1 preset language types can form a complete extensible markup language file system covering all k language types for the target vehicle model. This avoids repeated execution of the file generation process and improves file retrieval efficiency. Based on these full-language version files, the original data area is adjusted to obtain an n+1 row k column data area. At the same time, the target vehicle model index is included in the vehicle model index row, which enables the standardized collection of target vehicle model data in the spreadsheet, expanding the vehicle model coverage of the spreadsheet. Finally, the updated index rows, the original language type index columns, and the expanded data area are integrated to form the second target spreadsheet. This maintains the structured and standardized framework of the original spreadsheet while realizing dynamic data supplementation and improvement, ensuring the spreadsheet's full coverage of vehicle models and language types.

[0097] In summary, implementing the embodiments of the present invention has the following beneficial effects: As can be seen, the Extensible Markup Language (XML) file storage method described in this embodiment of the invention first obtains XML file storage instructions for n vehicle models and k preset language types. Then, it retrieves n diagnostic datasets corresponding to the n vehicle models from a diagnostic database. Next, based on the n diagnostic datasets, it determines the XML files corresponding to the k preset language types, resulting in n×k XML files. Finally, it determines a first target spreadsheet based on the n×k XML files, which is used to partition and store the n×k XML files. This embodiment of the invention improves the efficiency of managing vehicle diagnostic data.

[0098] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of an extensible markup language file storage device provided in an embodiment of this application. The extensible markup language file storage device 700 includes: an acquisition unit 701 and a processing unit 702; The acquisition unit 701 is used to acquire an extensible markup language file storage instruction for n vehicle models that are compatible with k preset language types; n is an integer greater than 1, k is an integer greater than 1, and each vehicle model corresponds to k preset language types. The processing unit 702 is used to obtain n diagnostic datasets corresponding to the n vehicle models from the diagnostic database; the diagnostic database pre-stores multiple diagnostic datasets, each diagnostic dataset corresponding to a vehicle model. Based on the n diagnostic datasets, the k preset language types are determined to produce n×k extensible markup language files; each vehicle model corresponds to k extensible markup language files. A first target spreadsheet is determined based on the n×k Extensible Markup Language (XML) files; the first target spreadsheet is used to partition and store the n×k XML files.

[0099] In some possible implementations, in determining the Extensible Markup Language (Extreme Markup Language) files corresponding to the k preset language categories based on the n diagnostic datasets, to obtain n×k Extreme Markup Language (Extreme Markup Language) files, the processing unit 702 is specifically used for: The first diagnostic dataset is decompressed to obtain the first diagnostic dataset; the first diagnostic dataset is any one of the n diagnostic datasets. Based on the k preset language categories, the first diagnostic dataset is converted into language text to obtain k diagnostic datasets; each diagnostic dataset corresponds to a preset language category. Determine the Extensible Markup Language (Extreme Markup Language) encapsulation format corresponding to each of the k preset language types to obtain k Extreme Markup Language (Extreme Markup Language) encapsulation formats; The k diagnostic datasets are encapsulated using the k Extensible Markup Language (XML) encapsulation formats to obtain the k XML files corresponding to the first diagnostic dataset.

[0100] In some possible implementations, in determining the first target spreadsheet based on the n×k Extensible Markup Language files, processing unit 702 is specifically configured to: Determine the text identifier corresponding to each of the n vehicle models to obtain n text identifiers; each text identifier is used to identify the feature code of the corresponding vehicle model. n vehicle model indices are determined based on the n text identifiers; Based on the k preset language categories, determine the k language category indexes; The vehicle index rows are determined based on the n vehicle indexes, and the language index columns are determined based on the k language indexes. Based on the n×k extensible markup language files, an n-row k-column data area is determined; each row corresponds to a vehicle model and k extensible markup language files for that vehicle model under the k preset language categories, and each column corresponds to a preset language category and n extensible markup language files corresponding to the n vehicle models under that preset language category; The first target spreadsheet is determined based on the vehicle type index row, the language type index column, and the n-row k-column data area.

[0101] In some possible implementations, the processing unit 702 is further specifically used for: Obtain instructions for extracting Extensible Markup Language (EXPLAIN) files that are compatible with the target language of the target vehicle. Determine the target vehicle model corresponding to the target vehicle; Based on the target vehicle model, determine the text identifier corresponding to the target vehicle to obtain the target text identifier; If the first target spreadsheet includes the target text identifier, then an Extensible Markup Language (XML) file corresponding to the target vehicle and adapted to the target language type is extracted from the first target spreadsheet based on the target text identifier to obtain the first target XML file.

[0102] In some possible implementations, the processing unit 702 is further specifically used for: If the first target spreadsheet does not include the target text identifier, then the diagnostic dataset corresponding to the target vehicle model is obtained from the diagnostic database to obtain the target diagnostic dataset; The target diagnostic dataset is decompressed to obtain the target diagnostic dataset; Based on the target language type, the target diagnostic dataset is converted into language text to obtain a diagnostic dataset corresponding to the target language type; Determine the Extensible Markup Language (XML) encapsulation format corresponding to the target language type to obtain the target XML encapsulation format; Based on the target extensible markup language encapsulation format, the diagnostic dataset corresponding to the target language type is encapsulated to obtain a second extensible markup language file that corresponds to the target vehicle and is adapted to the target language type.

[0103] In some possible implementations, after encapsulating the diagnostic dataset corresponding to the target language type based on the target extensible markup language encapsulation format to obtain a second extensible markup language file corresponding to the target vehicle and adapted to the target language type, the processing unit 702 is specifically used for: Determine k-1 preset language types from the k preset language types, excluding the target language type; Determine the extensible markup language files that are compatible with the k-1 preset language types corresponding to the target vehicle model, and obtain k-1 extensible markup language files; Based on the k-1 Extensible Markup Language (XML) files and the second XML file, the n-row k-column data area is adjusted to obtain an n+1-row k-column data area; The target vehicle index is determined based on the target text identifier; The vehicle index row is adjusted based on the target vehicle index to obtain the target vehicle index row; the target vehicle index row includes the n vehicle indices and the target vehicle index. The second target spreadsheet is determined based on the target vehicle index row, the language index column, and the n+1 row and k column data area.

[0104] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 8 As shown, the electronic device 800 includes a transceiver 801, a processor 802, and a memory 803. These are connected via a bus 804. The memory 803 stores computer programs and data, and the transceiver 801 can transmit data stored in the memory 803 to the processor 802. The program includes instructions for performing the following steps: Retrieve instructions for storing Extensible Markup Language (Extreme Markup Language) files that adapt to k preset language types for n vehicle models; n is an integer greater than 1, k is an integer greater than 1, and each vehicle model corresponds to k preset language types; Obtain n diagnostic datasets corresponding to the n vehicle models from the diagnostic database; the diagnostic database pre-stores multiple diagnostic datasets, each diagnostic dataset corresponding to one vehicle model; Based on the n diagnostic datasets, the k preset language types are determined to produce n×k extensible markup language files; each vehicle model corresponds to k extensible markup language files. A first target spreadsheet is determined based on the n×k Extensible Markup Language (XML) files; the first target spreadsheet is used to partition and store the n×k XML files.

[0105] In some possible implementations, in determining the Extensible Markup Language (Extreme Markup Language) files corresponding to the k preset language categories based on the n diagnostic datasets, to obtain n×k Extreme Markup Language files, the above procedure includes instructions for performing the following steps: The first diagnostic dataset is decompressed to obtain the first diagnostic dataset; the first diagnostic dataset is any one of the n diagnostic datasets. Based on the k preset language categories, the first diagnostic dataset is converted into language text to obtain k diagnostic datasets; each diagnostic dataset corresponds to a preset language category. Determine the Extensible Markup Language (Extreme Markup Language) encapsulation format corresponding to each of the k preset language types to obtain k Extreme Markup Language (Extreme Markup Language) encapsulation formats; The k diagnostic datasets are encapsulated using the k Extensible Markup Language (XML) encapsulation formats to obtain the k XML files corresponding to the first diagnostic dataset.

[0106] In some possible implementations, the above procedure includes instructions for performing the following steps in determining the first target spreadsheet based on the n×k Extensible Markup Language files: Determine the text identifier corresponding to each of the n vehicle models to obtain n text identifiers; each text identifier is used to identify the feature code of the corresponding vehicle model. n vehicle model indices are determined based on the n text identifiers; Based on the k preset language categories, determine the k language category indexes; The vehicle index rows are determined based on the n vehicle indexes, and the language index columns are determined based on the k language indexes. Based on the n×k extensible markup language files, an n-row k-column data area is determined; each row corresponds to a vehicle model and k extensible markup language files for that vehicle model under the k preset language categories, and each column corresponds to a preset language category and n extensible markup language files corresponding to the n vehicle models under that preset language category; The first target spreadsheet is determined based on the vehicle type index row, the language type index column, and the n-row k-column data area.

[0107] In some possible implementations, the above procedure includes instructions for performing the following steps: Obtain instructions for extracting Extensible Markup Language (EXPLAIN) files that are compatible with the target language of the target vehicle. Determine the target vehicle model corresponding to the target vehicle; Based on the target vehicle model, determine the text identifier corresponding to the target vehicle to obtain the target text identifier; If the first target spreadsheet includes the target text identifier, then an Extensible Markup Language (XML) file corresponding to the target vehicle and adapted to the target language type is extracted from the first target spreadsheet based on the target text identifier to obtain the first target XML file.

[0108] In some possible implementations, the above procedure includes instructions for performing the following steps: If the first target spreadsheet does not include the target text identifier, then the diagnostic dataset corresponding to the target vehicle model is obtained from the diagnostic database to obtain the target diagnostic dataset; The target diagnostic dataset is decompressed to obtain the target diagnostic dataset; Based on the target language type, the target diagnostic dataset is converted into language text to obtain a diagnostic dataset corresponding to the target language type; Determine the Extensible Markup Language (XML) encapsulation format corresponding to the target language type to obtain the target XML encapsulation format; Based on the target extensible markup language encapsulation format, the diagnostic dataset corresponding to the target language type is encapsulated to obtain a second extensible markup language file that corresponds to the target vehicle and is adapted to the target language type.

[0109] In some possible implementations, after encapsulating the diagnostic dataset corresponding to the target language type based on the target extensible markup language encapsulation format to obtain a second extensible markup language file corresponding to the target vehicle and adapted to the target language type, the above program includes instructions for performing the following steps: Determine k-1 preset language types from the k preset language types, excluding the target language type; Determine the extensible markup language files that are compatible with the k-1 preset language types corresponding to the target vehicle model, and obtain k-1 extensible markup language files; Based on the k-1 Extensible Markup Language (XML) files and the second XML file, the n-row k-column data area is adjusted to obtain an n+1-row k-column data area; The target vehicle index is determined based on the target text identifier; The vehicle index row is adjusted based on the target vehicle index to obtain the target vehicle index row; the target vehicle index row includes the n vehicle indices and the target vehicle index. The second target spreadsheet is determined based on the target vehicle index row, the language index column, and the n+1 row and k column data area.

[0110] It should be understood that the electronic devices mentioned in this application may include smartphones (such as Android phones, iOS phones, Windows Phones, etc.), tablets, PDAs, laptops, mobile internet devices (MIDs) or wearable devices, servers, edge computing nodes, etc. The above-mentioned electronic devices are merely examples and not exhaustive, and include, but are not limited to, the electronic devices described above.

[0111] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor to implement some or all of the steps of any of the methods described in the above method embodiments.

[0112] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments.

[0113] It should be noted that, for the sake of simplicity, the aforementioned methods are described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are optional, and the actions and modules involved are not necessarily essential to this application.

[0114] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0115] In the several embodiments provided in this application, it should be understood that the disclosed apparatus 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, n units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical or other forms.

[0116] 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 n network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0117] Furthermore, the functional units in the various embodiments of this application 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 program module.

[0118] If the integrated unit is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, 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 memory 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 this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0119] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage device, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0120] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The above description of the embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for storing Extensible Markup Language (Extreme Markup Language) files, characterized in that, include: Retrieve instructions for storing Extensible Markup Language (Extreme Markup Language) files that adapt to k preset language types for n vehicle models; n is an integer greater than 1, k is an integer greater than 1, and each vehicle model corresponds to k preset language types; Obtain n diagnostic datasets corresponding to the n vehicle models from the diagnostic database; the diagnostic database pre-stores multiple diagnostic datasets, each diagnostic dataset corresponding to one vehicle model; Based on the n diagnostic datasets, the k preset language types are determined to produce n×k extensible markup language files; each vehicle model corresponds to k extensible markup language files. A first target spreadsheet is determined based on the n×k Extensible Markup Language (XML) files; the first target spreadsheet is used to partition and store the n×k XML files.

2. The method as described in claim 1, characterized in that, Each of the n diagnostic datasets is a compressed diagnostic dataset. The step of determining the Extensible Markup Language (Extreme Markup Language) files corresponding to the k preset language types based on the n diagnostic datasets yields n×k Extreme Markup Language files, including: The first diagnostic dataset is decompressed to obtain the first diagnostic dataset; the first diagnostic dataset is any one of the n diagnostic datasets. Based on the k preset language categories, the first diagnostic dataset is converted into language text to obtain k diagnostic datasets; each diagnostic dataset corresponds to a preset language category. Determine the Extensible Markup Language (Extreme Markup Language) encapsulation format corresponding to each of the k preset language types to obtain k Extreme Markup Language (Extreme Markup Language) encapsulation formats; The k diagnostic datasets are encapsulated using the k Extensible Markup Language (XML) encapsulation formats to obtain the k XML files corresponding to the first diagnostic dataset.

3. The method as described in claim 2, characterized in that, The step of determining the first target spreadsheet based on the n×k Extensible Markup Language files includes: Determine the text identifier corresponding to each of the n vehicle models to obtain n text identifiers; each text identifier is used to identify the feature code of the corresponding vehicle model. n vehicle model indices are determined based on the n text identifiers; Based on the k preset language categories, determine the k language category indexes; The vehicle index rows are determined based on the n vehicle indexes, and the language index columns are determined based on the k language indexes. Based on the n×k extensible markup language files, an n-row k-column data area is determined; each row corresponds to a vehicle model and k extensible markup language files for that vehicle model under the k preset language categories, and each column corresponds to a preset language category and n extensible markup language files corresponding to the n vehicle models under that preset language category; The first target spreadsheet is determined based on the vehicle type index row, the language type index column, and the n-row k-column data area.

4. The method as described in claim 3, characterized in that, The method further includes: Obtain instructions for extracting Extensible Markup Language (EXPLAIN) files that are compatible with the target language of the target vehicle. Determine the target vehicle model corresponding to the target vehicle; Based on the target vehicle model, determine the text identifier corresponding to the target vehicle to obtain the target text identifier; If the first target spreadsheet includes the target text identifier, then an Extensible Markup Language (XML) file corresponding to the target vehicle and adapted to the target language type is extracted from the first target spreadsheet based on the target text identifier to obtain the first target XML file.

5. The method as described in claim 4, characterized in that, The method further includes: If the first target spreadsheet does not include the target text identifier, then the diagnostic dataset corresponding to the target vehicle model is obtained from the diagnostic database to obtain the target diagnostic dataset; The target diagnostic dataset is decompressed to obtain the target diagnostic dataset; Based on the target language type, the target diagnostic dataset is converted into language text to obtain a diagnostic dataset corresponding to the target language type; Determine the Extensible Markup Language (XML) encapsulation format corresponding to the target language type to obtain the target XML encapsulation format; Based on the target extensible markup language encapsulation format, the diagnostic dataset corresponding to the target language type is encapsulated to obtain a second extensible markup language file that corresponds to the target vehicle and is adapted to the target language type.

6. The method as described in claim 5, characterized in that, After encapsulating the diagnostic dataset corresponding to the target language type based on the target extensible markup language encapsulation format to obtain a second extensible markup language file corresponding to the target vehicle and adapted to the target language type, the method further includes: Determine k-1 preset language types from the k preset language types, excluding the target language type; Determine the extensible markup language files that are compatible with the k-1 preset language types corresponding to the target vehicle model, and obtain k-1 extensible markup language files; Based on the k-1 Extensible Markup Language (XML) files and the second XML file, the n-row k-column data area is adjusted to obtain an n+1-row k-column data area; The target vehicle index is determined based on the target text identifier; The vehicle index row is adjusted based on the target vehicle index to obtain the target vehicle index row; the target vehicle index row includes the n vehicle indices and the target vehicle index. The second target spreadsheet is determined based on the target vehicle index row, the language index column, and the n+1 row and k column data area.

7. An extensible markup language file storage device, characterized in that, The device includes: an acquisition unit and a processing unit; The acquisition unit is used to acquire storage instructions for Extensible Markup Language (EXPLAIN) files that are adapted to k preset language types for n vehicle models; n is an integer greater than 1, k is an integer greater than 1, and each vehicle model corresponds to k preset language types. The processing unit is used to obtain n diagnostic datasets corresponding to the n vehicle models from the diagnostic database; the diagnostic database pre-stores multiple diagnostic datasets, each diagnostic dataset corresponding to one vehicle model. Based on the n diagnostic datasets, the k preset language types are determined to produce n×k extensible markup language files; each vehicle model corresponds to k extensible markup language files. A first target spreadsheet is determined based on the n×k Extensible Markup Language (XML) files; the first target spreadsheet is used to partition and store the n×k XML files.

8. An electronic device, characterized in that, The method includes a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the one or more programs include instructions for performing the steps of the method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is executed by a processor to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1-6.

Images