Icon-related XML format recognition method, icon format recognition method and server

Abstract

The invention discloses an icon-related XML format recognition method, an icon format recognition method and a server, and the method comprises the steps: obtaining an XML document according to an icon file path in an installation package, and extracting a tag name of a root element; when the tag name is identified as a vector graph type or an adaptive icon type, reading attribute information or child node information of a root element, and executing structural integrity verification; and finally determining the icon format type according to the structure verification result and the tag name. According to the method and the device, through a dual detection mechanism of extension shunting and content deep analysis, and in cooperation with a main and standby analysis fault-tolerant strategy, accurate identification in an environment without Android running is realized, the problem of misjudgment of an XML icon format is effectively solved, and the consistency of icon display is ensured.

Description

Technical Field

[0001] This invention relates to the field of mobile application data processing technology, and in particular to icon-related XML format recognition, icon format recognition methods, and servers. Background Technology

[0002] When extracting APK icons, the icons displayed in the cloud app store are inconsistent with the icons actually rendered on the user's terminal, thus affecting the user experience. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide an icon-related XML format recognition method and a server to achieve consistency in icon display between the server and the device.

[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A method for recognizing icon-related XML formats, applied to cloud servers, includes: Obtain the XML document based on the icon file path in the installation package, and retrieve the tag name of the root element of the XML document; When the label name is identified as a vector graphic type or an adaptive icon type, the attribute information or child node information of the root element is read, and the structure verification of the attribute information or child node information is performed. Based on the results of the structure verification and the recognition results of the label name, the final icon format type is determined and returned.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: The icon format recognition method is characterized by including the following steps: Get the file extension of the icon file in the installation package; If the file extension is an XML format suffix, then the steps in the above-mentioned icon-related XML format recognition method are executed. If the extension is not an XML format suffix, then the corresponding format verification process is performed based on the extension to obtain the recognition result; Based on the recognition results, the final icon format type is determined.

[0006] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A server, applied to a cloud server, includes a memory, a processor, and a computer program stored on the memory and running on the processor. When the processor executes the computer program, it implements the steps of the above-described icon-related XML format recognition method or the steps of the above-described icon format recognition method.

[0007] The beneficial effects of this invention are as follows: It constructs an icon parsing logic independent of the Android system on the cloud server side. First, it performs a rapid initial screening using the root element tag name, quickly distinguishing between vector graphics requiring special rendering logic and adaptive icons. Then, it introduces a structural verification mechanism to deeply examine attribute information or child node information, ensuring that the file not only nominally conforms to a certain format but is also complete and usable in content. This method, based on a combination of tag recognition and deep structural verification, can accurately distinguish different types of XML icon formats in the APK, fundamentally avoiding inconsistencies in icon rendering caused by format recognition errors, and effectively ensuring visual consistency between icons generated on the server side and icons rendered locally on the Android device. Attached Figure Description

[0008] Figure 1 A flowchart illustrating the steps of the icon-related XML format recognition method provided in this embodiment of the invention; Figure 2 A flowchart of the icon format recognition method provided in the embodiments of the present invention; Figure 3 A flowchart of XML deep analysis provided for embodiments of the present invention; Figure 4 This is a flowchart of primary / backup detection and fault tolerance provided in an embodiment of the present invention; Figure 5 This is a flowchart of abnormal state handling provided in an embodiment of the present invention; Figure 6 A flowchart of the format recognition state machine provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the server structure provided in an embodiment of the present invention. Detailed Implementation

[0009] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0010] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0011] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0012] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0013] In related technologies, during application distribution and management scenarios, to ensure users can intuitively verify the application's identity before downloading and installing, it's typically necessary to display the application icon from the APK file in the app store or management backend. However, these technologies lack effective methods for recognizing and parsing complex Android XML-formatted icons in a server-side environment. They cannot effectively distinguish and process Vector Drawables or Adaptive Icons, resulting in inconsistencies between the icons displayed on the server and those actually rendered on the terminal device, leading to a disjointed visual experience.

[0014] For example, Android devices (such as POS machines) can dynamically synthesize and correctly display XML-formatted icons based on the system runtime environment. However, when the APK is uploaded to a cloud server, the server lacks the Android Context environment and can only perform simple identification based on the file extension. This can cause the server to misinterpret complex XML icons as plain text files or fail to parse their layer structure, resulting in the icons displayed on the application details page being default images, blank, or incorrectly parsed images. Consequently, when users download the app on the POS terminal, the cloud-based icons they see are inconsistent with the icons displayed locally after installation. Furthermore, existing technologies lack a deep analysis mechanism for XML content, making the recognition service prone to crashes due to complex file structures or missing attributes.

