Cross-network one-way file ferry transmission sharing method and system based on file name encoding

Abstract

The application relates to the field of network security and data isolation exchange technology, and discloses a cross-network one-way file ferry transmission sharing method and system based on file name coding, which comprises the following steps: S1: a sending end generates a structured coded file name containing a version number, an extraction code, a download count threshold, a validity period and an original name, and supports multi-version client compatibility; S2: a client writes a file into a first network FTP temporary area with a temporary name ".uploading", so as to avoid triggering the ferry; S3: after the uploading is completed, the file is renamed as ".ok" by using an FTP atomic instruction; S4: a network gate periodically scans the ".ok" file and ferries the file to a second network FTP in a one-way and non-feedback mode; and S5: a receiving end HTTP service parses the file name. The cross-network one-way file ferry transmission sharing method and system based on file name coding have the advantages that control information is coded and embedded into a file name, fine file sharing control without a reverse control channel can be realized in a physical one-way isolation environment, and the like.

Description

Technical Field

[0001] This invention relates to the field of network security and data isolation and exchange technology, specifically to a cross-network one-way file transfer and sharing method and system based on filename encoding. Background Technology

[0002] Cross-network one-way file transfer technology is a key technology in the field of network security and data isolation exchange. It is mainly used in scenarios with extremely high network security requirements, such as public security, government affairs, and finance. It is used to realize data exchange between physically isolated networks with different security levels. At present, the industry usually uses network gateways or physical isolation transfer devices as the core transmission carrier. By blocking direct network layer connections, it ensures the boundary security of high-security domain networks, while meeting the necessary file transfer and sharing needs between different security domains. It is an important technical means to balance network security and data flow efficiency.

[0003] While existing cross-network one-way file transfer technologies can achieve data transfer operations in practical applications, there are still several areas for improvement: Regarding control information transmission, the physical one-way isolation environment prevents the receiving end from sending control information, hindering the implementation of refined file sharing strategies. Regarding file transmission integrity, the lack of a clear mechanism to distinguish file upload status may result in files being transferred before they are fully written, affecting the integrity of the files received by the receiving end. In multi-user sharing scenarios, the adaptability of existing storage isolation methods needs improvement, making it difficult to ensure the isolation of user data access while sharing basic storage resources. Furthermore, existing solutions lack a robust front-end interception and back-end deduplication mechanism to address the issue of duplicate file submissions, easily leading to wasted storage resources and filename conflicts. Therefore, this paper proposes a cross-network one-way file transfer and sharing method and system based on filename encoding to solve these problems. Summary of the Invention

[0004] (a) Technical problems to be solved To address the shortcomings of existing technologies, this invention provides a cross-network one-way file transfer and sharing method and system based on filename encoding. It has advantages such as embedding control information encoding into the filename, enabling refined file sharing control without the need for a reverse control channel in a physically isolated environment. It solves problems such as unreliable status, insufficient isolation, and duplicate submissions in existing technologies.

[0005] (II) Technical Solution The technical solution of this invention to solve the above-mentioned technical problems is as follows: A cross-network one-way file transfer and sharing method based on filename encoding, comprising the following steps: S1: The sending client generates a structured encoded filename, wherein the encoded filename sequentially includes a version number, extraction code, download count threshold, retention expiration time stamp, and original filename in a preset format, wherein the version number is used to identify the transfer protocol version to support compatibility with multiple client versions; S2: The client writes the file to be transferred to the temporary storage area of ​​the first network FTP server with the temporary name "{encoded filename}.uploading". The network gateway transfer program only scans files with the suffix ".ok", so files in the upload state will not be triggered for transfer; S3: After the file is completely written to the first network FTP server and the FTP data connection is closed normally, the client uses the RNFR and RNTO groups of the standard FTP protocol. The combined instruction executes a renaming operation, renaming the file to "{encoded filename}.ok". The RNFR and RNTO combined instructions are atomic in the standard FTP protocol, ensuring that the renaming operation is uninterrupted and the intermediate state cannot be observed. S4: The network gateway ferry program scans the target directory of the first network FTP server at a preset fixed period. Only when a file with the suffix ".ok" is detected, a one-way physical isolation ferry operation is performed, transmitting the file to the second network FTP server without feedback. S5: The HTTP file service module on the second network side parses the encoded filename of the file in the second network FTP server and extracts all control information. The receiving end user accesses the HTTP service through a web browser and enters the extraction code. The HTTP service sequentially completes the extraction code authorization verification, deducts the remaining download counts, and determines the validity period. After all verifications are successful, the file download service is provided to the user.

