Method for stably displaying Base64 picture at Web end

Abstract

The invention discloses a method and a system for stably displaying a Base64 picture at a Web end. The server performs Base64 coding on pictures not exceeding 1MB, generates content fingerprints, associates versions with metadata, and distributes description data through homologous signatures; and the front end asynchronously loads and displays after coding and optional zooming on the canvas side, and when the loading fails, hierarchical backspacing taking the placeholder as the first is executed. The system can selectively start a fragmented list and memory water level control, combines local cache and flicker-free replacement with fingerprints and versions as keys, and supports operation rapid picture changing and history tracing. According to the scheme, the problems of cross-domain pollution, first screen blank and memory peak are solved, and the loading stability and the operation and maintenance efficiency are improved.

Description

Technical Field

[0001] This invention belongs to the field of web front-end image display and resource distribution, and in particular relates to a method for stably displaying Base64 images on the web. Background Technology

[0002] In existing web applications, to reduce the number of HTTP requests, lessen initial screen congestion, and facilitate direct referencing within components, front-end developers often embed small images in Base64 format into pages or scripts. This approach saves on additional resource fetching and permission configuration, but it also brings a series of problems: First, Base64 encoding results in a significant increase in file size compared to raw binary. During the initial rendering phase, the page needs to synchronously parse and decode the longer string, which can easily cause main thread congestion. In low-performance terminals or scenarios with multiple concurrent images, phenomena such as blank initial screens and prolonged initial screen loading times often occur. Second, when the image source and page domain are inconsistent, the browser will trigger canvas pollution to prevent cross-origin data leakage, resulting in unreadable pixel data and making it impossible to determine the size on the front end. Secondary processing such as proportional scaling, re-encoding, and partial cropping affects both the display strategy and limits subsequent quality and size optimization. Third, since Base64 is often directly written into the front-end code or packaged artifacts, the daily "image change" on the operations side requires a complete process of modifying code, packaging, regression testing, and release, which is time-consuming and easily coupled with business releases, making it difficult to respond to activities and style changes in a timely manner. Fourth, although existing object storage or CDN direct link solutions can alleviate bandwidth and caching issues to some extent, they have high requirements for cross-domain policies, signature verification, cache consistency, version rollback, etc., and lack a unified placeholder display and fallback path when there are network fluctuations or insufficient terminal capabilities. In abnormal situations, flickering, blank spaces, or long periods of invisibility may still occur.

[0003] In summary, a solution that balances source security, reprocessability, replaceability, and rollback capability is still insufficient. There is an urgent need for an implementation path that can stably display Base64 images and support rapid version-based replacement and weak network fault tolerance while ensuring pixel readability and link controllability. Summary of the Invention

[0004] In view of this, the present invention aims to propose a method for stably displaying Base64 images on a web platform, so as to at least solve one of the problems in the background technology.

[0005] To achieve the above objectives, the technical solution of the present invention is implemented as follows: A method for stably displaying Base64 images on a web application includes: The server receives the uploaded target image and performs a capacity check on the target image; when the capacity of the target image does not exceed a preset capacity threshold, the target image is Base64 encoded. A corresponding content fingerprint is generated based on the Base64 encoded data to uniquely identify the encoded data; the content fingerprint is then associated and stored with the Base64 encoded data, image type information, original size information, generation time information, and version number. Based on the same-origin distribution strategy, the server generates signature information carrying the validity period for the content fingerprint identifier and version number, and returns the description data carrying the signature information to the front end through an interface with the same origin as the web front end; The front end creates an image object based on the description data, sets the Base64 encoded data as the image data to be loaded, and listens for the loading result asynchronously; When the image loading is detected to be successful, a canvas object matching the original size is created on the front end, the image is drawn onto the canvas, and the drawn content is re-encoded and optionally scaled according to the browser's support for the target image format. Then the target image data is used for page display. When an image loading failure is detected or the drawing context of the canvas cannot be obtained, a rollback rendering process is triggered, which includes at least displaying a placeholder image associated with the content fingerprint and recording error information. When the backend management system uploads a replacement image for the same business identifier, the server only updates the version number and maintains the traceable relationship between the business identifier and the content fingerprint mapping. The frontend reloads according to the above process after refreshing or receiving a change notification.

