Method and apparatus for generating static website, and nonvolatile storage medium

Abstract

This application discloses a method and apparatus for generating a static website, as well as a non-volatile storage medium. The method includes: receiving a directory structure of a file storage system, wherein the directory structure records the storage location of each file to be processed stored in the file storage system; generating a file set based on the directory structure and the files to be processed, wherein the file set consists of multiple files to be processed located at the same storage location; for each file set, classifying the files to be processed in the file set into a first category of text-type files and a second category of non-text-type files; for each first category of files to be processed, determining a target format conversion template based on the first category of files to be processed; generating web pages based on the target format conversion template and the first category of files to be processed; and generating a static website based on the multiple web pages.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a method and apparatus for generating static websites, and a non-volatile storage medium. Background Technology

[0002] In related technologies, the mapping between the directory structure and the same resource location path (URL path) in methods for generating static websites relies on manual configuration. For example, when generating a static website using related technologies, developers are usually required to put files in a directory with a specific name. Furthermore, if a custom URL path or hierarchical structure is needed, a permalink or path alias must be configured. Otherwise, there will be a problem of inconsistency between the directory structure and the URL path of the webpage, resulting in a large consumption of data resources during website maintenance and generation, and a low consumption of resources during website generation and maintenance.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a method and apparatus for generating static websites, as well as a non-volatile storage medium, to at least solve the technical problem in related technologies where the mapping of directory structure and Uniform Resource Locator (URL) paths in methods for generating websites relies on manual configuration.

[0005] According to one aspect of the embodiments of this application, a method for generating a static website is provided, comprising: receiving a directory structure of a file storage system, wherein the directory structure is used to record the storage location of each file to be processed stored in the file storage system; generating a file set according to the directory structure and the files to be processed, wherein the file set consists of multiple files to be processed located in the same storage location; for each file set, classifying the files to be processed contained in the file set into a first category of text-type files to be processed and a second category of non-text-type files to be processed; for each first category of files to be processed, determining a target format conversion template according to the first category of files to be processed; generating web pages according to the target format conversion template and the first category of files to be processed, and generating a static website according to the multiple web pages.

[0006] Optionally, the directory structure consists of a root directory and at least one subdirectory; multiple file sets are generated based on the directory structure and the files to be processed, including: identifying target subdirectories with a target level in the multiple subdirectories, wherein the level is used to indicate the inclusion relationship between the various directories contained in the directory structure, the root directory is the highest level, and the target level is the next level after the highest level; determining the target storage location indicated by each target subdirectory, wherein the target storage location contains at least one storage location; and combining the files to be processed stored in the target storage location to generate a file set.

[0007] Optionally, determining the target format conversion template based on the first type of files to be processed includes: for each first type of file to be processed, parsing the first type of file to be processed into header metadata and content data, wherein the header metadata is used to record the attribute information of the first type of file to be processed, and the content data is the text content recorded in the first type of file to be processed; if the header metadata contains a type field, determining the target format conversion template based on the value of the type field, wherein the information recorded in the target format conversion template includes the value of the type field, and the type field is used to record the page layout type.

[0008] Optionally, determining the target format conversion template based on the first type of files to be processed further includes: if the header metadata does not contain a type field, determining the name of the target file set, and determining the format conversion template that records the name of the target file set as the target format conversion template, wherein the target file set is the file set to which the first type of files to be processed belong.

[0009] Optionally, generating a webpage based on the target format conversion template and the first type of file to be processed includes: performing format validation on the header metadata of the first type of file to be processed to obtain a validation result, wherein the format validation is used to verify the format of each field contained in the header metadata; if the validation result indicates that the format validation has failed, interrupting the current operation and outputting an alarm message; if the validation result indicates that the format validation has passed, performing format conversion processing on the header metadata of the first type of file to be processed and compiling processing on the content data of the first type of file to be processed, wherein the compilation processing is used to indicate that the content data is format converted and rendered; filling the format conversion result and the compilation processing result into a preset page object model to obtain the target page object model corresponding to the first type of file to be processed; and generating a webpage based on the target page object model and the target format conversion template.

[0010] Optionally, the content data is compiled, including: determining the representation format of the content data in the file to be processed, wherein the representation format includes: Markdown format, programming language, image, and footnote; for the first type of content data in Markdown format, converting the format of the first type of content data to Hypertext Markup Language format to obtain the first compilation result of the first type of content data; for the second type of content data in programming language format, determining the preset rendering template corresponding to the second type of content data according to the language type of the second type of content data, and filling the second type of content data into the preset rendering template to obtain the second type of content data. The second compilation result includes a preset rendering template used to change the visual effect of the second type of content data; for the third type of content data represented as images, the third type of content data is replaced with a target path, where the target path points to the location of the third type of content data in the web page resource storage set, which is used to store resources of the static website; for the fourth type of content data represented as footnotes, the fourth type of content data is converted into a footnote structure, where each footnote structure includes: a footnote link and footnote content, the footnote link is used to record the reference position of the fourth type of content data in the file to be processed, and the footnote content is used to record the text in the fourth type of content data.

[0011] Optionally, generating a webpage based on the target page object model and the target format conversion template includes: filling the format conversion result into a first position in the target format conversion template, and filling the compilation result into a second position in the target format conversion template to obtain a Hypertext Markup Language (HTML) format file. The first position is the position of a first type of tag in the target format conversion template, and the first type of tag is used to fill the attribute information of a first type of file to be processed. The second position is the position of a second type of tag in the target format conversion template, and the second type of tag is used to fill the text content recorded in the first type of file to be processed. Upon receiving a webpage generation instruction, generating a webpage based on the HTML format file and other configuration information recorded in the webpage generation instruction.

[0012] Optionally, generating a webpage based on the Hypertext Markup Language (HTML) format file and other configuration information recorded in the webpage generation instructions includes: if the other configuration information includes a first page layout type, determining a first format conversion template for generating the HTML format file, and determining a second page layout type recorded in the first format conversion template; if the second page layout type is different from the first page layout type, determining a second format conversion template whose recorded page layout type is the first page layout type, and modifying the target information recorded in the first format conversion template according to the second format conversion template, wherein the target information is information in the first format conversion template that is different from the information recorded in the second format conversion template.

[0013] Optionally, generating a webpage based on other configuration information recorded in the Hypertext Markup Language (HTML) format file and the webpage generation instructions further includes: if the other configuration information does not include a first page layout type, determining a second page layout type as the layout type of the generated webpage, wherein the layout type of the webpage includes: a single-page type displaying the main text content recorded in the HTML format file, a list page type displaying the table of contents recorded in the HTML format file, and a scene page corresponding to the application scene layout in the HTML format file.

[0014] Optionally, a static website is generated based on multiple web pages corresponding to multiple first-type files to be processed, including: for each web page, determining the directory level of the first-type files to be processed corresponding to the web page as the web page level, wherein the directory level is used to indicate the subdirectory to which the first-type files to be processed belong in the directory structure, and the web page level is used to indicate the level of the web page in the static website; generating a Uniform Resource Locator (URL) based on multiple web pages and the web page level of each web page, wherein the URL is a character representation of the static website, and the web page names of web pages at different web page levels are separated by a delimiter in the URL.

[0015] Optionally, the method for generating a static website further includes: compressing the second type of files to be processed and moving the result of the compression process to a web page resource storage set.