[0006] The beneficial effects of this invention are: 1) The cross-network one-way file transfer and sharing method and system based on filename encoding has the advantages of achieving fine-grained file sharing control without the need for a reverse control channel in a physically isolated environment by embedding control information encoding into the filename.

[0007] 2) This cross-network one-way file transfer and sharing method and system based on filename encoding has the advantages of mechanisms such as atomic state transition, prefix logical isolation, multi-level deduplication, and duplicate submission interception.

[0008] Based on the above technical solution, the present invention can be further improved as follows.

[0009] Furthermore, the method for generating the extraction code in step S1 is as follows: S1.1: Collect the millisecond-level timestamp T, the original filename F, and the random number R when the file is submitted; S1.2: Concatenate the three in order and perform a SHA-256 hash operation to obtain the hash value H; S1.3: Encode the hash value H using Base64 to obtain the string S; S1.4: Filter the "+", "=", and " / " characters in the string S and extract the first 5 characters as the extraction code C.

[0010] Furthermore, it also includes multi-level deduplication and conflict resolution steps: Level 1: Before submitting a file, the sending client queries the first network FTP server. If a file with the same original filename exists and is being transferred, duplicate submissions are blocked. If a file with the same original filename has already been transferred within a preset time, the user is prompted for secondary confirmation. Level 2: Before the file is transferred to the second network FTP server, the hash digest of the file to be written is calculated and compared with the hash digest of a file already existing in the target path. If the hashes match, the writing is skipped and only the metadata is refreshed. Level 3: If the hashes do not match but the filenames are the same, an incrementing sequence number is appended to the original filename for renaming. Level 4: When downloading a file, a subfolder is created based on the minute-level timestamp of the operation time. Files with the same name downloaded within the same minute are placed into the corresponding subfolder, and then the Level 2 and Level 3 steps are executed.

[0011] Furthermore, the encoded file name generated in step S1 also includes a user-unique identifier prefix, which can be any one of email account name, employee ID, or regional platform code; in step S5, when the HTTP service module responds to a user request, it filters the file list based on the identity information of the currently logged-in user and only displays files whose file name prefix matches the user identifier.

[0012] Furthermore, it also includes a ferry status detection step: when the sending client opens the ferry interface, it performs an FTPLIST operation to count the number of files with the ".ok" suffix in the first network FTP server; if the number exceeds a preset threshold, it prompts the user "The ferry program is busy, please check if the network gateway is abnormal"; if the user does not exit the interface, the client continues to poll at a preset period, but does not block the user interface operation.

[0013] Furthermore, the cross-network one-way file transfer and sharing system based on filename encoding includes: a client device on the first network side, used to generate a structured encoded filename containing a version number, extraction code, download count threshold, retention expiration time stamp, user unique identifier prefix, and original filename; write the file to be transferred to the first network FTP server with the temporary name "{encoded filename}.uploading"; and after the file is completely written and the data connection is closed, perform an atomic renaming operation using the RNFR and RNTO commands of the FTP protocol to rename the file to "{encoded filename}.ok"; the first network FTP server... The P server stores temporary files being uploaded and files with the ".ok" extension awaiting transfer. The network gateway transfer device scans the target directory of the first network FTP server at a preset fixed period, performing unidirectional physical isolation transfer only on files with the ".ok" extension, copying the files to the second network FTP server. The second network FTP server stores the transferred files. The HTTP file service device on the second network side parses the encoded filenames of files on the second network FTP server, verifies the extraction code submitted by the receiving user, deducts download counts and determines validity periods, and provides file download services to the user.

[0014] Furthermore, the client device has a built-in extraction code generation unit, which is used to collect millisecond-level timestamps, original file names and random numbers, and generate a 5-digit authorized extraction code after SHA-256 hash operation and Base64 encoding and filtering special characters.

