Container mirror image metadata analysis, editing and uploading method and system based on Web front end

Abstract

The invention discloses a container mirror image metadata analyzing, editing and uploading method and system based on a Web front end, and belongs to the technical field of computer software and containerization. The invention aims to solve the problems of network flow waste, large storage pressure and operation splitting caused by the fact that a complete Tar format file needs to be uploaded to a server for processing in a traditional scheme. According to the scheme, the OCI Tar format file selected by the user is directly analyzed at the browser end, the mirror image list is extracted and visually displayed, the user is supported to edit metadata such as mirror image names, labels and self-defined attributes on line, the mirror image is pushed to the remote warehouse through an incremental direct transmission mechanism after confirmation, and the uploading progress and the abnormal prompt are fed back in real time. The whole process does not need to be transferred by a server, so that the bandwidth and the storage overhead are remarkably reduced, the interaction efficiency and the user experience are improved, the lightweight and end-to-end container mirror image management capability is realized, and the method is suitable for DevOps platforms, private cloud environments and edge computing scenes.

Description

Technical Field

[0001] This invention relates to the field of computer software and containerization technology, and in particular to a method and system for parsing, editing and uploading container image metadata based on a web front-end. Background Technology

[0002] As a core infrastructure for modern application deployment, the efficiency of container image distribution and management directly impacts development and operation processes. Currently, the industry-standard operating procedure is as follows: first, the container image is packaged into a Tar format file conforming to the OCI (Open Container Initiative) specification using the `docker save` command; then, the Tar format file is uploaded completely to the server; and finally, the server-side processing program pushes it to the target container image repository.

[0003] However, this traditional method has significant technical drawbacks and wastes resources:

[0004] 1. Inefficient data transfer: Regardless of whether the final image repository requires all data layers, the process requires transferring the entire Tar format file (which is typically extremely large) from the user's end to the business server, resulting in unnecessary network traffic consumption. This problem is particularly pronounced for large images containing numerous algorithm dependencies or base layers (e.g., single images exceeding 10 GiB).

[0005] 2. Server resource consumption: The business server needs to receive and store the complete image Tar format file as a temporary file. This not only consumes a lot of disk storage space, but may also cause I / O bottlenecks due to concurrent uploads, increasing the server's maintenance burden and cost.

[0006] 3. Cumbersome and inflexible operation process: Existing technology separates the editing and modification of metadata (such as image name and tags) from image uploading into two independent steps. If users need to modify image attributes, they must do so through the Docker CLI tool before packaging, or through additional scripts after uploading to the server. It is impossible to conveniently preview and edit in a unified interface before transmission, and there is a lack of an integrated solution.

[0007] 4. Lack of Web Front-End Capabilities: Although web browsers have powerful local file processing capabilities (such as FileAPI and Streams API), existing technical solutions all rely on backend servers to parse complex OCI image formats (including parsing index.json, manifest files, and processing layered blob data), failing to utilize front-end technologies to achieve local parsing and preview, resulting in unnecessary network round trips and server computing pressure.

[0008] Therefore, there is an urgent need in this field for a new method and system that can directly parse and edit container image metadata in a web browser environment and efficiently and incrementally upload it to an image repository, in order to overcome the various drawbacks of the existing technologies. Summary of the Invention

[0009] The purpose of this invention is to solve the problems of network traffic waste, high server temporary storage pressure, fragmented operation process and low efficiency caused by the need to upload the complete container image Tar format file to the server before processing in the prior art. The invention provides an end-to-end method and system for directly completing container image metadata parsing, visual editing and incremental direct upload to the image repository in the web front end.

[0010] To achieve the above objectives, the present invention employs the following technical means:

[0011] A method for parsing, editing, and uploading container image metadata based on a web front-end includes the following steps:

[0012] Step S1: Web front-end parsing of container image OCI Tar format files. Users select OCI Tar format files that conform to the format through the browser file selection control. The page directly parses the OCI Tar to obtain a complete list of container images.

[0013] Step S2: Web front-end container manifest display and editing. The container image manifest list is displayed for users to preview through rendering. Users can edit the corresponding container image metadata for each container image, including image name, image tag or custom business attributes.

