High-performance asynchronous segmentation Base64 coding method and device based on VTE system
By using a high-performance asynchronous segmented Base64 encoding method, the problems of main thread blocking, Unicode character compatibility, and imperceptible progress in the VTE system were solved, achieving efficient and reliable transmission and real-time response of medical data, and reducing system transformation costs.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HANGZHOU JIECHUANGRUI MEDICAL TECHNOLOGY CO LTD
- Filing Date
- 2026-01-07
- Publication Date
- 2026-05-19
AI Technical Summary
The VTE system suffers from issues such as main thread blocking, lack of Unicode character compatibility, weak fault tolerance, and imperceptible progress of Base64 encoding, which affect the efficiency of medical data processing and the diagnosis and treatment process.
It adopts a high-performance asynchronous segmented Base64 encoding method, including data preprocessing, segment initialization, asynchronous segmentation loop, padding, and data verification. Combined with fault tolerance strategy and progress feedback mechanism, it dynamically adjusts segment size and encoding progress display.
It avoids blocking the main thread when encoding large files, adapts to Unicode medical characters, supports fault tolerance for illegal characters, provides scenario-based progress feedback, reduces system transformation costs, and ensures complete transmission and real-time response of medical data.
Smart Images
Figure CN122065772A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of medical data processing technology, and in particular to a high-performance asynchronous segmented Base64 encoding method and apparatus based on a VTE system. Background Technology
[0002] Base64 encoding is a core technology for converting binary medical data (such as DICOM image fragments and PDF format thrombosis risk assessment reports) into text format for transmission in VTE systems. The native browser's btoa API is currently the mainstream encoding tool, but it has significant pain points in VTE system scenarios, seriously affecting the efficiency of medical data processing and the diagnosis and treatment process: 1. Main thread blocking issue: The VTE system needs to frequently process 5-50MB DICOM image files or 10,000-character electronic medical records. The browser's native btoa synchronous encoding will occupy the main thread for 1-3 seconds, causing image preview loading to lag, medical record entry interface to become unresponsive, and delaying thrombosis risk assessment and treatment plan formulation.
[0003] 2. Lack of Unicode character compatibility: Patient information (such as ethnic minority names "Maimaiti" and "Zhuoga") and diagnostic conclusions (such as "deep vein thrombosis (left lower extremity)") in the VTE system contain a large number of Unicode characters. Direct encoding with native btoa will throw an exception, requiring the development of an additional customized conversion module, which increases the system development cost and maintenance complexity.
[0004] 3. Weak fault tolerance leads to data transmission interruption: Log data generated by medical devices (such as thrombosis ultrasound detectors) may contain control characters (such as 0x00 null character, 0x1F control character). When the native btoa encounters illegal characters, it terminates the encoding directly, causing the thrombosis risk assessment report and image data to fail to be uploaded, affecting the patient's treatment progress.
[0005] 4. Imperceptible progress reduces healthcare experience: When processing 3D thrombosis models and multi-page image files, the encoding process lacks progress feedback, making it impossible for healthcare staff to determine whether the data is being transmitted normally. This can easily lead to repeated operations, wasting VTE system resources and even causing data redundancy. Summary of the Invention
[0006] The purpose of this invention is to provide a high-performance asynchronous segmented Base64 encoding method and apparatus based on a VTE system to solve one or more of the above-mentioned technical problems.
[0007] To achieve this objective, the present invention adopts the following technical solution: A high-performance asynchronous segmented Base64 encoding method based on VTE system includes: S1: Dynamically adjust segment size based on data type; S2: VTE data preprocessing; The preprocessData method is used to convert both ArrayBuffer and string to UTF-8 encoded strings, while handling illegal characters according to a fault tolerance strategy. S3: Segmented initialization; Get the total length of the preprocessed string, and initialize the current encoding index and the result concatenation variable; S4: Asynchronous segmented loop; S41: Extract the current segment, use encodeSegment to complete the single-segment encoding, and put the encoding logic into the microtask queue using await; S42: Concatenate the encoding results, calculate the encoding progress, and display the encoding progress; S43: Use the yieldMainThread method to give priority to the main thread for handling critical operations or tasks; S5: Filler character completion and data validation; S6: Return the result.
[0008] In some implementations, step S2 specifically includes: S21: Convert the input data into a string; S211: Standard format; When the input is an ArrayBuffer, convert the ArrayBuffer to a Uint8Array and then convert it to a string using String.fromCharCode; When the input is a string, use it directly; S212: Unicode conversion; Use unescape(encodeURIComponent(str)) to convert Unicode characters to UTF-8 binary format.
[0009] In some implementations, unescape(encodeURIComponent(str)) can invoke a mapping table to convert Unicode characters containing the patient's Chinese name, ethnic minority names, and medical special symbols.
[0010] In some implementations, step S2 specifically includes: S22: Use the handleInvalidChars method to process characters with a code greater than 255 according to the fault tolerance strategy; The handleInvalidChars method is used to iterate through each character of the string. When the character's encoding is greater than 255, the fault tolerance strategy is executed by throwing, replacing, or skipping. This fault-tolerance strategy specifically includes: Throwing strategy: If an illegal character is detected, a type error is thrown directly; Replacement strategy: Replace illegal characters with ASCII codes; Skip strategy: Skip illegal characters directly and do not participate in the encoding.
[0011] In some implementations, in step S1: Text data: Set segment size to 8KB; Image data: Set segment size to 32KB.
[0012] In some implementations, in step S43: By listening to DOM operations through requestAnimationFrame, when a critical task or operation is detected on the main thread, the yieldMainThread method is used to extend the yield time of the main thread. Use Promise.resolve for quick scheduling when no critical tasks or operations are detected.
[0013] In some implementations, this extended yield time is 50ms; Key tasks or operations: image preview, medical record editing, medical record saving, thrombosis risk assessment calculation; In some implementations, S5: padding and data validation; Complete the Base64 standard padding characters, record the padding positions, and generate a data checksum; In some implementations, S6: Result returned; Returns a complete Base64 string, along with encoding duration, data type, and checksum metadata.
[0014] In some implementations, this encoding method uses the btoaPolyfill method to be compatible with the browser's native btoa calls.
[0015] The beneficial effects of this invention are: 1. Avoid large file encoding blocking the main thread and ensure real-time response of critical operations such as image preview and medical record editing in the VTE system; 2. Adapts to Unicode medical characters, enabling the encoding of patient Chinese names, special diagnostic symbols, and other data; 3. Supports error tolerance for illegal characters in medical data, ensuring uninterrupted encoding process and guaranteeing the complete transmission of thrombosis assessment reports and imaging data; 4. Provide medical-scenario-based progress feedback to improve the user experience for medical staff and avoid repetitive operations; 5. Compatible with native btoaAPI, reducing the cost of VTE system modification and migration. Attached Figure Description
[0016] Figure 1 This is one of the flowcharts of a high-performance asynchronous segmented Base64 encoding method based on a VTE system according to the present invention; Figure 2 This is the second flowchart of a high-performance asynchronous segmented Base64 encoding method based on a VTE system according to the present invention; Figure 3 This is a schematic diagram of the framework of a high-performance asynchronous segmented Base64 encoding method based on a VTE system according to the present invention; Figure 4 This is a structural diagram of a high-performance asynchronous segmented Base64 encoding device based on a VTE system according to the present invention. Detailed Implementation
[0017] The present invention will now be described in further detail with reference to the accompanying drawings.
[0018] refer to Figures 1 to 3 A high-performance asynchronous segmented Base64 encoding method based on VTE system, comprising: S1: Dynamically adjust segment size based on data type; Different segment sizes can be set based on text or image data to suit different environments or working conditions; S2: VTE data preprocessing; Convert the data into a uniformly encoded string, and handle illegal characters according to the fault tolerance strategy; S3: Segmented initialization; Get the total length of the preprocessed string, and initialize the current encoding index and the result concatenation variable; S4: Asynchronous segmented loop; The segments are encoded one by one, the encoding logic is put into the micro-task queue, the encoding progress is calculated and displayed, and the main thread is given priority to handle critical operations or critical tasks. S5: Filler character completion and data validation; S6: Return the result.
[0019] Step S1 can also be placed between steps S2 and S3. The fault tolerance strategy in step S2 can be executed in each step.
[0020] Further, in step S2: the preprocessData method is used to convert the ArrayBuffer and the string into UTF-8 encoded strings, while handling illegal characters according to the fault tolerance strategy.
[0021] The `preprocessData` method is used to preprocess data before encoding, converting strings into byte sequences.
[0022] ArrayBuffer is a core object used to process binary data, representing a contiguous, fixed-length memory region.
[0023] Since the browser's native btoa function only supports the Latin-1 character set (ISO-8859-1), direct encoding will produce errors. Therefore, the data is first converted into a string with a unified encoding format before encoding, which reduces errors and improves compatibility. Furthermore, illegal characters are handled according to the fault tolerance strategy, which further reduces errors and improves the efficiency and quality of encoding.
[0024] Step S2 includes steps S21 and S22.
[0025] S21: Convert the input data into a string; S211: Standard format; When the input is an ArrayBuffer, convert the ArrayBuffer to a Uint8Array and then convert it to a string using String.fromCharCode; When the input is a string, use it directly; S212: Unicode conversion; Use unescape(encodeURIComponent(str)) to convert Unicode characters to UTF-8 binary format.
[0026] Because the browser's native `btoa` function only supports the Latin-1 character set (ISO-8859-1), directly encoding Unicode characters will throw an error. Therefore, `unescape(encodeURIComponent(str))` encodes the Unicode string into a UTF-8 formatted percent-encoded string, and then converts the percent-encoded string back to a Latin-1 string, with each character corresponding to one byte in UTF-8. Then, the Latin-1 string can be Base64 encoded. This reduces errors, improves compatibility, and ensures compatibility with the browser's native `btoa` call.
[0027] In addition, unescape(encodeURIComponent(str)) can automatically convert Unicode character data such as Chinese patient names, ethnic minority names, and medical special symbols (such as "±, ℃"). For example, by expanding the medical character mapping table, a corresponding mapping relationship is formed between characters and Chinese patient names, ethnic minority names, medical special symbols, etc. When converting, this mapping table is called to ensure lossless encoding of the core data of the VTE system. The prior art only supports general Unicode character conversion and is not optimized for medical scenario special symbols. For example, ethnic minority names ("Mamat", "Zhuoga"), diagnostic conclusions (such as "Deep vein thrombosis (left lower limb)"), etc. contain a large number of Unicode characters, and direct encoding with the native btoa will throw an exception, and a customized conversion module needs to be developed additionally. This application can adapt to Unicode medical characters to ensure lossless encoding of the core data of the VTE system and improve the encoding efficiency.
[0028] S22: Use the handleInvalidChars method to handle characters with an encoding > 255 according to the fault tolerance strategy; Specifically, use the handleInvalidChars method to traverse each character in the string. When the encoding of the character > 255, execute the fault tolerance strategy of throwing, replacing, or skipping.
[0029] Among them, the handleInvalidChars method is used to detect and process illegal, unallowed, or escapable characters in the string, such as removing unallowed characters, etc. When it is detected that the encoding of the character > 255, execute the fault tolerance strategy to reduce errors and improve the fluency of operation.
[0030] This fault tolerance strategy specifically includes: Throwing strategy: directly throw a type error when detecting an illegal character; Replacement strategy: replace the illegal character with an ASCII code. For example, the character "?" corresponds to ASCII code 63; Skipping strategy: directly skip the illegal character and do not participate in encoding.
[0031] Therefore, by forming a fault tolerance matrix through three strategies—throwing, replacing, and skipping—the appropriate fault tolerance strategy can be executed according to different situations. For example, when data accuracy is paramount and errors are not allowed, the throwing strategy can be executed; when "repairing" data is permitted to improve usability, the replacing strategy can be executed; and when local errors are tolerated in batch processing, the skipping strategy can be executed. This supports fault tolerance for illegal characters in medical data, ensuring uninterrupted encoding and guaranteeing the complete transmission of thrombosis assessment reports and imaging data. Log data generated by medical devices (such as thrombosis ultrasound detectors) may contain control characters (such as the 0x00 null character and the 0x1F control character). The browser's native btoa directly terminates encoding upon encountering illegal characters, causing the upload of thrombosis risk assessment reports and imaging data to fail, affecting the patient's treatment progress. This application supports fault tolerance for illegal characters in medical data, ensuring uninterrupted encoding and guaranteeing the complete transmission of thrombosis assessment reports and imaging data.
[0032] Furthermore, in step S1: Text data: Set segment size to 8KB; Image data: Set segment size to 32KB; The default setting is 8KB.
[0033] Therefore, different segment sizes can be set according to data types such as text or image data to suit different environments or working conditions.
[0034] Furthermore, step S4 includes steps S41 to S43.
[0035] S41: Extract the current segment, use encodeSegment to complete the single-segment encoding, and put the encoding logic into the microtask queue using await; The `encodeSegment` function is used to process large amounts of data or macro tasks in segments; `await` pauses the execution of asynchronous functions, relinquishing control of the main thread and placing the code following `await` into a microtask queue; execution resumes only after `PromiseResolve`. In other words, unprocessed data is placed in the microtask queue.
[0036] S42: Combines the encoding results, calculates the encoding progress, and displays the encoding progress. The calculation accuracy is down to 0.1%, adapting to the refined progress display of medical documents, such as "DICOM image encoding in progress (35.2%)". This provides contextualized progress feedback in the medical setting, improving the user experience for medical staff and avoiding repetitive operations. The encoding progress can be displayed or reflected on the screen.
[0037] S43: Use the yieldMainThread method to give priority to the main thread for handling critical operations or tasks; Specifically, DOM operations are monitored through requestAnimationFrame. When a critical task or operation is detected on the main thread, the yieldMainThread method is used to extend the yield time of the main thread. Use Promise.resolve for quick scheduling when no critical tasks or operations are detected.
[0038] The requestAnimationFrame can poll the DOM for changes in each frame to achieve a listening effect. Of course, requestAnimationFrame can also be combined with MutationObserver and rAF to listen to DOM operations.
[0039] `yieldMainThread` is used to proactively relinquish control of the main thread, preventing long-running tasks from causing blocking. `yieldMainThread` is primarily used for macro-tasks. When used in conjunction with `await`, `yieldMainThread` enables asynchronous processing of macro-tasks and micro-tasks, improving coding efficiency.
[0040] Preferably, the extended yield time is approximately 50ms; Preferred key tasks or operations include: image preview, medical record editing, medical record saving, and thrombosis risk assessment calculation. Key tasks or operations can be identified and categorized based on medical operation priority.
[0041] Therefore, during encoding, large file encoding is avoided from blocking the main thread, ensuring real-time response of critical operations such as image preview and medical record editing in the VTE system.
[0042] Furthermore, S5: padding and data validation; For example, according to medical data integrity requirements, the Base64 standard padding characters (=) are added, and the padding positions are recorded to generate a data checksum (MD5). This allows the VTE system to verify data integrity after transmission, preventing the loss of thrombosis assessment reports and imaging data.
[0043] Furthermore, S6: Return the result; Returns a complete Base64 string, along with metadata such as encoding duration, data type (text or image), and checksum, thus adapting to the data transmission verification requirements of the VTE system.
[0044] This encoding method uses the btoaPolyfill method, which is compatible with the browser's native btoa call.
[0045] The `btoaPolyfill` method fully simulates native behavior and supports Unicode character processing, providing equivalent Base64 encoding in older browsers that do not support native btoa (such as IE9 and below). For example, it ensures compatibility with older hospital intranet terminals (such as Windows 7 + IE11) by using `setTimeout(fn,0)` to achieve microtask effects, guaranteeing multi-terminal compatibility. This reduces the cost of VTE system modification and migration without requiring the reconstruction of existing data transmission modules.
[0046] refer to Figure 4 A high-performance asynchronous segmented Base64 encoding device based on a VTE system, which is used to run the above-mentioned encoding method; The device includes: Character set module 1 is used to define the standard Base64 character set as the basis for encoding mapping; Segmentation configuration module 2 dynamically adjusts the segment size based on data type; Data preprocessing module 3 is used to convert ArrayBuffer and strings into UTF-8 encoded strings and to handle illegal characters; Asynchronous encoding module 4 uses segmented encoding based on microtask execution, prioritizing the main thread to handle critical operations or tasks. Progress callback module 5 is used to calculate the coding progress in real time and trigger callbacks; Fault tolerance module 6 is used to execute fault tolerance strategies such as throwing, replacing, and ignoring; and Compatibility adapter module 7 is used to provide synchronous btoaPolyfill, which is compatible with the browser's native btoa calls.
[0047] This device can be used in any of the following: client browser, application server, or edge node medical device terminal.
[0048] 1. Client Browser: Embedded in the VTE system front-end page, handling local encoding during image uploading, medical record editing, and medical record saving, and adapted to hospital intranet terminals and mobile tablets.
[0049] 2. Application Server (Node.js): Deployed on the backend service of the VTE system, it handles the batch encoding and transmission of large numbers of thrombosis assessment reports.
[0050] 3. Edge Node (Medical Device Terminal): Adapts to Linux / Windows terminal systems of thrombosis ultrasound detectors and imaging equipment, and processes the real-time encoding of data generated by the equipment.
[0051] Usage example 1. Asynchronous coding (with progress callback) HighPerformanceBtoa.encode('Hello, World!', (progress) =>{ console.log(`coding progress: ${progress}%`); / / Real-time output of progress (0-100)}, 'replace').then(encoded => { console.log('Encoding result: ', encoded); / / Outputs the Unicode-encoded Base64 string}).
[0052] 2. Compatible with native BTOA calls / / Replace the original btoawindow.btoa = HighPerformanceBtoa.btoaPolyfill; / / Existing code does not need to be modified const result = btoa('Test Unicode characters'); console.log(result).
[0053] 3. ArrayBuffer encoding (large file scenario) / / Read the file as an ArrayBuffer const fileReader = new FileReader(); fileReader.onload = async (e) =>{ const arrayBuffer = e.target.result; / / Encoding large files with progress callbacks const encoded = await HighPerformanceBtoa.encode(arrayBuffer,(progress) =>{ console.log(`File encoding progress: ${progress}%`); }); console.log('File Base64 encoding result:', encoded);}; fileReader.readAsArrayBuffer(file); / / Reads a large local file.
[0054] The beneficial effects of this encoding method and device are: 1. VTE Scenario-based Microtask Asynchronous Segmented Scheduling Mechanism For medical data types (text / image) in the VTE system, the segment size (8KB / 32KB) is dynamically adjusted. Combined with requestIdleCallback and medical operation priority judgment, priority is given to ensuring main thread resources for core diagnostic and treatment operations such as image preview and medical record editing. Compared to the existing "fixed segmentation + macro task scheduling" solution, this addresses the diagnostic and treatment delay problem caused by large file encoding in the VTE system. The main thread blocking time during encoding is reduced from 1-3 seconds to below 50ms, meeting the real-time requirements of medical scenarios.
[0055] 2. Adaptive conversion of Unicode medical characters This solution automatically converts Unicode data such as patient Chinese names, ethnic minority names, and special medical symbols (e.g., "±", "℃") using unescape(encodeURIComponent(str)), eliminating the need for manual user processing. It also extends the medical character mapping table to ensure lossless encoding of core data in the VTE system. Existing technologies only support general Unicode character conversion and are not optimized for special symbols in medical scenarios; this solution fills the technical gap in medical character encoding for VTE systems.
[0056] 3. VTE Medical Data Multi-Strategy Fault Tolerance Mechanism To address the characteristics of VTE system data, three fault tolerance strategies—"throw / replace / ignore"—are provided. A new fault tolerance mode specifically for medical data is added, filtering control characters for imaging equipment while retaining core diagnostic and treatment information. Data verification codes are generated to ensure transmission integrity, solving the problem of medical data loss caused by the existing technology's "single fault tolerance strategy + no verification." The encoding failure rate is reduced from 12% in traditional solutions to below 0.5%.
[0057] 4. Real-time feedback on VTE scenario-based progress Based on medical data types (text / images), it provides tiered progress prompts (such as "Medical record coding in progress (XX%)" and "DICOM image coding in progress (XX%)") with a progress accuracy of 0.1%, which meets the needs of medical staff for refined perception of data transmission status. Compared with the existing technology of "no progress feedback / coarse-grained progress", it significantly improves the user experience of the VTE system and reduces repeated upload operations.
[0058] 5. VTE System Native API Compatibility Solution This solution provides a btoaPolyfill method, compatible with native btoa calls, which can directly replace the existing coding logic of the VTE system. It is adaptable to multiple browser environments within the hospital intranet (IE11 and above, Chrome / Firefox), eliminating the need to refactor the existing data transmission module and reducing system upgrade costs. Existing technologies do not consider compatibility with older medical system terminals; this solution ensures a smooth upgrade of the VTE system.
[0059] The above description only discloses some embodiments of the present invention. For those skilled in the art, various modifications and improvements can be made without departing from the inventive concept of the present invention, and these all fall within the scope of protection of the invention.
Claims
1. A high-performance asynchronous segmented Base64 encoding method based on a VTE system, comprising: S1: Dynamically adjust segment size based on data type; S2: VTE data preprocessing; The preprocessData method is used to convert both ArrayBuffer and string to UTF-8 encoded strings, while handling illegal characters according to a fault tolerance strategy. S3: Segmented initialization; Get the total length of the preprocessed string, and initialize the current encoding index and the result concatenation variable; S4: Asynchronous segmented loop; S41: Extract the current segment, use encodeSegment to complete the single-segment encoding, and put the encoding logic into the microtask queue using await; S42: Concatenate the encoding results, calculate the encoding progress, and display the encoding progress; S43: Use the yieldMainThread method to give priority to the main thread for handling critical operations or tasks; S5: Filler character completion and data validation; S6: Return the result.
2. The high-performance asynchronous segmented Base64 encoding method based on VTE system according to claim 1, characterized in that, Step S2 includes: S21: Convert the input data into a string; S211: Standard format; When the input is an ArrayBuffer, convert the ArrayBuffer to a Uint8Array and then convert it to a string using String.fromCharCode; When the input is a string, use it directly; S212: Unicode conversion; Use unescape(encodeURIComponent(str)) to convert Unicode characters to UTF-8 binary format.
3. The high-performance asynchronous segmented Base64 encoding method based on a VTE system according to claim 2, characterized in that, The unescape(encodeURIComponent(str)) function can call a mapping table to convert Unicode characters containing Chinese patient names, ethnic minority names, and medical special symbols.
4. The high-performance asynchronous segmented Base64 encoding method based on a VTE system according to claim 2, characterized in that, Step S2 includes: S22: Use the handleInvalidChars method to process characters with a code greater than 255 according to the fault tolerance strategy; The handleInvalidChars method is used to iterate through each character of the string. When the character's encoding is greater than 255, the fault tolerance strategy is executed by throwing, replacing, or skipping. This fault-tolerance strategy specifically includes: Throwing strategy: If an illegal character is detected, a type error is thrown directly; Replacement strategy: Replace illegal characters with ASCII codes; Skip strategy: Skip illegal characters directly and do not participate in the encoding.
5. The high-performance asynchronous segmented Base64 encoding method based on a VTE system according to claim 1, characterized in that, In step S1: Text data: Set segment size to 8KB; Image data: Set segment size to 32KB.
6. The high-performance asynchronous segmented Base64 encoding method based on a VTE system according to claim 1, characterized in that, In step S43: By listening to DOM operations through requestAnimationFrame, when a critical task or operation is detected on the main thread, the yieldMainThread method is used to extend the yield time of the main thread. Use Promise.resolve for quick scheduling when no critical tasks or operations are detected.
7. The high-performance asynchronous segmented Base64 encoding method based on a VTE system according to claim 6, characterized in that, The extended yield time is 50ms. Key tasks or operations: image preview, medical record editing, medical record saving, and thrombosis risk assessment calculation.
8. The high-performance asynchronous segmented Base64 encoding method based on VTE system according to claim 1, characterized in that: S5: Filler character completion and data validation; Complete the Base64 standard padding characters, record the padding positions, and generate a data checksum; S6: Return the result; Returns a complete Base64 string, along with encoding duration, data type, and checksum metadata.
9. The high-performance asynchronous segmented Base64 encoding method based on a VTE system according to claim 1, characterized in that, This encoding method uses the btoaPolyfill method, which is compatible with the browser's native btoa call.
10. A high-performance asynchronous segmented Base64 encoding device based on a VTE system, the device being used to run the encoding method of claim 1; The device includes: Character set module: Used to define the standard Base64 character set as the basis for encoding mapping; The segmentation configuration module dynamically adjusts the segment size based on the data type. The data preprocessing module is used to convert ArrayBuffer and strings into UTF-8 encoded strings and to handle illegal characters. The asynchronous coding module uses segmented coding based on the execution of microtasks, prioritizing the main thread to handle critical operations or tasks. The progress callback module is used to calculate the coding progress in real time. The fault tolerance module is used to execute fault tolerance strategies such as throwing, replacing, and ignoring; and A compatibility and adaptation module is provided to offer a synchronous btoaPolyfill, ensuring compatibility with native browser btoa calls. This device can be used in any of the following: client browser, application server, or edge node medical device terminal.