本發(fā)明涉及計(jì)算機(jī)通信技術(shù)領(lǐng)域，尤其涉及一種文件保護(hù)方法及裝置。

背景技術(shù)：

現(xiàn)有市面上的富文本編輯器具有輕量、可定制、用戶體驗(yàn)優(yōu)秀等特點(diǎn)，因此很受網(wǎng)站開發(fā)者喜歡。

但是在文件保存上面都有一個(gè)弊端，例如當(dāng)在一個(gè)工程項(xiàng)目中的多個(gè)模塊中引用富文本編輯器組件時(shí)，如果想實(shí)現(xiàn)每個(gè)模塊分目錄保存用戶的上傳文件，那么則需要每個(gè)模塊各自去引用各自的編輯器代碼庫，然后再去修改他們相對(duì)應(yīng)的配置文件里面的文件存放目錄，這樣就導(dǎo)致我們的工程代碼中，出現(xiàn)多個(gè)富文本編輯器組件，冗余量太大。例如，假設(shè)一個(gè)系統(tǒng)有6個(gè)地方引用富文本編輯器，如果每個(gè)地方都引用不同的富文本編輯器的話，那么在這個(gè)工程里面，將需要在這6個(gè)模塊下面掛6個(gè)富文本編輯器組件，此時(shí)代碼工程量大大會(huì)提高，導(dǎo)致冗余量太大。

然而，如果在多個(gè)模塊中同時(shí)去引用同一個(gè)富文本編輯器組件時(shí)，因?yàn)榇藭r(shí)這些模塊它們共用了同一個(gè)富文本編輯器組件，就會(huì)出現(xiàn)這些模塊上傳的所有文件都保存在了同一個(gè)配置的文件目錄下。如圖7所示，是現(xiàn)有技術(shù)中a、b兩個(gè)模塊共用一個(gè)富文本編輯器組件保存文件的示意圖。如圖7所示，當(dāng)需要保存模塊a的文件或模塊b的文件時(shí)，富文本編輯器組件的后端均取富文本編輯器統(tǒng)一配置的地址路徑c，并按照地址路徑c進(jìn)行地址封裝，以將模塊a的文件或模塊b的文件統(tǒng)一保存在地址路徑c下。即是說，通過不同模塊上傳的文件均會(huì)保存在同一個(gè)配置的文件目錄下，這樣不僅不能區(qū)分開各個(gè)模塊上傳的文件，同時(shí)大量無序的文件后續(xù)可能造成安全性問題，后期難以維護(hù)。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明的主要目的在于提出一種文件保存方法及裝置，能夠?qū)崿F(xiàn)多個(gè)模塊中引用同一個(gè)富文本編輯器組件時(shí)，可以按照不同的模塊進(jìn)行分目錄保存，從而降低系統(tǒng)的代碼冗余量，增強(qiáng)了系統(tǒng)的安全性。

為實(shí)現(xiàn)上述目的，本發(fā)明提供的一種文件保存方法，用于使用富文本編輯器上傳的文件的保存，所述文件保存方法包括如下步驟：

配置待保存模塊的文件保存路徑；

接收通過所述富文本編輯器上傳的文件；

將所述文件保存在與所述文件匹配的所述文件保存路徑下。

其中，所述配置待保存模塊的文件保存路徑，具體包括：

獲取所述待保存模塊的文件名；

將所述文件名封裝入待保存的地址路徑，得到所述文件保存路徑。

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

通過所述富文本編輯器的前端配置所述待保存模塊的文件名；

通過所述富文本編輯器的前端將所述文件名傳給所述富文本編輯器的后端；

通過所述富文本編輯器的后端讀取所述文件名。

其中，所述通過所述富文本編輯器的前端配置所述待保存模塊的文件名，包括：

在實(shí)例化所述富文本編輯器時(shí)，通過所述前端的頁面接收傳入的所述文件名。

其中，所述通過所述富文本編輯器的前端將所述文件名傳給所述富文本編輯器的后端，包括：

通過所述前端的request實(shí)體將所述文件名提交給所述富文本編輯器的后端。

