Table processing method and system

Abstract

The invention provides a table processing method and system, and the method comprises the steps that a front-end module obtains header data and corresponding table data according to an initial query condition, generates table configuration information and authority information, and transmits the table configuration information and the authority information to a rear end; the table configuration information comprises a header configuration parameter, a header merging strategy and a table data parameter. And the back-end module obtains the to-be-processed header, combines the to-be-processed header to obtain a target header, generates a to-be-exported table in combination with the target header, the table data parameters, the preset paging parameters and the permission information, and exports the to-be-exported table as a file in a preset format. According to the method, dynamic adaptation of the header, efficient processing of data paging and authority control of fine granularity can be achieved, table export flexibility, safety and efficiency are improved, and diversified business requirements are met.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a table processing method and system. Background Technology

[0002] In enterprise information management and data statistical analysis scenarios, enterprise data is typically stored in data tables. When users need to view the data, the data tables can be exported as Excel spreadsheets. However, in practical applications, data tables may be frequently adjusted due to changes in business needs. Specifically, data tables exhibit characteristics such as dynamic header hierarchy and diverse data formats. This places higher demands on the functionality of exporting data tables to Excel spreadsheets.

[0003] Current mainstream solutions are centered around a Java backend, relying on plugins such as POI (Apache POI) and the Java Excel API (JXL). The frontend initiates requests through progressive JavaScript frameworks (Vue.js, VUE) or JavaScript libraries (React, React), forming a complete table export process. These mainstream solutions include specific implementations such as POI hard-coding, dynamic export from low-code platforms, and semi-dynamic configuration.

[0004] However, these specific implementation solutions are insufficient in terms of flexibility, access control, adaptation to complex scenarios, and processing of large amounts of data, making it difficult to meet the actual needs of enterprises. Summary of the Invention

[0005] The purpose of this application is to provide a table processing method and system to address the shortcomings of the existing technology mentioned above, so as to solve the problems that the existing technology is insufficient in terms of flexibility, access control, adaptation to complex scenarios and processing of large amounts of data, and is difficult to meet the actual needs of enterprises.

[0006] To achieve the above objectives, the technical solution adopted in this application is as follows: In a first aspect, this application provides a table processing method applied to a table processing system, the table processing system comprising: a front-end module running on a terminal device and a back-end module running on a server, the method comprising: The front-end module obtains the header data and the corresponding table data based on the initial query conditions. The front-end module generates table configuration information and permission information based on the initial query conditions, the table header data, and the table data, and sends the table configuration information and permission information to the back-end module. The table configuration information includes: table header configuration parameters, table header merging strategy, and table data parameters. The backend module obtains the header to be processed according to the table configuration information, and merges the header to be processed according to the header merging strategy to obtain the target header. The backend module generates a table to be exported based on the target table header, the table data parameters, the preset data pagination parameters, and the permission information, and exports the table to be exported as a table file in a preset format.

[0007] Optionally, the front-end module generates table configuration information and permission information based on the initial query conditions, the table header data, and the table data, including: The header configuration parameters are generated based on the header data, and the header configuration parameters are used to indicate the interface for obtaining the header data. The header merging strategy is determined based on the header data; The table data parameters are generated based on the table data corresponding to the header data, and the table data parameters are used to indicate the interface for obtaining the table data. The permission information is determined based on the user identifier of the initial query conditions.

[0008] Optionally, determining the header merging strategy based on the header data includes: Traverse each header item of the header to be processed, and determine whether the header item is a single-level header or a double-level header based on the structural identifier of each header item; If the header item is a parent column in a two-level header, then multiple header items to be merged are determined based on the child columns contained in the header item.

[0009] Optionally, the backend module generates a table to be exported based on the target table header, the table data parameters, preset data pagination parameters, and the permission information, including: Based on the table data parameters and the preset data pagination parameters, obtain the table data corresponding to the target table header to obtain the initial table; Based on the permission information, the data in the initial table is subjected to permission control processing to obtain the processed table; The processed table is then subjected to data transformation to obtain the table to be exported corresponding to the initial query conditions.

[0010] Optionally, obtaining the table data corresponding to the target table header based on the table data parameters and preset data pagination parameters to obtain the initial table includes: The table page corresponding to the target table header is obtained from the acquisition interface indicated by the table data parameters according to the preset pagination parameters, and the table page includes table data; Based on the total amount of data in the table corresponding to the target header and the amount of data already acquired, determine whether the currently acquired table page is the last page; If not, then the next table page corresponding to the target table header is obtained from the acquisition interface indicated by the table data parameters according to the preset pagination parameters, until all table data corresponding to the target table header is obtained; The initial table is obtained by combining the target header and all table data corresponding to the target header.

[0011] Optionally, the step of performing permission control processing on the data of the initial table according to the permission information to obtain the processed table includes: Iterate through each column in the initial table, and for the current column, obtain the permission configuration information of the current column; Based on the permission configuration information and permission information of the current column, determine whether to display the data of the current column; If the data in the current column is not displayed, a preset hidden identifier is added to the current column.

[0012] Optionally, the permission configuration information is used to indicate the set of user roles that can view the current column; The step of determining whether to display the data in the current column based on the permission configuration information and the permission information of the current column includes: If the user role corresponding to the permission information has a corresponding user role in the user role set, then it is determined to display the data in the current column; If the user role corresponding to the permission information does not have a corresponding user role in the user role set, then it is determined that the data in the current column will not be displayed.