[0016] According to another aspect of the embodiments of this application, an apparatus for generating a static website is also provided, comprising: a receiving module for receiving a directory structure of a file storage system, wherein the directory structure is used to record the storage location of each file to be processed stored in the file storage system; a generating module for generating a file set according to the directory structure and the files to be processed, wherein the file set consists of multiple files to be processed located in the same storage location; a classification module for classifying, for each file set, the files to be processed contained in the file set into a first category of text-type files to be processed and a second category of non-text-type files to be processed; a determining module for determining a target format conversion template for each first category of files to be processed; and a generating module for generating web pages according to the target format conversion template and the first category of files to be processed, and generating a static website from the multiple web pages.

[0017] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, in which a computer program is stored, wherein the above-described method for generating a static website is executed by running the computer program on the device where the non-volatile storage medium is located.

[0018] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-described method for generating a static website through the computer program.

[0019] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions that, when executed by a processor, implement the steps of the method for generating a static website described above.

[0020] In this embodiment, a directory structure of a receiving file storage system is adopted, wherein the directory structure is used to record the storage location of each file to be processed stored in the file storage system; a file set is generated according to the directory structure and the files to be processed, wherein the file set consists of multiple files to be processed located in the same storage location; for each file set, the files to be processed contained in the file set are classified into a first category of text-type files and a second category of non-text-type files; for each first category of files to be processed, a target format conversion template is determined according to the first category of files to be processed; web pages are generated according to the target format conversion template and the first category of files to be processed, and a static website is generated according to multiple web pages. By setting the directory as a routing rule, the route (i.e., URL path) is directly generated according to the directory structure, achieving the goal of not needing to manually configure the routing rules. This realizes the technical effect of automatically configuring the route according to the input information and generating a static website based on the automatically configured route, thereby solving the technical problem in the related technology of relying on manual configuration of the mapping between the directory structure and the Uniform Resource Locator (URL) path in the method for generating a website. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0022] Figure 1 It is a hardware structure block diagram of a computer terminal used to implement a method for generating static websites, based on related technologies;

[0023] Figure 2 This is a flowchart illustrating the steps of a method for generating a static website according to an embodiment of this application;

[0024] Figure 3 This is a schematic diagram of a process for generating a webpage from a text type file according to an embodiment of this application;

[0025] Figure 4 This is a flowchart of a template processing method according to an embodiment of this application;

[0026] Figure 5This is a flowchart of a subject system according to an embodiment of this application;

[0027] Figure 6 This is a structural diagram of an apparatus for generating a static website according to an embodiment of this application;

[0028] Figure 7 This is a flowchart of an apparatus for generating a static website according to an embodiment of this application. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] To better understand the embodiments of this application, the technical terms involved in the embodiments of this application are explained below:

[0032] Root directory: The top-level directory in a file system or project structure. It is the starting point for all other subdirectories and files and has no parent directories.

[0033] Directory hierarchy: In a file system or project structure, the hierarchical nesting relationship between directories (folders) is the hierarchical structure that starts from the root directory and includes subdirectories level by level.

[0034] In the evolution of web development, website architecture has gradually transitioned from the early static Hypertext Markup Language (HTML) format to dynamic Content Management Systems (CMS), and then to the current architecture composed of front-end interactive scripts (JavaScript), Application Programming Interfaces (APIs), and Markup Languages ​​(Markup). Among these, dynamic CMS generates pages in real time through server-side scripts, which, while offering flexible page generation, suffers from high resource consumption and response latency. To address this issue, this application provides relevant solutions, detailed below.

[0035] According to an embodiment of this application, a method for generating a static website is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0036] The methods and embodiments provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 1 A hardware block diagram of a computer terminal for implementing a method for generating static websites is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0037] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as processor control (e.g., selection of a variable resistor termination path connected to an interface).

[0038] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the method for generating a static website in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the above-mentioned method for generating a static website. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0039] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0040] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0041] This application provides a method for generating static websites that can run in the above-described operating environment. Figure 2 This is a flowchart of the steps of a method for generating a static website according to an embodiment of this application, as shown below. Figure 2 As shown, the method includes the following steps:

[0042] Step S202: Receive the directory structure of the file storage system, wherein the directory structure is used to record the storage location of each file to be processed stored in the file storage system.

[0043] The method provided in this application embodiment achieves configuration management of complex content (multiple directories, multiple versions, and multiple types) by pre-setting "directories as structure and metadata-driven association," solving the problem in other website generation methods where directories and links (URL paths, or routes) are not associated, requiring manual configuration of the directory-URL mapping relationship. Therefore, the method provided in this application embodiment embodiment can be applied to scenarios of generating static websites based on complex content (multiple directories, multiple versions, and multiple types).

[0044] Specifically, when applying the embodiments of this application to the above-mentioned scenario of generating a static website based on complex content (multiple directories, multiple versions, multiple types), in step S202, the directory structure of the file storage system for the files to be processed with multiple versions and / or multiple types will be received. The directory structure is maintained by the file storage system itself and records multiple storage locations in the file storage system. The files used to generate the static website (i.e. the files to be processed) are stored in the above-mentioned storage locations.

[0045] Step S204: Generate a file set based on the directory structure and the files to be processed, wherein the file set consists of multiple files to be processed located in the same storage location.

[0046] In step S204, based on the directory structure received in step S202, multiple storage locations recorded in the directory structure are scanned, the files to be processed recorded in the storage locations are identified, and all files located at the same directory level are aggregated into a file set (also known as a content partition section).

[0047] According to some optional embodiments of this application, the directory structure consists of a root directory and at least one subdirectory; generating multiple file sets based on the directory structure and the files to be processed includes: identifying target subdirectories with a target level in the multiple subdirectories, wherein the level is used to indicate the inclusion relationship between the various directories contained in the directory structure, the root directory has the highest level, and the target level is the next level after the highest level; determining the target storage location indicated by each target subdirectory, wherein the target storage location contains at least one storage location; and combining the files to be processed stored in the target storage location to generate a file set.

[0048] The method provided in this application embodiment can realize multi-directory structure management, wherein the file storage system starts from the root directory (such as "content / "), recursively scans all (to be processed) files in the file storage system, and automatically constructs a complete directory structure. Based on the directory structure, not only can the exact storage path of each file to be processed (including Markdown files and non-text files) be determined, but also the hierarchical relationship of multiple directories within the directory structure can be determined. The hierarchical relationship refers to the inclusion relationship between directories; within the same directory structure, a lower-level subdirectory is contained within a higher-level subdirectory (the larger the numerical value of the level, the lower the level). For example, given the directory structure content / docs / v1 / api / intro.md, the storage path of the Markdown file (intro.md) named "Intro" can be determined as content / docs / v1 / api / intro.md. This storage path consists of a root directory (content / ) and subdirectories named "Documents" (docs / ), "Version 1" (v1 / ), and "Interface" (api / ). Furthermore, within this storage path, the "Interface" subdirectory (api / ) is contained within the "Version 1" subdirectory (v1 / ), and the "Version 1" subdirectory (v1 / ) is contained within the "Documents" subdirectory (docs / ).