[0006] Furthermore, the content fingerprint identifier is a digest value calculated based on the Base64 encoded data using a secure hash algorithm. The digest value serves as both the primary retrieval key for the database and the retrieval key for the front-end cache.

[0007] Furthermore, the same-origin distribution strategy includes: generating signature information for the fields of "content fingerprint identifier, version number, generation time, and validity period"; the front end carries the signature information with each request, and the server performs consistency and validity period verification on the signature information at the same-origin interface.

[0008] Furthermore, the re-encoding and scaling include: based on the relative relationship between the current image data volume and the preset target data volume, prioritizing the selection of a target format with higher compression efficiency and supported by the browser for re-encoding; when the browser does not support the target format, selecting a compatible format for re-encoding; and when the display performance requirements are still not met, scaling down the canvas output size proportionally before re-encoding.

[0009] Furthermore, the server can split the Base64 encoded data into fixed fragment sizes and return a list containing the fragment order. The front end can then concatenate the fragments according to the order of the list to obtain the complete Base64 encoded data. During the concatenation process, memory usage is monitored. When the preset memory level is reached, the currently available data is converted into an object URL for temporary display, and the concatenated temporary string resources are released.

[0010] Furthermore, the rollback rendering process is a tiered rollback: the first tier displays a small placeholder image and indicates the loading status; the second tier completes recoding in the background and replaces the object URL without flickering; when both rollback tiers fail, an error is indicated by readable text or a vector placeholder image and error records are continuously retained.

[0011] Furthermore, the front-end establishes a local cache using a combination of "content fingerprint identifier and version number" as the cache key through the browser's service worker thread or an equivalent caching mechanism. When the cache is hit again and the version number is consistent, the local data is displayed directly. When the version number is inconsistent, the display is refreshed by updating in the background and replacing it in the foreground without flickering.

[0012] Furthermore, the server-side database establishes indexes for the fields of "content fingerprint identifier, business identifier, version number, image type, original size, generation time, validity period, uploader identifier, and business tag"; and provides an interface for reading the latest version number based on the business identifier.

[0013] Furthermore, after the front-end completes the page display, it converts the binary data exported from the canvas into an object URL for continuous display and releases the original Base64 long string and intermediate canvas resources.

[0014] Furthermore, the description data returned by the server includes both a placeholder image description and a target image description; the front end first displays the placeholder image to occupy the layout space, and then gradually replaces it after the target image is successfully decoded.

[0015] Furthermore, if the image loading fails to complete after exceeding the first time threshold, the front end automatically reduces the re-encoding quality or reduces the output size and then retryes once; if it still fails after exceeding the second time threshold, it directly enters the rollback rendering process.

[0016] Furthermore, the server performs image type whitelist verification during the image upload process, limiting it to common lossless or lossy image types; images that do not meet the whitelist requirements will not enter the encoding and distribution process.

[0017] Furthermore, the same-origin interface employs encrypted transmission and is coupled with entity tag verification; when the front end carries an entity tag and a match is found, the server returns a response without carrying an entity tag to reduce transmission load.

[0018] Furthermore, when it is detected that the browser does not support off-screen canvas, target re-encoding format, or other hardware acceleration capabilities, the front end skips the re-encoding step and directly uses the original Base64 encoded data for display, while maintaining the fallback rendering process unchanged.

[0019] Furthermore, this solution discloses a stable Base64 image display system for web applications, including: The upload and encoding module is used to Base64 encode images that meet the capacity threshold and generate content fingerprint identifiers; The signature distribution module is used to generate a same-origin signature based on the content fingerprint identifier, version number, and time information, and distribute it along with the description data; The rendering and re-encoding module is used to draw Base64 images onto the canvas on the front end and then re-encode and optionally scale them before outputting them for display. The fragmentation and reassembly module is used to concatenate Base64 encoded data in the order of the fragmentation list at the front end and control the memory level. The rollback rendering module is used to perform tiered rollbacks when loading fails or context acquisition fails. The versioning replacement module is used to trigger a flicker-free replacement when the version number corresponding to the business identifier is updated.

