CN115118385A - 解码方法及装置 - Google Patents

Abstract

本说明书实施例提供一种解码方法及装置，其中所述解码方法包括：对整合文件的文件头进行解码，得到所述整合文件的标识信息和属性信息；根据所述整合文件的标识信息和属性信息，判断所述整合文件是否符合解码条件；若是，对所述整合文件的至少两个内容区块中包含的目标编码文件进行解码，得到至少两种不同类型的数据结构，其中，所述数据结构在所述整合文件的编码阶段，通过对所述目标编码文件对应的源文件进行语法解析得到，从而减少了解码开销，提高了解码效率和界面渲染效率。

Description

解码方法及装置

技术领域

本说明书实施例涉及前端开发技术领域，特别涉及解码方法及装置。

背景技术

随着互联网技术的不断发展，对网页的前端开发技术提出了更高的需求，前端开发生成的页面以代码文件的形式发布到不同的CDN地址中。

现有技术中，通常对单一类型的代码文件进行压缩打包，用户需要下载经过压缩打包后的压缩文件，解压缩之后执行代码文件以得到网页界面，下载次数和下载开销较大，进而导致下载效率和生成网页界面过程中渲染效率的降低，需要提供更可靠的方案。

发明内容

有鉴于此，本说明书实施例提供了一种解码方法。本说明书一个或者多个实施例同时涉及一种解码装置、一种编码方法、一种编码装置、另一种编码方法、另一种编码装置，一种文件处理方法，一种计算设备，一种计算机可读存储介质以及一种计算机程序，以解决现有技术中存在的技术缺陷。

根据本说明书实施例的第一方面，提供了一种解码方法，包括：

对整合文件的文件头进行解码，得到所述整合文件的标识信息和属性信息；

根据所述整合文件的标识信息和属性信息，判断所述整合文件是否符合解码条件；

若是，对所述整合文件的至少两个内容区块中包含的目标编码文件进行解码，得到至少两种不同类型的数据结构，其中，所述数据结构在所述整合文件的编码阶段，通过对所述目标编码文件对应的源文件进行语法解析得到。

根据本说明书实施例的第二方面，提供了一种解码装置，包括：

第一解码模块，被配置为对整合文件的文件头进行解码，得到所述整合文件的标识信息和属性信息；

判断模块，被配置为根据所述整合文件的标识信息和属性信息，判断所述整合文件是否符合解码条件；

第二解码模块，被配置为，若是，对所述整合文件的至少两个内容区块中包含的目标编码文件进行解码，得到至少两种不同类型的数据结构，其中，所述数据结构在所述整合文件的编码阶段，通过对所述目标编码文件对应的源文件进行语法解析得到。

根据本说明书实施例的第三方面，提供了一种编码方法，包括：

基于至少两种不同类型的源文件，确定与所述至少两种不同类型的源文件对应的整合文件的标识信息，将所述整合文件的标识信息写入所述整合文件的文件头，其中，所述整合文件的标识信息包括所述整合文件的校验码和版本号；

分别对所述至少两种不同类型的源文件进行编码处理，得到第一类型目标编码文件和第二类型目标编码文件；

将所述第一类型目标编码文件和第二类型目标编码文件分别写入所述整合文件的第一内容区块和第二内容区块。

根据本说明书实施例的第四方面，提供了一种编码装置，包括：

第一写入模块，被配置为基于至少两种不同类型的源文件，确定与所述至少两种不同类型的源文件对应的整合文件的标识信息，将所述整合文件的标识信息写入所述整合文件的文件头，其中，所述整合文件的标识信息包括所述整合文件的校验码和版本号；

编码模块，被配置为分别对所述至少两种不同类型的源文件进行编码处理，得到第一类型目标编码文件和第二类型目标编码文件；

第二写入模块，被配置为将所述第一类型目标编码文件和第二类型目标编码文件分别写入所述整合文件的第一内容区块和第二内容区块。

根据本说明书实施例的第五方面，提供了一种编码方法，包括：

基于至少两种不同类型的源文件，确定与所述至少两种不同类型的源文件对应的整合文件的标识信息，将所述整合文件的标识信息写入所述整合文件的文件头，其中，所述整合文件的标识信息包括所述整合文件的校验码和版本号；

分别对所述至少两种不同类型的源文件进行编码处理，得到各个类型的目标编码文件；

将各个类型的目标编码文件分别写入所述整合文件的内容区块，其中，每个所述内容区块内存储一种类型的目标编码文件。

根据本说明书实施例的第六方面，提供了一种编码装置，包括：

第一写入模块，被配置为基于至少两种不同类型的源文件，确定与所述至少两种不同类型的源文件对应的整合文件的标识信息，将所述整合文件的标识信息写入所述整合文件的文件头，其中，所述整合文件的标识信息包括所述整合文件的校验码和版本号；

编码模块，被配置为分别对所述至少两种不同类型的源文件进行编码处理，得到各个类型的目标编码文件；

第二写入模块，被配置为将各个类型的目标编码文件分别写入所述整合文件的内容区块，其中，每个所述内容区块内存储一种类型的目标编码文件。

根据本说明书实施例的第七方面，提供了一种文件处理方法，包括：

编码模块将所述至少两种不同类型的源文件对应的整合文件的标识信息和属性信息写入所述整合文件的文件头，分别对所述至少两种不同类型的源文件进行编码处理，得到第一类型目标编码文件和第二类型目标编码文件，将所述第一类型目标编码文件和第二类型目标编码文件分别写入所述整合文件的第一内容区块和第二内容区块，得到目标整合文件；

解码模块对所述目标整合文件的文件头进行解码，得到所述目标整合文件的标识信息和属性信息，根据所述目标整合文件的标识信息和属性信息，确定所述目标整合文件符合解码条件的情况下，对所述第一类型目标编码文件进行解码，得到第一类型数据结构，以及，对所述第二类型目标编码文件进行解码，得到第二类型数据结构。

根据本说明书实施例的第八方面，提供了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述计算机指令时实现所述编码方法或者解码方法的步骤。

根据本说明书实施例的第九方面，提供了一种计算机可读存储介质，其存储有计算机指令，该计算机指令被处理器执行时实现所述编码方法或者解码方法的步骤。

根据本说明书实施例的第十方面，提供了一种计算机程序，其中，当所述计算机程序在计算机中执行时，令计算机执行上述编码方法或者解码方法的步骤。

本说明书一个实施例提供的解码方法，对整合文件的文件头进行解码，得到所述整合文件的标识信息和属性信息；根据所述整合文件的标识信息和属性信息，判断所述整合文件是否符合解码条件，为整合文件提供了自校验能力，进而方便检查整合文件在传输和存储过程中是否被损坏，为判断整合文件的完整性提供了条件，同时也为检验整合文件的兼容性提供了条件，保证了整合文件的解码效率和解码成功率；若是，对所述整合文件的至少两个内容区块中包含的目标编码文件进行解码，得到至少两种不同类型的数据结构，其中，所述数据结构在所述整合文件的编码阶段，通过对所述目标编码文件对应的源文件进行语法解析得到，由于在整合文件的编码阶段已经进行语法解析得到了数据结构，减少了解码开销，提高了解码效率和界面渲染效率。

附图说明

图1是本说明书一个实施例提供的一种解码方法的结构示意图；

图2是本说明书一个实施例提供的一种解码方法的流程图；

图3是本说明书一个实施例提供的一种解码装置的结构示意图；

图4是本说明书一个实施例提供的一种编码方法的结构示意图；

图5是本说明书一个实施例提供的一种编码方法的流程图；

图6是本说明书一个实施例提供的一种编码装置的结构示意图；

图7是本说明书一个实施例提供的一种编码方法的流程图；

图8是本说明书一个实施例提供的一种编码装置的结构示意图；

图9是本说明书一个实施例提供的一种编码+解码方法的处理过程结构示意图；

图10是本说明书一个实施例提供的一种编码+解码方法的处理过程流程图；

图11是本说明书一个实施例提供的一种计算设备的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本说明书。但是本说明书能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本说明书内涵的情况下做类似推广，因此本说明书不受下面公开的具体实施的限制。

在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本说明书一个或多个实施例中使用的术语“和/或”是指包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