[0013] Optionally, the step of performing data transformation on the processed table to obtain the table to be exported corresponding to the initial query conditions includes: Iterate through each column of the processed table. For the current column, if the current column contains a hidden identifier, then fill the data in the current column with a preset character. If the current column does not contain the hidden identifier, the data in the current column is converted based on a preset data format conversion strategy to obtain a processed data column. After the data conversion of all data columns is completed, a converted table is obtained. The converted tables are merged according to a preset table merging strategy to obtain the table to be exported.

[0014] Optionally, the step of merging the converted table according to a preset table merging strategy to obtain the table to be exported includes: Traverse each column in the transformed table to determine at least one merged area of ​​the transformed table and the merge information of each merged area. The merge information includes: starting row index, number of merged rows, starting column index, and number of merged columns. The merged regions are merged based on their merge information to obtain the table to be exported.

[0015] Secondly, embodiments of this application also provide a table processing system, the table processing system comprising: a front-end module running on a terminal device and a back-end module running on a server, wherein when the table processing system is running, the front-end module and the back-end module are used to execute the table processing method described in the first aspect.

[0016] The beneficial effects of this application are as follows: Through the collaborative work of the front-end and back-end modules, efficient export of dynamic tables to preset-format Excel files is achieved. The front-end module accurately obtains the table headers and corresponding table data, integrates and generates table configuration information and permission information containing header configuration, merging strategies, data parameters, and transmits it, ensuring the integrity and specificity of parameter transmission. The back-end module merges the headers to be processed based on the table configuration information to obtain the target header, and then combines the target header, data parameters, pagination parameters, and permission information to generate and export the table. The column names, widths, alignment, and hierarchical relationships of the headers are all dynamically defined through configuration parameters without requiring code modification. The overall solution supports dynamic header adaptation, data pagination processing, and fine-grained permission control, effectively improving the flexibility and adaptability of table export, avoiding memory overflow issues when exporting large amounts of data, ensuring data export security, and adapting to table export needs in different business scenarios, thus improving the overall efficiency of table processing and export.

[0017] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This paper illustrates a schematic diagram of the architecture of a table processing system provided in an embodiment of this application. Figure 2 A flowchart of a table processing method provided in an embodiment of this application is shown; Figure 3This document illustrates a flowchart illustrating how to determine table configuration information and permission information according to an embodiment of this application. Figure 4 This document illustrates a flowchart of a method for determining header items to be merged, as provided in an embodiment of this application. Figure 5 This document illustrates a flowchart of a method for generating a table to be exported, as provided in an embodiment of this application. Figure 6 This application provides a flowchart for generating an initial table according to an embodiment. Figure 7 This document illustrates a flowchart of an access control method provided in an embodiment of this application. Figure 8 This application provides a flowchart illustrating a method for determining whether to display data in the current column, as illustrated in an embodiment of this application. Figure 9 This document illustrates a flowchart of another method for generating a table to be exported, as provided in an embodiment of this application. Figure 10 This document illustrates a flowchart of a method for generating a table to be exported, as provided in an embodiment of this application. Figure 11 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0021] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0022] In enterprise information management and data statistical analysis scenarios, dynamic tables are the core data display medium. Their header structure, data dimensions, and column permission control need to be flexibly adjusted according to business needs, and exporting them to Excel files is a frequent requirement. Existing mainstream solutions include POI hard coding, dynamic export from low-code platforms, and semi-dynamic configuration.

[0023] The POI hard-coding scheme is suitable for exporting reports with fixed formats. The backend uses the POI plugin to hard-code the Excel header structure, data mapping relationships, and cell styles. The frontend only passes the query conditions; the header column names, column order, and data format are all fixedly configured by the backend code. If the table header structure, column order, or data format changes, the code needs to be modified to adjust it. Therefore, it cannot quickly adapt to dynamic business needs and also suffers from high maintenance costs.

[0024] Low-code platform dynamic export solutions are suitable for exporting simple tables. The low-code platform provides a visual configuration interface where users can drag and drop table headers, data sources, and export styles. The platform backend encapsulates POI capabilities to generate and export the table. However, this method only supports basic header customization, cannot adapt to nested double headers or complex cell merging rules, has poor scalability, cannot implement fine-grained column permission control based on user roles, cannot automatically recognize and process special data formats, and has low efficiency in processing large amounts of data.

[0025] The semi-dynamic configuration scheme is suitable for scenarios with few changes in the table header structure and simple permission control. The backend reserves some configuration items, but the table header hierarchy, merging rules and data format still need to be adapted by the code. The frontend can only pass a limited number of configuration parameters and cannot fully realize the dynamic adjustment of the table through configuration. Furthermore, the column hiding logic can only hide based on fixed conditions and cannot be dynamically judged based on user roles and business scenarios, resulting in poor adaptability. In addition, this scheme does not have a pagination loading mechanism designed for large data volumes, which will lead to long table export times if the data volume is large.

[0026] In summary, existing solutions are inadequate in terms of flexibility, access control, adaptation to complex scenarios, and processing of large amounts of data, making it difficult to meet the actual needs of enterprises.