[0015] Furthermore, the HTTP file service device incorporates a multi-level deduplication unit and a user logic isolation unit; the multi-level deduplication unit is used to perform hash comparison, automatic renaming, and timestamp bucketing operations; the user logic isolation unit is used to filter the file list based on the unique identifier of the currently logged-in user.

[0016] Furthermore, the client device has a built-in ferry status detection unit, which is used to perform FTPLIST operations to count the number of files with the ".ok" suffix in the first network FTP server. When the number exceeds a preset threshold, a prompt is issued to the user, and the number is continuously polled at a preset period. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the structure of the present invention; Figure 2 This is a flowchart of the short extraction code generation algorithm of the present invention; Figure 3 This is a diagram illustrating the format of the one-way communication protocol based on filename encoding according to the present invention. Figure 4This is a timing diagram of the FTP atomic state transitions of the present invention; Figure 5 This is a flowchart of the multi-level deduplication and conflict resolution strategy of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Example 1, by Figure 1-5 A cross-network one-way file transfer and sharing method based on filename encoding is presented, applied between a first network and a second network physically isolated unidirectionally by a network gateway. The first network deploys a client and a first network FTP server, while the second network deploys a second network FTP server and an HTTP file service module. The method includes the following steps: S1: The sending end deploys and runs the GCAPP client on dedicated terminals such as the decoding box. Users can drag and drop files, capture... Figure 1 Submit the file to be transferred through the one-click transfer or video download entry. The client first generates a structured encoded file name containing the version number, extraction code, download count threshold, expiration time stamp of the retention period and the original file name according to the preset encoding format. The version number is used to identify the transfer protocol version to support compatibility of multiple client versions. S2: The client writes the file to be transferred to the temporary storage area of ​​the private network FTP server on the first network side with the temporary name "{encoded file name}.uploading". During this period, the third-party transfer program running on the network gateway side will only scan files with the suffix ".ok" and will not transfer the file that is in the upload state. S3: After the file is completely written to the first network FTP server and the FTP data connection is closed normally, the client immediately sends the RNFR and RNTO commands of the standard FTP protocol to the first network FTP server to atomically rename the file to "{encoded file name}.ok". The combination of RNFR and RNTO commands is atomic in the standard FTP protocol, ensuring that the renaming operation cannot be interrupted and the intermediate state cannot be observed. S4: The network gateway transfer program scans the target directory of the first network FTP server at a preset fixed period of 5 seconds. When a file with the suffix ".ok" is detected in the next scan cycle, it confirms that the file has been written and is in a stable state. Then, it performs a one-way physical isolation transfer operation to transfer the file to the target storage area of ​​the FTP server on the second network side without feedback. S5: After the file arrives at the second network FTP server, the background script moves it to the download directory of the HTTP file service that is on the same machine as the FTP server or accessible on the intranet. The HTTP file service module on the second network side automatically parses the encoded filename of the file in the second network FTP server and extracts all the control information contained therein. The receiving user accesses the web interface of the HTTP file service through a web browser, enters the corresponding extraction code, and the HTTP service sequentially completes the extraction code authorization verification, deduction of remaining download attempts, and validity period judgment. After all verifications are successful, the file download service is provided to the user.

[0020] Meanwhile, the client limits the bandwidth to 200Mbps for both file upload and download processes. When the file size to be uploaded exceeds 2GB, the client prompts the user to split it into smaller parts for transmission, reducing the cost of retransmission after a single failed transmission. After the file is downloaded, the client queries the server file size using the FTPSIZE command and the file modification time using the FTPMDTM command, and compares the query results with the local file information to verify integrity. The client also persistently stores the transfer records for the past 7 days locally, with a maximum of 100 records, and displays the file transfer status in real time in the navigation bar, screenshot bar, video download interface, and other entry points.

[0021] This method embeds complete control information into the filename, achieving sophisticated file-sharing functions such as download limit, validity period control, version compatibility, and authorized access—features typically requiring bidirectional control channels—under the stringent constraints of physical unidirectional isolation and the absence of a reverse control channel. Through the atomic state transition mechanism of ".uploading→.ok," it completely avoids the problem of incomplete file transfers (where files are ferried before being fully uploaded) in a purely software-based manner, without modifying the network gateway hardware or adding additional confirmation protocols. Furthermore, auxiliary measures such as bandwidth limiting, large file alerts, integrity verification, and persistent fetch records further enhance the stability, reliability, and user experience of file transfers.