首先，对本说明书一个或多个实施例涉及的名词术语进行解释。

JS，即JavaScript，是一种具有函数优先的轻量级，解释型或即时编译型的编程语言。

CSS，英文全称为Cascading Style Sheets，是一种层叠样式表，用来表现HTML(标准通用标记语言的一个应用)或XML(标准通用标记语言的一个子集)等文件样式的计算机语言。

Weex，是一种构建移动端跨平台高性能UI的动态化渲染引擎，Weex使开发人员能够使用类似Web的语法通过单一代码库构建iOS、Android和Web UI。

WLM，是一种应用于Weex的文件格式。

整合文件，其是对多种源文件进行编码合并后得到的文件，其文件格式为WLM。

内容区块，是整合文件中的文件组成结构，其中存储有源文件经过编码处理后得到的目标编码文件。

bytecode，是一种包含执行程序的二进制文件。

magic number，是一种幻数，用于标记和识别整合文件的格式。

在本说明书中，提供了一种解码方法，本说明书同时涉及一种解码装置、一种编码方法、一种编码装置，另一种编码方式、另一种编码装置、一种文件处理方法、一种计算设备，一种计算机可读存储介质以及一种计算机程序，在下面的实施例中逐一进行详细说明。

实际应用中，对前端开发生成的资源文件进行打包时，通常支持单一类型资源文件的打包，即，对某一类型的资源文件进行合并压缩，从而得到资源包。

然而，随着互联网技术的发展，前端开发技术也在更新，对于前端开发生成的多种类型的资源文件进行打包下载时，对每种类型的资源文件分别进行打包下载，增加了下载次数和下载开销，同时也无法保证下载后的资源文件的兼容性和完整性的问题，因此亟需一种有效的方案以解决上述问题。

有鉴于此，本说明书的实施例提供了一种解码方法，图1示出了根据本说明书的一个实施例提供的一种解码方法的结构示意图，如图1所示，在对整合文件进行解码的过程中，对文件头进行解码，获得文件头中存储的标识信息和属性信息，根据标识信息和属性信息判断整合文件是否符合解码条件，若是，则对第一内容区块中存储的第一类型目标编码文件进行解码，得到第一类型数据结构；对第二内容区块中存储的第二类型目标编码文件进行解码，得到第二类型数据结构。

图2示出了根据本说明书的一个实施例提供的一种解码方法的流程图，具体包括以下步骤202至206。

步骤202，对整合文件的文件头进行解码，得到所述整合文件的标识信息和属性信息。

具体的，整合文件的标识信息包括整合文件的校验码和版本号，整合文件的属性信息用于定义整合文件的文件格式。

在本说明书的一个实施例中，可以直接从文件头内记录的信息直接读取整合文件的标识信息和属性信息。其中，通过解码文件头得到了整合文件的标识信息和属性信息，为之后判断整合文件是否符合解码条件提供了便利。

步骤204，根据所述整合文件的标识信息和属性信息，判断所述整合文件是否符合解码条件。

具体的，在上述通过对整合文件的文件头进行解码后的标识信息和属性信息的基础上，进一步的，考虑到需要根据整合文件中包含的文件对客户端相关内容进行更新，而不同的操作会使整合文件整合不同类型的源文件，因此在解码前，还需要检测整合文件是否满足当前场景下的解码条件，以此才能够支持当前场景下的使用。基于此，当确定整合文件的标识信息和属性信息后，可以根据标识信息和属性信息判断整合文件是否符合解码条件，若是，则执行下述步骤206，若否，确定整合文件的错误信息，根据错误信息生成报告。

当整合文件的标识信息符合预设标识信息的情况下，整合文件符合解码条件；相应的，当整合文件的属性信息符合预设属性信息的情况下，整合文件符合解码条件。

进一步地，为了保证整合文件的安全性，以及解码效率的高效性，可以通过整合文件的校验码、版本号和属性信息判断整合文件是否符合解码条件，具体实现方式如下。

确定所述整合文件的属性信息；在所述属性信息与预设属性信息匹配的情况下，确定所述标识信息中的版本号；在所述版本号属于历史版本号的情况下，确定所述标识信息中的校验码；在所述校验码与预设校验码匹配的情况下，执行所述对所述整合文件的至少两个内容区块中包含的目标编码文件进行解码，得到至少两种不同类型的数据结构的步骤。

具体的，可以依次根据整合文件的属性信息、版本号和校验码，判断整合文件是否符合解码条件，其中，整合文件的属性信息用于判断整合文件的格式属性，版本号用于判断整合文件的兼容性，校验码用于判断整合文件的完整性，当整合文件满足这三种解码条件时，对整合文件能够进行解码。

其中，判断整合文件是否符合解码条件也可以不需要按照先判断属性信息、之后判断版本号最后判断校验码的顺序来进行，换言之，可以根据任意顺序根据属性信息、版本号和校验码来判断整合文件是否符合解码条件。

此外，也可以基于属性信息、版本号和校验码中的任意一种，对整合文件进行判断。

举例说明，首先，根据整合文件的属性信息判断整合文件的是否为wlm文件，具体而言，可以从文件头中读取整合文件的magic number，当magic number与预设属性信息匹配的情况下，此时整合文件为wlm文件，之后确定整合文件的版本号，当版本号为历史版本号时，确定整合文件的校验码，在校验码与预设校验码匹配的情况下，判断的结果为整合文件符合解码条件，执行解码步骤。具体而言，可以通过checksum算法计算整合文件的校验码，按照int32对整合文件中的数据求和，在计算结果为0的情况下，说明整合文件保持完整性，在存储和传输过程中没有受到损坏，符合解码条件。

综上，在判断整合文件是否符合解码条件的过程中，通过对校验码的计算和校验为整合文件提供了自校验能力，进而方便检查整合文件在传输和存储过程中是否被损坏，为判断整合文件的完整性提供了条件，同时也为检验整合文件的兼容性提供了条件，保证了整合文件的解码效率和解码成功率。

再进一步地，在本说明书的一个实施例中，版本号还可以包括次版本号，次版本号记录了整合文件内的扩展功能，通过读取次版本号，可以用于判断整合文件内是否存在解码终端无法解析的功能。

步骤206，若是，对所述整合文件的至少两个内容区块中包含的目标编码文件进行解码，得到至少两种不同类型的数据结构。

具体的，当判断的结果为整合文件符合解码条件时，分别对至少两个内容区块中的包含的目标编码文件进行解码，即，对至少两个内容区块中的第一内容区块中包含的第一类型目标编码文件进行解码，得到第一类型数据结构，相应的，对至少两个内容区块中的第二内容区块中包含的第二类型目标编码文件进行解码，得到第二类型数据结构。

需要说明的是，第一类型数据结构中包括第一类型源文件运行时需要的第一类型运行数据、以及第一类型运行数据中的重复数据及重复数据的位置信息，相应的，第二类型数据结构中包括第二类型源文件运行时需要的第二类型运行数据、以及第二类型运行数据中的重复数据及重复数据的位置信息。

基于此，首先对至少两个内容区块中的第一内容区块中包含的第一类型目标编码文件进行解码，得到第一类型数据结构，之后，读取第一内容区块中的偏移信息，此时偏移信息为预设值，确定存在第二内容区块，再对第二内容区块中包含的第二类型目标编码文件进行解码，得到第二类型数据结构。

沿用上例，对整合文件进行解码的过程中，对第一内容区块中的JS类型目标编码文件进行解码，得到JS类型数据结构，之后，读取第一内容区块中的偏移信息，此时偏移信息为预设值X，说明存在第二内容区块，再对第二内容区块中的CSS类型目标编码文件进行解码，得到CSS类型数据结构。之后，读取第二内容区块中的偏移信息，此时偏移信息为0，说明不存在第三内容区块，至此完成对整合文件的解码，所述整合文件是基于JS类型源文件和CSS类型源文件合并生成的。

综上，由于在对整合文件的编码过程中已经对源文件进行了语法解析，得到了数据结构，因此，在解码阶段对整合文件中的目标编码文件进行解码时，能够直接得到数据结构，为后续能够高效率执行数据结构提供了条件，简化了解码过程，减少了客户端在解码过程中的加载开销。