[0015] To address the aforementioned problems, this application provides icon-related XML format recognition, an icon format recognition method, and a server. The icon-related XML format recognition method of this application is described in detail below.

[0016] The icon-related XML format recognition method in this application can be used for the automated parsing and management of APK application resources. The server in this application can be an application distribution platform, a mobile device management system (MDM), or a cloud application store server, such as a third-party application market backend server that provides application download services for POS terminals.

[0017] The following details the icon-related XML format recognition method of this invention, with reference to the appendix. Figure 1 This includes steps 110 to 140.

[0018] Step 110: Obtain the XML document based on the icon file path in the installation package, and get the tag name of the root element of the XML document.

[0019] The cloud server first locates the resource path within the installation package (APK) and reads the corresponding file stream. It then loads this file stream using an XML parser, constructs a document object model in memory, and extracts the top-level node of the document, i.e., the root element. Finally, it reads the tag name of this root element, which is the primary identifier for distinguishing XML resource types.

[0020] Step 120: When the label name is identified as a vector graphic type or an adaptive icon type, read the attribute information of the root element or the information of its child nodes.

[0021] Match the tag name obtained in step 110 with the preset resource standard keywords. If the tag name is <vector>If the label name is..., it will be identified as a vector graphics type; if the label name is... <adaptive-icon>If the icon matches, it is identified as an adaptive icon type. Once it is confirmed that it belongs to one of these two specific icon formats, the system will further delve into the attribute set defined inside the root element or the list of child nodes it contains, to prepare data for subsequent structural verification.

[0022] Step 130: Perform structural verification of attribute information or child node information.

[0023] For the tag names identified in step 120, perform a depth check. For vector graphics, focus on verifying the integrity of their drawing attributes; for adaptive icon types, focus on verifying the compliance of their layer structure. This step aims to exclude files that have correct tag names but missing or corrupted content.

[0024] Step 140: Based on the results of the structure verification and the recognition results of the label name, determine and return the final icon format type.

[0025] The system combines the results of label recognition and structure verification. If the label matches and the structure verification passes, the system outputs a specified format type (such as "Vector Drawable" or "Adaptive Icon"); if the structure verification fails, it is marked as a format error or downgraded.

[0026] This application constructs an icon parsing logic independent of the Android system on a cloud server. First, it performs a rapid initial screening using the root element tag name, quickly distinguishing between vector graphics requiring special rendering logic and adaptive icons. Then, it introduces a structural verification mechanism to deeply examine attribute information and child node information, ensuring that the file not only nominally conforms to a certain format but is also complete and usable in content. This method, combining tag recognition and deep structural verification, accurately distinguishes different types of XML icon formats in the APK, fundamentally avoiding icon rendering inconsistencies caused by format recognition errors, and effectively guaranteeing visual consistency between icons generated on the server and those rendered locally on the Android device.

[0027] In one embodiment of this application, the structural verification in step 130 specifically includes steps 131 to 132.

[0028] Step 131: When the tag name matches the identifier of the preset vector graphics type, check whether the root element's attribute information contains the viewport width and viewport height attributes.

[0029] The label name is the identifier of the preset vector graphic type. <vector>At that time, the system checks whether the viewport property exists in its property list. This property defines the size of the virtual canvas for vector graphics and is the basis for the rendering engine to perform coordinate mapping.

[0030] Step 132: If the viewport width and viewport height attributes are included, perform further element validation; if the viewport width and viewport height attributes are not included, mark the element as failing format validation.

[0031] If the viewport attribute is missing, the vector path data cannot be correctly parsed and scaled, and is therefore directly judged as an invalid format. If it exists, it proceeds to the next step for a deeper element content check.

[0032] In this way, a coordinate system-based verification mechanism for vector graphics was established. Viewport attributes serve as the baseline for vector drawing; the drawing of any path data depends on the coordinate space defined by this viewport. By prioritizing the verification of viewport attributes, non-compliant vector files can be quickly intercepted, preventing division by zero errors or coordinate overflows during subsequent complex path parsing calculations, thereby improving the system's efficiency and stability in parsing vector graphics.

[0033] In one embodiment of this application, after confirming the existence of the viewport attribute in step 132, the further element verification performed includes steps 133 to 134.

[0034] Step 133: Traverse the internal nodes of the root element and check if there are path elements used to define the shape of the graphic.