[0022] In step S1, the filename encoding format is as follows: {Version Number}{Extraction Code}_{Download Count}_{Save Date}_{Original Filename}.Extension Meaning and technical effects of each field: (1) Version number (e.g., "1"): Identifies the current version of the ferry protocol, supports the coexistence of multiple client versions and smooth upgrades; when the system is upgraded from version v1 (based on IP filtering) to version v2 (based on extraction code verification), the HTTP service executes differentiated access control policies for different version files by parsing the version number field, avoiding compatibility issues during the upgrade. (2) Extraction code (5 Base64 characters): It is dynamically generated by the sender when submitting and serves as the authorization credential for the receiver to access the file. This mechanism upgrades the traditional coarse-grained control of "IP whitelist" to fine-grained authorization of "one person, one code". Even if multiple receivers are in the same intranet segment, they cannot access other people's files without authorization. (3) Number of downloads (numerical value): The number of downloads is embedded in the file name. Each time the HTTP service successfully responds to a download request, the number of downloads in the file name is logically deducted (or independent metadata is maintained). After the threshold is reached, the file is automatically cleaned up, so that the sender can have precise control over the sharing scope. (4) Save date (time stamp): Identifies the expiration time of the file. Before responding to the request, the HTTP service compares the current time with the save date. Expired files are automatically cleaned up to avoid the unlimited growth of FTP server storage resources. (5) Original file name: The user's original name is retained, which is convenient for the receiving end to identify and use after downloading.

[0023] By using the aforementioned filename encoding protocol, under the strict constraints of the network gateway that only allows unidirectional file streams and prohibits any reverse TCP / UDP control messages, refined functions such as "download count limit", "validity period control", "version compatibility" and "authorized access" are achieved, which usually require a bidirectional control channel to complete.

[0024] Meanwhile, the extraction code is generated using the following algorithm: S1.1: Collect the millisecond-level submission timestamp T, the original file name F, and the random number R; S1.2: Calculate the hash value H=SHA-256(T||F||R), where "||" represents concatenation; S1.3: Encode H using Base64 to obtain the string S; S1.4: Filter the "+", "=", and " / " characters in the string S, and take the first 5 valid characters as the extraction code C.

[0025] This algorithm, by introducing millisecond-level timestamps and random numbers, ensures that the extraction codes of the same file submitted repeatedly within a short period are almost always different. Through the strong collision resistance of SHA-256, the extraction code space is mapped to 62^5 ≈ 916 million (the effective character set of Base64 is AZ, az, and 0-9, a total of 62 characters). In a scenario with an average of 200 requests per day and a 5-day window period (n=1000), the collision probability P≈n(n-1) / (2M)≈0.0545%, which is within an acceptable range. This significantly reduces the probability of different files generating the same extraction code. Furthermore, the extraction code is strongly bound to the original filename, so even if an attacker obtains the extraction code of one file, they cannot construct requests to obtain other files, achieving file-level isolation of the extraction code and ensuring the security of file access. Further reduction in collisions can be achieved by extending the extraction code to 6 bits or shortening the window period.

[0026] This embodiment also includes multi-level deduplication and conflict resolution steps: Level 1 (Front-end Interception): Before submitting the file, the sending client queries the first network FTP server. If a record with the same original file name already exists and is being transferred, it will prompt "The current file is being transferred, please try again later," directly blocking the duplicate submission. If the file has been recently submitted and completed, it will prompt "Recently submitted, do you want to submit again?", requiring the user to confirm again. The second level (hash comparison): Before the file is transferred to the second network FTP server, the hash digest (MD5 or SHA-256) of the file to be written is calculated and compared with the hash digest of the file that already exists in the target path. If the hashes match, it is determined that the file is being transferred repeatedly. The writing is skipped silently, and only the metadata (such as the transfer time) is refreshed to avoid disk redundancy. Level 3 (Automatic Renaming): If the hashes are inconsistent and the filenames are the same, an incrementing sequence number is appended to the original filename for renaming (e.g., "file(1).txt", "file(2).txt"). It supports unlimited incrementing or configuration of a limit. Level 4 (Timestamp Folder): When downloading a file, create a subfolder based on the minute-level timestamp of the operation time (e.g., "20260314_1430 / "). After grouping files with the same name downloaded within the same minute into the corresponding subfolder, perform the steps of Level 2 and Level 3 above.