进一步地，在得到至少两种不同类型的数据结构之后，为了能够生成整合文件中的目标编码文件相关联的渲染界面，需要通过处理引擎对数据结构进行处理，具体实现方式如下。

通过第一类型处理引擎对所述第一类型数据结构进行处理，以及，通过第二类型处理引擎对所述第二类型数据结构进行处理，生成关联所述第一类型数据结构和所述第二类型数据结构的渲染界面；其中，所述第一类型处理引擎和所述第二类型处理引擎的运行规则不同。

基于此，在得到第一类型数据结构和第二类型数据结构之后，通过第一类型处理引擎对第一类型数据结构进行处理，通过第二类型处理引擎对第二类型数据结构进行处理，进而在界面渲染引擎中能够生成关联第一类型数据结构和第二类型数据结构的渲染界面。

可以理解的是，界面渲染引擎中设有第一类型处理引擎和第二类型处理引擎，也可以根据下载解码源文件的需求设置其他类型的处理引擎。

沿用上例，Weex引擎中设有JS类型处理引擎和CSS类型处理引擎，利用JS类型处理引擎对JS类型数据结构进行处理，JS类型处理引擎能够执行JS类型数据结构对应的JS类型源文件，使得在Weex引擎中能够操作dom接口进行界面渲染，利用CSS类型处理引擎对CSS类型数据结构进行处理，使得CSS类型数据结构对应的CSS类型源文件中的内容成为Weex引擎中dom数据中的参数，用于控制界面渲染过程中的布局、绘制等行为，进而在Weex引擎中生成与JS类型数据结构和CSS类型数据结构相关联的渲染界面。

综上，由于数据结构是在编码阶段中对源文件进行语法解析得到的，因此在解码过程中能够节省该语法解析步骤，提高了解码效率和界面渲染效率。

进一步地，在对内容区块中包含的目标编码文件进行解码的过程中，为了快速找到内容区块的起始位置，进而提高解码速度和解码效率，可以先确定内容区块的起始位置，具体实现方式如下：对所述整合文件的第一内容区块中包含的第一类型目标编码文件进行解码，得到第一类型数据结构；确定所述第一内容区块中的偏移信息；根据所述偏移信息，确定所述整合文件中的第二内容区块的起始位置，在所述起始位置对所述第二内容区块中包含的第二类型目标编码文件进行解码，得到第二类型数据结构。

具体的，偏移信息用于标识内容区块的起始位置，第一内容区块中的偏移信息能够标识下一个内容区块，也就是第二内容区块的起始位置，在该起始位置处能够找到第二内容区块，从而对第二内容区块中包含的第二类型目标编码文件进行解码。

基于此，在确定整合文件中的第二内容区块的起始位置时，可以通过第一内容区块中的偏移信息来确定。在本说明书的一个实施例中，第一内容区块中的偏移信息可以指的是第一内容区块的偏移量，在第一内容区块的起始位置处，经过该偏移量，达到第二内容区块的起始位置。或者，第一内容区块中的偏移信息可以指的是第一内容区块与第二内容区块之间的偏移量，在第一内容区块的终止位置处，经过该偏移量，达到第二内容区块的起始位置。

举例说明，确定第一内容区块中的偏移量为L，在第一内容区块的起始位置处，经过长度L达到的位置，即为第二内容区块的起始位置。或者，确定第一内容区块中的偏移量为L，在第一内容区块的终止位置处，经过长度L达到的位置，即为第二内容区块的起始位置。

此外，通过检测偏移信息的方法确定是否存在下一个内容区块，比如，在第二内容区块中的目标编码文件解码完成后，可以从第二内容区块中确定第二偏移信息，并检测其是否为0，若是第二偏移信息为0，说明不存在下一个内容区块，即，不存在第三内容区块，进而说明该整合文件内只存储有两种类型的目标编码文件，进而确定合并打包的源文件的种类数。若是第二偏移信息不为0，说明存在下一个内容区块，即，存在第三内容区块，进而说明该整合文件内至少存储有三种类型的目标编码文件。

上述实施例中说明了根据第一内容区块中的偏移信息确定下一个内容区块，即第二内容区块的起始位置，基于此，为了进一步提高解码速度和解码效率，也需要确定第一内容区块的起始位置，具体方式如下：确定所述整合文件的文件组成结构，其中，所述文件组成结构包括文件头和内容区块，所述文件头和所述内容区块依次排列；根据所述文件头的长度，在所述文件组成结构中确定所述第一内容区块的起始位置。

具体的，文件组成结构指的是组成整合文件的结构，在本实施例中，整合文件的组成结构包括文件头和内容区块。

根据本说明书的一个实施例，文件头的长度是固定的，由于整合文件的文件头和内容区块依次排列，根据文件头的长度，就可以确定第一个内容区块的起始位置，为在第一个内容区块的起始位置对第一内容区块内存储的文件进行解码提供了条件。

举例说明，在整合文件的属性信息中，其定义了文件头的长度为32位，经过32位的长度后，即可达到第一个内容区块的起始位置。

综上，通过确定每个内容区块的起始位置，使得解码器能够快速找到起始位置，并在起始位置上对每个内容区块进行解码，进而提高了解码速度和解码效率。

进一步地，根据本说明书的一个实施例，为了分别对至少两个内容区块中的目标编码文件进行解码，可以通过第一类型解码器对所述第一类型目标编码文件进行解码，以及，通过第二类型解码器对所述第二类型目标编码文件进行解码；其中，所述第一类型解码器和所述第二类型解码器的解码规则不同。

具体的，第一类型目标编码文件适用于第一类型解码器的解码规则，第二类型目标编码文件适用于第二类型解码器的解码规则。

基于此，在对整合文件进行解码时，对解码器的类型不做限制，内容区块中存储的目标编码文件为第一类型目标编码文件时，选用第一类型编码器，这样可以支持对多种不同类型的目标编码文件进行解码，为实现对整合文件进行解码提供了条件。

沿用上例，确定第一内容区块中存储的目标编码文件的类型为JS类型之后，选择JS类型解码器对JS类型目标编码文件进行解码，相应的，在确定第二内容区块中存储的目标编码文件为CSS类型之后，选择CSS类型解码器对CSS类型目标编码文件进行解码。

再进一步地，由于每种类型的目标编码文件适用的解码器的规则不同，为了提高解码速度和解码效率，确定内容区块内存储的目标编码文件的类型，进而快速选择解码器对其进行解码，具体实现方式如下：分别确定所述第一内容区块和所述第二内容区块的区块类型；根据所述第一内容区块的区块类型，确定所述第一类型目标编码文件的类型信息，以及，根据所述第二内容区块的区块类型，确定所述第二类型目标编码文件的类型信息；根据所述第一类型目标编码文件的类型信息，选择第一类型解码器，以及，根据所述第二类型目标编码文件的类型信息，选择第二类型解码器。

具体的，区块类型可以用于表示内容区块内存储的目标编码文件的类型。

可以理解的是，第一内容区块的区块类型与第一内容区块内存储的第一类型目标编码文件的类型相同，因此，确定第一内容区块的区块类型，就可以确定第一类型目标编码文件的类型，进而可以选用第一类型的解码器对第一类型目标编码文件进行解码。相应的，第二内容区块的区块类型与第二内容区块内存储的第二类型目标编码文件的类型也是相同的。

基于此，在确定第一内容区块的起始位置之后，读取第一内容区块的区块类型，根据该区块类型，确定第一内容区块中的目标编码文件的类型。

沿用上例，在确定第一内容区块的起始位置之后，读取第一内容区块的区块类型为JS类型，此时，确定第一内容区块中的目标编码文件的类型为JS类型，对JS类型目标编码文件进行解码后，确定第二内容区块的起始位置，读取第二内容区块的区块类型为CSS类型，此时，确定第二内容区块中的目标编码文件的类型为CSS类型。

综上，通过区块类型确定目标编码文件的类型，为快速选择相同类型的解码器提供了便利条件，进而提高解码效率。