[0035] The system parses all child nodes under the root element and searches for the tag name. <path>Path elements are the core components of vector graphics that carry specific visual shapes.

[0036] Step 134: When a path element exists and the path data attribute of the path element is not empty, determine that the final icon format type is vector graphics.

[0037] Only <path>The tag itself is not enough; the system also needs to verify that the tag contains a pathData attribute and that its value is not empty. Only when valid path data is present is the XML file recognized as a valid vector graphics file, and the vector graphics type is returned as the recognition result.

[0038] This method enables the verification of the actual content of vector graphics. Path data is the specific instruction set for displaying vector icons. If a file only has a shell without path instructions, or if the path instructions are empty, a valid image cannot be rendered. By deeply verifying path elements and their data attributes, it ensures that the identified vector icon files contain actual renderable content, preventing the cloud server from generating blank or invalid icon resources and guaranteeing the display effect on the end user.

[0039] In one embodiment of this application, when the label name is identified as an adaptive icon type in step 120, the structure verification in step 130 specifically includes steps 135 to 136.

[0040] Step 135: When the label name matches the preset adaptive icon type identifier, check whether the child node information of the root element contains foreground and background elements.

[0041] The label name is the identifier of the preset vector graphic type. <adaptive-icon>At this time, the system traverses its child nodes to check if foreground and background layer labels exist. The specification for adaptive icons requires that the icon be separated into these two independent layers so that the system can apply the masking effect.

[0042] Step 136: If both foreground and background elements are present, perform further layer reference validation; if either foreground or background element is missing, mark it as a format validation failure.

[0043] The absence of any layer will prevent the adaptive icon from being synthesized. Subsequent content validity checks will only be performed when both layers are structurally complete.

[0044] In this way, a verification process was designed to address the unique layered structure of adaptive icons. Adaptive icons rely on the independent existence of the foreground and background to achieve parallax and masking effects. By forcibly checking the coexistence of foreground and background elements, incomplete icon files can be effectively eliminated, ensuring that the cloud server can obtain complete layer information. This provides the necessary structural foundation for subsequent layer overlay and cropping operations in simulating the Android system.

[0045] In one embodiment of this application, after confirming the integrity of the layer structure in step 136, the further layer reference verification performed includes step 137.

[0046] Step 137: Parse the attribute values ​​of the foreground and background elements, and verify whether the referenced resource format of the attribute values ​​is valid; when the referenced resource is valid, determine that the final icon format type is the adaptive icon type.

[0047] The system reads the `drawable` attribute values ​​from the foreground and background elements. It then verifies that these attribute values ​​conform to the syntax specifications for resource references (such as pointing to color values, image resources, or another Drawable XML). This step ensures that the layer not only exists but also actually references valid renderable content.

[0048] This method enables the validity check of the resource reference chain for adaptive icons. Since adaptive icons often nest references other resources, incorrect reference paths or invalid formats will lead to rendering failures. By parsing and verifying the validity of attribute values, it ensures that both the foreground and background layers of the icon can index the actual existing resource objects, thereby ensuring that the cloud server can correctly load and synthesize the final icon image, avoiding parsing interruptions caused by incorrect resource references.

[0049] In one embodiment of this application, a case is added where the label name identification in step 120 does not match, including steps 121 to 122.

[0050] Step 121: When the label name does not match the preset vector graphic type or adaptive icon type, mark it as a plain XML format.

[0051] If the root element tag is neither <vector>No <adaptive-icon>The system initially categorized it as ordinary XML.

[0052] Step 122: If the icon file in plain XML format conforms to the predefined XML syntax specification, then the final icon format type is determined to be plain XML type.

[0053] At this point, it is necessary to verify whether it is a syntactically valid XML file. If the syntax check passes, a plain XML type is returned. This ensures comprehensive identification, without overlooking other valid Android resource formats, enabling the system to perform basic processing on unknown or standard XML resources.

[0054] In this way, a fallback identification mechanism for non-specific formats was constructed. Within the Android ecosystem, there are various XML resource types, and not all XML is vector or adaptive icon. By classifying XML files that do not match specific characteristics as ordinary XML and verifying their syntactic validity, the system ensures that it will not report errors due to encountering unknown tags, but rather treats them as general resources. This improves the compatibility and coverage of the identification method and guarantees the continuity of business processes.

[0055] In one embodiment of this application, an exception handling mechanism is introduced in the execution structure verification in step 130, and steps 150 to 152 are also included.