此外，為實(shí)現(xiàn)上述目的，本發(fā)明還提出一種文件保存裝置，用于使用富文本編輯器上傳的文件的保存，所述裝置包括：

配置模塊，用于配置待保存模塊的文件保存路徑；

接收模塊，用于接收通過所述富文本編輯器上傳的文件；

存儲(chǔ)模塊，用于將所述文件保存在與所述文件匹配的所述文件保存路徑下。

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

獲取單元，用于獲取所述待保存模塊的文件名；

封裝單元，用于將所述獲取單元獲取的所述文件名封裝入待保存的地址路徑，形成所述文件保存路徑。

其中，所述獲取單元，具體用于：

通過所述富文本編輯器的前端配置所述待保存模塊的文件名；

通過所述富文本編輯器的前端將所述文件名傳給所述富文本編輯器的后端；

通過所述富文本編輯器的后端讀取所述文件名。

其中，所述獲取單元，具體用于：在實(shí)例化所述富文本編輯器時(shí)，通過所述前端的頁面接收傳入的所述文件名。

其中，所述獲取單元，具體用于：通過所述前端的request實(shí)體將所述文件名提交給所述富文本編輯器的后端。

本發(fā)明的有益效果是：

本發(fā)明實(shí)施例的技術(shù)方案，由于預(yù)先在前端頁面配置了待保存模塊的文件保存路徑，因此在完成富文本編輯器的調(diào)用，接收到上傳文件之后，后端便可將上傳的文件保存在與該文件匹配的、前端配置的文件保存路徑下。由此實(shí)現(xiàn)了一個(gè)工程項(xiàng)目多個(gè)模塊中引用同一個(gè)富文本編輯器組件時(shí)，可以按照不同的模塊進(jìn)行分目錄保存；同時(shí)還降低了系統(tǒng)的代碼冗余量，增強(qiáng)了系統(tǒng)的安全性，后期維護(hù)也更加方便。

附圖說明

圖1是本發(fā)明的文件保存方法的實(shí)施例的流程示意圖；

圖2為圖1中步驟101的實(shí)施例的流程示意圖；

圖3是圖2中步驟201的實(shí)施例的流程示意圖；

圖4是本發(fā)明的文件保存方法的框架示意圖；

圖5是本發(fā)明的文件保存裝置的實(shí)施例的結(jié)構(gòu)示意圖；

圖6是圖5中配置模塊的實(shí)施例的結(jié)構(gòu)示意圖；

圖7是現(xiàn)有技術(shù)中文件保存方法的框架示意圖；

圖8是現(xiàn)有技術(shù)中文件保存方法的用戶交互示意圖；

圖9是現(xiàn)有技術(shù)中文件保存方法的用戶交互示意圖；

圖10是本發(fā)明的文件保存方法的用戶交互示意圖；

本發(fā)明目的的實(shí)現(xiàn)、功能特點(diǎn)及優(yōu)點(diǎn)將結(jié)合實(shí)施例，參照附圖做進(jìn)一步說明。

具體實(shí)施方式

應(yīng)當(dāng)理解，此處所描述的具體實(shí)施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

如圖1所示，是本發(fā)明的文件保存方法的第一實(shí)施例的流程示意圖。如圖3所示，該文件保存方法包括如下步驟：

步驟101：配置待保存模塊的文件保存路徑。

步驟102：接收通過所述富文本編輯器上傳的文件。

步驟103：將所述文件保存在與所述文件匹配的所述文件保存路徑下。

根據(jù)背景技術(shù)的描述可知，當(dāng)在一個(gè)工程項(xiàng)目中的多個(gè)模塊中引用富文本編輯器組件時(shí)，若想實(shí)現(xiàn)各個(gè)模塊分目錄保存，則需要各個(gè)模塊各自引用各自的編輯器代碼庫，這樣就導(dǎo)致工程代碼中，出現(xiàn)多個(gè)富文本編輯器組件，冗余量太大。然而，若各個(gè)模塊共用一個(gè)富文本編輯器組件，又不能實(shí)現(xiàn)分目錄保存，并且還容易造成安全性問題，后期難以維護(hù)。為實(shí)現(xiàn)各模塊的分目錄存儲(chǔ)且各個(gè)模塊能共用一個(gè)富文本編輯器，提出了本發(fā)明的基于富文本編輯器的文件保存方法。