[0049] In the method provided in this application embodiment, a first-level subdirectory is identified as an independent "Section" (i.e., a collection of files) as the basis for content organization and routing mapping. In practical application scenarios, technical documents (docs), blogs, etc., can be used as first-level subdirectories. Here, "first-level" refers to a directory hierarchy of 1. In this application embodiment, the root directory has a hierarchy of 0, which is the highest level. A first-level subdirectory is a subdirectory with a hierarchy of 1, and it is the next level below the root directory. Therefore, when generating a file collection (Section), this application embodiment only needs to identify the target subdirectory with a hierarchy of 1 (i.e., the target hierarchy) among the multiple subdirectories contained in the directory structure. As illustrated in the example above (content / docs / v1 / api / intro.md), a first-level subdirectory (docs / ) may contain multiple nested lower-level subdirectories (e.g., v1 / and api / ). Therefore, a storage location indicated by a first-level subdirectory (i.e., the target subdirectory) may only contain the storage location indicated by the first-level subdirectory (this is the case of containing only one storage location); however, it may also contain multiple storage locations indicated by the first-level subdirectory and its multiple lower-level subdirectories (this is the case of containing multiple storage locations). In the method provided in this application embodiment, the hierarchical structure of subdirectories is used for URL generation and content aggregation. URL generation refers to the hierarchical structure being used to generate the URL path corresponding to the subdirectory. For example, the URL path of content / docs / v1 / api / is docs / v1 / api / . Content aggregation refers to the hierarchical structure of subdirectories being used as the basis for direct content aggregation. For example, v1 / api / indicates aggregation of content related to "v1 version API".

[0050] The method provided in this embodiment identifies directory levels to build file sets, thereby achieving automated file classification by business domain, avoiding the tedious operation of manually configuring file groups, and improving the execution efficiency of the method for generating static websites.

[0051] Step S206: For each set of files, classify the files to be processed contained in the set into a first category of text-type files and a second category of non-text-type files.

[0052] Further, in step S206, the files in the set are classified according to their application scenarios into files used to generate web pages for static websites (i.e., the first type of files to be processed) and files used as resources for static websites (i.e., the second type of files to be processed).

[0053] The files used to generate the web pages for the static website (i.e., the first type of files to be processed) can be lightweight markup language (e.g., Markdown) files, which are text files containing text in lightweight markup language. Because lightweight markup languages ​​are characterized by concise content expression, rich formatting, and strong compatibility, they can be widely used in scenarios such as technical document writing, e-book writing, and note-taking. Therefore, Markdown files can easily achieve conversion between HTML, portable document format (PDF), and other formats, thus supporting the implementation of the method in this application. The files used as resources for the generated static website (i.e., the second type of files to be processed) are non-text files, such as image types (PNG), portable document format (PDF), compressed files (ZIP), etc.

[0054] Files within each section can be categorized by their file extensions. For example, text-type files that are Markdown files are categorized by their extension ".md", while non-text files are categorized by their extensions ".png", ".pdf", or ".zip".

[0055] Step S208: For each first-class file to be processed, determine the target format conversion template based on the first-class file to be processed.

[0056] For the text-type files to be processed identified in step S206 (i.e., the first type of files to be processed), in step S208, a template (i.e., a target format conversion template) is matched for the first type of files to be processed to convert the format of the content recorded therein. The target format conversion template is used to convert the information recorded in the first type of files to be processed into HTML format for generating web pages in a static website.

[0057] In this embodiment, the following rules are followed when matching a target format conversion template for the first type of files to be processed: First, a target format conversion template is matched based on the processing result of the first type of files to be processed; if no target format conversion template can be matched based on the processing result of the first type of files to be processed, then a target format conversion template is matched based on the file set (Section) to which the first type of files to be processed belong; if no target format conversion template can be matched based on the file set (Section) to which the first type of files to be processed belong, then a default template is selected as the target format conversion template. The default template is stored in a storage location recorded in the directory structure. For example, it can be stored in a subdirectory named Default Layout (layouts / _default / ). The name of the default template can be a single-page template (single.html), and its corresponding URL path is "layouts / _default / single.html".

[0058] Through this template matching rule, the method provided in this application embodiment can automatically establish a mapping relationship between a file and a target format (such as HTML format) without modifying the information recorded in the file, thereby realizing a standardized conversion process from the original content to the target output.

[0059] According to some optional embodiments of this application, determining the target format conversion template based on the first type of file to be processed includes: for each first type of file to be processed, parsing the first type of file to be processed into header metadata and content data, wherein the header metadata is used to record the attribute information of the first type of file to be processed, and the content data is the text content recorded in the first type of file to be processed; if the header metadata includes a type field, determining the target format conversion template based on the value of the type field, wherein the information recorded in the target format conversion template includes the value of the type field, and the type field is used to record the page layout type.

[0060] As mentioned in step S208, in this embodiment of the application, when matching a target format conversion template for the first type of file to be processed, the target format conversion template is first matched according to the processing result of the first type of file to be processed. The selection of the template does not depend on external configuration or manual intervention, but is directly determined by the type attribute of the file itself. Specifically, when matching a template for the first type of file to be processed, such as a Markdown file, the information set corresponding to the Markdown file (used to record all information related to the Markdown file, including attribute information and body content) is divided into two parts: header metadata (Front Matter) and content body (i.e., content data) by identifying metadata blocks with ---, +++ or ;;; as boundaries. The header metadata records the title, date, page layout type and other attribute information of the Markdown file used to control the display and sorting of the page. Specifically, when the front matter of a Markdown file is in YAML format, it begins and ends with "---"; when it's in JSON format, it begins and ends with ";;;"; and when it's in TOML format, it begins and ends with "+++". A Markdown file's front matter can only belong to one of these three formats. The method provided in this application supports the YAML, JSON, and TOML formats and supports automatic parsing of basic data types (such as strings and numbers) and complex data types (such as arrays and objects). Furthermore, the front matter includes a slug field, and the URL can be flexibly adjusted by modifying the slug field and the link parameters in the configuration file.

[0061] The front matter header metadata may contain fields such as title, date, category, and type. The type field explicitly declares the page layout type of the file, for example: type:"api" or type:"(user guide)tutorial". If the front matter header metadata obtained from the above parsing contains a type field, then based on the value of the type field, the template layouts / [type value] / single.html in the template directory layouts / is directly matched as the target format conversion template. For example, if the type field in the front matter header metadata of the first type of file to be processed is type:"api", then the value of the type field is "api", and in this case, layouts / api / single.html is matched as the target format conversion template. If the type field does not exist, this matching logic is not triggered.

[0062] The method provided in this embodiment automatically locates and binds the corresponding page template through the type field in the header of the Markdown file, migrating the specification of the page layout type from the configuration file or hard-coded logic to the content metadata. This allows content authors to control the rendering style through simple field declarations without modifying system configuration or template mapping relationships, avoiding the cumbersome process of manually configuring the configuration type-template mapping in traditional systems.

[0063] Optionally, determining the target format conversion template based on the first type of files to be processed further includes: if the header metadata does not contain a type field, determining the name of the target file set, and determining the format conversion template that records the name of the target file set as the target format conversion template, wherein the target file set is the file set to which the first type of files to be processed belong.

[0064] If the header metadata (Front Matter) does not contain a type field, the template is matched based on the section (i.e., the set of target files) where the first type of files to be processed are located, with the matching rule being layouts / [Section name] / single.html. Therefore, in this embodiment, when matching the target format conversion template based on the section, it is necessary to first determine the name of the section (i.e., the set of target files) where the first type of files to be processed are located.