[0014] Step S3: Upload directly from the web frontend to the container image repository. After the user confirms the image metadata, the container image upload is executed. The upload progress is provided for the user to perceive, and the user is notified in case of any abnormalities.

[0015] In the above scheme, step S1 specifically includes:

[0016] File selection and reading: Users select OCI Tar format files through an HTML file selection control, enabling web applications to access the contents of OCI Tar format files through the File object;

[0017] Tar format file parsing: Implements a streaming Tar Reader based on JavaScript AysncGenerator, traversing and parsing sub-file header information, and providing a method to directly access the content of specific sub-files.

[0018] OCI Image Structure Parsing: Read the oci-layout file to obtain OCI version information, parse index.json to obtain the image manifest index, load the manifest file of each image according to the manifest index, parse the manifest to obtain configuration file and layer information, and establish a complete association between the image manifest, configuration file and block file;

[0019] Data structure construction: The parsed results are organized into a structured list of container image manifests, containing complete image hierarchy relationships and metadata.

[0020] In the above scheme, step S2 specifically includes:

[0021] This invention also provides a container image metadata parsing, editing, and uploading system based on a web front-end, comprising:

[0022] The web front-end parsing module is used to parse the OCI Tar format file selected by the user through the browser file selection control to obtain a complete list of container image manifests;

[0023] The display and editing module is used to render and display a list of container image manifests for users to preview, and provides container image metadata editing functions;

[0024] The upload module is used to directly upload container images with completed metadata editing to the container image repository, and provides upload progress monitoring and exception handling.

[0025] In the above system, the Web front-end parsing module includes:

[0026] The file reading unit allows users to select OCI Tar format files using an HTML file selection control, enabling web applications to access the contents of OCI Tar format files through the File object.

[0027] The Tar parsing unit, based on JavaScript AysncGenerator, implements a streaming Tar Reader that iterates through and parses subfile header information, providing a method to directly access the contents of specific subfiles.

[0028] The OCI structure parsing unit reads the layout file (filename oci-layout) of the OCI image to obtain the OCI version information, parses index.json to obtain the image manifest index, loads the manifest file of each image according to the manifest index, parses the manifest to obtain the configuration file and layer information, and establishes a complete association between the image manifest, configuration file and block file;

[0029] The data structure building unit is used to organize the parsed results into a structured list of container image manifests containing complete image hierarchy relationships and metadata.

[0030] In the above system, the display editing module includes:

[0031] The UI rendering unit uses a front-end UI framework to build a visual interface that displays an overview of the container image manifest list and complete metadata information for a single image.

[0032] Editing Function Unit: Provides a text input control for editing the image name, supporting modification of the image repository address, namespace, and image name; supports adding, deleting, and modifying multiple tabs; provides form controls for editing custom business attributes;

[0033] Validation unit: Performs format validation and legality checks on user input, verifying whether its format conforms to predetermined rules;

[0034] Data persistence unit: During user editing, the modified metadata is updated in real time to the image manifest data structure in memory.

[0035] In the above system, the upload module includes:

[0036] Authentication Unit: Obtains the authentication token for the container image repository, verifies upload permissions and repository availability;

[0037] Block file upload unit: According to the container image repository push protocol, upload blob block files one by one to realize block upload and breakpoint resume mechanism. The digest uses the file path of the corresponding file in the OCI Tar format file. For blob files that already exist in the Tar format file, use their original digest-based path as the identifier.

[0038] Progress monitoring unit: Used to display the overall upload progress bar and the upload status indicator for individual files;

[0039] Manifest Submission Unit: Based on the user-edited metadata, regenerate an image manifest that conforms to the OCI standard, and submit the final image manifest to the container image repository;

[0040] Error handling unit: Automatic retry mechanism in case of network abnormalities, and specific error message prompts for upload failures.

[0041] Because the present invention employs the above-mentioned technical means, it has the following beneficial effects:

[0042] 1. This invention solves the problem of wasted network traffic and server storage pressure caused by the traditional solution of having to upload the complete image to the server before metadata identification and processing, by directly parsing OCI Tar format files on the Web front end ("implementing a streaming Tar Reader based on JavaScript Generator" and "OCI image structure parsing: reading oci-layout, index.json, and manifest files and establishing a complete association relationship" in step S1). It achieves the effect of completing deep parsing of the image structure in the user's local browser environment and building a complete image list without relying on backend computing resources, thereby significantly reducing the overall system resource consumption and improving preprocessing efficiency.