[0027] Based on this, this application proposes a table processing method for use in a table processing system. Figure 1 This is a schematic diagram of the architecture of a table processing system provided in an embodiment of this application, with reference to... Figure 1 The system includes a front-end module, a back-end module, and an interaction module. The front-end module runs on the terminal device, while the back-end and interaction modules can run on the server. The interaction module is used to facilitate data exchange between the back-end and front-end modules.

[0028] Next, combine Figure 2 This application describes the form processing method, which can be applied to... Figure 1 The table processing system shown is, for example Figure 2 As shown, the method includes: S201. The front-end module obtains the header data and the corresponding table data based on the initial query conditions.

[0029] The front-end module can be a functional module deployed on the user terminal, responsible for receiving user operations, collecting query conditions, configuring table parameters, initiating processing requests, and receiving exported files. Its core function is to realize the interaction between the user and the system and the transmission of parameters.

[0030] Initial query criteria can be query parameters set by the user based on business needs, used to filter target data, such as year, department, budget version number, cost center, etc., and serve as the basis for obtaining header data and table data.

[0031] The header data describes information about the table's column structure, including column names, column widths, alignment, data format (decimal places, thousands place), hierarchical relationships (single / double level), and sub-column relationships. For example, the "Budget Version Number" column has a width of 80 and is centered. The table data consists of the specific business data corresponding to the header data and is the core content of the table, such as the amount data for each budget item in a department for a specific year.

[0032] After the user selects query criteria in the front-end module's visual interface, the front-end module can retrieve table header data in two ways: one is by calling a preset table header interface to obtain dynamic table header data from the server in real time; the other is by directly using locally configured table header information. The retrieved table header data includes attributes such as column names, column widths, alignment, decimal places, thousands separators, and hierarchical relationships. Simultaneously, based on the initial query criteria and table header data, the front-end module can call a data interface to retrieve the corresponding table data. The data interface returns a JSON response containing business data, which the front-end module then parses to extract the valid table data.

[0033] After obtaining the header data and table data, the front-end module can perform a validity check on the data to ensure that the column structure of the header data is complete and that the column identifiers of the table data are consistent with those of the header data, thus avoiding subsequent processing failures due to data mismatch.

[0034] S202. The front-end module generates table configuration information and permission information based on the initial query conditions, table header data, and table data, and sends the table configuration information and permission information to the back-end module.

[0035] Table configuration information is a standardized set of configuration parameters generated by the front-end module based on initial query conditions, header data, and table data. It guides the back-end module in table processing. Table configuration information includes: header configuration parameters, header merging strategy, and table data parameters.

[0036] The header configuration parameters indicate the source of the header data, supporting both API retrieval and local configuration. For example, the header API Uniform Resource Locator (URL) is " / ODPS2 / ZJYFYE022 / FRM_QUERY". The header merging strategy defines the parameter set for header cell merging rules, including the triggering conditions and execution logic for horizontal and vertical merging. For example, in a two-level header, the parent column needs to merge its two child columns. The table data parameters indicate the source of the table data, including the data API URL and corresponding query conditions. For example, the data API URL is " / ODPS2 / ZJYFYE022 / FRM_QUERY", and the query conditions include the year "2025" and the budget version number "V1.0".

[0037] Permission information refers to access control information associated with user identity. For example, it can be represented by user role codes to control the visibility of table columns. For instance, the role of a financial administrator can only see the detailed columns, while the role of a department head can only see the summary columns.

[0038] The front-end module can integrate scattered initial query conditions, header data, and table data into standardized configuration and permission information, thereby reducing the complexity of data transmission between the front-end and back-end, while ensuring that the back-end module can accurately understand user needs. The table configuration information clarifies the table's structural rules and data source, while the permission information defines the control boundaries for data access. Together, they provide a complete basis for the back-end module's processing.

[0039] In one possible implementation, the front-end module can extract the header source identifier and column attribute set from the acquired header data to form standardized header configuration parameters. These parameters inform the back-end module of the header data acquisition method and structural details. Furthermore, the front-end module can analyze the hierarchical relationship of the header data and determine the header merging strategy. It can then extract the corresponding interface URL and initial query conditions to form table data parameters, thus enabling the back-end module to clearly define the path and filtering conditions for acquiring table data. Additionally, the front-end module can automatically obtain the current user's user code as permission information, which indicates the user's data viewing permissions.

[0040] After obtaining the table configuration and permission information, the front-end module can integrate the table configuration and permission information into JSON format request parameters, and initiate a POST request through a dedicated interaction instance. Figure 1The interactive module shown sends parameters to a designated interface of the backend module. During transmission, the request header carries an authentication token to ensure data transmission security, and a timeout is set to adapt to scenarios with large data volumes. For example, the interactive module can forward the request to the designated interface of the backend module through a reverse proxy. The backend module receives the JSON-formatted table configuration parameters and permission information through the interface, completing the parameter transmission.

[0041] S203. The backend module obtains the header to be processed based on the table configuration information, and merges the headers according to the header merging strategy to obtain the target header.

[0042] Backend modules can be functional modules deployed on servers, responsible for receiving configuration and permission information from the frontend, and executing processing logic such as header merging, data pagination retrieval, permission control, format conversion, and file generation.

[0043] The backend module first needs to obtain the original header to be processed based on the table configuration information, and then adjust the header structure through a header merging strategy to ensure that the header meets the user's expected display format. The core of the merging process is to solve the alignment problem of single / double-layer headers, and improve the readability and professionalism of the table by merging cells horizontally or vertically.