[0065] For example, if the first type of file to be processed is intro.md, and its storage path in the directory structure is content / docs / v1 / intro.md, then the target file set name to which it belongs can be determined is docs. Subsequently, the template file matching this set name is searched in the template directory (layouts / ), i.e., layouts / docs / single.html, and this is identified as the target format conversion template. If this template file does not exist, the process continues to fall back to the default template (layouts / _default / single.html). This process does not require manual configuration of the mapping table; it automatically infers the template's affiliation based entirely on the file's physical location in the content directory.

[0066] The method provided in this embodiment automatically uses the name of the top-level directory (Section) where the file is located as the template matching basis when the type field is not explicitly specified. This realizes the implicit binding mechanism of "directory as template", which enables the content file to obtain a reasonable page layout without relying on metadata. This effectively makes up for the gap in page layout adaptation in the case of missing metadata and improves the maintainability of static websites.

[0067] Step S210: Generate web pages based on the target format conversion template and the first type of files to be processed, and generate a static website based on multiple web pages.

[0068] After template matching is completed in step S208, in step S210, the target format conversion template matched for each type of file to be processed in step S208 is used to process the file, generating a single webpage (HTML page), thus completing the structured mapping and output of the file content. Subsequently, all the single webpages (HTML pages) corresponding to the first type of files to be processed, stored in the storage locations recorded in the directory structure, are uniformly output to the public directory (public / ). Multiple webpages generated in the above manner are aggregated, and based on their content relevance and organizational structure, they are integrated to generate a static website, achieving unified publishing and access of multiple pages. The aforementioned public directory can be a folder (file collection) storing the compilation results (HTML pages and files) of the files to be processed related to the directory structure.

[0069] According to some optional embodiments of this application, generating a webpage based on a target format conversion template and a first type of file to be processed includes: performing format verification on the header metadata of the first type of file to be processed to obtain a verification result, wherein the format verification is used to verify the format of each field contained in the header metadata; if the verification result indicates that the format verification has failed, interrupting the current operation and outputting an alarm message; if the verification result indicates that the format verification has passed, performing format conversion processing on the header metadata of the first type of file to be processed and compiling processing on the content data of the first type of file to be processed, wherein the compilation processing is used to indicate that the content data is format converted and rendered; filling the format conversion result and the compilation processing result into a preset page object model to obtain a target page object model corresponding to the first type of file to be processed; and generating a webpage based on the target page object model and the target format conversion template.

[0070] Figure 3 This is a flowchart illustrating the process of generating a webpage from a text file, such as... Figure 3 As shown, generating a webpage requires processing the header metadata (Front Matter) and content data (Content Body) of text-type files (i.e., the first type of file to be processed, such as Markdown files) separately. Therefore, when reading a Markdown file, the metadata (Front Matter) and content body are first separated using delimiters. Next, the Front Matter enters the validation process. The validation process includes: 1) identifying whether the metadata is correctly wrapped with valid boundary characters (---, +++, or ;;;) at the beginning and end; 2) verifying whether its internal structure conforms to the syntax specifications of the selected format (YAML, TOML, or JSON), such as verifying whether key-value pairs are complete, whether nested objects are closed, and whether array elements are valid. If a formatting error is found, such as missing indentation in YAML header metadata, unquoted field names in TOML header metadata, or extra commas at the end of JSON header metadata, the header metadata is deemed to have failed format validation. In this case, the processing flow of the current Markdown file is interrupted, and a clear warning message is output, such as: "Front Matter formatting error: YAML parsing failed, illegal indentation on line 5".

[0071] Still Figure 3As shown, if the Front Matter format validation passes, the metadata (Front Matter) undergoes format conversion processing, transforming it into structured data, such as structured data in Go struct format or structured data in Map format. Simultaneously, the content body of the file (i.e., content data) is compiled. In this embodiment, compiling the content data supports format conversion through syntax parsing (Markdown syntax parsing) and also supports the application of custom rendering rules. Therefore, the compilation processing of content data includes both format conversion and rendering. For each first-type file to be processed, after processing its header metadata and content body, the processing results of the metadata (i.e., the result of format conversion) and the processing results of the content body (i.e., the result of compilation) are filled into a preset Page Model. This model includes standard fields such as title (.Title), content body (.Content), custom parameters (.Params), and permanent links (.RelPermalink). The positions of these fields are used to fill in relevant data in the content data. Finally, the preset page object model (i.e., the target page object model) filled with the above information is combined with the matching target format conversion template (such as layouts / docs / single.html), and the template engine (which supports variables, conditions, and loops) is used to perform rendering to output the final static HTML page (i.e., webpage).

[0072] The method provided in this embodiment ensures that only files with the correct format will enter the subsequent rendering process, effectively avoiding rendering crashes or page anomalies caused by metadata errors; it improves the system's fault tolerance and stability when building large-scale content, and avoids the "silent failure" phenomenon caused by configuration errors.

[0073] Optionally, the content data is compiled, including: determining the representation format of the content data in the file to be processed, wherein the representation format includes: Markdown format, programming language, image, and footnote; for the first type of content data in Markdown format, converting the format of the first type of content data to Hypertext Markup Language format to obtain the first compilation result of the first type of content data; for the second type of content data in programming language format, determining the preset rendering template corresponding to the second type of content data according to the language type of the second type of content data, and filling the second type of content data into the preset rendering template to obtain the second type of content data. The second compilation result includes a preset rendering template used to change the visual effect of the second type of content data; for the third type of content data represented as images, the third type of content data is replaced with a target path, where the target path points to the location of the third type of content data in the web page resource storage set, which is used to store resources of the static website; for the fourth type of content data represented as footnotes, the fourth type of content data is converted into a footnote structure, where each footnote structure includes: a footnote link and footnote content, the footnote link is used to record the reference position of the fourth type of content data in the file to be processed, and the footnote content is used to record the text in the fourth type of content data.

[0074] In the method provided in this application embodiment, the parser (e.g., GoldMark parser, Blackfriday parser) used to implement the above-mentioned compilation processing supports the semantic forms of various Enhanced Grammar Features (GFM), such as tables, code blocks, task lists, and footnotes. When displaying the first type of file to be processed, data following the above-mentioned different grammatical features will be displayed in different forms. Furthermore, during compilation processing, different processing is supported for data in different forms, for example... Figure 3 As shown, data recorded in Markdown format undergoes syntax analysis; while data in programming language formats, such as shortcodes, undergoes replacement and / or highlighting. In this embodiment, when compiling the content data of the first type of file to be processed (Markdown file), for content data in markup language format: a parser performs syntax analysis on the full text of the content data (i.e., the first type of content data), converting it into HTML format (Hypertext Markup Language format); the aforementioned first type of content data includes: headings, lists, emphasized text, tables, task lists, strikethroughs, etc., and the HTML tags generated from the syntax analysis of the first type of content data are used as the first compilation result. For example, if the first type of content is: ##heading, its corresponding (first) compilation result is... <h2> title< / h2> .