[0056] Step 150: If a parsing exception or structure validation failure occurs while parsing the XML document, log the error.

[0057] In real-world engineering projects, XML files may cause parsers to crash due to transmission truncation or encoding issues. The system first catches these exceptions and logs detailed error information for traceability.

[0058] Step 151: Activate the fault tolerance mechanism and switch to the backup XML parser to reread the XML document.

[0059] The system activates a backup parsing scheme (such as using a more fault-tolerant third-party parsing library) and re-attempts to read the file stream.

[0060] Step 152: Execute again using the backup XML parser to identify whether the XML document belongs to the vector graphics type or the adaptive icon type based on the tag name.

[0061] Repeat the previous tag recognition and verification process using a backup parser, and try to obtain the correct file structure information under different parsing strategies.

[0062] In this way, a dual-parser fault-tolerant architecture was established. Different XML parsers have varying tolerances for malformed files or special characters. By automatically switching to a backup parser after the primary parser fails, the probability of the recognition task completely failing due to encoding problems or minor corruption of individual files is greatly reduced. This mechanism significantly enhances the system's robustness when processing massive amounts of APK files from diverse sources, ensuring high service availability.

[0063] In one embodiment of this application, a final fault-tolerant output strategy for step 153 is also included, which can be executed during structural verification in step 130.

[0064] Step 153: If the backup XML parser still cannot determine the icon format type after parsing, it returns the predefined default icon format type.

[0065] If the backup solution still fails, in order to ensure that the business process is not interrupted (for example, to prevent the entire APK parsing task from being suspended), the system will return a predefined default type (such as unknown format or default icon) so that the upper-layer application can display it as a fallback or mark it as pending manual review.

[0066] This approach establishes a safe landing strategy for the system. In extreme cases where all technical means fail to recognize the file format, the stability of the main program is ensured by returning the default type instead of throwing a fatal error. This allows the system to continue processing the next file in the queue, while providing a controllable degradation processing path for abnormal files, preventing a single point of failure from spreading to the entire service.

[0067] In one embodiment of this application, a method for recognizing the overall icon format based on extension splitting is provided, which includes the XML recognition logic of steps 110 to 140 above, and the method includes steps 210 to 240.

[0068] Step 210: Obtain the file extension of the icon file in the installation package.

[0069] The system extracts the name of the target icon file from the APK's file index and extracts its file extension.

[0070] Step 220: If the file extension is XML format, then execute the icon-related XML format recognition method as described in the previous embodiment.

[0071] When the file extension is .xml, the deep content analysis process is initiated, performing steps such as root element retrieval, tag recognition, and structure verification to distinguish between Vector, Adaptive, and ordinary XML tags.

[0072] Step 230: If the file extension is not an XML format suffix, then perform the corresponding format verification process based on the file extension to obtain the recognition result.

[0073] When the file extension is a bitmap format such as .png or .webp, the system does not perform XML parsing. Instead, it executes the corresponding format attribute verification process to check whether the file content conforms to the specification requirements of the format corresponding to that extension (e.g., whether the attribute verification passes), thereby confirming the file format.

[0074] Step 240: Determine the final icon format type based on the recognition results.

[0075] Whether it goes through the XML deep analysis branch or the bitmap extension verification branch, the final output is a unified format type identifier for use by downstream icon rendering or transcoding modules.

[0076] In this way, a complete two-level traffic separation and recognition framework was established. File extensions are used as a primary filter to separate complex XML processing logic from simple bitmap processing logic. For XML files, deep content analysis technology ensures accurate classification; for non-XML files, dual verification of content and extension is employed. This architecture design guarantees accurate recognition of complex Android XML icons while maintaining efficiency in processing traditional bitmap icons, achieving full coverage support for all mainstream icon formats within the APK and significantly improving the overall performance of the server-side icon extraction service.

[0077] In summary, this application effectively solves the technical challenge of accurately recognizing complex icon formats on cloud servers without an Android operating environment by constructing a dual detection mechanism based on extension-based traffic splitting and deep content verification. This method utilizes deep verification of key structures such as XML root elements, viewports, and layers to achieve accurate classification of Vector Drawable, AdaptiveIcon, and bitmap formats, ensuring a high degree of consistency between cloud display and terminal rendering effects. At the same time, combined with primary / backup parsing switching and anomaly degradation strategies, it significantly improves the robustness and business continuity of the system when handling abnormal files.