[0044] The header data to be processed can be the raw header data obtained by the backend module based on the header configuration parameters. It has not been merged and may contain single-layer or double-layer structures, which need to be adjusted to a standardized structure through merging strategies. The target header data can be the final header structure obtained after merging the header data to be processed. It has completed horizontal / vertical merging and style unification, and meets the display requirements of Excel export.

[0045] Optionally, the backend module can receive the table configuration information passed from the frontend, parse the table header configuration parameters, and if it is obtained through an interface, call the interface in the table header configuration parameters to obtain the table header data. If it is configured locally, directly read the table header information. Both methods are eventually converted into a table header to be processed in a unified format.

[0046] After obtaining the header to be processed, the header can be hierarchically identified, horizontally merged, vertically merged, and styled uniformly processed based on the header merging strategy to generate the target header, which will then be used as the column identifier for the table to be exported.

[0047] S204. The backend module generates the table to be exported based on the target table header, table data parameters, preset data pagination parameters, and permission information, and exports the table to be exported as a table file in a preset format.

[0048] The data pagination parameters can be configuration parameters used by the backend module to control data loading, including the current page, the number of records per page, and whether it is the last page. The default configuration can be, for example, 1000 records per page to avoid memory overflow caused by large amounts of data. The preset format table file can refer to an Excel file that conforms to industry-standard specifications, retaining the merged header structure, data format, and access control results.

[0049] The backend module needs to integrate the target table header, table data, pagination rules, and access control to complete the data filtering, transformation, and optimization, generate standardized tables that meet export requirements, and finally convert them into general Excel files to ensure that the exported files meet business usage needs.

[0050] Optionally, the backend module can obtain table data based on data pagination parameters, set permissions for the table data based on permission information to control the display or hiding of the table data according to the user's permissions, perform data transformation processing on the table data to ensure standardized and consistent display of the data, and perform merging processing on the table data to finally obtain the table to be exported.

[0051] For example, the backend module can convert the table to be exported into a byte stream and encode it into a string, then encapsulate the string in the response and return it to the frontend. Upon receiving the response, the frontend module decodes the Base64 string into a Blob object, triggers the browser to download the file, and generates an Excel file in .xlsx format.

[0052] In this embodiment, the efficient export of dynamic tables to preset-format Excel files is achieved through the collaborative work of the front-end and back-end modules. The front-end module accurately obtains the table headers and corresponding table data, integrates and generates table configuration information and permission information containing header configuration, merging strategies, data parameters, and transmits it, ensuring the integrity and specificity of parameter transmission. The back-end module merges the headers to be processed based on the table configuration information to obtain the target header, and then combines the target header, data parameters, pagination parameters, and permission information to generate and export the table. The column names, widths, alignment, and hierarchical relationships of the headers are all dynamically defined through configuration parameters without requiring code modification. The overall solution supports dynamic header adaptation, data pagination processing, and fine-grained permission control, effectively improving the flexibility and adaptability of table export, avoiding memory overflow issues when exporting large amounts of data, ensuring data export security, and adapting to table export needs in different business scenarios, thus improving the overall efficiency of table processing and export.

[0053] The following describes the steps taken by the aforementioned front-end module to generate table configuration and permission information based on the initial query conditions, header data, and table data. Figure 3 As shown, the above step S201 includes: S301. Generate header configuration parameters based on header data.

[0054] The header configuration parameters indicate the interface for retrieving header data. The header data retrieval interface refers to the interface that provides header configuration information. It supports returning attributes such as column names, widths, alignment, and sub-column associations for single-level / double-level headers, responding to frontend requests in JSON format. It is the carrier for dynamically retrieving header data.

[0055] After the front-end module obtains the header data, it can parse the data source type. For example, if the header data comes from a network interface, the URL of that interface is extracted as SHEET_HEAD_URL; if it comes from local configuration, meaning it can be obtained directly from the local machine, it is marked as SHEET_CONFIG type. Here, SHEET_HEAD_URL is the interface type parameter for the header data, and SHEET_CONFIG is the local configuration type parameter.

[0056] The front-end module can encapsulate table header configuration parameters in a standardized format, including data source type identifiers and corresponding retrieval interface information, such as the interface type parameter "SHEET_HEAD_URL: / ODPS2 / ZJYFYE022 / FRM_QUERY" or the local configuration type parameter "SHEET_CONFIG:{tableColumn:[...]}".

[0057] S302. Determine the header merging strategy based on the header data.

[0058] Optionally, the front-end module can iterate through each column of the header data and analyze the hierarchical characteristics of the header data to obtain a list of header merging rules. The list of merging rules records the headers that need to be merged horizontally or vertically, as well as the number of headers to be merged. The list of merging rules is then encapsulated as a header merging strategy and incorporated into the table configuration information in JSON format, specifying parameters such as the column index to be merged and the number of rows / columns to be merged.

[0059] S303. Generate table data parameters based on the table data corresponding to the header data.

[0060] The table data parameter indicates the interface used to retrieve the table data. This interface can be a network interface that provides business data.

[0061] The front-end module can associate the corresponding table business data with the table header data, determine the data source interface, and then encapsulate the query parameters and data source interface in the initial query conditions into table data parameters according to a standardized format.

[0062] S304. Determine permission information based on the user identifier of the initial query conditions.