[0075] For content data represented as a programming language (i.e., the second type of content data), identify the shortcode markers (which indicate the language type) within the second type of content data and locate their corresponding preset rendering template. For example, the shortcode (i.e., the second type of content data) is {{ <video url="x">If the shortcode is generated as `layouts / shortcodes / video.html`, then its corresponding preset rendering template is `layouts / shortcodes / video.html`. The content of the shortcode is populated into its corresponding preset rendering template, and a URL parameter is passed. The preset rendering template dynamically generates an HTML fragment (i.e., the second compilation result) based on the populated URL parameter, and replaces it back into the content data. Since the code can be generated using different programming languages, and different programming languages ​​may match different preset rendering targets, when processing shortcodes, the preset rendering template is matched according to the specific programming language type (e.g., Python, JavaScript, Java). The aforementioned preset rendering template can be loaded through a template engine. Furthermore, combining the highlighting configuration information recorded in the configuration item (`[markup.highlight]`) in the configuration file (`config`), such as the highlighting theme (`monokai`, `light`), the code (i.e., the second type of content data) is wrapped in a tag with a Cascading Style Sheets (CSS) class name. For example, the code content can be included using the above method. <pre>Elements and <code>The elements are further enhanced visually (such as keyword highlighting and line number display), and the compiled result of the code (i.e., the second compiled result) is output. The compilation processing method for programming languages ​​provided in this application can be executed for code with nested calls (short code containing other short code) and code containing complex parameters (objects / arrays).

[0076] For non-character data in the body of a Markdown file, such as image data (i.e., third-category content data), during compilation, the system scans the image reference syntax (e.g., ) in the Markdown file, identifies the resource file path (i.e., the target path), and replaces the image content data (i.e., third-category content data) with the aforementioned resource file path. The aforementioned resource file path (i.e., the target path) points to the location of the image content data (i.e., third-category content data) in the webpage resource storage set. During the build phase, the system automatically copies all non-text files under the root directory (content / ) to the directory public / , forming a webpage resource storage set. To maintain path consistency, non-character data in text files (i.e., first-category files to be processed) under the same root directory structure is also stored in this webpage resource storage set. The data stored in this webpage resource storage set will be used as resources for the static website. For example, the original path of the image content data (i.e., third-category content data), cover.png, will be replaced with the target path public / blog / cover.png, and accessible HTML tags will be generated. This ensures that images can be loaded in a static website without requiring manual intervention in resource deployment.

[0077] Text files typically use different formatting for characters, such as superscripts and footnotes. For data with these special formats, the content and format are separated into independent structures for storage. For example, for content data presented as footnotes: identify the footnote markers (e.g., [^1]) in the main content and their corresponding footnote definitions (e.g., [^1]: This is footnote content), and split each footnote into footnote links (...). [1] The Chinese annotation for this HTML tag is: The numbering used for citation in the text is a footnote link [1] and the footnote content block ( This is the footnote content. The Chinese annotation for this HTML tag is: This is the footnote content, i.e., the complete annotation text displayed at the end of the document or at a specified location. It consists of two independent structures, which are then combined to form the footnote structure. The footnote link is used to locate the footnote's reference position within the file. The reference position and content are bidirectionally associated through an identifier (id) and a hyperlink address (href), ensuring that clicking the link will jump to the footnote, conforming to HTML standard semantics. The footnote content block is used to record the semantic content (or text) of the footnote (i.e., the fourth type of content data).

[0078] The method provided in this embodiment implements differentiated compilation strategies for data in different presentation formats in Markdown content, achieving accurate conversion and semantic rendering of structured content. Compared with related technologies for generating static websites, this solution achieves semantic preservation and visual enhancement of complex elements such as code, images, and footnotes, enabling the generated web pages to meet standards compatibility.

[0079] According to some optional embodiments of this application, generating a webpage based on a target page object model and a target format conversion template includes: filling the result of the format conversion into a first position in the target format conversion template, and filling the result of the compilation process into a second position in the target format conversion template to obtain a hypertext markup language format file. The first position is the position of a first type of tag in the target format conversion template, and the first type of tag is used to fill attribute information of a first type of file to be processed. The second position is the position of a second type of tag in the target format conversion template, and the second type of tag is used to fill the text content recorded in the first type of file to be processed. Upon receiving a webpage generation instruction, generating a webpage based on the hypertext markup language format file and other configuration information recorded in the webpage generation instruction.

[0080] Figure 4 This is a flowchart of template processing, such as... Figure 4 As shown, according to the method provided in the above embodiments, the corresponding template file (i.e., the target format conversion template) is automatically matched based on whether the type field is specified in the Front Matter metadata of the file to be processed, or based on its Section (such as docs), for example, layouts / docs / single.html. Then, the template is parsed by the template engine, and the parsing result is injected into the preset page model (such as Page object, Section object, Site object). After that, different types of web pages can be generated by performing layout type rendering. When rendering layout types, the information recorded in the page model (i.e., the target page object model) containing the format conversion results of the file to be processed needs to be added to the template (i.e., the target format conversion template) matched through the above method. Specifically, the format conversion template presets the following two types of placeholder tags: The first type of tag, such as title {{.Title}}, category parameters {{.Params.category}}, and date {{.Date}}, is located within the tag or in the page title area and is used to fill in the processing results of the aforementioned FrontMatter metadata (i.e., the format conversion results); the second type of tag, such as body content {{.Content}}, is located in... <main>The `<body>` section is used to process the compiled content data, generating the HTML-formatted body content, including headings, paragraphs, code blocks, tables, and other GFM syntax rendering results. Therefore, during layout-type rendering, the processing result of the header metadata of the text-type file to be processed (i.e., the format conversion result) is inserted into the position of the first type of tag in the target format conversion template (i.e., the first position), and the processing result of the content data of the text-type file to be processed (i.e., the compilation result) is inserted into the position of the second type of tag in the target format conversion template (i.e., the second position). Upon receiving specific webpage generation instructions, the final static webpage file can be generated based on the template filling result (i.e., the Hypertext Markup Language format file) and the configuration information carried in the webpage generation instructions.

[0081] The template engine mentioned in the above solution can handle variables ({{.Title}}), conditional statements ({{if.IsHome}}), loops ({{range.Pages}}), and built-in functions (where / sort / groupBy), far exceeding the capabilities of templates that do not support nested loops, enabling low-code expression of complex logic. The template can directly access the following three types of objects: Page object: containing basic information about the current page, accessed directly through the {{.Page attribute}}; Section object: containing the content collection of the directory where the current page is located, accessed through the {{.CurrentSection. attribute}}; Site object: containing global configuration information for the website, accessed through the {{.Site. attribute}}. Therefore, in the solution provided in this application embodiment, data access requires no additional query steps, directly calling through the object attribute chain, greatly simplifying the development process.

[0082] The method provided in this application integrates the originally scattered Markdown metadata and main content into structured HTML through a template mechanism, realizing a separate development model of "content is data, template is structure", which significantly improves content reusability and maintenance efficiency.

[0083] Optionally, generating a webpage based on the Hypertext Markup Language (HTML) format file and other configuration information recorded in the webpage generation instructions includes: if the other configuration information includes a first page layout type, determining a first format conversion template for generating the HTML format file, and determining a second page layout type recorded in the first format conversion template; if the second page layout type is different from the first page layout type, determining a second format conversion template whose recorded page layout type is the first page layout type, and modifying the target information recorded in the first format conversion template according to the second format conversion template, wherein the target information is information in the first format conversion template that is different from the information recorded in the second format conversion template.

[0084] In the method provided in this application embodiment, when generating a webpage through template processing, the main template can be inherited and a custom layout can be overridden. Template inheritance is based on block syntax: the parent template definition can reserve a customizable area through the syntax {{block"block name".}}{{end}}, and the child template can override the specified block in the parent module through the syntax {{define"block name"}}...{{end}}. The child module will reuse the parts of the parent module that are not overridden, and only modify the parts that need to be customized, which can solve the redundancy problem of needing to copy the entire template for inheritance.

[0085] In this embodiment, before generating the webpage, the file has already matched a format conversion template (i.e., the first format conversion template) based on the type field in the header metadata or the file set (Section) to which the file belongs. When generating the webpage, if the configuration information carried by the webpage generation instruction specifies the page layout type of the webpage (i.e., the first page layout type), then the page layout type carried by the configuration information (i.e., the first page layout type) is compared with the format conversion template (i.e., the first format conversion template) matched based on the type field or the file set (Section). If the page layout type (i.e., the second page layout type) recorded in the format conversion template (i.e., the first format conversion template) matched in step S208 is consistent with the page layout type (i.e., the first page layout type) specified in the configuration information, then there is no need to perform the template inheritance step; otherwise, if the page layout type (i.e., the second page layout type) recorded in the format conversion template (i.e., the first format conversion template) matched in step S208 is inconsistent with the page layout type (i.e., the first page layout type) specified in the configuration information, then template inheritance is performed. Specifically, when performing template inheritance, the parent template (i.e., the first format conversion template) is modified. Only the information in the parent template (i.e., the first format conversion template) that is different from the page layout type (i.e., the first page layout type) carried in the configuration information (i.e., the target information) is modified to obtain a format conversion template (i.e., the second format conversion template) that is completely consistent with the page layout type (i.e., the first page layout type) carried in the configuration information.

[0086] The method provided in this embodiment uses the block-level overriding rules in the template inheritance mechanism as a benchmark to automatically determine whether to retain or override the corresponding block content in the sub-template, thereby achieving consistency and maintainability of web page layout semantics without having to copy the entire template.

[0087] Optionally, generating a webpage based on other configuration information recorded in the Hypertext Markup Language (HTML) format file and the webpage generation instructions further includes: if the other configuration information does not include a first page layout type, determining a second page layout type as the layout type of the generated webpage, wherein the layout type of the webpage includes: a single-page type displaying the main text content recorded in the HTML format file, a list page type displaying the table of contents recorded in the HTML format file, and a scene page corresponding to the application scene layout in the HTML format file.

[0088] In the method provided in this application embodiment, if the configuration information carried by the webpage generation instruction does not record information related to the page layout type, then the page layout type (i.e., the second page layout type) recorded in the default template (i.e., the target format conversion template) matched in step S208 is used as the layout type of the webpage to be generated. Figure 4 As shown in the embodiments of this application, there are multiple page layout types (i.e., second page layout types) recorded in the default template (i.e., the target format conversion template). For example, if the file type is not a list configuration file (_index.md) and is located in the content / docs / v1 / directory, it is determined to be single-page content, and a template with a single-page layout (such as layouts / docs / single.html) is used as the template for generating the webpage.

[0089] If the user accesses the path https: / / example.com / docs / (i.e., the directory itself, not a file), the system detects that the request is for the content / docs / directory and automatically looks for the list configuration file (_index.md) in that directory. If it does not exist, it uses the format conversion template (layouts / docs / list.htm) with the layout type of list page to generate a webpage, which displays the titles, summaries, and links of all sub-documents in that directory.

[0090] For special files in the files to be processed, such as list configuration files (_index.md), the following processing is performed on such special files: read their Front Matter metadata (such as title:"v1 documentation") to generate the list page of the directory (such as content / docs / v1 / _index.md generating / docs / v1 / index.html), which can be configured without relying on plugins.

[0091] If the user accesses https: / / example.com / categories / api / (automatically generated from categories:["api"] in the header metadata), the system recognizes it as a category page. Even if none of the relevant documents contain the type field, the system will still automatically match the format conversion template (layouts / _default / taxonomy.html) with the recorded layout type as the scene page type to generate the webpage.

[0092] If a user visits the website root path (https: / / example.com / ), the system will automatically match layouts / index.html and generate "Homepage" in the scenario page type.

[0093] The method provided in this embodiment automatically identifies and matches three types of standard layout templates: "single page", "list page" or "scene page", based on the file's location in the content directory, whether it is a list configuration file (_index.md) and the semantics of the access path. This achieves intelligent webpage structure mapping without manual intervention, ensuring that the content and display format remain semantically consistent and structurally reasonable even in scenarios without configuration.

[0094] Optionally, a static website is generated based on multiple web pages corresponding to multiple first-type files to be processed, including: for each web page, determining the directory level of the first-type files to be processed corresponding to the web page as the web page level, wherein the directory level is used to indicate the subdirectory to which the first-type files to be processed belong in the directory structure, and the web page level is used to indicate the level of the web page in the static website; generating a Uniform Resource Locator (URL) based on multiple web pages and the web page level of each web page, wherein the URL is a character representation of the static website, and the web page names of web pages at different web page levels are separated by a delimiter in the URL.

[0095] In the method provided in this application embodiment, when multiple Markdown files (the first type of files to be processed) are stored in different subdirectories under the root directory (content / ), the system performs the following processing on each file: It generates a corresponding Uniform Resource Locator (URL) based on the directory structure of each file. For example, the file content / docs / intro.md has a directory level of docs / , and its corresponding webpage level is determined to be the first level, generating the URL: / docs / intro / ; the file content / docs / v1 / api / health.md has a directory level of docs / v1 / api / health ... The file ` / v1 / api / ` corresponds to a third-level webpage, generating the URL ` / docs / v1 / api / health / `. The file `content / blog / 2024 / 03 / announcement.md` has a directory level of `blog / 2024 / 03 / `, generating the URL ` / blog / 2024 / 03 / announcement / `. The file `content / docs / v1 / _index.md`, although a directory index file, still has a directory level of `docs / v1 / `, generating the URL ` / docs / v1 / `, which serves as the entry point for the list page at this level.

[0096] When generating a static website, the HTML output file for each document is placed in the `public / ` directory, with a path structure identical to `content / `. For example, `content / docs / v1 / api / health.md` corresponds to the output file `public / docs / v1 / api / health / index.html`, and it can be accessed on the website via the path ` / docs / v1 / api / health / `. In all generated URLs, different levels of path segments (such as `docs`, `v1`, `api`, and `health`) are connected by forward slashes " / ", forming a clear and semantically unambiguous Uniform Resource Locator (URL). Users can directly infer the file's location within the content hierarchy from the URL, and search engines can understand the site topology based on the hierarchical structure. Ultimately, the static website consists of multiple web pages, and the URL of each web page accurately reflects the nesting level of its source file within the `content / ` directory, achieving a consistent mapping between the content organization structure and the access path structure.

[0097] The method provided in this application provides a mechanism for automatically generating webpage URLs based on the content directory hierarchy: the system directly uses the subdirectory path structure of each text type file as the hierarchical structure of its corresponding webpage, and concatenates them with separators to form a hierarchical URL, realizing a 1:1 correspondence between the path structure and content storage structure of the static website, eliminating the need for manual routing configuration and improving the efficiency of generating static websites.

[0098] According to another optional embodiment of this application, the method for generating a static website further includes: compressing the second type of files to be processed, and moving the result of the compression process to a web page resource storage set.

[0099] For non-text content files (i.e., the second type of files to be processed), such as resource files (images, attachments, etc.), when the method provided in this application embodiment is executed, if a non-text content file (such as ".png", ".pdf", ".zip", etc.) is scanned, it is determined to be a resource file. Simultaneously, the resource file is automatically compiled and compressed, and copied from the root directory (content / ) to the public path. For example, content / blog / cover.png will be automatically copied to public / blog / cover.png. The public path points to a storage collection that stores web page resources. The resource files in this collection will ultimately be inserted as resources into the corresponding positions in the HTML during page rendering, avoiding resource redundancy or omissions. In Markdown, relative paths can also be used for direct referencing, for example, directly referencing the image , solving the problem of manually configuring resource paths in related technologies and other tools.

[0100] The method provided in this embodiment sets specific processing methods for non-text type files to be processed, realizing the decoupling of content and layout, parallel processing of text and resources, and automatic mapping of paths and structures, significantly reducing the configuration complexity of static website construction and improving generation efficiency and system maintainability.

[0101] Through the above steps, based on the directory structure of the file storage system, the system automatically identifies, classifies, transforms, and organizes the files to be processed, ultimately generating a structured, deployable static website. The directory-as-route design solves the problem of relying on manual configuration of routing mapping rules in related technologies; the use of a parser supporting multiple syntaxes to perform file parsing solves the problem of incomplete syntax support in related technologies; and the system achieves full automation from route mapping to static website output, solving the problem of related methods for generating static websites being unable to automatically establish logical relationships, route mappings, or page aggregations based on metadata (such as titles, dates, and categories) recorded in the files, thus relying on manual configuration.

[0102] Figure 5 This is a flowchart of the workflow of a topic system, which is a system that can execute the methods provided in this embodiment, such as... Figure 5 As shown in the method provided in the application embodiment, the theme system supports multiple theme sources: the system identifies two types of theme resources by default, namely the project's local layouts / (custom) and themes / xxx / layouts / (theme default). When rendering the page, the system loads both types of resources simultaneously. During loading, local files take priority over theme files (e.g., layouts / partials / nav.html overwrites the theme / xxx / layouts / partials / nav.html with the same name). Users do not need to copy the entire theme directory; they only need to create a file with the same name as the theme file under the local layouts / directory to modify a specific component or template, significantly reducing customization costs.

[0103] The core functionality of the theme is broken down into independent, reusable components, all stored in the `partials / ` directory. Examples include the navigation bar (nav.html) and the footer (footer.html). Data sharing is achieved by calling these components within the template using `{{partial "nav.html".}}` and passing the Page object. Within the theme system, resources are automatically linked between components: CSS referenced in components (such as `{{resources.Get "css / nav.css"}}`) are automatically included in the resource pipeline, including automatic resource dependency identification and automatic compilation / compression. Finally, during page rendering, the processed resources are automatically inserted into the corresponding positions in the HTML, avoiding resource redundancy or omissions.

[0104] The theme's source resources are uniformly stored in the `assets / ` directory. These resources include uncompiled stylesheet files, uncompressed script source files, and unoptimized raw image files. The system automatically processes these source resources through the resource pipeline: uncompiled stylesheet files are compiled into browser-readable files. Uncompressed script source files are compressed, removing spaces and comments to reduce file size. Unoptimized raw image files are optimized, adjusting image size and compression quality. Processed resources automatically invoke their associated components, eliminating the need for manual configuration of resource paths or build tools, significantly simplifying resource management.

[0105] In addition, the theme includes by default features such as side navigation (a hierarchical structure generated based on the "directory scanning and section definition" steps), search box, and breadcrumb navigation (hierarchical navigation automatically generated based on the URL path of the current page). These features can be configured through parameters in the config file without relying on other plugins, thus reducing the risk of dependency chains.

[0106] Figure 6 This is a structural diagram of an apparatus for generating a static website according to an embodiment of this application, such as... Figure 6 As shown, the apparatus for generating a static website includes: a receiving module 60 for receiving a directory structure of a file storage system, wherein the directory structure records the storage location of each file to be processed stored in the file storage system; a generating module 62 for generating a file set based on the directory structure and the files to be processed, wherein the file set consists of multiple files to be processed located in the same storage location; a classification module 64 for classifying the files to be processed in each file set into a first category of text-type files and a second category of non-text-type files; a determining module 66 for determining a target format conversion template based on each first category of files to be processed; and a generating module 68 for generating web pages based on the target format conversion template and the first category of files to be processed, and generating a static website based on multiple web pages.

[0107] Figure 7 This is a flowchart of the workflow of the device that generates static websites, such as... Figure 7 As shown, when the apparatus for generating a static website executes the method provided in this application embodiment, it receives a directory structure through the receiving module 60. The directory structure records multiple storage locations for storing files to be processed, and all files to be processed stored in the directory structure are located under the root directory (content / ). Next, the generating module 62 aggregates the files to be processed under the root directory (content / ) according to their file types, forming multiple file sets. For example, it groups the files to be processed under the first-level directory into a single file set (Section). For each file set, the classification module 64 classifies the files in each set according to their extensions, classifying text files with the extension ".md" as the first type of files to be processed, and classifying non-text files with extensions ".png" and ".jpg" as the second type of files to be processed. Furthermore, module 66 calls the parser to read the file content of each text file, extracts the header metadata (FrontMatter) such as title and date, converts the body text into a Hypertext Markup (HTML) file, and then injects the metadata and body text into placeholders such as {{.Title}} and {{.Content}} in the corresponding templates, finally rendering it into an HTML file and outputting it to the public / directory. Module 68 generates a static website based on the HTML files in the public / directory.

[0108] It should be noted that, Figure 7 Preferred embodiments of the shown examples can be found in [reference needed]. Figure 2 The relevant descriptions of the embodiments shown will not be repeated here.

[0109] This application also provides a non-volatile storage medium storing a computer program, wherein the device containing the non-volatile storage medium executes the above-described method for generating a static website by running the computer program.

[0110] The aforementioned non-volatile storage medium is used to store a program that performs the following functions: receiving a directory structure of a file storage system, wherein the directory structure records the storage location of each file to be processed stored in the file storage system; generating a file set based on the directory structure and the files to be processed, wherein the file set consists of multiple files to be processed located in the same storage location; for each file set, classifying the files to be processed contained in the file set into a first category of text-type files and a second category of non-text-type files; for each first category of files to be processed, determining a target format conversion template based on the first category of files to be processed; generating web pages based on the target format conversion template and the first category of files to be processed, and generating a static website based on the multiple web pages.

[0111] This application also provides an electronic device, including a memory and a processor. The memory stores a computer program, and the processor is configured to execute the above-described method for generating a static website through the computer program.

[0112] The processor in the aforementioned electronic device is used to run a program that performs the following functions: receiving the directory structure of a file storage system, wherein the directory structure records the storage location of each file to be processed stored in the file storage system; generating a file set based on the directory structure and the files to be processed, wherein the file set consists of multiple files to be processed located in the same storage location; for each file set, classifying the files to be processed contained in the file set into a first category of text-type files and a second category of non-text-type files; for each first category of files to be processed, determining a target format conversion template based on the first category of files to be processed; generating web pages based on the target format conversion template and the first category of files to be processed, and generating a static website based on the multiple web pages.

[0113] This application also provides a computer program product, including computer instructions, which, when executed by a processor, implement the steps of the above-described method for generating a static website.

[0114] It should be noted that the modules in the above-mentioned device for generating static websites can be program modules (e.g., a set of program instructions that implement a certain function) or hardware modules. For the latter, they can be in the following forms, but are not limited to these: each of the above modules is in the form of a processor, or the functions of each of the above modules are implemented by a processor.

[0115] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0116] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0117] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0118] 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 units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0119] Furthermore, the functional units in the various embodiments of 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0120] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it 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 related technologies, or all or part 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, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0121] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.< / main> < / code> < / pre> < / video>