[0043] This invention solves the problems of fragmented metadata editing and image upload processes and lack of a unified interactive entry point in the prior art by building a visual editing interface on the web front end and supporting real-time metadata modification (referring to "UI interface rendering", "container image metadata editing function" and "data persistence: updating the modified metadata to the image manifest data structure in memory in real time" in step S2). It achieves a closed-loop operation effect where users can complete image preview, attribute editing, legality verification and data synchronization within the same interface, greatly improving the smoothness of human-computer interaction and the consistency of operation, and avoiding the operational complexity and error risk caused by switching multiple tools or script intervention.

[0044] This invention solves the bandwidth redundancy and transmission delay problems caused by the traditional centralized upload mode, which requires the full transmission of Tar format files to an intermediate server before forwarding. It achieves the effect of uploading only necessary data blocks, skipping existing layers, and incrementally pushing data as needed. This effectively avoids the temporary file accumulation and I / O bottleneck caused by the business server acting as a relay node, and realizes an end-to-end lightweight direct transmission architecture. By directly connecting to the Container Image Repository Protocol v2 in the Web frontend and implementing block upload and breakpoint resume (referring to "Block file upload: upload blob block files one by one according to the Container Image Repository Push Protocol v2 version to realize block upload and breakpoint resume mechanism" in step S3), this invention achieves the effect of uploading only necessary data blocks, skipping existing layers, and incrementally pushing data as needed.

[0045] This invention solves the problems of lack of transparency and difficulty in locating and recovering from failures in the traditional upload process by integrating a complete upload status monitoring and anomaly recovery mechanism on the front end (referring to "progress monitoring: displaying the overall upload progress bar and individual file status indicators" and "error handling and retry: automatic retry and error prompts when there is a network anomaly" in step S3). This achieves the effect that users can perceive the upload status throughout the process, accurately grasp the transmission status of each data block, and obtain automatic recovery capabilities in abnormal scenarios such as network fluctuations, thereby greatly improving the robustness of the upload task and the controllability of the user experience.

[0046] This invention combines three technical approaches—A (front-end local parsing of the OCI structure and construction of the image manifest), B (front-end visual editing of metadata and real-time persistence), and C (front-end direct connection to the image repository to perform protocol-based chunked uploads)—to create a three-in-one collaborative effect of "parsing-editing-uploading." This solves the core pain points of traditional container image management processes, such as fragmented front-end and back-end responsibilities, multiple data transfers, and non-atomic operations. This collaborative architecture allows the entire image upload lifecycle to be completed in a closed loop on the browser side, eliminating the temporary storage and computational burden on the server side while giving users full control and flexibility throughout the process. Ultimately, it achieves comprehensive technical advantages, including maximized resource utilization, minimized operation paths, and simplified system architecture. Attached Figure Description

[0047] Figure 1 This is a simplified flowchart of the present invention;

[0048] Figure 2 This is a schematic diagram of the UI interface for step 1 of the present invention;

[0049] Figure 3 This is a schematic diagram of the UI interface for step 2 of the present invention;

[0050] Figure 4 This is a schematic diagram of the UI interface for step 3 of the present invention. Detailed Implementation

[0051] The embodiments of the present invention will be described in detail below. Although the present invention will be described and illustrated in conjunction with some specific embodiments, it should be noted that the present invention is not limited to these embodiments. On the contrary, any modifications or equivalent substitutions made to the present invention should be covered within the scope of the claims of the present invention.

[0052] Furthermore, to better illustrate the present invention, numerous specific details are set forth in the following detailed embodiments. Those skilled in the art will understand that the present invention can be practiced without these specific details.

[0053] The core idea of ​​this invention is to completely migrate the process of parsing container image OCITAr format files, editing metadata, and pushing to the image repository—which traditionally needs to be completed on the server backend—to the user's web browser frontend. This not only avoids uploading the entire (usually huge) Tar format file to the business server, significantly saving network bandwidth and server storage resources, but also provides users with an integrated, visual interface that allows them to preview, edit, and confirm before uploading, greatly improving operational flexibility and user experience.