进一步地，根据本说明书的一个实施例，在步骤404中判断的结果为整合文件不符合解码条件的情况下，确定所述整合文件的错误信息，根据所述错误信息，生成报告，具体技术方案如下：在所述属性信息与所述预设属性信息不匹配的情况下，判断的结果为所述整合文件不符合解码条件，执行所述确定所述整合文件的错误信息，根据所述错误信息，生成报告步骤；相应的，在所述版本号不小于所述客户端的版本号的情况下，判断的结果为所述整合文件不符合解码条件，执行所述确定所述整合文件的错误信息，根据所述错误信息，生成报告步骤；相应的，在所述校验码与预设值不匹配的情况下，判断的结果为所述整合文件不符合解码条件，执行所述确定所述整合文件的错误信息，根据所述错误信息，生成报告步骤。

具体的，当整合文件的属性信息、版本号和校验码中有一种不符合解码条件，则执行确定所述整合文件的错误信息，根据所述错误信息，生成报告。

举例说明，根据整合文件的属性信息判断整合文件的是否为wlm文件，具体而言，可以从文件头中读取整合文件的magic number，当magic number与预设属性信息不匹配的情况下，此时整合文件为非wlm文件，不符合解码条件，此时执行确定所述整合文件的错误信息，根据所述错误信息，生成报告。或者，当整合文件的版本号不属于历史版本号时，此时整合文件与解析终端不兼容，不符合解码条件，此时执行确定所述整合文件的错误信息，根据所述错误信息，生成报告。或者，在校验码与预设校验码不匹配的情况下，此时整合文件处于损坏状态，无法保证整合文件的完整性，不符合解码条件，此时执行确定所述整合文件的错误信息，根据所述错误信息，生成报告。具体而言，可以通过checksum算法计算整合文件的校验码，按照int32对整合文件中的数据求和，在计算结果不为0的情况下，说明整合文件在存储和传输过程中受到损坏，不符合解码条件。

综上，在解码之前设置判断步骤，对不符合解码条件的整合文件生成错误报告，省去对无法进行解码的整合文件解码的解码时间，减少解码开销，提高了解码效率，并且，基于整合文件的属性信息、校验码和版本号等多种信息对整合文件进行判断，可以根据多种角度对整合文件进行判断，提高了判断效率。

与上述解码方法实施例相对应，本说明书还提供了解码装置实施例，图3示出了本说明书一实施例提供的一种解码装置的结构示意图。如图3所示，该装置包括：第一解码模块302，被配置为对整合文件的文件头进行解码，得到所述整合文件的标识信息和属性信息；判断模块304，被配置为根据所述整合文件的标识信息和属性信息，判断所述整合文件是否符合解码条件；第二解码模块306，被配置为，若是，对所述整合文件的至少两个内容区块中包含的目标编码文件进行解码，得到至少两种不同类型的数据结构。

一个可选的实施例中，所述第二解码模块306进一步被配置为：对所述整合文件的第一内容区块中包含的第一类型目标编码文件进行解码，得到第一类型数据结构；确定所述第一内容区块中的偏移信息；根据所述偏移信息，确定所述整合文件中的第二内容区块的起始位置，在所述起始位置对所述第二内容区块中包含的第二类型目标编码文件进行解码，得到第二类型数据结构。

一个可选的实施例中，所述第二解码模块306进一步被配置为：通过第一类型解码器对所述第一类型目标编码文件进行解码，以及，通过第二类型解码器对所述第二类型目标编码文件进行解码；其中，所述第一类型解码器和所述第二类型解码器的解码规则不同。

一个可选的实施例中，所述判断模块304进一步被配置为：确定所述整合文件的属性信息；在所述属性信息与预设属性信息匹配的情况下，确定所述标识信息中的版本号；在所述版本号属于历史版本号的情况下，确定所述标识信息中的校验码；在所述校验码与预设校验码匹配的情况下，执行所述对所述整合文件的至少两个内容区块中包含的目标编码文件进行解码，得到至少两种不同类型的数据结构的步骤。

上述为本实施例的一种解码装置的示意性方案。需要说明的是，该解码装置的技术方案与上述的解码方法的技术方案属于同一构思，解码装置的技术方案未详细描述的细节内容，均可以参见上述解码方法的技术方案的描述。

与上述解码方法相对应，本说明书的一个实施例还提供一种编码方法，可以用于开发端，也可以用于云端，图4示出了根据本说明书一个实施例提供的一种编码方法的结构示意图，参见图4所示，基于至少两种不同类型的源文件，确定与该两种不同类型的源文件对应的整合文件的标识信息，将标识信息写入文件头中，其中，标识信息包括整合文件的校验码和版本号；之后，分别对该两种不同类型的源文件进行编码处理，得到第一类型目标编码文件和第二类型目标编码文件；最后，将第一类型目标编码文件写入第一内容区块，将第二类型目标编码文件写入第二内容区块，从而完成将两种源文件合并至整合文件的过程，用户下载时只需要下载一个整合文件，减少了下载次数和下载开销，并且，确定整合文件的校验码为整合文件提供了自校验能力，其能够根据校验码来校验整合文件的完整性，相应的，确定整合文件的版本号为整合文件提供了识别兼容性的能力。

可以理解的是，在本说明书的一个实施例中，也可以在确定两种不同类型的源文件对应的整合文件的标识信息的同时，对这两种不同类型的源文件进行编码处理。

图5示出了根据本说明书一个实施例提供的一种编码方法的流程图，包括步骤502至步骤506。

步骤502，基于至少两种不同类型的源文件，确定与所述至少两种不同类型的源文件对应的整合文件的标识信息，将所述整合文件的标识信息写入所述整合文件的文件头，其中，所述整合文件的标识信息包括所述整合文件的校验码和版本号。

具体的，源文件是一种资源文件，可以从其中读取出用户需要的资源，例如，图片资源、音频资源、视频资源、文字资源、代码资源等内容。标识信息指的是用于识别整合文件的信息，可以理解的是，不同的源文件对应的整合文件的标识信息不同，例如，A类型的源文件和B类型的源文件对应的整合文件的标识信息，与A类型的源文件和C类型的源文件对应的整合文件的标识信息，二者不同，也就是说，由不同的源文件合并生成的整合文件，所对应的标识信息的表达内容不同，可以用于在对整合文件的解码阶段，根据该标识信息识别整合文件中包括的目标编码文件的类型等信息，进而为多种类型的目标编码文件的解码提供条件。文件头指的是整合文件的头部，其中存储有整合文件的标识信息。校验码属于整合文件的标识信息中的一种，其用于校验整合文件的完整性。版本号属于整合文件的标识信息中的一种，其用于使用户识别整合文件的版本以及所提供的功能。

进一步地，可以利用checksum算法计算整合文件的校验码。举例而言，可以按照int32计算该至少两种不同类型的源文件中的数字和，之后，按照bit取反得到校验码，写入文字头。可以理解的是，本说明书的实施例中对校验码的计算方法并不局限于此，本说明书的实施例也可以选用其他的算法计算整合文件的校验码。

再进一步地，可以根据所述至少两种不同类型的源文件的版本信息，确定所述至少两种不同类型的源文件对应的整合文件的版本号。

将整合文件的标识信息写入文件头，用于在解码阶段根据文件头中的标识信息识别整合文件的完整性和兼容性，将整合文件的标识信息写入文件头，此时只是生成了一部分整合文件，并未生成完整的整合文件，将目标编码文件写入内容区块后，文件头内存储的信息和内容区块内存储的文件共同构成整合文件，进而完成对多种源文件的合并打包。

实际应用中，为了使网页展示内容丰富化，增加网页中展示内容的种类，通常需要下载多种类型的源文件才能够支持，而对于多种类型的源文件的下载传输，通常都是单独完成，即，将每种类型的源文件分别进行压缩打包，再将经过压缩打包的文件分别传输到客户端，此种打包方式使得下载的效率低下，当需要多种类型的源文件时，需要进行多次下载，增加下载开销，并要分别对每种类型的源文件进行解码，过程繁琐，网络资源占用较多，有鉴于此，本实施例通过将多种不同类型的源文件合并打包至同一个整合文件中，减少了下载次数和下载开销，能够满足网页展示丰富化的文件需求。

本实施例以对前端开发的JS类型源文件和CSS类型源文件进行合并打包的场景为例对编码方法进行说明，其他场景相关的描述内容均可参见本实施例，相同或相应的描述内容在此不做过多赘述。