[0063] Optionally, the front-end module can extract the user code from the user identifier associated with the initial query conditions and use the user code as permission information. The back-end module can parse user permissions based on the user code, thereby achieving column-level data hiding control.

[0064] In this embodiment, the generation logic and core function of each configuration item are clarified by standardizing the generation of header configuration parameters, header merging strategy, table data parameters, and permission information. The header configuration parameters and table data parameters enable precise location of data sources, thereby ensuring consistency in front-end and back-end data integration. The header merging strategy supports the structural alignment of headers at different levels, improving table readability. Permission information is generated based on user identifiers, enabling the back-end module to implement column-level permission control.

[0065] The following is a further explanation of the strategy for determining the header merging based on the header data, such as... Figure 4 As shown, step S302 above includes: S401. Traverse each header item of the header to be processed, and determine whether the header item is a single-level header or a double-level header based on the structural identifier of each header item.

[0066] Optionally, a header item can be a single column unit in the header to be processed, which is the basic unit that constitutes the header. The structural representation can be an identifier that distinguishes the hierarchical type of the header item, which is achieved by whether the header item contains a set of child columns. If child columns exist, it is the parent column of a two-level header; otherwise, it is a single-level header item.

[0067] A single-level header refers to a header structure where none of the header items have a child column, and the column hierarchy is unique. For example, a header may only contain columns for "Year," "Department," and "Amount." A two-level header can be a header structure where some header items contain child columns, with two levels of parent and child columns. For example, a header may have "Budget Information" as the parent column and contain child columns for "Budget Version Number" and "Budget Amount."

[0068] After obtaining the headers to be processed, the front-end module can iterate through each header item and extract its `children` attribute or set of child columns for each item. If the `children` attribute is empty or the number of child columns is 0, the header item is determined to be a single-level header item; if the `children` attribute is not empty and the number of child columns is ≥1, the header item is determined to be the parent column of a two-level header. The module records the level type of all header items, forming a level identifier list. For example, "single" is used to mark single-level header items, and "parent" is used to mark the parent column of a two-level header, providing a clear basis for subsequent merging processing. Simultaneously, the front-end module can also count the maximum header level, marked as 1 for single-level headers and 2 for two-level headers, used for calculating the row index of the merged area.

[0069] S402. If a header item is the parent column in a two-level header, then determine the multiple header items to be merged corresponding to the header item based on the child columns contained in the header item.

[0070] After the front-end module identifies a header item as a two-level parent column, it extracts the set of child columns from its `children` attribute and counts the number of child columns. Based on the number of child columns and the position of the header item, it determines the range of header items to be merged. For example, starting from the index of the parent column in the header to be processed, it continuously selects header items with the same number of child columns as the header items to be merged. It also records the correspondence between the parent column and the header items to be merged, obtaining a list of merge rules, and encapsulates this list as a header merging strategy.

[0071] In this embodiment, by traversing the header item parsing structure identifiers, single-level / double-level header types can be distinguished, providing a clear basis for the merging strategy. For double-level header parent columns, the range of header items to be merged is determined based on the number of child columns, ensuring hierarchical alignment. This achieves automatic identification of header levels and precise positioning of the merging range, avoiding the tedious manual configuration of merging rules, adapting to dynamically changing header structures, and making the exported Excel headers more standardized and readable.

[0072] The following is a further explanation of how the backend module generates the table to be exported based on the target table header, table data parameters, preset data pagination parameters, and permission information. Figure 5 As shown, step S204 above includes: S501. Obtain the table data corresponding to the target table header based on the table data parameters and the preset data pagination parameters to obtain the initial table.

[0073] The backend module can parse table data parameters, extract the table data retrieval interface and query conditions, and load preset pagination parameters. The backend module can send a request to the retrieval interface and pass the pagination parameters and query conditions to obtain the business data corresponding to the table header. After obtaining all the business data, it combines all the pagination data and the target table header to form the initial table.

[0074] S502. Perform permission control processing on the data in the initial table according to the permission information to obtain the processed table.

[0075] Each column in the table includes column configuration, which contains a hidden role attribute and a column hiding flag. The hidden role attribute is used to indicate the user role that cannot view the business data in that column.

[0076] The backend module can parse the role code in the permission information and traverse the column configuration of each column. If the user role indicated in the permission information exists in the hidden role attribute of the column, the column hidden flag is set to the preset value, thereby marking the column as a hidden column.

[0077] S503. Perform data transformation on the processed table to obtain the table to be exported corresponding to the initial query conditions.

[0078] The backend module can perform format conversions on the processed table's values ​​and dates, handle special characters, and show / hide business data in columns according to column hiding indicators. After completing all data conversions, a properly formatted and accurate table is obtained for export.

[0079] In this embodiment, the efficient and stable acquisition of large amounts of data is achieved through the collaboration of table data parameters and pagination parameters, avoiding memory overflow. Column-level control based on permission information accurately hides sensitive columns and ensures data security. Standardized data conversion processing unifies numerical and date formats and solves the problem of special characters.

[0080] The following is a further explanation of how to obtain the table data corresponding to the target table header based on the table data parameters and preset data pagination parameters to obtain the initial table. Figure 6 As shown, the above S501 step includes: S601. Obtain the table page corresponding to the target table header from the acquisition interface indicated by the table data parameters according to the preset pagination parameters. The table page includes table data.