[0054] Example 1:

[0055] This embodiment describes in detail the method according to claims 1 to 4 of the present invention. The method is implemented in a typical web application environment, where the web application is deployed on a web server, and users access the application through modern web browsers (such as Chrome, Firefox, Edge, etc.) on terminal devices such as personal computers and workstations.

[0056] Step S1: Web front-end parsing of container image OCI Tar format files

[0057] The goal of this step is to completely parse the user's local OCI Tar format file directly in the user's browser without relying on any server-side computation, and build a complete and operable mirror data structure.

[0058] S1.1: File Selection and Reading On the web application interface, the user clicks on a file selected via standard HTML...<inputtype="file"> The control implements a file selection button. The user selects a Tar format OCI (Open Container Initiative) image archive file generated by dockersave or a similar tool from the local file system.

[0059] Once the user selects a file, the browser triggers the `change` event of that control. The front-end JavaScript code retrieves the file information through the event object and uses the HTML5 File API to reference that file as a `File` object. The `File` object is a special form of the `Blob` object, allowing JavaScript to access raw file data asynchronously without loading the entire file into memory at once. This is crucial because container image Tar format files can be several gigabytes or even tens of gigabytes in size; loading them all at once could easily cause the browser tab to overflow and crash.

[0060] S1.2: Streaming Parsing of Tar Format Files

[0061] Due to the lack of readily available JavaScript libraries specifically designed for efficiently parsing large Tar format files in browsers, this embodiment employs a streaming Tar Reader implemented based on the JavaScript AysncGenerator (currently, no open-source library uses this browser interface). This approach is key to overcoming browser memory limitations.

[0062] The implementation principle of streaming Tar Reader is as follows:

[0063] Step S1.2.1: According to the Tar format file specification, declare a global variable `offset`, perform a small-block character reading operation on the `File` object using `file.slice(offset, offset + 512)`, and parse the Tar Header from this small block of file content. For special types, multiple small-block readings will be performed to obtain a valid and complete Tar Header. When the file is a file (flagtype is 0), it must at least contain a `name` field indicating the file path and a `size` field indicating the file size.

[0064] When a special type of file entry is identified, the following specific processing is performed:

[0065] When the file type identifier is a long path type (LF_GNU_LONGNAME or PAX extension header), an additional complete content block is read according to the size parameter specified in the current file header. The first N non-empty characters of the content block are then parsed into the complete file path, where N is the actual effective length of the content block.

[0066] When the file type identifier is a long link (LF_GNU_LONGLINK), an additional complete content block is read according to the size parameter specified in the current file header. The first M non-empty characters of the content block are then parsed into the complete link target path, where M is the actual effective length of the content block.

[0067] When the file type identifier is a sparse file type, the basic file header is read first. Then, based on the number of sparse mappings indicated in the header, the number of additional sparse mapping data blocks that need to be read is calculated. All sparse mapping blocks are read in sequence and merged to construct a complete sparse file description structure. For entries of ordinary file types, the file path identifier and file size parameter are extracted from the file header information.

[0068] Step S1.2.2: Calculate the start and end positions of the corresponding subfile using offset and Tar Header size, obtain the Blob object using file.slice(offset, offset + size), and instantiate the TarEntry(header: TarHeader, contents:Blob) object together with the header.

[0069] Step S1.2.3: After completing step S1.2.2, record the new offset and repeat steps S1.2.1-S1.2.2 until the offset is less than the total size of the Tar format file.

[0070] For example, one possible implementation:

[0071] The streaming Tar Reader employs an asynchronous iterative processing mechanism, achieving efficient processing of OCI image files of arbitrary size by reading and parsing Tar format files in blocks. Specifically, the implementation of this streaming Tar Reader includes the following steps:

[0072] First, the system initializes a position pointer, which tracks the current read position within the Tar file. According to the Tar file format specification, a Tar file consists of a series of consecutive file entries, each containing a 512-byte header area and a variable-length content area. The system starts reading from the beginning of the file, reading one standard 512-byte header block at a time.