由于一個(gè)工程項(xiàng)目中有多個(gè)模塊，因此在步驟101中，首先需要配置各個(gè)待保存模塊的文件保存路徑；在具體配置各個(gè)待保存模塊的文件保存路徑時(shí)，實(shí)現(xiàn)方式例如可以通過圖2所示的方法。

圖2是圖1中步驟101的實(shí)施例的流程示意圖。包括如下步驟：

步驟201：獲取所述待保存模塊的文件名。本步驟中，通過文件名來區(qū)分不同模塊的路徑保存參數(shù)。

步驟202：將所述文件名封裝入待保存的地址路徑，得到待保存模塊的文件保存路徑。

步驟201具體操作時(shí)，可以通過圖3所示的方法實(shí)現(xiàn)。

步驟301：通過所述富文本編輯器的前端配置所述待保存模塊的文件名。

步驟302：通過所述富文本編輯器的前端將所述文件名傳給所述富文本編輯器的后端。

步驟303：通過所述富文本編輯器的后端讀取所述文件名。

一般地，在引用富文本編輯器時(shí)，只需要在對(duì)應(yīng)的頁面引入富文本編輯器的js組件，然后實(shí)例化該文本編輯器，就完成了該富文本編輯器的調(diào)用。

本發(fā)明實(shí)施例中，在實(shí)例化富文本編輯器，還通過所述富文本編輯器的前端配置所述待保存模塊的文件名，例如通過富文本編輯器的前端配置一個(gè)參數(shù)名為filename的文件名a，旨在表明當(dāng)前需要保存的模塊為模塊a。在配置文件名時(shí)，具體可以是：在實(shí)例化所述富文本編輯器時(shí)，通過所述前端的頁面接收用戶傳入的所述文件名，例如用戶通過前端頁面輸入的文件名a。

富文本編輯器的前端頁面完成文件名的配置之后，還通過前端的request實(shí)體將配置的文件名提交給所述富文本編輯器的后端。在編輯器后端中，將前端頁面配置的文件名通過request實(shí)體將配置的文件名取出來。即是說，此時(shí)不去取富文本編輯器默認(rèn)的保存路徑地址，而是取前端傳遞過來的路徑參數(shù)(即文件名)，來替代原來的默認(rèn)路徑。

通過步驟301至步驟303完成待保存模塊的文件名獲取之后，還將獲取的文件名封裝入待保存的地址路徑，即是說需要將取出來的文件名封裝進(jìn)入需要保持存的地址路徑中去，然后當(dāng)通過富文本編輯器上傳的文件的文件名與該文件保存路徑中攜帶的文件名匹配時(shí)，通過該文件保存路徑去保存用戶通過富文本編輯器上傳的文件，這樣就實(shí)現(xiàn)了通過在模塊的前端頁面?zhèn)魅胛募麃韰^(qū)分保存各個(gè)模塊的上傳文件的目的。

可以理解的是，因?yàn)樾枰袛嗤ㄟ^富文本編輯器上傳的文件的文件名與該文件保存路徑中攜帶的文件名是否匹配，因此在接收到通過富文本編輯器上傳的文件之后，還提取該文件中攜帶的文件名，該文件名表明該文件是通過哪個(gè)待保存模塊上傳的。當(dāng)富文本編輯器上傳的文件的文件名與該文件保存路徑中攜帶的文件名匹配時(shí)，則表明上傳該文件的模塊與文件保存路徑對(duì)應(yīng)的待保存模塊為同一模塊。此時(shí)，可使用該文件保存路徑保存該文件，或者說將文件保存在與該文件匹配的文件保存路徑下，以實(shí)現(xiàn)不同模塊的分目錄保存。

下面，結(jié)合圖4舉一實(shí)際例子來進(jìn)行詳細(xì)說明。