[0020] Furthermore, this solution discloses a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is used to implement a method for stably displaying Base64 images on a web application.

[0021] Compared with existing technologies, the method for stably displaying Base64 images on a web platform as described in this invention has the following advantages: (1) The method for stably displaying Base64 images on the Web client described in this invention adopts same-origin signature distribution and validity period verification to avoid canvas pollution caused by cross-domain issues and ensure pixel readability and security controllability; (2) The method for stably displaying Base64 images on the Web side described in this invention is based on the association storage and distribution of content fingerprint identifiers and version numbers, and supports rapid replacement and historical tracing on the operation side; (3) The method for stably displaying Base64 images on the Web side according to the present invention performs re-encoding and optional size scaling on the canvas side after the front end loads the image, balancing the size and clarity and improving loading stability; (4) The method for stably displaying Base64 images on the Web client described in this invention, with placeholder image priority and hierarchical rollback mechanism, significantly reduces the cost of blank first screen and failure, and retains minimal error records for operation and maintenance; (5) The method for stably displaying Base64 images on the Web client described in this invention includes optional fragmentation list and memory level control to suppress peak usage and improve stability in scenarios with multiple concurrent images or weak devices. (6) The method for stably displaying Base64 images on the Web client described in this invention uses "fingerprint + version" as the key and returns the result with conditions to achieve flicker-free updates and bandwidth saving; (7) The method for stably displaying Base64 images on the Web client described in this invention includes a type whitelist and metadata index, which improves data quality and retrieval efficiency and facilitates large-scale deployment. Attached Figure Description

[0022] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a schematic diagram illustrating a method for stably displaying Base64 images on a web interface, as described in an embodiment of the present invention. Figure 2 This is a schematic diagram of a system for stably displaying Base64 images on a web interface, as described in an embodiment of the present invention. Detailed Implementation

[0023] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0024] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0025] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0026] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0027] To facilitate understanding, let's first define the core terms used in this article: "Fingerprint identifier" refers to an identifier that uniquely identifies the content of Base64 encoded image data; "Description data" refers to the comprehensive set of information returned by the server to the front end to drive the display process; "Placeholder images" refer to images that are logically related to the target image, have a smaller file size, and are used for placement on the first screen and for rollback in case of failure. The "version number" is used to identify replacement iterations under the same business identifier; "Rollback rendering process" refers to a tiered display strategy when loading fails or the canvas is unavailable; "Sharding list" refers to the order in which the server distributes the segments after splitting the Base64 data; "Same-origin interface" refers to a server-side interface that shares the same origin as the front-end page.

[0028] Example 1 This embodiment provides the minimum viable path to ensure stable image display from upload in a same-source scenario: 1. Upload and Encoding: The server provides an upload portal and performs capacity checks on images. When the capacity threshold (preferably 1MB) is met, the image is Base64 encoded and a fingerprint is generated. The fingerprint is then associated with and stored along with the image type, original size, generation time, and version number to form a searchable entry.

[0029] 2. Signature and Distribution: The server generates signature information based on the fingerprint identifier, version number, and time information, and distributes the description data containing the above fields through the same-origin interface. The description data includes at least: fingerprint identifier, version number, image type, original size, validity period, placeholder image information, and image data (complete Base64 or fragment list) for front-end display.

[0030] 3. Front-end Loading and Listening: The front-end first renders a placeholder image to occupy layout space, then creates an image object based on the description data and asynchronously listens for the loading status. If loading is successful, canvas processing begins; if loading fails or the canvas is unavailable, a fallback rendering process is initiated.

[0031] 4. Display and Resource Recycling: After completing canvas processing and obtaining displayable data, the front-end replaces the page; once stability is confirmed, release the Base64 long string and temporary resources such as the intermediate canvas in a timely manner to reduce memory usage.

[0032] 5. Same Origin and Security: Same-origin interfaces sign and verify the validity period of each request, and the interface is encrypted throughout the transmission; conditional responses can be returned for unchanged content to reduce duplicate transmissions.

[0033] The above process avoids canvas pollution in a homogeneous environment, making pixel readability and subsequent reprocessing possible; placeholder image pre-processing and resource recycling ensure the first-screen experience and stability.