[0027] By employing a four-level strategy encompassing front-end interception, content deduplication, name resolution, and time-based binning, the system systematically addresses filename conflicts and storage redundancy issues in repetitive data transfer scenarios. Furthermore, each level can be enabled independently to adapt to different security and performance requirements.

[0028] In this embodiment, in step S1, when the sending client generates a structured encoded filename, it additionally embeds the unique identifier of the currently logged-in user as a prefix into the encoded filename. The unique identifier of the user can be any one of email account name, employee ID, or regional platform code. In step S5, when the HTTP service module on the second network side responds to the user's file list query request, it first obtains the identity information of the currently logged-in user, extracts the corresponding unique identifier of the user, and then traverses all files on the second network FTP server, only selecting files whose filename prefix matches the unique identifier of the currently logged-in user to display to the user. For version v2, a secondary filtering is further implemented through extraction code verification: even if the filename prefix is ​​guessed, download cannot be triggered without the correct extraction code.

[0029] By using a pure naming convention, multi-user-level data isolation was achieved without increasing the number of FTP accounts or modifying the FTP server configuration, reducing operational complexity and ensuring compatibility with existing IT infrastructure.

[0030] In this embodiment, a ferry status detection step is also included: When the user opens the ferry interface, the sending client automatically sends an FTP LIST execution command to the first network FTP server to obtain a list of all files in the target directory of the server, counts the number of files to be ferryed with the suffix ".ok", and if the counted number exceeds a preset threshold, a prompt message is immediately displayed to the user, informing the user that the ferry program is busy and suggesting checking if the network gateway is abnormal. If the user does not exit the ferry interface, the client will continuously send FTP LIST operation commands to the first network FTP server at a preset period to poll, update the number of files to be ferryed in real time, and adjust the prompt message according to the updated number. The entire polling process is executed asynchronously in the background and will not block the normal operation of the user interface; wherein, the preset threshold is 8-12 files and the preset period is 9-11 seconds.

[0031] This mechanism indirectly detects the health status of the gateway / ferry program through FTP directory scanning without relying on the gateway's API or status interface. It provides the sending end with backpressure capability and anomaly early warning capability, helping users to detect abnormal situations in the ferry process in a timely manner, thereby improving the system's maintainability and user experience.

[0032] Example 2, building upon Example 1, provides a cross-network one-way file transfer and sharing system based on filename encoding. It includes: a client device on the first network side, used to generate a structured encoded filename containing a version number, extraction code, download count threshold, expiration time stamp, user unique identifier prefix, and the original filename; writing the file to be transferred to the first network FTP server with the temporary name "{encoded filename}.uploading"; and after the file is completely written and the data connection is closed, performing an atomic renaming operation using the RNFR and RNTO commands of the FTP protocol to rename the file to "{encoded filename}.ok". The system consists of: a first network FTP server for storing temporary files being uploaded and files with the ".ok" extension awaiting transfer; a network gateway transfer device for scanning the target directory of the first network FTP server at a preset fixed interval of 5 seconds, performing one-way physical isolation transfer only on files with the ".ok" extension, and copying the files to the second network FTP server; a second network FTP server for storing files that have been transferred; and an HTTP file service device on the second network side for parsing the encoded filenames of files on the second network FTP server, verifying the extraction code submitted by the receiving user, deducting download counts and determining validity periods, and providing file download services to the user.

[0033] This system achieves cross-network one-way file transfer and sharing in a physically isolated environment by rationally dividing the functional modules into three security domains. The modules interact with each other through standard protocols, without the need for customized modifications to existing network gateway hardware and FTP services. It has good compatibility and scalability, and can effectively solve problems such as difficulty in transmitting control information, inability to guarantee file transfer integrity, and insufficient isolation of multi-user shared storage in existing technologies.