[0073] Secondly, the system performs structured parsing on the read header blocks. The parsing process includes verifying the header checksum, identifying file type identifiers, and extracting file metadata. When a special type of file entry is identified (such as a long filename, a linked file, or a sparse file), the system automatically triggers additional reading operations to obtain the complete file header information according to the extension rules in the Tar format specification. Specifically, for entries of ordinary file types, the system extracts the file path information (stored in the name field) and the file content size (stored in the size field) from the header information; these two parameters are crucial for subsequent content extraction.

[0074] Next, based on the parsed file header information, the system calculates the precise location range of the file entry's content area within the Tar file. Specifically, the start position of the content area is the end position of the current header block, and the end position is the start position plus the number of bytes specified by the file size field. Using file fragmentation technology, the system extracts only the binary data within this precise range, constructs it into an independent data object, and associates the parsed header information with this data object to form a complete file entry representation.

[0075] The system then updates the position pointer to point to the beginning of the next file entry. This calculation takes into account the alignment requirements of the Tar format specification, which stipulates that the total size of each file entry (header + content) must be a multiple of 512 bytes; any shortfall is padded. The updated position pointer will then be used for the next round of iterations.

[0076] Finally, the system checks if the updated position pointer exceeds the total file size. If it does not, it returns to the header block reading step and continues processing the next file entry; if it does exceed the size, it indicates that the entire Tar file has been completely parsed, and the processing flow ends.

[0077] Through the above processing mechanism, this embodiment achieves streaming parsing of large Tar files, avoiding loading the entire file into memory at once, thus overcoming the memory limitations of web browsers. Tests show that this solution can stably handle OCI image files exceeding 20GB, with memory usage remaining within a controllable range while maintaining a high parsing speed. This streaming parsing mechanism is the core technological foundation for enabling this invention to directly process container image files on the web front end.

[0078] S1.3: OCI Mirror Structure Analysis

[0079] Having been able to traverse all files within a Tar format file, the next step is to perform structured parsing according to the OCI image layout specification:

[0080] Step S1.3.1: Traverse TarEntry. When the file path is oci-layout, it can be considered a valid OCITAr format file. Other files will necessarily include a file with the path index.json, several container image layer files and other configuration files with the path blobs / {alg} / {digest}. Extract the alg and digest from the blob path, concatenate them into alg:digest as the key, and store the file in a Map as a BlobMap.

[0081] Step S1.3.2: Read and parse the contents of the index.json file to obtain a list of manifests (the field manifests is an array of Descriptor objects). The Descriptor will contain at least the digest string and the mediaType string. The digest format is the same as alg:digest, and the mediaType is a MIME type that conforms to the IANA format.

[0082] Step S1.3.3: When mediaType is application / vnd.oci.image.manifest.v1+json or application / vnd.docker.distribution.manifest.v2+json (the predecessor of application / vnd.oci.image.manifest.v1+json, which needs to be compatible with older versions of the image), the digest is used as the key to retrieve the corresponding file from the BlobMap in step S1.3.1, and the file is read and parsed in JSON format to obtain the config (Descriptor object) and the layer list (the layer field is an array of Descriptor objects), which is then encapsulated into the class ImageManifest(config: Descriptor, layers: Descriptor[], annotations:Record).<string,string> ).

[0083] Step S1.3.4: When mediaType is application / vnd.oci.image.index.v1+json or application / vnd.docker.distribution.manifest.list.v2+json (the older version of application / vnd.oci.image.index.v1+json), the corresponding file is retrieved from the BlobMap in step S1.3.1 using digest as the key. The file is then read and parsed in JSON format to obtain a list of manifests, which is encapsulated into a class Index(manifests: Array).<ImageManifest | Index> ,annotations:Record<string,string> ).

[0084] Step S1.3.5: Repeat steps S1.3.3-S1.3.4 until all files are processed and the complete mapping relationship of the final image file is obtained.

[0085] S1.4: Data Structure Construction

[0086] After the above analysis steps, the front-end application constructs a complete, structured JavaScript object in memory. This object clearly describes the hierarchical relationship of all images within the OCI Tar format file, for example:

[0087] rootIndex is the index where manifests contain one or more image manifests.

[0088] ImageManifest{config,layers,annotations} Single-architecture image

[0089] Index{manifests, annotations} Multi-architecture image

[0090] The annotations section stores the metadata for each image, with some fields consistent with community standards:

[0091] org.opencontainers.image.base.name is the image name, such as xxx / yy