如圖4所示，當(dāng)需要保存模塊a的文件時(shí)，首先在編輯器的前端頁面配置一個(gè)參數(shù)名為filename的文件名a，同時(shí)，前端頁面通過request實(shí)體將配置的文件名提交給后端。完成富文本編輯器組件的調(diào)用之后，后端通過request實(shí)體讀取文件名a，并將文件名a封裝入需要保存的地址路徑。此時(shí)，當(dāng)用戶通過a模塊、富文本編輯器上傳文件時(shí)，富文本編輯器的后端可提取上傳的文件中攜帶的文件名，并查找與該文件名匹配的文件保存路徑，以及按照查找出的文件保存路徑保存用戶上傳的文件，這樣，說用戶通過所述富文本編輯器上傳的文件便可保存在文件a路徑下。

同理，適用于模塊b的文件保存。

當(dāng)需要保存模塊b的文件時(shí)，首先在編輯器的前端頁面配置一個(gè)參數(shù)名為filename的文件名b，同時(shí)，前端頁面通過request實(shí)體將配置的文件名提交給后端。完成富文本編輯器組件的調(diào)用之后，后端通過request實(shí)體讀取文件名b，并將文件名b封裝入需要保存的地址路徑。此時(shí)，當(dāng)用戶通過b模塊、富文本編輯器上傳文件時(shí)，富文本編輯器的后端可提取上傳的文件中攜帶的文件名，并查找與該文件名匹配的文件保存路徑，以及按照查找出的文件保存路徑保存用戶上傳的文件，這樣，說用戶通過所述富文本編輯器上傳的文件便可保存在文件b路徑下。

本發(fā)明實(shí)施例的用于富文本編輯器上傳的文件的文件保存方法，由于預(yù)先在前端頁面配置了待保存模塊的文件保存路徑，因此在完成富文本編輯器的調(diào)用，接收到上傳文件之后，后端便可將上傳的文件保存在與該文件匹配的、前端配置的文件保存路徑下。由此實(shí)現(xiàn)了一個(gè)工程項(xiàng)目多個(gè)模塊中引用同一個(gè)富文本編輯器組件時(shí)，可以按照不同的模塊進(jìn)行分目錄保存；同時(shí)還降低了系統(tǒng)的代碼冗余量，增強(qiáng)了系統(tǒng)的安全性，后期維護(hù)也更加方便。

下面，將舉幾個(gè)具體例子進(jìn)行詳細(xì)說明。

假如一個(gè)網(wǎng)站或系統(tǒng)有n個(gè)頁面，在這n個(gè)頁面中有abcd四個(gè)頁面(模塊)需要用到富文本編輯器。此時(shí)在代碼開發(fā)的時(shí)候，為這四個(gè)頁面引入了同一個(gè)富文本編輯器組件。在沒有改進(jìn)之前，不管進(jìn)入abcd這四個(gè)頁面的不管哪個(gè)頁面進(jìn)行文件上傳時(shí)，此時(shí)這些上傳的文件或圖片都會(huì)被保存到該富文本編輯器的統(tǒng)一路徑地址下面。當(dāng)日積月累過后，此時(shí)該路徑下的文件數(shù)目會(huì)太多太雜，冗余量太大，同時(shí)不易區(qū)分是哪個(gè)頁面上傳過來的，會(huì)造成系統(tǒng)安全性問題，以及后期的維護(hù)工作量大大提高。上傳文件的示意圖可以如圖8(圖8為通過頁面a上傳的文件)和圖9所示(頁面a上傳的文件保存至默認(rèn)地址)。

若采用本發(fā)明實(shí)施例的保存方法，具體保存過程如下：

同樣地，假如一個(gè)網(wǎng)站或系統(tǒng)有n個(gè)頁面，在這n個(gè)頁面中有abcd四個(gè)頁面(模塊)需要用到富文本編輯器。此時(shí)在代碼開發(fā)的時(shí)候，為這四個(gè)頁面引入了同一個(gè)富文本編輯器組件；同時(shí)，在開發(fā)abcd這四個(gè)頁面的時(shí)候，在它們各自的頁面代碼中，將要保存的路徑地址參數(shù)a、b、c、d寫入到它們各自的這四個(gè)頁面里面。那么此時(shí)當(dāng)有一個(gè)用戶登錄到這個(gè)系統(tǒng)，進(jìn)入到a頁面進(jìn)行文件或圖片的上傳時(shí)，就會(huì)將這個(gè)寫在a頁面的參數(shù)路徑地址a一起連同文件或圖片一起提交到富文本編輯器的代碼后臺(tái)去。那么此時(shí)進(jìn)行文件保存時(shí)，富文本編輯器就會(huì)將文件保存到對(duì)應(yīng)的路徑地址參數(shù)a下面去。同理當(dāng)我們?cè)赽cd頁面操作上傳文件時(shí)也一樣會(huì)把對(duì)應(yīng)的文件保存到路徑地址參數(shù)b、c、d路徑下。這樣我們就區(qū)分開了將不同的頁面或模塊保存到不同的對(duì)應(yīng)地址中去，如圖10所示。

