CN107122463B - 文件保存方法及装置 - Google Patents

Abstract

本发明公开了一种文件保存方法及装置。该文件保存方法包括：配置待保存模块的文件保存路径；接收通过所述富文本编辑器上传的文件；将所述文件保存在与所述文件匹配的所述文件保存路径下。应用本发明的技术方案，能够实现多个模块中引用同一个富文本编辑器组件时，可以按照不同的模块进行分目录保存，从而降低系统的代码冗余量，增强了系统的安全性。

Description

文件保存方法及装置

技术领域

本发明涉及计算机通信技术领域，尤其涉及一种文件保护方法及装置。

背景技术

现有市面上的富文本编辑器具有轻量、可定制、用户体验优秀等特点，因此很受网站开发者喜欢。

但是在文件保存上面都有一个弊端，例如当在一个工程项目中的多个模块中引用富文本编辑器组件时，如果想实现每个模块分目录保存用户的上传文件，那么则需要每个模块各自去引用各自的编辑器代码库，然后再去修改他们相对应的配置文件里面的文件存放目录，这样就导致我们的工程代码中，出现多个富文本编辑器组件，冗余量太大。例如，假设一个系统有6个地方引用富文本编辑器，如果每个地方都引用不同的富文本编辑器的话，那么在这个工程里面，将需要在这6个模块下面挂6个富文本编辑器组件，此时代码工程量大大会提高，导致冗余量太大。

然而，如果在多个模块中同时去引用同一个富文本编辑器组件时，因为此时这些模块它们共用了同一个富文本编辑器组件，就会出现这些模块上传的所有文件都保存在了同一个配置的文件目录下。如图7所示，是现有技术中A、B两个模块共用一个富文本编辑器组件保存文件的示意图。如图7所示，当需要保存模块A的文件或模块B的文件时，富文本编辑器组件的后端均取富文本编辑器统一配置的地址路径C，并按照地址路径C进行地址封装，以将模块A的文件或模块B的文件统一保存在地址路径C下。即是说，通过不同模块上传的文件均会保存在同一个配置的文件目录下，这样不仅不能区分开各个模块上传的文件，同时大量无序的文件后续可能造成安全性问题，后期难以维护。

发明内容

本发明的主要目的在于提出一种文件保存方法及装置，能够实现多个模块中引用同一个富文本编辑器组件时，可以按照不同的模块进行分目录保存，从而降低系统的代码冗余量，增强了系统的安全性。

为实现上述目的，本发明提供的一种文件保存方法，用于使用富文本编辑器上传的文件的保存，所述文件保存方法包括如下步骤：

配置待保存模块的文件保存路径；

接收通过所述富文本编辑器上传的文件；

将所述文件保存在与所述文件匹配的所述文件保存路径下。

其中，所述配置待保存模块的文件保存路径，具体包括：

获取所述待保存模块的文件名；

将所述文件名封装入待保存的地址路径，得到所述文件保存路径。

其中，所述获取所述待保存模块的文件名，包括：

通过所述富文本编辑器的前端配置所述待保存模块的文件名；

通过所述富文本编辑器的前端将所述文件名传给所述富文本编辑器的后端；

通过所述富文本编辑器的后端读取所述文件名。

其中，所述通过所述富文本编辑器的前端配置所述待保存模块的文件名，包括：

在实例化所述富文本编辑器时，通过所述前端的页面接收传入的所述文件名。

其中，所述通过所述富文本编辑器的前端将所述文件名传给所述富文本编辑器的后端，包括：

通过所述前端的request实体将所述文件名提交给所述富文本编辑器的后端。

此外，为实现上述目的，本发明还提出一种文件保存装置，用于使用富文本编辑器上传的文件的保存，所述装置包括：

配置模块，用于配置待保存模块的文件保存路径；

接收模块，用于接收通过所述富文本编辑器上传的文件；

存储模块，用于将所述文件保存在与所述文件匹配的所述文件保存路径下。

其中，所述配置模块包括：

获取单元，用于获取所述待保存模块的文件名；

封装单元，用于将所述获取单元获取的所述文件名封装入待保存的地址路径，形成所述文件保存路径。

其中，所述获取单元，具体用于：

通过所述富文本编辑器的前端配置所述待保存模块的文件名；

通过所述富文本编辑器的前端将所述文件名传给所述富文本编辑器的后端；

通过所述富文本编辑器的后端读取所述文件名。

其中，所述获取单元，具体用于：在实例化所述富文本编辑器时，通过所述前端的页面接收传入的所述文件名。

