具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。基于本申请的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护。
需要说明的是,本申请的说明书和权利要求书及上述附图中的术语“包括”、“包含”和“具有”以及它们任何变形,意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、终端、产品或设备没有限定于已列出的步骤或单元,而是可选地还包括没有列出的步骤或单元,或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。在本申请的权利要求书、说明书以及说明书附图中的术语,诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体/操作/对象与另一个实体/操作/对象区分开来,而不一定要求或者暗示这些实体/操作/对象之间存在任何这种实时的关系或者顺序。
在本文中提及“实施例”意味着,结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例,也不是与其他实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是,本文所描述的实施例可以与其他实施例相结合。
ePub(Electronic Publication的缩写,意为:电子出版),是电子出版物的基本开放标准格式,是一种用来分发并显示电子书内容的XML文档文件格式。ePub是基于XHTML格式制作的电子书,以zip压缩格式来包裹档案内容,具有低存储空间、易携带等优势。在相关技术中,当ePub文件发生损坏时,无法对ePub文件进行修复,以使其能正常打开。
有鉴于此,本申请实施例通过对待修复文件中损坏的必要数据进行修复,得到修复必要数据,从而可以根据修复必要数据生成修复文件。由于修复文件中的必要数据完整,因此修复文件可以顺利打开,从而实现对损坏ePub文件的修复。
为了说明本申请的技术方案,下面通过具体实施例来进行说明。
图1示出了本申请实施例提供的一种文件的修复方法的实现流程示意图,该方法可以应用于终端设备上。终端设备可以是手机、平板电脑、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer,UMPC)、上网本等。
具体的,上述文件的修复方法可以包括以下步骤S101至步骤S104。
步骤S101,获取待修复文件。
其中,待修复文件为损坏的ePub文件。
在本申请的实施方式中,终端设备可以直接获取用户输入的待修复文件,也可以直接调取存储于存储器中的待修复文件,本申请实施例对获取待修复文件的方式不做限定。
步骤S102,对待修复文件进行解压,得到解压文件。
应了解,待修复文件(即损坏的ePub文件)是一个压缩文件。解压文件的数量可以有多份,其中一些解压文件可能发生了损坏。
在本申请的实施方式中,终端设备可以先将待修复文件的后缀由epub改为zip,再进行解压,可以得到多份解压文件。
步骤S103,当解压文件中存在损坏必要数据时,对损坏必要数据进行修复,得到修复必要数据。
其中,必要数据为打开ePub文件不可缺少的数据,包括mimetype文件、container.xml文件以及opf文件。损坏必要数据为出现损坏的必要数据。
具体的,mimetype文件用于说明epub的文件格式。container.xml文件用于记录电子书的根文件(rootfile)的路径和打开方式。opf文件是epub电子书的核心文件,且是一个标准的XML文件,用于组织ops文档以及提供相应的导航机制。
在本申请的实施方式中,当解压文件中存在损坏必要数据时,终端设备可以根据损坏必要数据的结构特征,对损坏必要数据进行修复,从而得到修复必要数据。
步骤S104,基于修复必要数据生成修复文件。
其中,修复文件为对待修复文件进行修复后的ePub文件。
在本申请的实施方式中,终端设备可以将修复必要数据、没有损坏的必要数据(如果存在)以及其他数据进行压缩,得到修复文件。
本申请实施例与现有技术相比的有益效果是:本申请实施例通过获取待修复文件,并对待修复文件进行解压,得到解压文件,当解压文件中存在损坏必要数据时,对损坏必要数据进行修复,得到修复必要数据,并基于修复必要数据生成修复文件。本申请实施例通过对待修复文件中损坏的必要数据进行修复,得到修复必要数据,从而可以根据修复必要数据生成修复文件。由于修复文件中的必要数据完整,因此修复文件可以顺利打开,从而实现对损坏ePub文件的修复。
如图2所示,在本申请的一些实施方式中,当损坏必要数据包括损坏opf文件,且修复必要数据包括修复opf文件时,上述对损坏必要数据进行修复,得到修复必要数据,具体可以包括步骤S201至步骤S205。
应了解,一个完整的opf文件一般包括package节点、metadata节点、manifest节点、spine节点、tour节点、guide节点。
步骤S201,根据固定的格式生成package节点以及metadata节点。
应了解,package节点以及metadata节点一般都有固定的格式。
其中,package节点为opf文件的根节点。metadata节点(元数据节点)用于记录opf文件的宏观信息,包括dc-metadata和x-metadata。dc-metadata,其元素构成采用dublinecore(DC)的15项核心元素,包括:<title>:题名、<creator>:责任者、<subject>:主题词或关键词、<description>:内容描述、<contributor>:贡献者或其它次要责任者、<date>:日期、<type>:类型、<format>:格式、<identifier>:标识符、<source>:来源、<language>:语种、<relation>:相关信息、<coverage>:履盖范围、<rights>:权限描述。x-metadata即扩展元素,如果有些信息在上述元素中无法描述,则在此元素中进行扩展。
在本申请的实施方式中,终端设备可以根据package节点对应的固定格式生成package节点,还可以根据metadata节点对应的固定格式生成metadata节点。
步骤S202,获取解压文件中的标记语言文件,并基于标记语言文件生成manifest节点。
其中,manifest节点用于记录epub文件中所有的标记语言文件(例如html、xml、ncx等),其由三个属性构成:id(文件的ID号)、href(文件的相对路径)、media-type(文件的媒体类型)。可以根据manifest节点中的信息索引到对应的标记语言文件。
在本申请的实施方式中,终端设备可以寻找解压文件中的所有标记语言文件,并将这些标记语言文件记录至空白的manifest节点,从而生成manifest节点。
步骤S203,基于manifest节点生成spine节点。
其中,spine节点(脊骨),用于提供书籍的线性阅读次序,其由一个属性(idref)构成。idref与manifest节点的id相对应。
在本申请的实施方式中,终端设备可以根据manifest节点中的id生成对应的spine节点。
步骤S204,生成空的tour节点以及空的guide节点。
其中,tour节点(导读),用于根据用户的读者水平或者阅读目的,按一定次序,选择电子书中的部分页面组成导读。guide节点(指南),用于列出电子书的特定页面,例如封面、目录、序言等。应了解,epub电子书可以不需要tour节点以及guide节点。
在本申请的实施方式中,终端设备可以直接生成空的tour节点以及空的guide节点,以确保opf文件中节点的完整性。
步骤S205,根据package节点、metadata节点、manifest节点、spine节点、tour节点以及guide节点,生成修复opf文件。
在本申请的实施方式中,终端设备可以将上述节点按照预设的顺序进行组装,从而生成修复opf文件。
在本申请的一些实施方式中,当损坏必要数据包括损坏container.xml文件,且修复必要数据包括修复container.xml文件时,上述对损坏必要数据进行修复,得到修复必要数据,具体可以包括以下步骤:
根据固定的格式对损坏container.xml文件进行修复,生成修复container.xml文件。
应了解,container.xml文件一般有固定的格式。
在本申请的实施方式中,终端设备可以根据container.xml文件对应的固定格式生成修复container.xml文件,并设置修复container.xml文件指向opf文件。
在本申请的一些实施方式中,当损坏必要数据包括损坏mimetype文件,且修复必要数据包括修复mimetype文件时,上述对损坏必要数据进行修复,得到修复必要数据,具体可以包括以下步骤:
应了解,mimetype文件一般有固定的格式。
在本申请的实施方式中,终端设备可以根据mimetype文件对应的固定格式生成修复mimetype文件。
在本申请的一些实施方式中,上述基于修复必要数据生成修复文件,具体可以包括以下步骤:
对待压缩数据进行压缩,得到修复文件。
其中,待压缩数据可以包括修复必要数据、以及解压文件中除损坏必要数据外的其他数据。请注意,待压缩数据中除了修复必要数据外,还有可能存在完好的必要数据(待修复文件中可能有必要数据没有收到损坏),以及其他非必要数据,例如ncx文件、html、css等。
在本申请的实施方式中,由于ePub文件是压缩文件,因此需要对待压缩数据进行压缩。具体的,终端设备可以通过压缩软件对待压缩数据进行压缩,从而得到修复文件。
如图3所示,在本申请的一些具体实施方式中,上述对待压缩数据进行压缩,得到修复文件,具体可以包括步骤S301至步骤S303。
值得注意的是,将待修复文件的后缀由epub改为zip,再进行解压,对损坏必要数据进行修复,将待压缩数据进行压缩时,如果直接将mimetype文件和其他数据一起压缩,那么压缩后的文件无法正常打开。
步骤S301,对完好mimetype文件或修复mimetype文件进行压缩,得到第一压缩文件。
其中,完好mimetype文件为解压文件中未损坏的mimetype文件。
在本申请的实施方式中,若待修复文件中mimetype文件没有损坏,则终端设备可以对待修复文件中的完好mimetype文件进行压缩,得到第一压缩文件。若待修复文件中mimetype文件损坏了,则终端设备可以对修复后的修复mimetype文件进行压缩,得到第一压缩文件。
步骤S302,对待压缩数据中除完好mimetype文件或修复mimetype文件外的其他数据进行压缩,得到第二压缩文件。
在本申请的实施方式中,若待修复文件中mimetype文件没有损坏,则终端设备可以对待压缩数据中除完好mimetype文件外的其他数据进行压缩,得到第二压缩文件。若待修复文件中mimetype文件损坏了,则终端设备可以对待压缩数据中除修复mimetype文件外的其他数据进行压缩,得到第二压缩文件。
步骤S303,将第一压缩文件添加进第二压缩文件中,得到修复文件。
在本申请的实施方式中,终端设备可以将第一压缩文件以仅存储的方式单独添加进第二压缩文件中,从而得到修复文件。
本申请实施方式通过对完好mimetype文件或修复mimetype文件、以及其他数据分开压缩,并将压缩后的mimetype文件添加进压缩后的其他数据,从而得到完整的opf文件,同时通过这种方式得到的opf文件,可以正常打开。
在本申请的一些实施方式中,上述对待修复文件进行解压,得到解压文件,具体可以包括以下步骤:
对待修复文件进行流式解压,得到解压文件。
应了解,zip文件由许多个“Local File Header+File Data”和一些其他数据组成。每一个“Local File Header+File Data”块都可以解压出来一个文件。只需存在“LocalFile Header+File Data”即可解出压缩包中一个完整的文件。
在本申请的实施方式中,终端设备可以对待修复文件进行流式解压,具体的,终端设备可以对待修复文件进行提取,并将提取出的多个文件释放到一个文件夹,也即流式解压,从而得到解压文件。
图4示出了本申请实施例提供的一种文件的修复装置的结构示意图,上述文件的修复装置4可以配置于终端设备上,具体的,上述文件的修复装置4,可以包括:
获取模块401,用于获取待修复文件,待修复文件为损坏的ePub文件;
解压模块402,用于对待修复文件进行解压,得到解压文件;
修复模块403,用于当解压文件中存在损坏必要数据时,对损坏必要数据进行修复,得到修复必要数据,其中,必要数据为打开ePub文件不可缺少的数据;
生成模块404,用于基于修复必要数据生成修复文件。
本申请实施例与现有技术相比的有益效果是:本申请实施例通过获取待修复文件,并对待修复文件进行解压,得到解压文件,当解压文件中存在损坏必要数据时,对损坏必要数据进行修复,得到修复必要数据,并基于修复必要数据生成修复文件。本申请实施例通过对待修复文件中损坏的必要数据进行修复,得到修复必要数据,从而可以根据修复必要数据生成修复文件。由于修复文件中的必要数据完整,因此修复文件可以顺利打开,从而实现对损坏ePub文件的修复。
在本申请的一些实施方式中,上述修复模块403还用于:根据固定的格式生成package节点以及metadata节点;获取解压文件中的标记语言文件,并基于标记语言文件生成manifest节点;基于manifest节点生成spine节点;生成空的tour节点以及空的guide节点;根据package节点、metadata节点、manifest节点、spine节点、tour节点以及guide节点,生成修复opf文件。
在本申请的一些实施方式中,上述生成模块404还用于:对待压缩数据进行压缩,得到修复文件,待压缩数据包括修复必要数据、以及解压文件中除损坏必要数据外的其他数据。
在本申请的一些实施方式中,上述生成模块404还用于:对完好mimetype文件或修复mimetype文件进行压缩,得到第一压缩文件,完好mimetype文件为解压文件中未损坏的mimetype文件;对待压缩数据中除完好mimetype文件或修复mimetype文件外的其他数据进行压缩,得到第二压缩文件;将第一压缩文件添加进第二压缩文件中,得到修复文件。
在本申请的一些实施方式中,上述修复模块403还用于:根据固定的格式对损坏container.xml文件进行修复,生成修复container.xml文件。
在本申请的一些实施方式中,上述修复模块403还用于:根据固定的格式对损坏mimetype文件进行修复,生成修复mimetype文件。
在本申请的一些实施方式中,上述解压模块402还用于:对待修复文件进行流式解压,得到解压文件。
如图5所示,为本申请实施例提供的一种终端设备的示意图。该终端设备5可以包括:处理器501、存储器502以及存储在所述存储器502中并可在所述处理器501上运行的计算机程序503,例如文件修复程序。所述处理器501执行所述计算机程序503时实现上述各个文件的修复方法实施例中的步骤,例如图1所示的步骤S101至步骤S104。或者,所述处理器501执行所述计算机程序503时实现上述各装置实施例中各模块/单元的功能,例如图4所示的获取模块401、解压模块402、修复模块403、生成模块404。
所述计算机程序可以被分割成一个或多个模块/单元,所述一个或者多个模块/单元被存储在所述存储器502中,并由所述处理器501执行,以完成本申请。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段,该指令段用于描述所述计算机程序在所述终端设备中的执行过程。
所述终端设备可包括,但不仅限于,处理器501、存储器502。本领域技术人员可以理解,图5仅仅是终端设备的示例,并不构成对终端设备的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件,例如所述终端设备还可以包括输入输出设备、网络接入设备、总线等。
所称处理器501可以是中央处理单元(Central Processing Unit,CPU),还可以是其他通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现成可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
所述存储器502可以是所述终端设备的内部存储单元,例如终端设备的硬盘或内存。所述存储器502也可以是所述终端设备的外部存储设备,例如所述终端设备上配备的插接式硬盘,智能存储卡(Smart Media Card,SMC),安全数字(Secure Digital,SD)卡,闪存卡(Flash Card)等。进一步地,所述存储器502还可以既包括所述终端设备的内部存储单元也包括外部存储设备。所述存储器502用于存储所述计算机程序以及所述终端设备所需的其他程序和数据。所述存储器502还可以用于暂时地存储已经输出或者将要输出的数据。
需要说明的是,为描述的方便和简洁,上述终端设备的结构还可以参考方法实施例中对结构的具体描述,在此不再赘述。
所属领域的技术人员可以清楚地了解到,为了描述的方便和简洁,仅以上述各功能单元、模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能单元、模块完成,即将所述装置的内部结构划分成不同的功能单元或模块,以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中,上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。另外,各功能单元、模块的具体名称也只是为了便于相互区分,并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
本申请实施例还提供了一种计算机可读存储介质,所述计算机可读存储介质存储有计算机程序,所述计算机程序被处理器执行时可实现上述文件的修复方法中的步骤。
本申请实施例提供了一种计算机程序产品,当计算机程序产品在移动终端上运行时,使得移动终端执行时可实现上述文件的修复方法中的步骤。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述或记载的部分,可以参见其它实施例的相关描述。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对各个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
在本申请所提供的实施例中,应该理解到,所揭露的装置/终端设备和方法,可以通过其它的方式实现。例如,以上所描述的装置/终端设备实施例仅仅是示意性的,例如,所述模块或单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口,装置或单元的间接耦合或通讯连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请实现上述实施例方法中的全部或部分流程,也可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一计算机可读存储介质中,该计算机程序在被处理器执行时,可实现上述各个方法实施例的步骤。其中,所述计算机程序包括计算机程序代码,所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括:能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、电载波信号、电信信号以及软件分发介质等。需要说明的是,所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减,例如在某些司法管辖区,根据立法和专利实践,计算机可读介质不包括电载波信号和电信信号。
以上所述实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围,均应包含在本申请的保护范围之内。