如圖5所示，是本發(fā)明的文件保存裝置的實(shí)施例的結(jié)構(gòu)示意圖。如圖5所示，該文件保存裝置500包括：配置模塊501，存儲(chǔ)模塊502，接收模塊503。

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

接收模塊503，用于接收通過富文本編輯器上傳的文件。

存儲(chǔ)模塊502，用于將接收模塊503接收的文件存儲(chǔ)在與該文件匹配的配置模塊501配置的文件保存路徑下。

根據(jù)背景技術(shù)的描述可知，當(dāng)在一個(gè)工程項(xiàng)目中的多個(gè)模塊中引用富文本編輯器組件時(shí)，若想實(shí)現(xiàn)各個(gè)模塊分目錄保存，則需要各個(gè)模塊各自引用各自的編輯器代碼庫，這樣就導(dǎo)致工程代碼中，出現(xiàn)多個(gè)富文本編輯器組件，冗余量太大。然而，若各個(gè)模塊共用一個(gè)富文本編輯器組件，又不能實(shí)現(xiàn)分目錄保存，并且還容易造成安全性問題，后期難以維護(hù)。為實(shí)現(xiàn)各模塊的分目錄存儲(chǔ)且各個(gè)模塊能共用一個(gè)富文本編輯器，提出了本發(fā)明的基于富文本編輯器的文件保存裝置。

由于一個(gè)工程項(xiàng)目中有多個(gè)模塊，因此文件保存裝置首先需要通過配置模塊501配置待保存模塊的文件保存路徑；配置模塊501的結(jié)構(gòu)例如可以是如圖6所示。配置模塊501包括：獲取單元5011以及封裝單元5012。

其中，獲取單元5011，用于獲取所述待保存模塊的文件名，以通過文件名來區(qū)分不同模塊的路徑保存參數(shù)。而封裝單元5012則用于將所述獲取單元獲取的所述文件名封裝入待保存的地址路徑，形成文件保存路徑。具體操作時(shí)，獲取單元5011通過所述富文本編輯器的前端配置所述待保存模塊的文件名，通過所述富文本編輯器的前端將所述文件名傳給所述富文本編輯器的后端，通過所述富文本編輯器的后端讀取所述文件名。

一般地，在引用富文本編輯器時(shí)，只需要在對(duì)應(yīng)的頁面引入富文本編輯器的js組件，然后實(shí)例化該文本編輯器，就完成了該富文本編輯器的調(diào)用。

本發(fā)明實(shí)施例中，在實(shí)例化富文本編輯器，獲取單元5011還通過所述富文本編輯器的前端配置所述待保存模塊的文件名，例如通過富文本編輯器的前端配置一個(gè)參數(shù)名為filename的文件名a，旨在表明當(dāng)前需要保存的模塊為模塊a。在配置文件名時(shí)，具體可以是：在實(shí)例化所述富文本編輯器時(shí)，獲取單元5011通過所述前端的頁面接收用戶傳入的所述文件名，例如用戶通過前端頁面輸入的文件名a。

富文本編輯器的前端頁面完成文件名的配置之后，獲取單元5011還通過前端的request實(shí)體將配置的文件名提交給所述富文本編輯器的后端。在編輯器后端中，將前端頁面配置的文件名通過request實(shí)體將配置的文件名取出來。即是說，此時(shí)不去取富文本編輯器默認(rèn)的保存路徑地址，而是取前端傳遞過來的路徑參數(shù)(即文件名)，來替代原來的默認(rèn)路徑。