其中，所述获取单元，具体用于：通过所述前端的request实体将所述文件名提交给所述富文本编辑器的后端。

本发明的有益效果是：

本发明实施例的技术方案，由于预先在前端页面配置了待保存模块的文件保存路径，因此在完成富文本编辑器的调用，接收到上传文件之后，后端便可将上传的文件保存在与该文件匹配的、前端配置的文件保存路径下。由此实现了一个工程项目多个模块中引用同一个富文本编辑器组件时，可以按照不同的模块进行分目录保存；同时还降低了系统的代码冗余量，增强了系统的安全性，后期维护也更加方便。

附图说明

图1是本发明的文件保存方法的实施例的流程示意图；

图2为图1中步骤101的实施例的流程示意图；

图3是图2中步骤201的实施例的流程示意图；

图4是本发明的文件保存方法的框架示意图；

图5是本发明的文件保存装置的实施例的结构示意图；

图6是图5中配置模块的实施例的结构示意图；

图7是现有技术中文件保存方法的框架示意图；

图8是现有技术中文件保存方法的用户交互示意图；

图9是现有技术中文件保存方法的用户交互示意图；

图10是本发明的文件保存方法的用户交互示意图；

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

如图1所示，是本发明的文件保存方法的第一实施例的流程示意图。如图3所示，该文件保存方法包括如下步骤：

步骤101：配置待保存模块的文件保存路径。

步骤102：接收通过所述富文本编辑器上传的文件。

步骤103：将所述文件保存在与所述文件匹配的所述文件保存路径下。

根据背景技术的描述可知，当在一个工程项目中的多个模块中引用富文本编辑器组件时，若想实现各个模块分目录保存，则需要各个模块各自引用各自的编辑器代码库，这样就导致工程代码中，出现多个富文本编辑器组件，冗余量太大。然而，若各个模块共用一个富文本编辑器组件，又不能实现分目录保存，并且还容易造成安全性问题，后期难以维护。为实现各模块的分目录存储且各个模块能共用一个富文本编辑器，提出了本发明的基于富文本编辑器的文件保存方法。

由于一个工程项目中有多个模块，因此在步骤101中，首先需要配置各个待保存模块的文件保存路径；在具体配置各个待保存模块的文件保存路径时，实现方式例如可以通过图2所示的方法。

图2是图1中步骤101的实施例的流程示意图。包括如下步骤：

步骤201：获取所述待保存模块的文件名。本步骤中，通过文件名来区分不同模块的路径保存参数。

步骤202：将所述文件名封装入待保存的地址路径，得到待保存模块的文件保存路径。

步骤201具体操作时，可以通过图3所示的方法实现。

步骤301：通过所述富文本编辑器的前端配置所述待保存模块的文件名。

步骤302：通过所述富文本编辑器的前端将所述文件名传给所述富文本编辑器的后端。

步骤303：通过所述富文本编辑器的后端读取所述文件名。

一般地，在引用富文本编辑器时，只需要在对应的页面引入富文本编辑器的JS组件，然后实例化该文本编辑器，就完成了该富文本编辑器的调用。

本发明实施例中，在实例化富文本编辑器，还通过所述富文本编辑器的前端配置所述待保存模块的文件名，例如通过富文本编辑器的前端配置一个参数名为Filename的文件名A，旨在表明当前需要保存的模块为模块A。在配置文件名时，具体可以是：在实例化所述富文本编辑器时，通过所述前端的页面接收用户传入的所述文件名，例如用户通过前端页面输入的文件名A。

富文本编辑器的前端页面完成文件名的配置之后，还通过前端的request实体将配置的文件名提交给所述富文本编辑器的后端。在编辑器后端中，将前端页面配置的文件名通过request实体将配置的文件名取出来。即是说，此时不去取富文本编辑器默认的保存路径地址，而是取前端传递过来的路径参数(即文件名)，来替代原来的默认路径。

通过步骤301至步骤303完成待保存模块的文件名获取之后，还将获取的文件名封装入待保存的地址路径，即是说需要将取出来的文件名封装进入需要保持存的地址路径中去，然后当通过富文本编辑器上传的文件的文件名与该文件保存路径中携带的文件名匹配时，通过该文件保存路径去保存用户通过富文本编辑器上传的文件，这样就实现了通过在模块的前端页面传入文件名来区分保存各个模块的上传文件的目的。