综上，通过确定整合文件的校验码和版本号，能够为整合文件提供检验完整性和兼容性的自校验能力，其使得整合文件能够在解码阶段实现自校验功能，以保证进入解码阶段的整合文件的完整性和兼容性，进而提高解码效率，节省解码资源。

步骤504，分别对所述至少两种不同类型的源文件进行编码处理，得到第一类型目标编码文件和第二类型目标编码文件。

具体的，第一类型目标编码文件是对至少两种不同类型的源文件中的第一类型的源文件进行编码处理得到的，第二类型目标编码文件是对至少两种不同类型的源文件中的第二类型的源文件进行编码处理得到的。第一类型目标编码文件和第二类型目标编码文件指的是计算机能够识别的文件，通过对用户点选的多种源文件进行编码处理，并将目标编码文件传输至客户端，对该目标编码文件进行解码后实现格式的转换，进而使得客户端可以通过网页展示用户点选的内容，展示内容与用户提交的指令相对应，以满足用户对网页的展示需求。在本说明书的一个实施例中，目标编码文件可以是二进制格式，也可以是其他格式。

综上，分别对所述至少两种不同类型的源文件进行编码处理，是为了实现对源文件的内容的加密保护，进而避免源文件直接进行传输下载时产生的内容泄露问题，提高了文件传输的安全性和保密性。

此外，在本说明书的一个实施例中，可以分别对三种不同类型的源文件进行编码处理，得到第一类型目标编码文件、第二类型目标编码文件和第三类型目标编码文件，可以理解的是，第一类型目标编码文件是对三种类型的源文件中的第一类型的源文件进行编码处理得到的，第二类型目标编码文件是对三种类型的源文件中的第二类型的源文件进行编码处理得到的，第三类型目标编码文件是对三种类型的源文件中的第三类型的源文件进行编码处理得到的。可以理解的是，在本实施例中，进行编码处理的源文件的类型数量可以根据用户的需求设定，用户可以基于对网页展示的需求选择任意多种不同类型的源文件进行合并下载。本实施例不对源文件的类型数量进行限定。

本实施例是以两种源文件合并为例进行说明，其他的情况可以相互参见。

进一步地，为了提高整合文件在解码阶段的解码效率，进而减少解码阶段的资源占用，在对至少两种不同类型的源文件进行编码的过程中，对源文件的语法进行解析，具体实现方方式如下：

分别对所述至少两种不同类型的源文件的语法进行解析，得到第一类型运行数据和第二类型运行数据；将所述第一类型运行数据和第二类型运行数据，分别写入第一类型数据结构和第二类型数据结构；分别对所述第一类型数据结构和第二类型数据结构进行编码处理，得到所述第一类型目标编码文件和第二类型目标编码文件。

具体的，第一类型运行数据指的是第一类型的源文件运行时需要用到的数据，例如，第一类型运行数据可以包括第一类型的源文件运行时需要用到的语法、函数、字符串，字解码、数据接口等，相应的，第二类型运行数据指的是第二类型的源文件运行时需要用到的数据，例如，第二类型运行数据可以包括第二类型的源文件运行时需要用到的语法、函数、字符串，字解码、数据接口等。

基于此，在对第一类型源文件进行编码的过程中，先解析第一类型源文件的语法，得到第一类型源文件运行时需要用到的语法、函数、字符串、字解码、数据接口等第一类型运行数据，再将上述第一类型运行数据写入第一类型数据结构，在编码阶段就完成了语法解析，使得整合文件在解码阶段无需再进行语法解析，减少解码阶段的资源占用，提高解码效率。相应的，对第二类型源文件进行编码的过程与上述对第一类型源文件进行编码的过程相同，在此不再重复赘述。进一步地，在本说明书的一个实施例中，将第一类型运行数据写入第一类型数据结构时，还将第一类型运行数据之间的逻辑结构写入第一类型数据结构，其中，逻辑结构是指第一类型运行数据之间的函数调用关系，可以理解的是，根据第一类型运行数据和第一类型运行数据之间的逻辑结构，可以确定源文件中的内容。相应的，将第二类型运行数据写入第二类型数据结构时，还将第二类型运行数据之间的逻辑结构写入第二类型数据结构。

综上，在编码阶段通过分别对所述至少两种不同类型的源文件的语法进行解析，以获得第一类型运行数据及其逻辑结构和第二类型运行数据及其逻辑结构，可以避免用户将整合文件下载至客户端后再进行解析，能够减小在解码阶段加载源文件的开销，进而提高解码效率。

再进一步地，在编码过程中，为了减小第一类型目标编码文件和第二类型目标编码文件的大小，分别对第一类型运行数据和第二类型运行数据进行去重，具体实现方式如下。

分别对所述至少两种不同类型的源文件的语法进行解析，得到初始第一类型运行数据和初始第二类型运行数据；对所述初始第一类型运行数据进行去重，得到中间第一类型运行数据，以及，对所述初始第二类型运行数据进行去重，得到中间第二类型运行数据；记录所述初始第一类型运行数据中重复数据的第一类型属性信息，以及，记录所述初始第二类型运行数据中重复数据的第二类型属性信息，其中，所述第一类型属性信息包括所述第一类型运行数据中重复数据的第一类型位置信息，所述第二类型属性信息包括所述第二类型运行数据中重复数据的第二类型位置信息；根据所述第一类型属性信息和所述中间第一类型运行数据生成所述第一类型运行数据，以及，根据所述第二类型属性信息和所述中间第二类型运行数据生成所述第二类型运行数据。

具体的，第一类型属性信息包括第一类型运行数据中重复数据的第一类型数据标识以及第一类型位置信息，其中，第一类型数据标识可以用于确定第一类型运行数据中的重复数据，相应的，第二类型属性信息包括第二类型运行数据中重复数据的第二类型数据标识以及第二类型位置信息，其中，第二类型数据标识可以用于确定第二类型运行数据中的重复数据。

进一步地，对初始第一类型运行数据进行去重，具体而言，是指删除初始第一类型运行数据中的重复数据，将初始第一类型运行数据中的重复数据的数量从多个删除至保留一个，相应的，对初始第二类型运行数据进行去重，具体而言，是指删除初始第二类型运行数据中的重复数据，将初始第二类型运行数据中的重复数据的数量从多个删除至保留一个。

综上，通过对重复数据进行去重，以防止重复数据在整合文件中重复出现，进而减小整合文件的大小，进而提高下载效率。并且，通过标识重复数据以及记录重复数据的位置信息，可以使整合文件在解码阶段能够更快速更高效的还原源文件内的内容。

本实施例以对JS类型的源文件和对CSS类型的源文件进行编码为例进行说明，对于其他至少两种不同类型的源文件的编码方法均可参见本实施例相应的描述内容，在此不作过多赘述。

举例说明，为了支持用户需求的信息在网页界面展示，前端在开发阶段生成了JS类型源文件和CSS类型源文件，用户需要将JS类型源文件和CSS类型源文件下载至客户端，在客户端进行解码后即可在网页展示信息。根据本说明书的实施例提供的编码方法，可以对JS类型源文件和CSS类型源文件进行合并打包下载，以提高下载的效率。

在对JS类型的源文件和CSS类型的源文件进行合并时，首先，基于JS类型的源文件和CSS类型的源文件，确定与JS类型的源文件和CSS类型的源文件对应的整合文件的标识信息，将包含有整合文件的校验码和版本号的标识信息写入整合文件的文件头；之后，分别对JS类型的源文件和CSS类型的源文件进行编码处理，得到JS类型的目标编码文件和CSS类型的目标编码文件。

具体而言对JS类型的源文件的语法进行解析，得到JS类型源文件运行时需要用到的字符串、函数等初始JS类型运行数据，对初始JS类型运行数据中的重复数据进行去重，得到中间JS类型运行数据，并且，确定初始JS类型运行数据中的重复数据的数据标识和位置信息，将中间JS类型运行数据、重复数据的数据标识和位置信息，写入JS类型数据结构，之后，对JS类型数据结构进行编码处理，使其转换为目标格式，以得到JS类型二进制编码文件。同理，对CSS类型的源文件的处理过程与对JS类型的源文件的处理过程相似，根据处理结果可以得到CSS类型二进制编码文件。