在完成待保存模塊的文件名獲取之后，還通過封裝單元5012將獲取的文件名封裝入待保存的地址路徑，即是說需要將取出來的文件名封裝進(jìn)入需要保持存的地址路徑中去，然后當(dāng)通過富文本編輯器上傳的文件的文件名與該文件保存路徑中攜帶的文件名匹配時(shí)，通過該文件保存路徑去保存用戶通過富文本編輯器上傳的文件，這樣就實(shí)現(xiàn)了通過在模塊的前端頁面?zhèn)魅胛募麃韰^(qū)分保存各個(gè)模塊的上傳文件的目的。

可以理解的是，因?yàn)樾枰袛嗤ㄟ^富文本編輯器上傳的文件的文件名與該文件保存路徑中攜帶的文件名是否匹配，因此在接收到通過富文本編輯器上傳的文件之后，還提取該文件中攜帶的文件名，該文件名表明該文件是通過哪個(gè)待保存模塊上傳的。當(dāng)富文本編輯器上傳的文件的文件名與該文件保存路徑中攜帶的文件名匹配時(shí)，則表明上傳該文件的模塊與文件保存路徑對(duì)應(yīng)的待保存模塊為同一模塊。此時(shí)，可使用該文件保存路徑保存該文件，或者說將文件保存在與該文件匹配的文件保存路徑下，以實(shí)現(xiàn)不同模塊的分目錄保存。

如圖4所示，當(dāng)需要保存模塊a的文件時(shí)，首先在編輯器的前端頁面配置一個(gè)參數(shù)名為filename的文件名a，同時(shí)，前端頁面通過request實(shí)體將配置的文件名提交給后端。完成富文本編輯器組件的調(diào)用之后，后端通過request實(shí)體讀取文件名a，并將文件名a封裝入需要保存的地址路徑。此時(shí)，當(dāng)用戶通過a模塊、富文本編輯器上傳文件時(shí)，富文本編輯器的后端可提取上傳的文件中攜帶的文件名，并查找與該文件名匹配的文件保存路徑，以及按照查找出的文件保存路徑保存用戶上傳的文件，這樣，說用戶通過所述富文本編輯器上傳的文件便可保存在文件a路徑下。

同理，適用于模塊b的文件保存。

當(dāng)需要保存模塊b的文件時(shí)，首先在編輯器的前端頁面配置一個(gè)參數(shù)名為filename的文件名b，同時(shí)，前端頁面通過request實(shí)體將配置的文件名提交給后端。完成富文本編輯器組件的調(diào)用之后，后端通過request實(shí)體讀取文件名b，并將文件名b封裝入需要保存的地址路徑。此時(shí)，當(dāng)用戶通過b模塊、富文本編輯器上傳文件時(shí)，富文本編輯器的后端可提取上傳的文件中攜帶的文件名，并查找與該文件名匹配的文件保存路徑，以及按照查找出的文件保存路徑保存用戶上傳的文件，這樣，說用戶通過所述富文本編輯器上傳的文件便可保存在文件b路徑下。

本發(fā)明實(shí)施例的用于富文本編輯器上傳的文件的文件保存裝置，由于預(yù)先在前端頁面配置了待保存模塊的文件保存路徑，因此在完成富文本編輯器的調(diào)用、接收到上傳文件之后，后端便可將上傳的文件保存在與該文件匹配的、前端配置的文件保存路徑下。由此實(shí)現(xiàn)了一個(gè)工程項(xiàng)目多個(gè)模塊中引用同一個(gè)富文本編輯器組件時(shí)，可以按照不同的模塊進(jìn)行分目錄保存；同時(shí)還降低了系統(tǒng)的代碼冗余量，增強(qiáng)了系統(tǒng)的安全性，后期維護(hù)也更加方便。

下面，將舉幾個(gè)具體例子進(jìn)行詳細(xì)說明。