可以理解的是，因为需要判断通过富文本编辑器上传的文件的文件名与该文件保存路径中携带的文件名是否匹配，因此在接收到通过富文本编辑器上传的文件之后，还提取该文件中携带的文件名，该文件名表明该文件是通过哪个待保存模块上传的。当富文本编辑器上传的文件的文件名与该文件保存路径中携带的文件名匹配时，则表明上传该文件的模块与文件保存路径对应的待保存模块为同一模块。此时，可使用该文件保存路径保存该文件，或者说将文件保存在与该文件匹配的文件保存路径下，以实现不同模块的分目录保存。

下面，结合图4举一实际例子来进行详细说明。

如图4所示，当需要保存模块A的文件时，首先在编辑器的前端页面配置一个参数名为Filename的文件名A，同时，前端页面通过request实体将配置的文件名提交给后端。完成富文本编辑器组件的调用之后，后端通过request实体读取文件名A，并将文件名A封装入需要保存的地址路径。此时，当用户通过A模块、富文本编辑器上传文件时，富文本编辑器的后端可提取上传的文件中携带的文件名，并查找与该文件名匹配的文件保存路径，以及按照查找出的文件保存路径保存用户上传的文件，这样，说用户通过所述富文本编辑器上传的文件便可保存在文件A路径下。

同理，适用于模块B的文件保存。

当需要保存模块B的文件时，首先在编辑器的前端页面配置一个参数名为Filename的文件名B，同时，前端页面通过request实体将配置的文件名提交给后端。完成富文本编辑器组件的调用之后，后端通过request实体读取文件名B，并将文件名B封装入需要保存的地址路径。此时，当用户通过B模块、富文本编辑器上传文件时，富文本编辑器的后端可提取上传的文件中携带的文件名，并查找与该文件名匹配的文件保存路径，以及按照查找出的文件保存路径保存用户上传的文件，这样，说用户通过所述富文本编辑器上传的文件便可保存在文件B路径下。

本发明实施例的用于富文本编辑器上传的文件的文件保存方法，由于预先在前端页面配置了待保存模块的文件保存路径，因此在完成富文本编辑器的调用，接收到上传文件之后，后端便可将上传的文件保存在与该文件匹配的、前端配置的文件保存路径下。由此实现了一个工程项目多个模块中引用同一个富文本编辑器组件时，可以按照不同的模块进行分目录保存；同时还降低了系统的代码冗余量，增强了系统的安全性，后期维护也更加方便。

下面，将举几个具体例子进行详细说明。

假如一个网站或系统有N个页面，在这N个页面中有ABCD四个页面(模块)需要用到富文本编辑器。此时在代码开发的时候，为这四个页面引入了同一个富文本编辑器组件。在没有改进之前，不管进入ABCD这四个页面的不管哪个页面进行文件上传时，此时这些上传的文件或图片都会被保存到该富文本编辑器的统一路径地址下面。当日积月累过后，此时该路径下的文件数目会太多太杂，冗余量太大，同时不易区分是哪个页面上传过来的，会造成系统安全性问题，以及后期的维护工作量大大提高。上传文件的示意图可以如图8(图8为通过页面A上传的文件)和图9所示(页面A上传的文件保存至默认地址)。

若采用本发明实施例的保存方法，具体保存过程如下：

同样地，假如一个网站或系统有N个页面，在这N个页面中有ABCD四个页面(模块)需要用到富文本编辑器。此时在代码开发的时候，为这四个页面引入了同一个富文本编辑器组件；同时，在开发ABCD这四个页面的时候，在它们各自的页面代码中，将要保存的路径地址参数a、b、c、d写入到它们各自的这四个页面里面。那么此时当有一个用户登录到这个系统，进入到A页面进行文件或图片的上传时，就会将这个写在A页面的参数路径地址a一起连同文件或图片一起提交到富文本编辑器的代码后台去。那么此时进行文件保存时，富文本编辑器就会将文件保存到对应的路径地址参数a下面去。同理当我们在BCD页面操作上传文件时也一样会把对应的文件保存到路径地址参数b、c、d路径下。这样我们就区分开了将不同的页面或模块保存到不同的对应地址中去，如图10所示。

如图5所示，是本发明的文件保存装置的实施例的结构示意图。如图5所示，该文件保存装置500包括：配置模块501，存储模块502，接收模块503。

其中，配置模块501，用于配置待保存模块的文件保存路径。

接收模块503，用于接收通过富文本编辑器上传的文件。

存储模块502，用于将接收模块503接收的文件存储在与该文件匹配的配置模块501配置的文件保存路径下。