Claims

1. A method for generating a static website, characterized in that, include: Receive the directory structure of the file storage system, wherein the directory structure is used to record the storage location of each file to be processed stored in the file storage system; A file set is generated based on the directory structure and the files to be processed, wherein the file set consists of multiple files to be processed located in the same storage location; For each set of files, the files to be processed contained in the set of files are classified into a first category of text-type files and a second category of non-text-type files. For each file of the first type to be processed, a target format conversion template is determined based on the file of the first type to be processed; Web pages are generated based on the target format conversion template and the first type of files to be processed, and a static website is generated based on multiple web pages.

2. The method according to claim 1, characterized in that, The directory structure consists of a root directory and at least one subdirectory; multiple file sets are generated based on the directory structure and the files to be processed, including: Identify a target subdirectory with a target level in multiple subdirectories, wherein the level is used to indicate the inclusion relationship between the various directories contained in the directory structure, the root directory has the highest level, and the target level is the next level below the highest level; Determine the target storage location indicated by each of the target subdirectories, wherein the target storage location includes at least one of the storage locations; The files to be processed stored in the target storage location are combined to generate a file set.

3. The method according to claim 1, characterized in that, The target format conversion template is determined based on the first type of files to be processed, including: For each file of the first type to be processed, the file of the first type to be processed is parsed into header metadata and content data, wherein the header metadata is used to record the attribute information of the file of the first type to be processed, and the content data is the text content recorded in the file of the first type to be processed. If the header metadata includes a type field, the target format conversion template is determined based on the value of the type field. The target format conversion template contains information including the value of the type field, which is used to record the page layout type.