假如一個(gè)網(wǎng)站或系統(tǒng)有n個(gè)頁面，在這n個(gè)頁面中有abcd四個(gè)頁面(模塊)需要用到富文本編輯器。此時(shí)在代碼開發(fā)的時(shí)候，為這四個(gè)頁面引入了同一個(gè)富文本編輯器組件。在沒有改進(jìn)之前，不管進(jìn)入abcd這四個(gè)頁面的不管哪個(gè)頁面進(jìn)行文件上傳時(shí)，此時(shí)這些上傳的文件或圖片都會(huì)被保存到該富文本編輯器的統(tǒng)一路徑地址下面。當(dāng)日積月累過后，此時(shí)該路徑下的文件數(shù)目會(huì)太多太雜，冗余量太大，同時(shí)不易區(qū)分是哪個(gè)頁面上傳過來的，會(huì)造成系統(tǒng)安全性問題，以及后期的維護(hù)工作量大大提高。上傳文件的示意圖可以如圖8(圖8為通過頁面a上傳的文件)和圖9所示(頁面a上傳的文件保存至默認(rèn)地址)。

若采用本發(fā)明實(shí)施例的保存方法，具體保存過程如下：

同樣地，假如一個(gè)網(wǎng)站或系統(tǒng)有n個(gè)頁面，在這n個(gè)頁面中有abcd四個(gè)頁面(模塊)需要用到富文本編輯器。此時(shí)在代碼開發(fā)的時(shí)候，為這四個(gè)頁面引入了同一個(gè)富文本編輯器組件；同時(shí)，在開發(fā)abcd這四個(gè)頁面的時(shí)候，在它們各自的頁面代碼中，將要保存的路徑地址參數(shù)a、b、c、d寫入到它們各自的這四個(gè)頁面里面。那么此時(shí)當(dāng)有一個(gè)用戶登錄到這個(gè)系統(tǒng)，進(jìn)入到a頁面進(jìn)行文件或圖片的上傳時(shí)，就會(huì)將這個(gè)寫在a頁面的參數(shù)路徑地址a一起連同文件或圖片一起提交到富文本編輯器的代碼后臺(tái)去。那么此時(shí)進(jìn)行文件保存時(shí)，富文本編輯器就會(huì)將文件保存到對(duì)應(yīng)的路徑地址參數(shù)a下面去。同理當(dāng)我們?cè)赽cd頁面操作上傳文件時(shí)也一樣會(huì)把對(duì)應(yīng)的文件保存到路徑地址參數(shù)b、c、d路徑下。這樣我們就區(qū)分開了將不同的頁面或模塊保存到不同的對(duì)應(yīng)地址中去，如圖10所示。

需要說明的是，在本文中，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者裝置不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者裝置所固有的要素。在沒有更多限制的情況下，由語句“包括一個(gè)……”限定的要素，并不排除在包括該要素的過程、方法、物品或者裝置中還存在另外的相同要素。

上述本發(fā)明實(shí)施例序號(hào)僅僅為了描述，不代表實(shí)施例的優(yōu)劣。

通過以上的實(shí)施方式的描述，本領(lǐng)域的技術(shù)人員可以清楚地了解到上述實(shí)施例方法可借助軟件加必需的通用硬件平臺(tái)的方式來實(shí)現(xiàn)，當(dāng)然也可以通過硬件，但很多情況下前者是更佳的實(shí)施方式?；谶@樣的理解，本發(fā)明的技術(shù)方案本質(zhì)上或者說對(duì)現(xiàn)有技術(shù)做出貢獻(xiàn)的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計(jì)算機(jī)軟件產(chǎn)品存儲(chǔ)在一個(gè)存儲(chǔ)介質(zhì)(如rom/ram、磁碟、光盤)中，包括若干指令用以使得一臺(tái)終端設(shè)備(可以是手機(jī)，計(jì)算機(jī)，服務(wù)器，空調(diào)器，或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個(gè)實(shí)施例所述的方法。

以上僅為本發(fā)明的優(yōu)選實(shí)施例，并非因此限制本發(fā)明的專利范圍，凡是利用本發(fā)明說明書及附圖內(nèi)容所作的等效結(jié)構(gòu)或等效流程變換，或直接或間接運(yùn)用在其他相關(guān)的技術(shù)領(lǐng)域，均同理包括在本發(fā)明的專利保護(hù)范圍內(nèi)。