[0092] `org.opencontainers.image.ref.name` represents the image version, such as `v1.1`.

[0093] Metadata related to other business use cases is used to represent mirroring capabilities.

[0094] Step S2: Displaying and Editing the Web Front-End Container List

[0095] This step provides users with an intuitive interface for reviewing and modifying the image metadata parsed in the previous step.

[0096] S2.1: UI rendering

[0097] Use a front-end UI framework (such as React) to render the list of in-memory image manifests onto the page. The interface can be divided into two parts:

[0098] Mirror list overview;

[0099] Complete metadata information for a single image.

[0100] S2.2: Container image metadata editing functionality:

[0101] Image Name Editing: Provides a text input control that supports modifying the image repository address, namespace, and image name;

[0102] Tag management: Supports adding, deleting, and modifying multiple tags;

[0103] Business attribute extension: Provides form controls for editing custom business attributes (such as algorithm type, version description, etc.);

[0104] Real-time validation: Performs format validation and legality checks on user input;

[0105] Data persistence: During user editing, the modified metadata is updated in real time to the in-memory image manifest data structure.

[0106] S2.3: Real-time Validation and Data Persistence

[0107] Input validation: Perform real-time validation on every piece of user input. For example, use regular expressions to validate whether the image name and tags conform to OCI specifications (e.g., cannot contain uppercase letters, special characters, etc.). If the input is invalid, provide the user with a clear and immediate message.

[0108] In-memory data updates: Any valid modifications made by the user are updated in real-time, with a two-way binding to the in-memory JavaScript object built in step S1. For example, if the image name is changed, the `name` property of the corresponding image in the data structure will change immediately. This WYSIWYG editing experience ensures data consistency. All information is written back to the rootIndex.

[0109] Step S3: Upload directly from the web frontend to the container image repository

[0110] Once the user has finished editing all metadata and clicked the "Upload" button, this step begins, pushing the modified image directly to the target container image repository.

[0111] Step S3.1: Obtain the authentication token for the container image repository and verify upload permissions and repository availability;

[0112] Step S3.2: After checking or modifying rootContainerIndex.manifests in step S2.2, upload the image corresponding to each manifest in a loop.

[0113] Step S3.3: According to the container image repository push protocol, upload all files corresponding to all Descriptors in the Index or ImageManifest as blobs to the image repository (retrieved from BlobMap in Step S1.3). Calculate the total size based on all Descriptors and count the uploaded size of the blob corresponding to each Descriptor. After updating the UI status, the image upload progress bar will be displayed. For blobs that already exist in the image repository (alg:digest already exists), skip the transmission and directly use the size in the Descriptor as the uploaded size. During the upload process, if there is a network error, it will automatically retry, and specific error messages will be displayed for upload failures.

[0114] Step S3.3: After uploading all the blobs of the image, convert the Index or ImageManifest back into the corresponding image manifest (JSON format) and submit it to the container image repository.

Claims

1. A method for parsing, editing, and uploading container image metadata based on a web front-end, characterized in that, Includes the following steps: Step S1: Web front-end parsing of container image OCI Tar format files. Users select OCI Tar format files that conform to the format through the browser file selection control. The page directly parses the OCI Tar to obtain a complete list of container images. Step S2: Web front-end container manifest display and editing. The container image manifest list is displayed for users to preview through rendering. Users can edit the corresponding container image metadata for each container image, including image name, image tags or custom business attributes. Step S3: Upload directly from the web frontend to the container image repository. After the user confirms the image metadata, the container image upload is executed. The upload progress is provided for the user to perceive, and the user is notified in case of any abnormalities.

2. The method according to claim 1, characterized in that, Step S1 specifically includes: File selection and reading: Users select OCI Tar format files using HTML file selection controls, and the browser converts the files into Blob objects using the FileAPI; Tar format file parsing: Implement a streaming Tar Reader based on JavaScript AsyncGenerator, parse the header information of Tar format files, read specific file content as needed, and traverse all file entries within a Tar format file. The file header information includes the file path, file size, and file type. OCI Image Structure Parsing: Read the layout file of the OCI image to obtain the OCI version information, parse index.json to obtain the image manifest index, load the manifest file of each image according to the manifest index, parse the manifest to obtain the configuration file and layer information, and establish a complete association between the image manifest, configuration file and block file; Data structure construction: The parsed results are organized into a structured list of container image manifests, containing complete image hierarchy relationships and metadata.