4. The method according to claim 3, characterized in that, Based on determining the target format conversion template according to the first type of files to be processed, the method further includes: If the type field is not included in the header metadata, the name of the target file set is determined, and the format conversion template that records the name of the target file set is determined as the target format conversion template, wherein the target file set is the file set to which the first type of files to be processed belong.

5. The method according to claim 1, characterized in that, Generate a webpage based on the target format conversion template and the first type of file to be processed, including: The header metadata of the first type of file to be processed is format-validated to obtain a validation result, wherein the format validation is used to validate the format of each field contained in the header metadata; If the verification result indicates that the format verification has failed, the current operation will be interrupted and an alarm message will be output. If the verification result indicates that the format verification is passed, the header metadata of the first type of file to be processed is subjected to format conversion processing, and the content data of the first type of file to be processed is subjected to compilation processing, wherein the compilation processing is used to indicate that the content data is format converted and rendered; The results of the format conversion and the compilation process are filled into a preset page object model to obtain the target page object model corresponding to the first type of file to be processed. A webpage is generated based on the target page object model and the target format conversion template.

6. The method according to claim 5, characterized in that, The content data is compiled and processed, including: Determine the representation format of the content data in the file to be processed, wherein the representation format includes: Markdown format, programming language, image, and footnote; For the first type of content data in Markdown format, the format of the first type of content data is converted into Hypertext Markup Language format to obtain the first compilation result of the first type of content data; For the second type of content data represented by a programming language, a preset rendering template corresponding to the second type of content data is determined according to the language type of the second type of content data, and the second type of content data is filled into the preset rendering template to obtain the second compilation result of the second type of content data. The preset rendering template is used to change the visual effect of the second type of content data. For the third type of content data represented as an image, the third type of content data is replaced with a target path, wherein the target path points to the location of the third type of content data in the web page resource storage set, and the web page resource storage set is used to store the resources of the static website; For the fourth type of content data represented as footnotes, the fourth type of content data is converted into a footnote structure, wherein each footnote structure includes: a footnote link and footnote content. The footnote link is used to record the reference position of the fourth type of content data in the file to be processed, and the footnote content is used to record the text in the fourth type of content data.