[0081] The table page can be a single batch of data obtained from the data interface according to the pagination parameters. It contains all the business data in the batch, with 1000 data records per page by default. It is the basic unit that constitutes the complete table data.

[0082] The preset pagination parameters limit the number of data items loaded at a time and the batch identifier, while the table data parameters specify the data acquisition path and filtering conditions. Combining these two allows for precise batch data retrieval. By loading small amounts of data at a time, excessive memory consumption by large datasets is avoided, ensuring system stability while guaranteeing a precise match between the acquired table page data and the target table header column structure.

[0083] The backend module can parse the table data parameters, extract the data interface and query conditions, load the preset pagination parameters, integrate the pagination parameters with the query conditions, generate complete request parameters, and send a POST request to the interface indicated in the table data parameters. After the interface responds, it parses the returned result to obtain the table data of the current table page and converts it into a list data in a unified format, thereby ensuring that the data fields are consistent with the column identifiers of the target table header. At the same time, while receiving the table data, the backend module can also record the number of data rows in the current table page to obtain the amount of data obtained, providing a basis for determining whether it is the last page.

[0084] S602. Based on the total amount of data in the table corresponding to the target header and the amount of data already acquired, determine whether the currently acquired table page is the last page.

[0085] The total data volume can be the total number of business data rows corresponding to the target table header, obtained by parsing the fields returned by the data interface, and used to determine whether pagination loading is complete. The data volume already obtained can be the sum of the number of data rows of each table page that has been loaded, used to compare with the total data volume to determine whether to continue loading the next page of data.

[0086] The total data volume reflects the complete data scale corresponding to the target table header, while the amount of data already acquired reflects the current loading progress. Comparing the two allows for accurate determination of whether data loading has covered all data. Identifying the last page avoids invalid subsequent requests, improves data retrieval efficiency, and ensures that data is neither duplicated nor omitted.

[0087] If the amount of data already acquired + the number of records per page (1000) ≥ the total amount of data, then the current table page is determined to be the last page; otherwise, it is determined to be not the last page. For example, if the total amount of data is 5680 and the amount of data already acquired is 5000, and 5000 + 1000 ≥ 5680, then the currently loaded 6th page is the last page.

[0088] S603. If not, then obtain the next table page corresponding to the target table header from the acquisition interface indicated by the table data parameters according to the preset pagination parameters, until all table data corresponding to the target table header is obtained.

[0089] If the current table page is not the last page, it means there is still unloaded business data. The next table page needs to be retrieved by incrementing the pagination parameter. The loading logic is executed in a loop until all total data is covered, ensuring data integrity. Simultaneously, the pagination mechanism continuously controls memory usage to prevent system overload.

[0090] If the interface responds abnormally during the loading process, the error information can be recorded, the loading can be interrupted, and an exception message can be returned to ensure the reliability of data loading.

[0091] S604. Combine the target header and all table data corresponding to the target header to obtain the initial table.

[0092] The target table header provides the column structure and identifiers for the table, while all table data contains complete business information. Combining these two elements creates a structurally complete and data-rich initial table. The combination process must ensure that each field in the table data corresponds one-to-one with the column identifiers in the target table header to avoid column misalignment and provide the foundational data for subsequent access control and format conversion.

[0093] Optionally, the backend module can use the target header as the column base, create a blank worksheet, define the table column identifiers according to the column order of the target header, then traverse the table data, mapping the field values ​​of each data entry to the corresponding columns according to the column identifiers, and writing them sequentially to the worksheet. After all data has been written, an initial table containing the target header and complete business data is obtained.

[0094] In this embodiment, by coordinating preset pagination parameters and table data parameters, the table data is accurately acquired in batches, effectively controlling memory usage and avoiding memory overflow caused by large amounts of data. By comparing the total amount of data with the amount of data already acquired, the last page is accurately determined, reducing invalid requests and improving loading efficiency. Finally, the target header and all table data are integrated to form a structurally complete initial table.

[0095] The following is a further explanation of the permission control processing applied to the initial table based on the permission information, resulting in the processed table. Figure 7 As shown, the above step S502 includes: S701. Traverse each column in the initial table, and for the current column, obtain the permission configuration information of the current column.

[0096] The permission configuration information includes a hidden role attribute and a column hidden flag. The hidden role attribute is used to indicate whether the set of user roles can view the current column or the set of user roles cannot view the current column.

[0097] After the backend module obtains the initial table, it can iterate through each column in the initial table, parse and extract the permission configuration information for the current column, format the extracted permission configuration information, and record the correspondence between the column index of the current column and the permission configuration information.

[0098] S702. Based on the permission configuration information and permission information of the current column, determine whether to display the data in the current column.

[0099] By comparing the permission configuration information of the current column with the user's permission information, it is possible to accurately determine whether the user has the right to view the data in that column.

[0100] After completing the permission check for each column, the column index and the column display status can be recorded to form a mapping table between the column index and the display status, providing a basis for adding hidden identifiers later.

[0101] S703. If the data in the current column is not displayed, a preset hidden flag is added to the current column.

[0102] Optionally, the backend module can mark columns that are determined to be "not displayed" by adding a hidden identifier based on the mapping table formed in step S702 above. When generating Excel files later, these columns can be quickly identified and skipped to avoid leakage of sensitive data.