3. The method according to claim 2, characterized in that, The specific steps for implementing a streaming Tar Reader based on JavaScript AsyncGenerator include: Step S1.2.1: Initialize the file position pointer to the beginning of the Tar file, read 512 bytes of file header data in blocks using the slice method of the File API, perform structured parsing on the file header data, and extract the checksum, file type identifier, and metadata information; when a special type of file entry is identified, perform the following specific processing: When the file type identifier is a long path type {LF_GNU_LONGNAME or PAX extension header}, an additional complete content block is read according to the size parameter specified in the current file header. The first N non-empty characters of the content block are parsed into the complete file path, where N is the actual effective length of the content block. When the file type identifier is a long link type {LF_GNU_LONGLINK}, an additional complete content block is read according to the size parameter specified in the current file header. The first M non-empty characters of the content block are parsed into the complete link target path, where M is the actual effective length of the content block. When the file type identifier is a sparse file type, the basic file header is read first. Then, based on the number of sparse mappings indicated in the header, the number of additional sparse mapping data blocks that need to be read is calculated. All sparse mapping blocks are read in sequence and merged to construct a complete sparse file description structure. For entries of ordinary file types, the file path identifier and file size parameter are extracted from the file header information. Step S1.2.2: Based on the file size parameter contained in the parsed file header information, combined with the current file position pointer, calculate the precise start and end positions of the content area of ​​the file entry in the Tar file, extract the binary data of the corresponding area through the slice method of the File API, encapsulate the binary data into a Blob object, and associate it with the parsed file header information to form a complete file entry object; Step S1.2.3: According to the 512-byte block alignment requirement of the Tar format specification, update the file position pointer to the starting position of the next file entry. The calculation formula is: new position pointer = current header position + 512 + Math.ceil(file size / 512) * 512; determine whether the updated position pointer exceeds the total file size; if it does not exceed the total file size, return to step S1.2.1 to continue processing the next file entry; if it exceeds the total file size, complete the parsing process of the entire Tar format file and return the set of all parsed file entry objects. Step S1.2.4: Encapsulate the above iteration process using the JavaScript AsyncGenerator function, enabling the caller to asynchronously traverse file entries using the for-await-of syntax or the next() method, achieving non-blocking streaming processing and avoiding browser memory overflow issues caused by large Tar files.

4. The method according to claim 2, characterized in that, The specific implementation steps for parsing the OCI image structure include: Step S1.3.1: Traverse all file entries obtained through the streaming Tar Reader, identify file entries with the path "oci-layout", verify whether their content conforms to the OCI specification, and confirm that the input file is a valid OCI image format; at the same time, construct a Blob mapping table, extract file entries with the path conforming to the format "blobs / {alg} / {digest}", use the string in the format "{alg}:{digest}" as the key and the corresponding file entry object as the value, and store them in the memory data structure; Step S1.3.2: Extract the content of the file with the path "index.json" from the Tar file entry, parse its JSON structure, obtain the top-level list index object, and extract the manifests field. This field is an array of Descriptor objects. Each Descriptor object contains at least a digest field and a mediaType field. The digest field value is in the format "{alg}:{digest}". Step S1.3.3: Determine the type of each Descriptor object based on its mediaType field value: When the mediaType is "application / vnd.oci.image.manifest.v1+json", the digest value is used as the key to retrieve the corresponding file entry from the Blob mapping table, its JSON content is parsed, the config field and layers field are extracted, and an ImageManifest object is constructed, where the config field is the configuration file Descriptor and the layers field is an array of layer file Descriptors. When mediaType is "application / vnd.oci.image.index.v1+json", the digest value is used as the key to retrieve the corresponding file entry from the Blob mapping table, its JSON content is parsed, the manifests field is extracted, and step S1.3.3 is recursively applied for processing to construct the Index object. Step S1.3.4: Extract the annotations field from each image manifest. This field is a collection of key-value pairs containing image metadata information. The standard metadata fields include "org.opencontainers.image.base.name" representing the image name and "org.opencontainers.image.ref.name" representing the image tag. Associate these metadata with the corresponding image manifest object. Step S1.3.5: Recursively process all levels of image manifests, establish a complete image hierarchy relationship graph, and finally construct a structured data object containing the root Index object, all child image manifests, configuration files, and the relationships between layer files, as the basic data structure of the container image manifest list.