7. The method according to claim 5, characterized in that, Generate a webpage based on the target page object model and the target format conversion template, including: The result of the format conversion is filled into the first position of the target format conversion template, and the result of the compilation process is filled into the second position of the target format conversion template to obtain a Hypertext Markup Language format file. The first position is the position of the first type of tag in the target format conversion template, and the first type of tag is used to fill the attribute information of the first type of file to be processed. The second position is the position of the second type of tag in the target format conversion template, and the second type of tag is used to fill the text content recorded in the first type of file to be processed. Upon receiving a webpage generation instruction, a webpage is generated based on the Hypertext Markup Language format file and other configuration information recorded in the webpage generation instruction.

8. The method according to claim 7, characterized in that, Generate a webpage based on the Hypertext Markup Language format file and other configuration information recorded in the webpage generation instructions, including: If the other configuration information includes a first page layout type, a first format conversion template for generating the Hypertext Markup Language format file is determined, and a second page layout type recorded in the first format conversion template is determined; When the second page layout type is different from the first page layout type, the recorded page layout type is determined to be the second format conversion template of the first page layout type, and the target information recorded in the first format conversion template is modified according to the second format conversion template. The target information is information that is different from the information recorded in the first format conversion template and the information recorded in the second format conversion template.

9. The method according to claim 8, characterized in that, Generating a webpage based on the hypertext markup language format file and other configuration information recorded in the webpage generation instructions further includes: If the first page layout type is not included in the other configuration information, the second page layout type is determined as the layout type of the generated webpage. The layout type of the webpage includes: a single page type that displays the main text content recorded in the hypertext markup language format file, a list page type that displays the directory recorded in the hypertext markup language format file, and a scene page that corresponds to the application scene layout in the hypertext markup language format file.

10. The method according to claim 1, characterized in that, Generate a static website based on multiple web pages corresponding to multiple files of the first type to be processed, including: For each webpage, the directory level of the first type of file to be processed corresponding to the webpage is determined as the webpage level of the webpage, wherein the directory level is used to indicate the subdirectory to which the first type of file to be processed belongs in the directory structure, and the webpage level is used to indicate the level of the webpage in the static website; A Uniform Resource Locator (URL) is generated based on the multiple web pages and the web page hierarchy of each web page. The URL is a character representation of the static website, and the web page names of the web pages at different web page levels are separated by a separator in the URL.

11. The method according to claim 1, characterized in that, The method further includes: for the second type of files to be processed, compressing the second type of files to be processed, and moving the result of the compression process to the web resource storage set.

12. An apparatus for generating static websites, characterized in that, include: A receiving module is used to receive the directory structure of a file storage system, wherein the directory structure is used to record the storage location of each file to be processed stored in the file storage system; A generation module is used to generate a file set based on the directory structure and the files to be processed, wherein the file set consists of multiple files to be processed located in the same storage location; The classification module is used to classify the files to be processed contained in each file set into a first category of text-type files to be processed and a second category of non-text-type files to be processed; The determination module is used to determine the target format conversion template for each of the first type of files to be processed, based on the first type of files to be processed. The generation module is used to generate web pages based on the target format conversion template and the first type of files to be processed, and to generate a static website based on multiple web pages.

13. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores a computer program, wherein the device containing the non-volatile storage medium executes the method for generating a static website as described in any one of claims 1 to 11 by running the computer program.

14. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method for generating a static website as described in any one of claims 1 to 11 through the computer program.

15. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the steps of the method for generating a static website as described in any one of claims 1 to 11.

Images