[0034] Example 2 To ensure the correctness and integrity of data during transmission and reuse, the server includes a signature when generating descriptive data. The frontend sends this signature with its requests, and the server performs consistency and validity checks on the same-origin interface. Requests that do not meet the verification conditions do not return the actual image data. The interface uses encrypted transmission and employs entity tags for conditional return, further reducing network load. This mechanism also avoids unreadable canvas pixels caused by cross-origin issues.

[0035] Example 3 After successful image decoding, the front-end creates a canvas matching the original size and draws the image onto it. The target output format is selected based on the browser's capabilities: a high-compression format is preferred if supported, otherwise a compatible format is used; if display performance is still difficult to guarantee, the output size can be scaled down proportionally before output. During the display phase, the object URL is used first, and once stability is confirmed, the original Base64 string and temporary objects such as the intermediate canvas are released. This path is feasible across different browsers and devices.

[0036] Example 4 In scenarios with low performance or multiple concurrent graphs, to reduce memory spikes caused by single string allocations, the server can split Base64 data into fixed-size segments and include a list of segments in the description data. The frontend concatenates the segments according to the list order; during the concatenation process, memory levels are monitored, and when the memory level approaches a threshold, the currently available content is converted into an object URL for temporary display, and the unused temporary strings are released; after the remaining segments are concatenated and decoded, the temporary content is replaced with a flicker-free display. This strategy significantly improves page smoothness and stability.

[0037] Example 5 When an image times out, a network error occurs, or the canvas becomes unavailable, the front-end immediately enters a fallback rendering process: Level 1 fallback: Displays a placeholder image associated with the fingerprint identifier, maintaining layout stability and indicating the loading status to the user; Second-level fallback: After the backend completes reprocessing (such as re-encoding or degradation), the frontend replaces it with the object URL without flickering; Gradual replacement: After the target image is successfully loaded, the placeholder image is replaced in a gradual transition to avoid visual abruptness.

[0038] The rollback path always retains error records (including trigger location, network status, fingerprint identifier, and version number) to facilitate subsequent problem identification and adjustment strategies.

[0039] Example 6 When replacing images corresponding to the same business identifier, the referencing relationship remains unchanged; the server only increments the version number and retains historical mappings. The frontend retrieves the description data and completes the replacement after a page refresh or upon receiving a version change notification. If the local cache hits the replacement but the version number is outdated, the latest version is fetched from the backend and replaced without flickering. All historical versions are traceable, supporting operational rollback and effect comparison.

[0040] Example 7 The frontend uses a combination of "fingerprint identifier + version number" as the cache key to establish a local cache. When the same version number is matched, the page can be displayed directly for a fast first-screen experience. If a version inconsistency is detected, the existing display is maintained first, and the new version is fetched and replaced in the backend. After the replacement is completed, outdated object URLs and redundant strings are cleaned up to avoid long-term memory occupation. This strategy can significantly reduce jitter under weak network conditions or high concurrency requests.

[0041] Example 8 Server-side database entries must include at least the following fields: fingerprint identifier, business identifier, version number, image type, original size, generation time, validity period, uploader identifier, and business tag, with necessary indexes established. The read interface supports reading the latest version by business identifier; the upload entry performs whitelist verification on media types, and non-whitelisted data is not allowed to enter the encoding and distribution chain. This constraint reduces abnormal data and improves operational controllability.

[0042] Example 9 When the browser does not support critical capabilities (such as off-screen canvas or specific output formats), the front-end skips the re-encoding and scaling steps and directly uses the original Base64 for display; the fallback rendering process remains unchanged. The combined path of placeholder images, object URLs, and back-end replacements ensures basic usability under the minimum capability environment; when the environment capability is restored or upgraded, it automatically reverts to the re-encoding optimization path.

[0043] It should be noted that the above embodiments can be combined and applied according to business needs. For example, the fragmentation mechanism of Embodiment 4 can be introduced into the basic process of Embodiment 1, while the local caching strategy of Embodiment 7 can be enabled; or the re-encoding degradation path of Embodiment 3 can be superimposed on the fallback process of Embodiment 5 to adapt to different terminals and network environments. As long as they do not deviate from the technical points defined in the claims, the above combinations are all optional embodiments of the present invention.