[0103] In this embodiment, fine-grained column-level permission control is achieved by traversing the initial table columns, extracting permission configuration information, comparing user permissions, and adding hidden identifiers.

[0104] In one possible implementation, permission configuration information is used to indicate the set of user roles that can view the current column. The process described above, which determines whether to display data in the current column based on the permission configuration information and permission information, is as follows: Figure 8 As shown, it includes: S801. If the user role corresponding to the permission information has a corresponding user role in the user role set, then determine to display the data in the current column.

[0105] By comparing a user's actual role with the set of allowed access roles for a column, if a match is found, it means the user has the access permission for that column, and the column data should be displayed to ensure that legitimate users can obtain the information they need.

[0106] S802. If the user role corresponding to the permission information does not have a corresponding user role in the user role set, then determine that the data in the current column will not be displayed.

[0107] When a user's role is not in the list of allowed access roles, it means that the user does not have the access rights for that role. To ensure data security, the data in that role needs to be hidden to prevent the leakage of sensitive information and to achieve fine-grained access control.

[0108] This application's embodiment achieves fine-grained column-level access control by precisely comparing user roles with the allowed access role set for each column. When roles match, column data is displayed normally to ensure the business needs of legitimate users; when roles do not match, sensitive columns are hidden to mitigate data security risks.

[0109] The following is a further explanation of the data transformation process performed on the processed table to obtain the table to be exported corresponding to the initial query conditions, such as... Figure 9 As shown, the above S503 step includes: S901. Traverse each column of the processed table. For the current column, if the current column contains a hidden identifier, fill the data in the current column with a preset character.

[0110] For example, the business data of the column that needs to be hidden can be filled with " / " to cover the original data, ensuring that users can only view the business data within their permissions.

[0111] S902. If the current column does not contain a hidden identifier, the data in the current column is converted based on a preset data format conversion strategy to obtain the processed data column. After the data conversion of all data columns is completed, the converted table is obtained.

[0112] Optionally, for the current column that does not contain hidden identifiers, the format of numeric data can be converted. For example, regular expressions can be used to identify numeric values, exclude coded data that starts with 0 and has no decimal places, set decimal places, add thousands separators, and use regular expressions to match zero values ​​and convert them to empty strings. For date data, special characters such as "-", " / ", and "year" can be removed from the date string to extract pure numeric strings; the format can be matched according to the length of the numeric string to convert the date data to a standard date type. Special characters can be escaped to avoid data garbled characters.

[0113] S903. Merge the converted tables according to the preset table merging strategy to obtain the table to be exported.

[0114] The table merging strategy defines the rules for merging cells. By performing merging processing on the converted table, cells across rows and columns can be merged, making the table structure clearer and the hierarchy more distinct, thus adapting to the display needs of complex business tables.

[0115] A table merging strategy can be a set of parameters that define cell merging rules. Based on the table merging strategy, at least one merging area can be determined, along with information such as the starting row index, the number of rows to merge, the starting column index, and the number of columns to merge.

[0116] The backend module can merge regions based on table merging strategies to obtain the table to be exported.

[0117] The following is a further explanation of how the converted tables are merged according to the preset table merging strategy to obtain the table to be exported. Figure 10 As shown, the above S903 step includes: S1001. Traverse each column in the converted table to determine at least one merged area of ​​the converted table and the merge information of each merged area.

[0118] Optionally, the merge information includes: starting row index, number of rows to merge, starting column index, and number of columns to merge.

[0119] The backend module can iterate through each column in the transformed table, filter out the columns that need to be merged based on the merging rules, thereby determining at least one merged area and extracting the merging information for each merged area.

[0120] Here, the starting row index can be the starting row position of the merged region, the number of merged rows can be the number of rows that need to be merged consecutively, the starting column index can be the starting column position of the merged region, and the number of merged columns can be the number of columns that need to be merged consecutively.

[0121] S1002. Merge each merged region according to its merge information to obtain the table to be exported.

[0122] The backend module can combine the column positions in the header area with the starting row index to correct for errors, ensuring that the merge starts from the data rows and avoids conflicts with the header area. It then calculates the ending row index based on the starting row index and the number of rows to be merged, and the ending column index based on the starting column index and the number of columns to be merged. Finally, it performs row merging in the merged area based on the starting and ending row indices, and column merging based on the starting and ending column indices.

[0123] As shown in Table 1 below, this is an example of an initial table. It can be seen that the target header in the initial table is already the header after the merge process, while there are still areas in the data rows that need to be merged. Based on the above processing, the data is formatted and the data of "other unit prices" is hidden based on the permission information. The initial table shown in Table 1 can be merged and processed into the table to be exported shown in Table 2.

[0124] Table 1 Initial Table Example

[0125] Table 2 Example of a table to be exported

[0126] In this embodiment of the application, by traversing the table columns to accurately identify the merging area and merging information, the specific scope and parameters of the merging are clarified, and the merging process is performed based on the merging information, which can improve the accuracy of the merging process.

[0127] Based on the same inventive concept, this application also provides a table processing system corresponding to the table processing method. Since the principle of the system in this application is similar to the table processing method described above, the implementation of the system can refer to the implementation of the method, and the repeated parts will not be described again.