进一步地，根据本说明书的一个实施例，分别对第一类型数据结构和第二类型数据结构进行编码处理时，通过第一类型编码器对所述第一类型数据结构进行编码处理，以及，通过第二类型编码器对所述第二类型数据结构进行编码处理；其中，所述第一类型编码器和所述第二类型编码器的编码规则不同。

具体的，第一类型数据结构适用于第一类型编码器的编码规则，第二类型数据结构适用于第二类型编码器的编码规则。

沿用上例，对JS类型的源文件和CSS类型的源文件进行编码的过程中，选用JS类型编码器对JS类型数据结构进行编码处理，相应的，选用CSS类型编码器对CSS类型数据结构进行编码处理，可以理解的是，JS类型编码器与CSS类型编码器的编码规则不同。

在上述实施例中，对编码器的类型不做限定，也就是说，编码器的类型是根据需要进行编码处理的源文件的类型确定的，因此，可以实现对多种类型的源文件的编码处理，进而实现对多种类型的源文件的合并打包。

步骤506，将所述第一类型目标编码文件和第二类型目标编码文件分别写入所述整合文件的第一内容区块和第二内容区块。

具体的，在对第一类型源文件编码处理得到第一类型目标编码文件、对第二类型源文件编码处理得到第二类型目标编码文件之后，将第一类型目标编码文件写入整合文件的第一内容区块，将第二类型目标编码文件写入整合文件的第二内容区块。第一内容区块用于储存第一类型目标编码文件，第二内容区块用于储存第二类型目标编码文件，第一内容区块和第二内容区块在整合文件中依次排列。其中，整合文件中已经包括了文件头中的标识信息和内容区块中的目标编码文件，至此，得到了包含有两种源文件的信息和目标编码文件的整合文件，实现了对两种源文件的合并打包。

进一步地，根据本说明书的一个实施例，将所述整合文件的文件格式写入所述整合文件的文件头，其中，所述整合文件的文件格式用于定义所述整合文件的属性信息。

具体的，文件格式是指为了存储信息而使用的对信息的特殊编码方式，是用于识别内部储存的资料。例如，文件格式包括存储图片的格式、存储程序的格式、存储文字信息的格式等。

在本说明书的一个实施例中，整合文件的文件格式可以是自定义的文件格式，该文件格式包括整合文件的文件组成结构以及文件组成结构的长度等信息。具体而言，文件组成结构可以包括文件头和内容区块，文件头和内容区块依次排列，其中内容区块的数量可以根据要进行合并打包的源文件的数量确定，例如，当有两种源文件需要进行合并时，相应的整合文件中设有两个内容区块，当有三种源文件需要进行合并时，相应的整合文件中设有三个内容区块，并且，每个内容区块依次排列。

此外，在本说明书的一个实施例中，文件头的长度可以固定，此时可以基于文件头的长度确定内容区块的起始位置。

举例说明，整合文件的文件格式可以是自定义的wlm文件格式，在其中，定义了属于该wlm文件的magic number，以识别整合文件的属性信息，具体而言，magic number可以用于识别该整合文件是否为wlm文件格式，此外，在其中还定义了文件头的长度和内容区块的长度。可以理解的是，内容区块的长度可以是预先设定的，也可以是根据存储于内容区块中的文件的大小确定的。

综上，将整合文件的文件格式写入文件头，便于识别整合文件的格式属性，并且，定义该种文件格式可以便于将多种不同类型的文件分别写入内容区块，使得多种文件能够在整合文件中分区存储，便于对单种文件的解码，减少加载开销。

综上所述，本说明书一个实施例提供的编码方法，通过基于至少两种不同类型的源文件，确定与所述至少两种不同类型的源文件对应的整合文件的标识信息，将标识信息写入整合文件的文件头，此时整合文件的文件头中存储有整合文件的标识信息，该标识信息可以用于标识合并打包至整合文件中的源文件；之后分别对至少两种不同类型的源文件进行编码处理，得到第一类型目标编码文件和第二类型目标编码文件，在对源文件的合并打包过程中实现了对源文件内容的加密保护；最后，将第一类型目标编码文件和第二类型目标编码文件分别写入整合文件的第一内容区块和第二内容区块，能够将不同类型的源文件打包至同一个整合文件内，提供了多类型文件打包的扩展功能，减少了下载开销和下载次数，提高了下载效率。

与上述编码方法实施例相对应，本说明书还提供了编码装置实施例，图6示出了本说明书一实施例提供的一种编码装置的结构示意图。如图6所示，该装置包括：第一写入模块602，被配置为基于至少两种不同类型的源文件，确定与所述至少两种不同类型的源文件对应的整合文件的标识信息，将所述整合文件的标识信息写入所述整合文件的文件头，其中，所述整合文件的标识信息包括所述整合文件的校验码和版本号；编码模块604，被配置为分别对所述至少两种不同类型的源文件进行编码处理，得到第一类型目标编码文件和第二类型目标编码文件；第二写入模块606，还被配置为将所述第一类型目标编码文件和第二类型目标编码文件分别写入所述整合文件的第一内容区块和第二内容区块。

一个可选的实施例中，所述编码模块604进一步被配置为：分别对所述至少两种不同类型的源文件的语法进行解析，得到第一类型运行数据和第二类型运行数据；将所述第一类型运行数据和第二类型运行数据，分别写入第一类型数据结构和第二类型数据结构；分别对所述第一类型数据结构和第二类型数据结构进行编码处理，得到所述第一类型目标编码文件和第二类型目标编码文件。

一个可选的实施例中，所述编码模块604进一步被配置为：分别对所述至少两种不同类型的源文件的语法进行解析，得到初始第一类型运行数据和初始第二类型运行数据；对所述初始第一类型运行数据进行去重，得到中间第一类型运行数据，以及，对所述初始第二类型运行数据进行去重，得到中间第二类型运行数据；记录所述初始第一类型运行数据中重复数据的第一类型属性信息，以及，记录所述初始第二类型运行数据中重复数据的第二类型属性信息，其中，所述第一类型属性信息包括所述第一类型运行数据中重复数据的第一类型位置信息，所述第二类型属性信息包括所述第二类型运行数据中重复数据的第二类型位置信息；根据所述第一类型属性信息和所述中间第一类型运行数据生成所述第一类型运行数据，以及，根据所述第二类型属性信息和所述中间第二类型运行数据生成所述第二类型运行数据。

一个可选的实施例中，所述编码模块604进一步被配置为：通过第一类型编码器对所述第一类型数据结构进行编码处理，以及，通过第二类型编码器对所述第二类型数据结构进行编码处理；其中，所述第一类型编码器和所述第二类型编码器的编码规则不同。

一个可选的实施例中，所述第一写入模块602进一步被配置为：将所述整合文件的文件格式写入所述整合文件的文件头，其中，所述整合文件的文件格式用于定义所述整合文件的属性信息。

综上所述，本说明书一个实施例提供的编码装置，第一写入模块通过基于至少两种不同类型的源文件，确定与所述至少两种不同类型的源文件对应的整合文件的标识信息，将标识信息写入整合文件的文件头，此时整合文件的文件头中存储有整合文件的标识信息，该标识信息可以用于标识合并打包至整合文件中的源文件；之后通过编码模块分别对至少两种不同类型的源文件进行编码处理，得到第一类型目标编码文件和第二类型目标编码文件，在对源文件的合并打包过程中实现了对源文件内容的加密保护；最后，第二写入模块将第一类型目标编码文件和第二类型目标编码文件分别写入整合文件的第一内容区块和第二内容区块，能够将不同类型的源文件打包至同一个整合文件内，提供了多类型文件打包的扩展功能，减少了下载开销和下载次数，提高了下载效率。

上述为本实施例的一种编码装置的示意性方案。需要说明的是，该编码装置的技术方案与上述的编码方法的技术方案属于同一构思，编码装置的技术方案未详细描述的细节内容，均可以参见上述编码方法的技术方案的描述。

本说明书的实施例还提供了一种编码方法，图7示出了根据本说明书的一个实施例提供的一种编码方法的流程图，具体包括以下步骤702至706。