[0044] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for stably displaying a Base64 picture on a Web side, characterized in that, The method comprises the following steps: The server receives the uploaded target picture, and performs capacity checking on the target picture; When it is detected that the capacity of the target picture does not exceed a preset capacity threshold, the target picture is Base64 encoded; A corresponding content fingerprint identifier is generated based on the Base64 encoded data, which is used to uniquely identify the encoded data; The content fingerprint identifier is stored in association with the Base64 encoded data, picture type information, original size information, generation time information and version number; The server generates signature information carrying a validity period for the content fingerprint identifier and version number based on a same-origin distribution strategy, and returns description data carrying the signature information to the front end through an interface that is same-origin with the Web front end; The front end creates an image object based on the description data, sets the Base64 encoded data as image data to be loaded, and listens to the loading result in an asynchronous manner; When it is detected that the image loading is successful, a canvas object matching the original size is created in the front end, the image is drawn to the canvas, and the drawn content is re-encoded and optionally scaled in size according to the support of the target picture format by the browser, and then the target image data is used for page display; When it is detected that the image loading fails or the drawing context of the canvas cannot be obtained, a fallback rendering process is triggered, at least including displaying a placeholder image associated with the content fingerprint identifier and recording error information; When the background management system uploads a replacement picture for the same business identifier, the server only updates the version number and maintains the traceable relationship between the business identifier and the content fingerprint, and the front end reloads according to the above process after refreshing or receiving a change notification.

2. The method for stably displaying a Base64 picture on a Web end according to claim 1, characterized in that: The content fingerprint identifier is a digest value calculated based on the Base64 encoded data by a secure hash algorithm, which is also used as the primary search key of the database and the search key of the front end cache.

3. The method of claim 1, wherein, The same-origin distribution strategy includes generating signature information for the fields of "content fingerprint identifier, version number, generation time, validity period", and the front end carries the signature information every time a request is made, and the server performs consistency and validity period checking on the signature information at the same-origin interface.

4. The method of claim 1, wherein, Re-encoding and size scaling include: according to the relative relationship between the current image data amount and the preset target data amount, preferentially selecting a target format with higher compression efficiency and supported by the browser for re-encoding; when the browser does not support the target format, selecting a compatible format for re-encoding; when the display performance requirement is still not met, reducing the canvas output size in proportion and then encoding.

5. The method of claim 1, wherein: The server can split the Base64 encoded data by a fixed fragmentation size and return a list containing the fragmentation order, and the front end splices the complete Base64 encoded data according to the list order; during the splicing process, memory occupation detection is performed, and when the preset memory water level is reached, the current available data is first converted into an object URL for temporary display, and the spliced temporary string resource is released.

6. The method of claim 1, wherein, The fallback rendering process is hierarchical fallback: the first level is to display a small placeholder image and prompt the loading status, the second level is to replace the object URL without flicker after background re-encoding; when both levels of fallback fail, readable text or vector placeholder is used to prompt the exception and continuously keep the error record.

7. The method for stably displaying a Base64 picture on a Web end according to claim 1, characterized in that: The front end uses the service worker thread or equivalent cache mechanism of the browser to establish local cache with the combination of "content fingerprint and version number" as the cache key; When the cache is hit again and the version number is consistent, the local data is directly displayed; when the version number is detected to be inconsistent, the background update and front-end non-flicker replacement are used to complete the display refresh.

8. The method for stably displaying a Base64 picture on a Web end according to claim 1, characterized in that: The server-side database establishes an index for the fields of "content fingerprint, business identification, version number, picture type, original size, generation time, validity period, uploader identification and business label"; And provides an interface based on business identification to read the latest version number.

9. The method for stably displaying a Base64 picture on a Web end according to claim 1, characterized in that: After the front end completes the page display, the binary data exported by the canvas is converted into an object URL for continuous display, and the original Base64 long string and intermediate canvas resources are released.

10. The method for stably displaying a Base64 picture on a Web end according to claim 1, characterized in that: The description data returned by the server contains both placeholder image description and target image description; the front end first displays the placeholder image to occupy the layout space, and then replaces it with a gradual transition after the target image is successfully decoded.

Images