[0078] The following combination Figure 2 (Flowchart of icon format recognition method) Figure 3 (XML Deep Analysis Flowchart) Figure 4 (Primary / Backup Detection and Fault Tolerance Flowchart) Figure 5 (Flowchart for handling abnormal states) and Figure 6 (Format Recognition State Machine Flowchart), detailing the specific implementation logic of this invention step by step. Among them, Figure 6 It shows the complete state transition of the entire recognition process, which runs through all the steps below.

[0079] Step 1: File access and initial file extension splitting (corresponding to...) Figure 2 Steps S1 to S3 correspond to obtaining the extension of the icon file in the installation package in step 210 above.

[0080] The system first receives the file path of the icon to be identified. Before proceeding with deep parsing, extension detection is performed as the first-level filter. Based on the captured file extension, the processing flow is distributed to different detection channels: if the extension is .xml, it enters the XML detection branch; if the extension is .png, .webp, etc., it enters the respective format detection branch; if it is any other extension, it is marked as an unknown format to be processed.

[0081] Step 2: XML Environment Initialization and DOM Tree Construction (corresponding to...) Figure 2 In steps S4.1 to S4.2, and Figure 3 Steps S1 to S3 correspond to obtaining the XML document based on the icon file path in the installation package in step 110 above.

[0082] Upon entering the XML branch, the system creates a DocumentBuilder instance in the server-side Java environment. This parser reads the file stream and converts the XML text into an in-memory DOM (Document Object Model) tree structure. This process does not rely on the Android SDK's resource manager but uses standard Java XML processing capabilities, ensuring compatibility in a pure server-side environment.

[0083] Step 3: Root element extraction and type routing (corresponding) Figure 2 In steps S4.3 to S4.4, and Figure 3 Steps S4 to S6 correspond to obtaining the tag name of the root element of the XML document in step 110 above.

[0084] The system accesses the top-level node of the DOM tree and extracts the root element's tag name. Based on the tag name, logical routing is performed, further subdividing the XML file into different processing states: if the tag is `vector`, it enters the vector graphics analysis process; if the tag is `adaptive-icon`, it enters the adaptive icon analysis process; if it is another tag, it enters the normal XML analysis process. This process achieves initial type screening based on tag name.

[0085] Step 4: Vector Drawable Depth Verification (corresponding to...) Figure 3 (Steps S7.1 to S7.5) correspond to steps 120 to 130 above, where when the data is identified as a vector graphic type, attribute information is read and structural verification is performed.

[0086] For the `vector` tag, the system performs strict attribute checks. First, it verifies the existence of the `viewport` attribute to establish the coordinate system basis. Then, it traverses child nodes to find path elements and checks if the `pathData` attribute is not empty. Only when both the viewport definition and path data pass validation does the system confirm the file structure as valid.

[0087] Step 5: Adaptive Icon Hierarchy Validation (corresponding to...) Figure 3 In steps S8.1 to S8.5, corresponding to steps 120 to 130 above, when the icon is identified as an adaptive icon type, the child node information is read and the structure verification is performed.

[0088] For the `adaptive-icon` tag, the system checks its child node structure. It verifies whether it contains... <foreground>(Prospect) and <background>(Background) elements. Next, the drawable properties of these two elements are parsed to verify the validity of the referenced resource formats. By verifying layer integrity and resource reference validity, it is ensured that the icon can be correctly composited by the subsequent rendering engine.

[0089] Step 6: Validation of plain XML and bitmap formats (corresponding) Figure 3 In steps S9.1 to S9.3, and Figure 2 Steps S8 and S9 correspond to the format verification process based on the file extension in step 230 above.

[0090] For non-specific XML tags, the system checks whether they conform to the basic XML syntax specification and confirms them as ordinary XML tags. For .png or .webp files output from step 1, the system executes the corresponding format attribute validation process to check whether the file content conforms to the specification requirements of the format corresponding to the extension, in order to establish the PNG / WebP format identifier.

[0091] Step 7: Exception handling and hierarchical fault tolerance (corresponding to...) Figure 4 Full process and Figure 5 (Full process), corresponding to the fault tolerance mechanism executed during structural verification in step 130 above.

[0092] In any of the above detection steps (such as XML parsing interruption or structure verification failure), the system captures the exception and follows the procedure. Figure 5 The state machine logic is used for processing. If the exception is determined to be recoverable, a backup parser (such as SAX) is switched for retry; if the retry fails or the exception is unrecoverable, degradation processing is performed, the result is marked as an unknown format or the default icon type is returned, and an error log is recorded.