步骤702，基于至少两种不同类型的源文件，确定与所述至少两种不同类型的源文件对应的整合文件的标识信息，将所述整合文件的标识信息写入所述整合文件的文件头，其中，所述整合文件的标识信息包括所述整合文件的校验码和版本号。

步骤704，分别对所述至少两种不同类型的源文件进行编码处理，得到各个类型的目标编码文件。

步骤706，将各个类型的目标编码文件分别写入所述整合文件的内容区块，其中，每个所述内容区块内存储一种类型的目标编码文件。

上述实施例中提供的编码方法与前述实施例中的编码方法属于同一技术构思，在此不再重复赘述。

与上述编码方法实施例相对应，本说明书还提供了解码方法实施例，所述解码方法实施例与前述实施例中的解码方法相同，所述解码方法包括：对整合文件的文件头进行解码，得到所述整合文件的标识信息和属性信息；根据所述整合文件的标识信息和属性信息，判断所述整合文件是否符合解码条件；若是，对所述整合文件的至少两个内容区块中包含的目标编码文件进行解码，得到至少两种不同类型的数据结构。

与上述编码方法实施例相对应，本说明书还提供了编码装置实施例，图8示出了本说明书一实施例提供的一种编码装置的结构示意图。如图8所示，该装置包括：第一写入模块802，被配置为基于至少两种不同类型的源文件，确定与所述至少两种不同类型的源文件对应的整合文件的标识信息，将所述整合文件的标识信息写入所述整合文件的文件头，其中，所述整合文件的标识信息包括所述整合文件的校验码和版本号；编码模块804，被配置为分别对所述至少两种不同类型的源文件进行编码处理，得到各个类型的目标编码文件；第二写入模块806，还被配置为将各个类型的目标编码文件分别写入所述整合文件的内容区块，其中，每个所述内容区块内存储一种类型的目标编码文件。

上述为本实施例的一种编码装置的示意性方案。需要说明的是，该编码装置的技术方案与上述的编码方法的技术方案属于同一构思，编码装置的技术方案未详细描述的细节内容，均可以参见上述编码方法的技术方案的描述。

与上述解码方法和编码方法相对应，本说明书的一个实施例还提供了一种文件处理方法，包括：编码模块将所述至少两种不同类型的源文件对应的整合文件的标识信息和属性信息写入所述整合文件的文件头，分别对所述至少两种不同类型的源文件进行编码处理，得到第一类型目标编码文件和第二类型目标编码文件，将所述第一类型目标编码文件和第二类型目标编码文件分别写入所述整合文件的第一内容区块和第二内容区块，得到目标整合文件；解码模块对所述目标整合文件的文件头进行解码，得到所述目标整合文件的标识信息和属性信息，根据所述目标整合文件的标识信息和属性信息，确定所述目标整合文件符合解码条件的情况下，对所述第一类型目标编码文件进行解码，得到第一类型数据结构，以及，对所述第二类型目标编码文件进行解码，得到第二类型数据结构。

具体的，编码模块可以用于执行上述编码方法，编码模块可以是开发前端，解码模块用于执行上述解码方法，解码模块可以是客户端。

上述实施例中提供的文件处理方法与上述编码方法和解码方法相对应，属于统一技术构思，在此不再赘述。

下述结合图9和图10，以本申请提供的编码+解码方法对前端开发的JS类型源文件和CSS类型源文件的合并打包为例，对所述编码+解码方法进行进一步说明。其中，图9示出了根据本说明书一实施例提供的一种编码+解码方法的处理过程结构示意图，如图9所示，编码方法可以在前端执行，经过编码处理后的整合文件被发布至CDN地址，用户可以在CDN地址中将整合文件下载至客户端，解码方法在客户端执行。图10示出了根据本说明书一实施例提供的一种编码+解码方法的处理过程流程图，具体步骤如下。

步骤1002，将基于JS类型源文件和CSS类型源文件确定的版本号和校验码写入整合文件的文件头。

具体的，利用checksum算法，计算JS类型源文件和CSS类型源文件的数据和，并对计算结果进行取反，得到校验码。

步骤1004，分别对JS类型源文件和CSS类型源文件的语法进行解析，得到JS类型运行数据和CSS类型运行数据。

具体的，通过JS类型解析器将JS类型源文件的语法进行解析，得到JS类型源文件运行时需要用到的字符串、函数等JS类型运行数据，通过CSS类型解析器将CSS类型源文件的语法进行解析，得到CSS类型源文件运行时需要用到的字符串、函数等CSS类型运行数据。

步骤1006，分别对JS类型运行数据和CSS类型运行数据进行去重，写入JS类型数据结构和CSS类型数据结构。

具体的，确定JS类型运行数据中的重复数据，并记录重复数据的位置信息，将重复数据删除至保留一个，确定JS类型运行数据之间的逻辑结构，写入JS类型数据结构，相应的，对CSS类型运行数据进行类似的操作，在此不再重复赘述。

步骤1008，分别对JS类型数据结构和CSS类型数据结构进行编码处理，得到JS类型目标编码文件和CSS类型目标编码文件。

步骤1010，分别将JS类型目标编码文件和CSS目标编码文件写入第一内容区块和第二内容区块。

步骤1012，解码整合文件的文件头，得到整合文件的校验码、版本号和属性信息。

步骤1014，根据校验码、版本号和属性信息，判断整合文件是否符合解码条件。

具体的，属性信息包括整合文件的magic number，当magic number与预设属性信息匹配的情况下，符合解码条件，执行解码步骤，当magic number与预设属性信息不匹配的情况下，不符合解码条件，此时执行确定所述整合文件的错误信息，根据所述错误信息，生成报告。

或者，在版本号为历史版本号的情况下，判断的结果为整合文件符合解码条件，执行解码步骤，当整合文件的版本号不属于历史版本号时，此时整合文件与解析终端不兼容，不符合解码条件，此时执行确定所述整合文件的错误信息，根据所述错误信息，生成报告。

或者，在校验码与预设校验码匹配的情况下，判断的结果为整合文件符合解码条件，执行解码步骤，在校验码与预设校验码不匹配的情况下，此时整合文件处于损坏状态，无法保证整合文件的完整性，不符合解码条件，此时执行确定所述整合文件的错误信息，根据所述错误信息，生成报告。具体而言，可以通过checksum算法计算整合文件的校验码，按照int32对整合文件中的数据求和，在计算结果不为0的情况下，说明整合文件在存储和传输过程中受到损坏，不符合解码条件。在计算结果为0的情况下，说明整合文件保持完整性，在存储和传输过程中没有受到损坏，符合解码条件。

步骤1016，若是，对整合文件中的内容区块中存储的JS类型目标编码文件和CSS目标编码文件进行解码，得到JS类型数据结构和CSS类型数据结构。

具体的，先确定第一内容区块，读取第一内容区块的区块类型为JS类型，确定第一内容区块内存储有JS类型目标编码文件，利用JS类型解码器对JS类型目标编码文件进行解码，以得到JS类型数据结构，读取第一内容区块中的偏移信息，此时的偏移信息为预设值，确定存在第二内容区块，读取第二内容区块的区块类型为CSS类型，确定第二内容区块内存储有CSS类型目标编码文件，利用CSS类型解码器对CSS类型目标编码文件进行解码，得到CSS类型数据结构。

之后，读取第二内容区块中的第二偏移信息，此时，第二偏移信息为0，不存在第三内容区块，至此解码完成。

步骤1018，通过JS引擎执行JS类型数据结构，通过CSS引擎执行CSS类型数据结构，将JS引擎和CSS引擎的执行结果写入Weex引擎进行界面渲染，以生成网页页面。

综上所述，通过上述编码+解码方法，能够实现对前端开发多种不同类型源文件的合并打包下载，减少了下载次数和下载开销，减少客户端的资源占用，提高了网络页面生成效率。

需要说明的是，编码过程和解码过程可以连续出现，也就是说，在对前端开发的源文件合并打包呈整合文件，将整合文件下载至客户端后，用户可以立刻进行解码，也可以间隔一段时间后进行解码，换言之，整合文件的编码过程和解码过程可以是连续的，也可以是不连续的。