根据背景技术的描述可知，当在一个工程项目中的多个模块中引用富文本编辑器组件时，若想实现各个模块分目录保存，则需要各个模块各自引用各自的编辑器代码库，这样就导致工程代码中，出现多个富文本编辑器组件，冗余量太大。然而，若各个模块共用一个富文本编辑器组件，又不能实现分目录保存，并且还容易造成安全性问题，后期难以维护。为实现各模块的分目录存储且各个模块能共用一个富文本编辑器，提出了本发明的基于富文本编辑器的文件保存装置。

由于一个工程项目中有多个模块，因此文件保存装置首先需要通过配置模块501配置待保存模块的文件保存路径；配置模块501的结构例如可以是如图6所示。配置模块501包括：获取单元5011以及封装单元5012。

其中，获取单元5011，用于获取所述待保存模块的文件名，以通过文件名来区分不同模块的路径保存参数。而封装单元5012则用于将所述获取单元获取的所述文件名封装入待保存的地址路径，形成文件保存路径。具体操作时，获取单元5011通过所述富文本编辑器的前端配置所述待保存模块的文件名，通过所述富文本编辑器的前端将所述文件名传给所述富文本编辑器的后端，通过所述富文本编辑器的后端读取所述文件名。

一般地，在引用富文本编辑器时，只需要在对应的页面引入富文本编辑器的JS组件，然后实例化该文本编辑器，就完成了该富文本编辑器的调用。

本发明实施例中，在实例化富文本编辑器，获取单元5011还通过所述富文本编辑器的前端配置所述待保存模块的文件名，例如通过富文本编辑器的前端配置一个参数名为Filename的文件名A，旨在表明当前需要保存的模块为模块A。在配置文件名时，具体可以是：在实例化所述富文本编辑器时，获取单元5011通过所述前端的页面接收用户传入的所述文件名，例如用户通过前端页面输入的文件名A。

富文本编辑器的前端页面完成文件名的配置之后，获取单元5011还通过前端的request实体将配置的文件名提交给所述富文本编辑器的后端。在编辑器后端中，将前端页面配置的文件名通过request实体将配置的文件名取出来。即是说，此时不去取富文本编辑器默认的保存路径地址，而是取前端传递过来的路径参数(即文件名)，来替代原来的默认路径。

在完成待保存模块的文件名获取之后，还通过封装单元5012将获取的文件名封装入待保存的地址路径，即是说需要将取出来的文件名封装进入需要保持存的地址路径中去，然后当通过富文本编辑器上传的文件的文件名与该文件保存路径中携带的文件名匹配时，通过该文件保存路径去保存用户通过富文本编辑器上传的文件，这样就实现了通过在模块的前端页面传入文件名来区分保存各个模块的上传文件的目的。

可以理解的是，因为需要判断通过富文本编辑器上传的文件的文件名与该文件保存路径中携带的文件名是否匹配，因此在接收到通过富文本编辑器上传的文件之后，还提取该文件中携带的文件名，该文件名表明该文件是通过哪个待保存模块上传的。当富文本编辑器上传的文件的文件名与该文件保存路径中携带的文件名匹配时，则表明上传该文件的模块与文件保存路径对应的待保存模块为同一模块。此时，可使用该文件保存路径保存该文件，或者说将文件保存在与该文件匹配的文件保存路径下，以实现不同模块的分目录保存。

如图4所示，当需要保存模块A的文件时，首先在编辑器的前端页面配置一个参数名为Filename的文件名A，同时，前端页面通过request实体将配置的文件名提交给后端。完成富文本编辑器组件的调用之后，后端通过request实体读取文件名A，并将文件名A封装入需要保存的地址路径。此时，当用户通过A模块、富文本编辑器上传文件时，富文本编辑器的后端可提取上传的文件中携带的文件名，并查找与该文件名匹配的文件保存路径，以及按照查找出的文件保存路径保存用户上传的文件，这样，说用户通过所述富文本编辑器上传的文件便可保存在文件A路径下。

同理，适用于模块B的文件保存。

当需要保存模块B的文件时，首先在编辑器的前端页面配置一个参数名为Filename的文件名B，同时，前端页面通过request实体将配置的文件名提交给后端。完成富文本编辑器组件的调用之后，后端通过request实体读取文件名B，并将文件名B封装入需要保存的地址路径。此时，当用户通过B模块、富文本编辑器上传文件时，富文本编辑器的后端可提取上传的文件中携带的文件名，并查找与该文件名匹配的文件保存路径，以及按照查找出的文件保存路径保存用户上传的文件，这样，说用户通过所述富文本编辑器上传的文件便可保存在文件B路径下。