5. The method according to claim 1, characterized in that, Step S2 specifically includes: UI rendering: Use a front-end UI framework to build a visual interface that displays an overview of the container image manifest list and complete metadata information for a single image; Container image metadata editing functionality: Provides a text input control for editing the image name, supporting modification of the image repository address, namespace, and image name; supports adding, deleting, and modifying multiple tabs; provides form controls for editing custom business attributes; Real-time validation: Performs format validation and legality checks on user input, verifying whether its format conforms to predetermined rules; Data persistence: During user editing, the modified metadata is updated in real time to the in-memory image manifest data structure.

6. The method according to claim 1, characterized in that, Step S3 specifically includes: Authentication preparation: Obtain the authentication token for the container image repository, and verify upload permissions and repository availability; Block file upload: According to the container image repository push protocol, upload blob block files one by one to realize block upload and breakpoint resume mechanism. The digest uses the file path of the corresponding file in the OCI Tar format file. For blob files that already exist in the Tar format file, use their original digest-based path as the identifier. Progress monitoring: Displays the overall upload progress bar and the upload status indicator for individual files; Manifest file submission: Based on the user-edited metadata, regenerate an image manifest that conforms to the OCI standard, and submit the final image manifest to the container image repository; Error handling and retries: Automatic retry mechanism in case of network errors, and specific error messages for upload failures.

7. A container image metadata parsing, editing, and uploading system based on a web front-end, characterized in that, include: The web front-end parsing module is used to parse the OCI Tar format file selected by the user through the browser file selection control to obtain a complete list of container image manifests; The display and editing module is used to render and display a list of container image manifests for users to preview, and provides container image metadata editing functions; The upload module is used to directly upload container images with completed metadata editing to the container image repository, and provides upload progress monitoring and exception handling.

8. The system according to claim 7, characterized in that, The Web front-end parsing module includes: The file reading unit allows users to select OCI Tar format files using an HTML file selection control, enabling web applications to access the contents of OCI Tar format files through the File object. The Tar parsing unit, based on JavaScript AysncGenerator, implements a streaming Tar Reader that iterates through and parses subfile header information, providing a method to directly access the contents of specific subfiles. The OCI structure parsing unit reads the layout file of the OCI image to obtain the OCI version information, parses index.json to obtain the image manifest index, loads the manifest file of each image according to the manifest index, parses the manifest to obtain the configuration file and layer information, and establishes a complete association between the image manifest, configuration file and block file. Data structure building blocks are used to organize the parsed results into a structured list of container image manifests containing complete image hierarchy relationships and metadata.

9. The system according to claim 7, characterized in that, The display editing module includes: The UI rendering unit uses a front-end UI framework to build a visual interface that displays an overview of the container image manifest list and complete metadata information for a single image. Editing Function Unit: Provides a text input control for editing the image name, supporting modification of the image repository address, namespace, and image name; supports adding, deleting, and modifying multiple tabs; provides form controls for editing custom business attributes; Validation unit: Performs format validation and legality checks on user input, verifying whether its format conforms to predetermined rules; Data persistence unit: During user editing, the modified metadata is updated in real time to the image manifest data structure in memory.

10. The system according to claim 7, characterized in that, The upload module includes: Authentication Unit: Obtains the authentication token for the container image repository, verifies upload permissions and repository availability; Block file upload unit: According to the container image repository push protocol, upload blob block files one by one to realize block upload and breakpoint resume mechanism. The digest uses the file path of the corresponding file in the OCI Tar format file. For blob files that already exist in the Tar format file, use their original digest-based path as the identifier. Progress monitoring unit: Used to display the overall upload progress bar and the upload status indicator for individual files; Manifest Submission Unit: Based on the user-edited metadata, regenerate an image manifest that conforms to the OCI standard and submit the final image manifest to the container image repository; Error handling unit: Automatic retry mechanism in case of network abnormalities, and specific error message prompts for upload failures.

Images