图11示出了根据本说明书一实施例提供的一种计算设备的结构框图。该计算设备1100的部件包括但不限于存储器1110和处理器1120。处理器1120与存储器1110通过总线1130相连接，数据库1150用于保存数据。

计算设备1100还包括接入设备1140，接入设备1140使得计算设备1100能够经由一个或多个网络1160通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备1040可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。

在本说明书的一个实施例中，计算设备1100的上述部件以及图11中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图11所示的计算设备结构框图仅仅是出于示例的目的，而不是对本说明书范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备1100可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备1100还可以是移动式或静止式的服务器。

其中，处理器1120执行所述计算机指令时实现所述的编码方法或者解码方法的步骤。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的编码方法或者解码方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述编码方法或者解码方法的技术方案的描述。

本说明书一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该计算机指令被处理器执行时实现如前所述编码方法或者解码方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的编码方法或者解码方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述编码方法或者解码方法的技术方案的描述。

本说明书一实施例还提供一种计算机程序，其中，当所述计算机程序在计算机中执行时，令计算机执行上述编码方法或者解码方法的步骤。

上述为本实施例的一种计算机程序的示意性方案。需要说明的是，该计算机程序的技术方案与上述的编码方法或者解码方法的技术方案属于同一构思，计算机程序的技术方案未详细描述的细节内容，均可以参见上述编码方法或解码方法的技术方案的描述。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本说明书实施例并不受所描述的动作顺序的限制，因为依据本说明书实施例，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本说明书实施例所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本说明书优选实施例只是用于帮助阐述本说明书。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书实施例的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本说明书实施例的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本说明书。本说明书仅受权利要求书及其全部范围和等效物的限制。

Claims (14)

1.一种解码方法，包括：

对整合文件的文件头进行解码，得到所述整合文件的标识信息和属性信息；

根据所述整合文件的标识信息和属性信息，判断所述整合文件是否符合解码条件；

若是，对所述整合文件的至少两个内容区块中包含的目标编码文件进行解码，得到至少两种不同类型的数据结构，其中，所述数据结构在所述整合文件的编码阶段，通过对所述目标编码文件对应的源文件进行语法解析得到。

2.根据权利要求1所述的解码方法，所述对所述整合文件的至少两个内容区块中包含的目标编码文件进行解码，得到至少两种不同类型的数据结构步骤，包括：

对所述整合文件的第一内容区块中包含的第一类型目标编码文件进行解码，得到第一类型数据结构；

确定所述第一内容区块中的偏移信息；

根据所述偏移信息，确定所述整合文件中的第二内容区块的起始位置，在所述起始位置对所述第二内容区块中包含的第二类型目标编码文件进行解码，得到第二类型数据结构。

3.根据权利要求2所述的解码方法，所述得到至少两种不同类型的数据结构之后，还包括：

通过第一类型处理引擎对所述第一类型数据结构进行处理，以及，通过第二类型处理引擎对所述第二类型数据结构进行处理，生成关联所述第一类型数据结构和所述第二类型数据结构的渲染界面；

其中，所述第一类型处理引擎和所述第二类型处理引擎的运行规则不同。

4.根据权利要求2所述的解码方法，所述对所述整合文件的至少两个内容区块中包含的目标编码文件进行解码，得到至少两种不同类型的数据结构步骤，包括：

通过第一类型解码器对所述第一类型目标编码文件进行解码，以及，通过第二类型解码器对所述第二类型目标编码文件进行解码；

其中，所述第一类型解码器和所述第二类型解码器的解码规则不同。

5.根据权利要求1所述的解码方法，所述根据所述整合文件的标识信息和属性信息，判断所述整合文件是否符合解码条件，包括：

确定所述整合文件的属性信息；

在所述属性信息与预设属性信息匹配的情况下，确定所述标识信息中的版本号；

在所述版本号属于历史版本号的情况下，确定所述标识信息中的校验码；

在所述校验码与预设校验码匹配的情况下，执行所述对所述整合文件的至少两个内容区块中包含的目标编码文件进行解码，得到至少两种不同类型的数据结构的步骤。

6.一种编码方法，包括：

基于至少两种不同类型的源文件，确定与所述至少两种不同类型的源文件对应的整合文件的标识信息，将所述整合文件的标识信息写入所述整合文件的文件头，其中，所述整合文件的标识信息包括所述整合文件的校验码和版本号；

分别对所述至少两种不同类型的源文件进行编码处理，得到第一类型目标编码文件和第二类型目标编码文件；

将所述第一类型目标编码文件和第二类型目标编码文件分别写入所述整合文件的第一内容区块和第二内容区块。

7.根据权利要求6所述的编码方法，其特征在于，所述分别对所述至少两种不同类型的源文件进行编码处理，得到第一类型目标编码文件和第二类型目标编码文件步骤，包括：

分别对所述至少两种不同类型的源文件的语法进行解析，得到第一类型运行数据和第二类型运行数据；

将所述第一类型运行数据和第二类型运行数据，分别写入第一类型数据结构和第二类型数据结构；

分别对所述第一类型数据结构和第二类型数据结构进行编码处理，得到所述第一类型目标编码文件和第二类型目标编码文件。

8.根据权利要求7所述的编码方法，其特征在于，所述分别对所述至少两种不同类型的源文件的语法进行解析，得到第一类型运行数据和第二类型运行数据步骤，包括：

分别对所述至少两种不同类型的源文件的语法进行解析，得到初始第一类型运行数据和初始第二类型运行数据；

对所述初始第一类型运行数据进行去重，得到中间第一类型运行数据，以及，对所述初始第二类型运行数据进行去重，得到中间第二类型运行数据；

记录所述初始第一类型运行数据中重复数据的第一类型属性信息，以及，记录所述初始第二类型运行数据中重复数据的第二类型属性信息，其中，所述第一类型属性信息包括所述第一类型运行数据中重复数据的第一类型位置信息，所述第二类型属性信息包括所述第二类型运行数据中重复数据的第二类型位置信息；

根据所述第一类型属性信息和所述中间第一类型运行数据生成所述第一类型运行数据，以及，根据所述第二类型属性信息和所述中间第二类型运行数据生成所述第二类型运行数据。

9.根据权利要求7所述的编码方法，所述分别对所述第一类型数据结构和第二类型数据结构进行编码处理步骤，包括：

通过第一类型编码器对所述第一类型数据结构进行编码处理，以及，通过第二类型编码器对所述第二类型数据结构进行编码处理；

其中，所述第一类型编码器和所述第二类型编码器的编码规则不同。

10.根据权利要求6所述的编码方法，还包括：

将所述整合文件的文件格式写入所述整合文件的文件头，其中，所述整合文件的文件格式用于定义所述整合文件的属性信息。

11.一种编码方法，包括：

基于至少两种不同类型的源文件，确定与所述至少两种不同类型的源文件对应的整合文件的标识信息，将所述整合文件的标识信息写入所述整合文件的文件头，其中，所述整合文件的标识信息包括所述整合文件的校验码和版本号；

分别对所述至少两种不同类型的源文件进行编码处理，得到各个类型的目标编码文件；

将各个类型的目标编码文件分别写入所述整合文件的内容区块，其中，每个所述内容区块内存储一种类型的目标编码文件。

12.一种文件处理方法，包括：

编码模块将所述至少两种不同类型的源文件对应的整合文件的标识信息和属性信息写入所述整合文件的文件头，分别对所述至少两种不同类型的源文件进行编码处理，得到第一类型目标编码文件和第二类型目标编码文件，将所述第一类型目标编码文件和第二类型目标编码文件分别写入所述整合文件的第一内容区块和第二内容区块，得到目标整合文件；

解码模块对所述目标整合文件的文件头进行解码，得到所述目标整合文件的标识信息和属性信息，根据所述目标整合文件的标识信息和属性信息，确定所述目标整合文件符合解码条件的情况下，对所述第一类型目标编码文件进行解码，得到第一类型数据结构，以及，对所述第二类型目标编码文件进行解码，得到第二类型数据结构。

13.一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述计算机指令时实现权利要求1-5、6-10、11或者12任意一项所述方法的步骤。

14.一种计算机可读存储介质，其存储有计算机可执行指令，该计算机指令被处理器执行时实现权利要求1-5、6-10、11或者12任意一项所述方法的步骤。

Images