[0034] In this embodiment, the client device integrates an independent extraction code generation unit. This unit runs automatically when the client needs to generate an extraction code. First, it collects the millisecond-level timestamp of the file submission, the original filename of the file to be transferred, and a random number randomly generated within the unit. These three parameters are concatenated in order and then subjected to SHA-256 hashing to obtain a hash value. The hash value is then Base64 encoded to obtain the corresponding string. Subsequently, the string is automatically filtered for special characters such as "+", "=", and " / ". Finally, the first 5 valid characters are extracted from the filtered string as the authorized extraction code for this file transfer. By integrating the extraction code generation unit into the client device, local generation of the extraction code is achieved without relying on additional server-side services, reducing the network interaction links of the system and improving the efficiency and security of extraction code generation. At the same time, the generated extraction code has strong anti-collision and file-level isolation, which can effectively ensure the authorization security of file access.

[0035] Meanwhile, the HTTP file service device integrates a multi-level deduplication unit and a user logic isolation unit. When a file is transferred to the second network FTP server for final write, the multi-level deduplication unit calculates the hash digest of the file to be written, using MD5 or SHA-256 algorithms, and compares it with the hash digest of existing files on the target path. If the hashes match, the write operation is skipped, and only the metadata is refreshed. If the hashes do not match but the filenames are the same, an incrementing sequence number is automatically appended to the original filename for renaming. Simultaneously, when a user downloads a file, subfolders are created based on the minute-level timestamp of the download operation time. Files with the same name downloaded within the same minute are grouped into the corresponding subfolders, and hash comparison and automatic renaming operations are performed again. When responding to a user's file list query request, the user logic isolation unit first obtains the identity information of the currently logged-in user and extracts the corresponding unique user identifier. Then, it iterates through all files on the second network FTP server, only selecting files whose filename prefixes match the unique identifier of the currently logged-in user and displaying them to the user.

[0036] The client device incorporates a built-in ferry status detection unit. This unit performs FTP LIST operations to count the number of files with the ".ok" extension on the first network FTP server. When the number exceeds a preset threshold, it alerts the user and continuously polls for the number at a preset cycle. By incorporating the ferry status detection unit into the client device, real-time indirect detection of the health status of the gateway and ferry program is achieved. This allows for timely feedback to the user on the ferry system's operational status, helping the user to detect anomalies in advance and take appropriate measures, thereby improving system availability and user experience.

[0037] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0038] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A cross-network one-way file transfer and sharing method based on filename encoding, characterized in that: Includes the following steps: S1: The sending client generates a structured encoded file name. The encoded file name contains, in a preset format, a version number, an extraction code, a download count threshold, a retention expiration time stamp, and the original file name. The version number is used to identify the version of the ferry protocol to support compatibility with multiple client versions. S2: The client writes the file to be transferred to the temporary storage area of ​​the first network FTP server with the temporary name "{encoded file name}.uploading". The network gateway transfer program only scans files with the suffix ".ok", so files in the upload state will not be transferred. S3: After the file is completely written to the first network FTP server and the FTP data connection is closed normally, the client performs a renaming operation using the RNFR and RNTO combination instructions of the standard FTP protocol, renaming the file to "{encoded filename}.ok". The RNFR and RNTO combination instructions are atomic in the standard FTP protocol, ensuring that the renaming operation cannot be interrupted and the intermediate state cannot be observed. S4: The network gateway transfer program scans the target directory of the first network FTP server at a preset fixed period. Only when a file with the extension ".ok" is detected, a one-way physical isolation transfer operation is performed to transfer the file to the second network FTP server without feedback. S5: The HTTP file service module on the second network side parses the encoded filename of the file in the second network FTP server and extracts all control information; the receiving user accesses the HTTP service through a web browser and enters the extraction code. The HTTP service sequentially completes the extraction code authorization verification, deduction of remaining download counts, and validity period judgment. After all verifications are successful, the file download service is provided to the user.