本发明实施例的用于富文本编辑器上传的文件的文件保存装置，由于预先在前端页面配置了待保存模块的文件保存路径，因此在完成富文本编辑器的调用、接收到上传文件之后，后端便可将上传的文件保存在与该文件匹配的、前端配置的文件保存路径下。由此实现了一个工程项目多个模块中引用同一个富文本编辑器组件时，可以按照不同的模块进行分目录保存；同时还降低了系统的代码冗余量，增强了系统的安全性，后期维护也更加方便。

下面，将举几个具体例子进行详细说明。

假如一个网站或系统有N个页面，在这N个页面中有ABCD四个页面(模块)需要用到富文本编辑器。此时在代码开发的时候，为这四个页面引入了同一个富文本编辑器组件。在没有改进之前，不管进入ABCD这四个页面的不管哪个页面进行文件上传时，此时这些上传的文件或图片都会被保存到该富文本编辑器的统一路径地址下面。当日积月累过后，此时该路径下的文件数目会太多太杂，冗余量太大，同时不易区分是哪个页面上传过来的，会造成系统安全性问题，以及后期的维护工作量大大提高。上传文件的示意图可以如图8(图8为通过页面A上传的文件)和图9所示(页面A上传的文件保存至默认地址)。

若采用本发明实施例的保存方法，具体保存过程如下：

同样地，假如一个网站或系统有N个页面，在这N个页面中有ABCD四个页面(模块)需要用到富文本编辑器。此时在代码开发的时候，为这四个页面引入了同一个富文本编辑器组件；同时，在开发ABCD这四个页面的时候，在它们各自的页面代码中，将要保存的路径地址参数a、b、c、d写入到它们各自的这四个页面里面。那么此时当有一个用户登录到这个系统，进入到A页面进行文件或图片的上传时，就会将这个写在A页面的参数路径地址a一起连同文件或图片一起提交到富文本编辑器的代码后台去。那么此时进行文件保存时，富文本编辑器就会将文件保存到对应的路径地址参数a下面去。同理当我们在BCD页面操作上传文件时也一样会把对应的文件保存到路径地址参数b、c、d路径下。这样我们就区分开了将不同的页面或模块保存到不同的对应地址中去，如图10所示。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (6)

1.一种文件保存装置，用于使用富文本编辑器上传的文件的保存，其特征在于，所述装置包括：

配置模块，用于配置待保存模块的文件保存路径；

接收模块，用于接收通过所述富文本编辑器上传的文件；

存储模块，用于当所述接收模块接收的文件的文件名与所述文件保存路径中携带的文件名匹配时，使用所述文件保存路径保存所述文件；

所述配置模块包括：

获取单元，用于获取所述待保存模块的文件名；

封装单元，用于将所述获取单元获取的所述文件名封装入待保存的地址路径，形成所述文件保存路径；

所述获取单元，具体用于：

通过所述富文本编辑器的前端配置所述待保存模块的文件名；

通过所述富文本编辑器的前端将所述文件名传给所述富文本编辑器的后端；

通过所述富文本编辑器的后端读取所述文件名。

2.根据权利要求1所述的文件保存装置，其特征在于，所述获取单元，具体用于：在实例化所述富文本编辑器时，通过所述前端的页面接收传入的所述文件名。

3.根据权利要求1所述的文件保存装置，其特征在于，所述获取单元，具体用于：通过所述前端的request实体将所述文件名提交给所述富文本编辑器的后端。

4.一种文件保存方法，用于使用富文本编辑器上传的文件的保存，其特征在于，所述文件保存方法包括如下步骤：

配置待保存模块的文件保存路径；

接收通过所述富文本编辑器上传的文件；

将所述文件保存在与所述文件匹配的所述文件保存路径下；

所述配置待保存模块的文件保存路径，具体包括：

获取所述待保存模块的文件名；

将所述文件名封装入待保存的地址路径，得到所述文件保存路径；

所述获取所述待保存模块的文件名，包括：

通过所述富文本编辑器的前端配置所述待保存模块的文件名；

通过所述富文本编辑器的前端将所述文件名传给所述富文本编辑器的后端；

通过所述富文本编辑器的后端读取所述文件名。

5.如权利要求4所述的文件保存方法，其特征在于，所述通过所述富文本编辑器的前端配置所述待保存模块的文件名，包括：

在实例化所述富文本编辑器时，通过所述前端的页面接收传入的所述文件名。

6.如权利要求4所述的文件保存方法，其特征在于，所述通过所述富文本编辑器的前端将所述文件名传给所述富文本编辑器的后端，包括：

通过所述前端的request实体将所述文件名提交给所述富文本编辑器的后端。

Images