[0128] Figure 11 This illustration shows a structural schematic diagram of an electronic device provided in an embodiment of this application. The electronic device may be... Figure 1The electronic device is a terminal device that deploys a front-end module or a server that deploys an interaction module and a back-end module. The electronic device includes a processor 1101, a storage medium 1102, and a bus 1103. The storage medium 1102 stores machine-readable instructions that can be executed by the processor 1101. When the electronic device runs a table processing method as described in the embodiment, the processor 1101 communicates with the storage medium 1102 through the bus 1103. The processor 1101 executes the machine-readable instructions. The preamble of the method item of the processor 1101 executes the steps in the table processing method described above.

[0129] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor, which performs the steps in the table processing method described above.

[0130] In this embodiment, the computer program, when run by the processor, can also execute other machine-readable instructions to perform other methods as described in the embodiments. For details on the specific execution steps and principles, please refer to the description of the embodiments, which will not be repeated here.

[0131] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interface; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

[0132] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0133] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0134] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0135] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0136] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A table processing method, characterized in that, The method is applied to a table processing system, which includes a front-end module running on a terminal device and a back-end module running on a server. The front-end module obtains the header data and the corresponding table data based on the initial query conditions. The front-end module generates table configuration information and permission information based on the initial query conditions, the table header data, and the table data, and sends the table configuration information and permission information to the back-end module. The table configuration information includes: table header configuration parameters, table header merging strategy, and table data parameters. The backend module obtains the header to be processed according to the table configuration information, and merges the header to be processed according to the header merging strategy to obtain the target header. The backend module generates a table to be exported based on the target table header, the table data parameters, the preset data pagination parameters, and the permission information, and exports the table to be exported as a table file in a preset format.

2. The method according to claim 1, characterized in that, The front-end module generates table configuration information and permission information based on the initial query conditions, the table header data, and the table data, including: The header configuration parameters are generated based on the header data, and the header configuration parameters are used to indicate the interface for obtaining the header data. The header merging strategy is determined based on the header data; The table data parameters are generated based on the table data corresponding to the header data, and the table data parameters are used to indicate the interface for obtaining the table data. The permission information is determined based on the user identifier of the initial query conditions.

3. The method according to claim 2, characterized in that, The step of determining the header merging strategy based on the header data includes: Traverse each header item of the header to be processed, and determine whether the header item is a single-level header or a double-level header based on the structural identifier of each header item; If the header item is a parent column in a two-level header, then multiple header items to be merged are determined based on the child columns contained in the header item.

4. The method according to claim 1, characterized in that, The backend module generates a table to be exported based on the target table header, the table data parameters, preset data pagination parameters, and the permission information, including: Based on the table data parameters and the preset data pagination parameters, obtain the table data corresponding to the target table header to obtain the initial table; Based on the permission information, the data in the initial table is subjected to permission control processing to obtain the processed table; The processed table is then subjected to data transformation to obtain the table to be exported corresponding to the initial query conditions.

5. The method according to claim 4, characterized in that, The step of obtaining the table data corresponding to the target table header based on the table data parameters and preset data pagination parameters to obtain the initial table includes: The table page corresponding to the target table header is obtained from the acquisition interface indicated by the table data parameters according to the preset pagination parameters, and the table page includes table data; Based on the total amount of data in the table corresponding to the target header and the amount of data already acquired, determine whether the currently acquired table page is the last page; If not, then the next table page corresponding to the target table header is obtained from the acquisition interface indicated by the table data parameters according to the preset pagination parameters, until all table data corresponding to the target table header is obtained; The initial table is obtained by combining the target header and all table data corresponding to the target header.

6. The method according to claim 4, characterized in that, The step of performing permission control processing on the data of the initial table according to the permission information to obtain the processed table includes: Iterate through each column in the initial table, and for the current column, obtain the permission configuration information of the current column; Based on the permission configuration information and permission information of the current column, determine whether to display the data of the current column; If the data in the current column is not displayed, a preset hidden identifier is added to the current column.

7. The method according to claim 6, characterized in that, The permission configuration information is used to indicate the set of user roles that can view the current column; The step of determining whether to display the data in the current column based on the permission configuration information and the permission information of the current column includes: If the user role corresponding to the permission information has a corresponding user role in the user role set, then it is determined to display the data in the current column; If the user role corresponding to the permission information does not have a corresponding user role in the user role set, then it is determined that the data in the current column will not be displayed.

8. The method according to claim 4, characterized in that, The step of performing data transformation on the processed table to obtain the table to be exported corresponding to the initial query conditions includes: Iterate through each column of the processed table. For the current column, if the current column contains a hidden identifier, then fill the data in the current column with a preset character. If the current column does not contain the hidden identifier, the data in the current column is converted based on a preset data format conversion strategy to obtain a processed data column. After the data conversion of all data columns is completed, a converted table is obtained. The converted tables are merged according to a preset table merging strategy to obtain the table to be exported.

9. The method according to claim 8, characterized in that, The step of merging the converted table according to a preset table merging strategy to obtain the table to be exported includes: Traverse each column in the transformed table to determine at least one merged area of ​​the transformed table and the merge information of each merged area. The merge information includes: starting row index, number of merged rows, starting column index, and number of merged columns. The merged regions are merged based on their merge information to obtain the table to be exported.

10. A table processing system, characterized in that, The table processing system includes a front-end module running on a terminal device and a back-end module running on a server. When the table processing system is running, the front-end module and the back-end module are used to execute the table processing method as described in any one of claims 1-9.

Images