[0093] Step 8: Result Aggregation and Final Output (corresponding) Figure 2 In steps S11 to S12, and Figure 4 Steps S4, S8, and S12 correspond to the determination and return of the final icon format type in steps 140 and 240 above.

[0094] The system aggregates the output results from both the primary and backup detection methods. Regardless of the branch, a unified formatted recognition object is ultimately generated, containing a format type enumeration and necessary metadata. This result is returned to the caller to guide subsequent icon rendering, transcoding, or display logic.

[0095] In summary, this application constructs an icon recognition engine that integrates initial extension screening, in-depth content analysis, and intelligent fault tolerance. It can not only accurately distinguish standard Android XML icons (Vector / Adaptive), but also process bitmaps through a dual verification mechanism and utilize a robust exception recovery strategy to solve the technical challenge of inaccurate and unstable APK resource recognition by the server in an environment without Android.

[0096] Please refer to Figure 7 The present invention also provides a server 400, including a memory 401 and a processor 402, and a computer program stored on the memory 401 and running on the processor 402. When the processor 402 executes the computer program, it implements the various steps in the icon-related XML format recognition method or the various steps in the icon recognition method as described above.

[0097] The beneficial effects of the server of the present invention are the same as those of the method described above, and will not be repeated here.

[0098] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.< / background> < / foreground> < / vector> < / path> < / path> < / vector> < / vector>

Claims

1. A method for recognizing icon-related XML formats, applied to cloud servers, characterized in that... The method includes: Obtain the XML document based on the icon file path in the installation package, and retrieve the tag name of the root element of the XML document; When the label name is identified as a vector graphic type or an adaptive icon type, the attribute information of the root element or the child node information is read; Perform structural verification of the attribute information or child node information; Based on the results of the structure verification and the recognition results of the label name, the final icon format type is determined and returned.

2. The icon-related XML format recognition method according to claim 1, characterized in that, The step of determining and returning the final icon format type based on the results of the structure verification includes: When the label name matches the identifier of a preset vector graphic type, check whether the root element's attribute information includes viewport width and viewport height attributes. If the viewport width and viewport height attributes are included, further element validation is performed; If the viewport width and viewport height attributes are not included, the format validation is marked as failed.

3. The icon-related XML format recognition method according to claim 2, characterized in that, The further element verification includes: Traverse the internal nodes of the root element and check if there are path elements used to define the shape of the graphic; When the path element exists and the path data attribute of the path element is not empty, the final icon format type is determined to be a vector graphic type.

4. The icon-related XML format recognition method according to claim 1, characterized in that, The step of determining and returning the final icon format type based on the results of the structure verification includes: When the label name matches the identifier of the preset adaptive icon type, check whether the child node information of the root element contains foreground layer elements and background layer elements; If both the foreground and background elements are present, further layer reference verification is performed. If either the foreground layer element or the background layer element is missing, the format validation is marked as failed.

5. The icon-related XML format recognition method according to claim 4, characterized in that, The further layer reference verification includes: Parse the attribute values ​​of the foreground and background elements, and verify whether the resource reference format of the attribute values ​​is valid; When the referenced resource is valid, the final icon format type is determined to be an adaptive icon type.

6. The icon-related XML format recognition method according to claim 1, characterized in that, Also includes: When the label name does not match the preset vector graphic type or adaptive icon type, it is marked as a plain XML format; If the icon file in plain XML format conforms to the predefined XML syntax specification, then the final icon format type is determined to be plain XML type.

7. The icon-related XML format recognition method according to claim 1, characterized in that, Also includes: If a parsing exception occurs or the structure validation fails while parsing the XML document, an error log is recorded. Activate the fault tolerance mechanism and switch to the backup XML parser to reread the XML document; The backup XML parser is then used to re-execute the process to identify whether the XML document belongs to a vector graphics type or an adaptive icon type based on the tag name.

8. The method according to claim 7, characterized in that, Also includes: If the backup XML parser still cannot determine the icon format type after parsing, it returns the predefined default icon format type.

9. An icon format recognition method, characterized in that, Includes the following steps: Get the file extension of the icon file in the installation package; If the file extension is XML format, then the icon-related XML format recognition method as described in any one of claims 1-8 is executed; If the extension is not an XML format suffix, then the corresponding format verification process is performed based on the extension to obtain the recognition result; Based on the recognition results, the final icon format type is determined.

10. A server, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the icon-related XML format recognition method as described in any one of claims 1 to 8, or implements the steps of the icon format recognition method as described in claim 9.

Images