2. The cross-network one-way file transfer and sharing method based on filename encoding according to claim 1, characterized in that: The method for generating the extraction code in step S1 is as follows: S1.1: The millisecond-level timestamp T, the original filename F, and the random number R at the time of file submission; S1.2: Concatenate the three elements in order and then perform a SHA-256 hash operation to obtain the hash value H; S1.3: Base64 encoding the hash value H to obtain the string S; S1.4: Filter the "+", "=", and " / " characters in string S, and extract the first 5 characters as the extraction code C.

3. The cross-network one-way file transfer and sharing method based on filename encoding according to claim 1, characterized in that: It also includes multi-level deduplication and conflict resolution steps: Level 1: Before submitting a file, the sending client queries the first network FTP server. If a file with the same original filename exists and is being transferred, the duplicate submission is blocked. If a file with the same original filename has been transferred within a preset time, the user is prompted for secondary confirmation. Level 2: Before the file is transferred to the second network FTP server, the hash digest of the file to be written is calculated and compared with the hash digest of the file that already exists in the target path. If the hashes match, the writing is skipped and only the metadata is refreshed. Level 3: If the hashes are inconsistent and the filenames are the same, rename the filename by appending an incrementing sequence number to the original filename. Level 4: When downloading files, create subfolders based on the minute-level timestamp of the operation time. After grouping files with the same name downloaded within the same minute into the corresponding subfolders, execute the steps of Level 2 and Level 3 above.

4. The cross-network one-way file transfer and sharing method based on filename encoding according to claim 2, characterized in that: The encoded file name generated in step S1 also includes a user-unique identifier prefix, which can be any one of email account name, employee ID, or regional platform code; in step S5, when the HTTP service module responds to a user request, it filters the file list based on the identity information of the currently logged-in user and only displays files whose file name prefix matches the user identifier.

5. The cross-network one-way file transfer and sharing method based on filename encoding according to claim 4, characterized in that: It also includes a ferry status detection step: when the sending client opens the ferry interface, it performs an FTP LIST operation to count the number of files with the ".ok" suffix in the first network FTP server; if the number exceeds a preset threshold, it prompts the user "The ferry program is busy, please check if the network gateway is abnormal"; if the user does not exit the interface, the client continues to poll at a preset period, but does not block the user interface operation.

6. The cross-network one-way file transfer and sharing system based on filename encoding according to any one of claims 1-5, characterized in that: include: The client device on the first network side is used to generate a structured encoded file name containing a version number, extraction code, download count threshold, expiration time stamp of the retention period, user unique identifier prefix and original file name, write the file to be transferred to the first network FTP server with the temporary name "{encoded file name}.uploading", and after the file is completely written and the data connection is closed, perform an atomic renaming operation through the RNFR and RNTO instructions of the FTP protocol to rename the file to "{encoded file name}.ok". The first network FTP server is used to store temporary files being uploaded and files with the ".ok" extension that are yet to be transferred. The network gateway transfer device is used to scan the target directory of the first network FTP server at a preset fixed period, and only perform one-way physical isolation transmission for files with the ".ok" suffix, copying the files to the second network FTP server; A second network FTP server is used to store the files that have been transferred. The HTTP file service device on the second network side is used to parse the encoded filenames of files in the second network FTP server, verify the extraction code submitted by the receiving user, deduct download counts and determine validity period, and provide file download services to the user.

7. The cross-network one-way file transfer and sharing system based on filename encoding according to claim 6, characterized in that: The client device has a built-in extraction code generation unit. The extraction code generation unit is used to collect millisecond-level timestamps, original file names and random numbers, and generate a 5-digit authorized extraction code after SHA-256 hash operation and Base64 encoding and filtering special characters.

8. The cross-network one-way file transfer and sharing system based on filename encoding according to claim 6, characterized in that: The HTTP file service device has a built-in multi-level deduplication unit and a user logic isolation unit; the multi-level deduplication unit is used to perform hash comparison, automatic renaming and timestamp bucketing operations; the user logic isolation unit is used to filter the file list based on the unique identifier of the currently logged-in user.

9. The cross-network one-way file transfer and sharing system based on filename encoding according to claim 7, characterized in that: The client device has a built-in ferry status detection unit, which is used to perform FTPLIST operations to count the number of files with the ".ok" suffix in the first network FTP server. When the number exceeds a preset threshold, a prompt is issued to the user, and the number is continuously polled at a preset period.

Images