CN105844170A - 一种文件处理方法和装置 - Google Patents

Abstract

本申请实施例提供了一种文件处理方法及装置。该文件处理方法包括：接收第一应用对第一文件的访问请求，所述访问请求中包括用于对所述第一文件进行解密的解密信息；根据所述解密信息对所述第一文件进行解密；根据解密后的所述第一文件创建所述第一文件的临时文件；输出所述第一文件的临时文件；根据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理。本申请实施例通过对应用程序运行文件的加密保护，使得在应用程序访问该文件时，只有其对应的应用程序才能实现对文件的解密，访问到文件的明文内容，从而减少了数据安全问题和隐私泄露情况，该方法提高了存储卡中存储文件的安全性。

Description

一种文件处理方法和装置

技术领域

本申请涉及数据处理技术领域，特别是涉及一种文件处理方法和一种文件处理装置。

背景技术

随着现代通信的不断发展和移动终端自身性能的不断提高，手机等移动终端已经进入了智能数字时代，Android(安卓)***凭借其开放性和易用性成为了当今移动设备的主流操作***之一。Android手机与个人的生活隐私、商业活动的联系越来越紧密，但随之也带来了数据安全和隐私保护的问题。

根据数据储存的位置不同，Android***的数据分为内部SQLite数据库中的数据和外部储存卡的数据。外部储存卡的数据主要是以文件形式储存在安全数码卡(Secure Digital Memory Card，SD)中。但是Android***对SD卡中的文件访问权限粒度过大，只有访问与不能访问的权限控制，某个应用程序只要申请到了访问SD卡的权限就可以任意读取、篡改SD卡里的大部分文件，简而言之，一个应用程序可以随意读取、篡改另一个应用程序在SD卡中保存的文件。例如，App A、App B、App C等应用程序都在运行过程中分别产生了各自的文件File A、File B、File C，且File A、File B、File C存储在SD卡中，某一恶意程序只要申请了访问该SD卡的权限就可以访问并篡改这些文件，这样就很容易造成用户的照片、记事本等隐私数据的泄露。

因此，目前需要本领域技术人员迫切解决的一个技术问题就是：如何提高存储卡中存储文件的安全性。

发明内容

本申请实施例所要解决的技术问题是提供一种文件处理方法，能够提高存储卡中存储文件的安全性。

相应的，本申请实施例还提供了一种文件处理装置，用以保证上述方法的实现及应用。

为了解决上述问题，本申请公开了一种文件处理方法，包括：

接收第一应用对第一文件的访问请求，所述访问请求中包括用于对所述第一文件进行解密的解密信息；

根据所述解密信息对所述第一文件进行解密；

根据解密后的所述第一文件创建所述第一文件的临时文件；

输出所述第一文件的临时文件；

根据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理。

进一步，在所述接收第一应用对第一文件的访问请求之前，所述方法还包括：

接收所述第一应用对所述第一文件的加密请求，所述加密请求中包括用于对所述第一文件进行加密的加密信息；

根据所述加密信息对所述第一文件进行加密。

进一步，在所述接收对所述第一文件的加密请求之前，所述方法还包括：

验证所述第一应用是否具有对所述第一文件进行加密的加密权限；

若是，再根据所述加密信息对所述第一文件进行加密。

进一步，所述加密请求中还包括所述第一应用的权限验证信息，其中，所述权限验证信息是在所述第一应用向加密权限审核平台申请对所述第一文件进行加密的加密权限时，由所述加密权限审核平台审核通过并授予所述加密权限后返回的信息；

所述验证所述第一应用是否具有对所述第一文件进行加密的加密权限，包括：

根据所述权限验证信息验证所述第一应用是否具有对所述第一文件进行加密的加密权限。

进一步，所述根据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理，包括：

若所述第一应用对所述临时文件的操作为读取操作，则在所述第一应用读取所述临时文件后，删除所述临时文件；

若所述第一应用对所述临时文件的操作为内容更新操作，则对更新后的所述临时文件进行加密后替换所述第一文件。

本申请还提供了一种文件处理装置，包括：

第一请求接收单元，被配置为接收第一应用对第一文件的访问请求，所述访问请求中包括用于对所述第一文件进行解密的解密信息；

解密单元，被配置为根据所述解密信息对所述第一文件进行解密；

文件生成单元，被配置为根据解密后的所述第一文件创建所述第一文件的临时文件；

文件输出单元，被配置为输出所述第一文件的临时文件；

文件处理单元，被配置为根据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理。

进一步，所述装置还包括：

第二请求接收单元，被配置为在所述第一请求接收单元接收第一应用对第一文件的访问请求之前，接收所述第一应用对所述第一文件的加密请求，所述加密请求中包括用于对所述第一文件进行加密的加密信息；

加密单元，被配置为根据所述加密信息对所述第一文件进行加密。

进一步，所述装置还包括：

权限验证单元，被配置为在所述加密单元根据所述加密信息对所述第一文件进行加密之前，验证所述第一应用是否具有对所述第一文件进行加密的加密权限；

所述加密单元，被配置为当所述权限验证单元验证所述第一应用具有对所述第一文件进行加密的加密权限时，再根据所述加密信息对所述第一文件进行加密。

进一步，所述加密请求中还包括所述第一应用的权限验证信息，其中，所述权限验证信息是在所述第一应用向加密权限审核平台申请对所述第一文件进行加密的加密权限时，由所述加密权限审核平台审核通过并授予所述加密权限后返回的信息；

所述权限验证单元，被配置为根据所述权限验证信息验证所述第一应用是否具有对所述第一文件进行加密的加密权限。10、根据权利要求6至9中任意一项所述的装置，其特征在于，

所述文件处理单元，被配置为当所述第一应用对所述临时文件的操作为读取操作时，在所述第一应用读取所述临时文件后，删除所述临时文件；当所述第一应用对所述临时文件的操作为内容更新操作时，对更新后的所述临时文件进行加密后替换所述第一文件。

与现有技术相比，本申请实施例包括以下优点：

本申请实施例通过对应用程序运行文件的加密保护，使得在应用程序访问该文件时，只有其对应的应用程序也即文件的“宿主”应用才能实现对文件的解密，才能访问到文件的明文内容，从而减少了现有技术中恶意程序通过扫描存储卡里的文件即可获得文件内容而造成数据安全问题和隐私泄露情况，该方法提高了存储卡中存储文件的安全性。

附图说明

图1是本申请的一种文件处理方法实施例的步骤流程图；

图2是本申请的另一种文件处理方法实施例的步骤流程图；

图3是本申请的一种文件处理装置实施例的结构框图；

图4是本申请的另一种文件处理装置实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

参照图1，示出了本申请的一种文件处理方法实施例的步骤流程图，具体可以包括如下步骤：

步骤101，接收第一应用对第一文件的访问请求，该访问请求中包括用于对第一文件进行解密的解密信息。

本申请实施例中，该文件处理装置可以是操作***本身或设置在操作***中的装置，该操作***可以是Android***。

该文件处理装置具有实现文件加密保护的功能，例如可以对SD卡中的存储文件进行加密保护。该功能可以通过在操作***的应用层开放一个用于实现文件加解密的API(Application Programming Interface，应用程序编程接口)来实现，应用程序的开发方可以通过调用该API实现对其应用程序运行产生的文件进行加解密。其中，该API具体可以通过修改操作***的源代码来实现。

该文件处理装置可以主动或者基于应用程序的开发方的请求对应用程序运行产生的文件的内容进行加密，其中该文件内容的加密信息和解密信息(如加密密钥和解密密钥)可以由文件处理装置和应用程序的开发方中的一方确定并告知另一方，也可以由双方协商确定。

本实施例中，该文件处理装置预先对第一应用运行产生的第一文件进行加密。其中，加密算法可以是AES加密算法，或者DES等其他加密算法。

当第一应用需要访问其第一文件时发起访问请求，并在该访问请求中包含用于对第一文件进行解密的解密信息，例如该第一应用开发方的私钥，或某一口令等。

该文件处理装置在接收到该访问请求后，获取其中的解密信息，执行步骤102。

步骤102，根据解密信息对第一文件进行解密。

该文件处理装置根据该解密信息，例如第一应用开发方的私钥，对第一文件进行解密，获得解密后的第一文件，也即第一文件的明文。

步骤103，根据解密后的第一文件创建第一文件的临时文件。

该文件处理装置进一步根据第一文件的明文创建或生成与第一文件同类型的临时文件。第一应用对第一文件的访问就变成了对临时文件的访问。

步骤104，输出第一文件的临时文件。

该文件处理装置向第一应用返回第一文件的临时文件，以供第一应用使用。

步骤105，根据第一应用对临时文件的操作，对第一文件和/或临时文件进行处理。

文件处理装置会根据第一应用对临时文件的操作情况，对第一文件或临时文件，或第一文件及临时文件进行处理。

例如，若第一应用对临时文件的操作仅为读取操作，则在第一应用读取临时文件后，文件处理装置删除该临时文件。

若第一应用对临时文件的操作为内容更新操作，例如，删除或增加或修改等，则文件处理装置会删除第一文件，并对更新后的临时文件进行加密以替换第一文件。

本申请实施例通过对应用程序运行文件的加密保护，使得在应用程序访问该文件时，只有其对应的应用程序也即文件的“宿主”应用才能实现对文件的解密，才能访问到文件的明文内容，从而减少了现有技术中恶意程序通过扫描存储卡里的文件即可获得文件内容而造成数据安全问题和隐私泄露情况，该方法提高了存储卡中存储文件的安全性。

在本申请的另一实施例中，在文件处理装置接收到第一应用对第一文件的访问请求之前，还可以首先包括：

接收第一应用对第一文件的加密请求，该加密请求中包括用于对第一文件进行加密的加密信息；

根据加密信息对第一文件进行加密。

第一应用的开发方可以根据第一应用运行产生的文件中所存内容隐私级别的高低来决定是否调用API进行文件加密，若是，则发起对第一文件的加密请求，并在该加密请求中包含用于对第一文件进行加密的加密信息，例如开发方私钥等。

文件处理装置在接收到该加密请求后即可根据其中的加密信息对该第一文件进行加密。

在另一实施例中，为了防止恶意程序利用该加密API对存储卡中未加密的文件进行恶意加密而造成原应用程序对文件的不可读，文件处理装置不是在接收到加密请求后即进行文件加密，而是在之前先进行以下步骤：

验证第一应用是否具有对第一文件进行加密的加密权限；

若是，文件处理装置再根据加密信息对第一文件进行加密。

在另一实施例中，为了验证第一应用是否具有对第一文件进行加密的加密权限，可以增设加密权限审核平台，即文件加密API权限审核平台，该审核平台用于审核应用程序对调用API进行文件加密的权限申请，并有助于后续加密过程中对应用程序的验证。

第一应用首先向该加密权限审核平台发起对第一文件进行加密的加密权限的申请，实质也即申请对上述API的使用权限。该申请中可以包含第一应用的相关内容，例如公钥证书、身份资料以及App简介等。

加密权限审核平台在接收到该申请后，审查第一应用的相关内容，确定是否通过验证，若通过验证，则授予第一应用对第一文件进行加密的加密权限，也即授予第一应用使用上述API的权限，同时还会返回权限验证信息，该权限验证信息用于后续第一应用请求对第一文件进行加密时，文件处理装置验证该第一应用是否具有对第一文件加密的权限。

这样，在第一应用向文件处理装置请求对第一文件进行加密时，其中加密请求中除了包括加密信息还可以包括该权限验证信息，这样，在文件处理装置根据加密信息对第一文件进行加密之前，可以包括：

根据权限验证信息验证第一应用是否具有对所述第一文件进行加密的加密权限；

若是，再根据加密信息对第一文件进行加密。

通过增加该加密过程和验证过程，可以防止恶意程序利用该加密API对存储卡中未加密的文件进行恶意加密而造成原应用程序对文件的不可读，保证了该文件加密保护方法的有效性和可行性。

下面以对Android***中SD卡中的文件进行处理为例进行说明。

参照图2，示出了本申请的另一种文件处理方法实施例的步骤流程图，具体可以包括如下步骤：

步骤201，在Android***中设置文件加解密的API。

该API具体可以通过修改并编译Android***源码的方式来实现文件加解密的API，增加Android***SD卡文件的透明加解密功能。具体的，可以在Framework层文件***源码部分中增加加解密功能。

由于Android的API均由Framework层向应用层提供，而Framework层主要使用Java语言编写，所以本方案采用在Framework层的File类中引入Java加密相关的类库javax.crypto。javax.crypto中包含实现了加密算法、解密算法以及密钥协商的类和接口，将其中的类导入到libcore/luni/src/main/java/java/io目录下的File.java中，并在File类中新增加密函数encryptFileByAES(sourceFile，encryptedSignature，developerKey，certificateFilePath)实现文件的加密。

修改***源码完毕后，利用编译Android***及SDK的方法编译出具有SD卡文件加密的Android***和Android SDK。

首先，修改Android***的配置文件。

可以采用32位的Ubuntu操作***进行的编译工作，需要以下几个Android.mk文件(备注：android_src表示Android源码根目录)：

(1)android_src/external/clearsilver/cgi/Android.mk

(2)android_src/external/clearsilver/java-jni/Android.mk

(3)android_src/external/clearsilver/util/Android.mk

(4)android_src/external/clearsilver/cs/Android.mk

将以上文件中的m64修改为m32。

另外，将android_src/build/core/main.mk中的ifneq(64，$(findstring 64，$(build_arch)))修改为：ifneq(i686，$(findstring i686，$(build_arch)))。

然后，编译修改源码后的Android***。

在Android源码的根目录下执行make命令开始编译Android源码。另外，为了缩短编译时间，可以在拥有多CPU、多核、超线程的PC上使用-jn命令行参数，例如4核PC可以使用make j4来加快编译速度。执行make之后会新建一些重要的目录来存放编译结果，make之后会在android_src/out/target/product/generic目录下生成system.img、userdata.img以及ramdisk.img等镜像文件，这些镜像文件即为编译的成果，用它们就可以启动一个新的Android***。

再然后，在成功编译Android***的基础上，进行SDK的编译。

在编译Android源码时会生成在两种平台运行Android所需要的Libraries和tools，一种是在PC端直接运行Android需要的库和工具，存放在out/host目录中；另一种是直接运行在Android平台上的库和工具(基于ARM架构)，存放在out/target目录中。本申请修改源码后编译SDK可以在android_src/out/host/linux-x86/sdk/目录下生成SDK的原文件及其压缩包。android-sdk_eng.root_linux-x86文件夹是新的SDK文件，android-sdk_eng.root_linux-x86.zip是SDK的压缩包。

Android镜像文件为支持SD卡文件加解密功能的Android***，该镜像可装入Android智能终端。SDK文件为提供了SD卡文件加解密API的开发工具包，Android应用程序开发者可使用该SDK快速开发出具有加密保护其存入SD卡中的文件功能的应用程序。

步骤202，加密权限审核平台接收第一应用对第一文件进行加密的加密权限的申请。

本实施例中，可以建立Android***SD卡文件加密API权限审核平台，记为加密权限审核平台。第一应用的开发方将自己的公钥证书、身份资料以及App简介提交给审核平台对文件加解密API的使用权限进行实名申请。

步骤203，加密权限审核平台对申请验证通过后，授予第一应用对第一文件进行加密的加密权限，并返回权限验证信息。

审核通过后，审核平台授予第一应用对第一文件进行加密的加密权限，也即授予第一应用对对文件加解密API的使用权限，并会给第一应用分配一个AppID以及AppKey，审核平台用自己的私钥对AppID和AppKey进行签名，然后再用开发方的公钥对AppID、AppKey以及相应的签名进行加密，最后将密文及平台的公钥证书作为该第一应用的权限验证信息颁发给第一应用。

该密文及公钥证书的存储路径就是文件加密API encryptFileByAES(FilesourceFile，String encryptedSignature，String developerKey，StringcertificateFilePath，String sourceFileKey)所需的参数，其中sourceFile是要被加密的文件，developerKey是开发者的私钥，该私钥将作为解密encryptedSignature的密钥，sourceFileKey是通过验证以后对sourceFile进行AES加密所需的加密口令。

上述步骤201与步骤202～203之间的步骤顺序可以根据需要进行调整。

步骤204，***接收第一应用对第一文件的加密请求，该加密请求中包括用于对第一文件进行加密的加密信息及权限验证信息。

第一应用的开发方将自己的私钥，审核平台颁发的密文及平台的公钥证书的文件路径，以及加密所需的口令发送至Android***，以发起对第一文件的加密请求。

步骤205，***根据权限验证信息判断第一应用是否具有对第一文件进行加密的加密权限。

Android***首先利用第一应用开发方的私钥解密审核平台发送的密文获得解密后的AppID、AppKey以及签名信息，然后读取审核平台的公钥证书获得审核平台的有效公钥，验证解密后的AppID、AppKey以及签名信息来判断开发方是否已被审核平台授权，并具有文件加解密API的使用权限。

具体的，***调用isAuthorized(encryptedSignature，developerKey，certificateFilePath)，该函数利用开发方私钥解密encryptedSignature获得明文AppID、AppKey以及签名signature，再读取平台颁发的公钥证书获得平台的公钥，利用平台的公钥、AppID、AppKey以及signature进行RSA的签名验证，函数最后会根据验证结果对授权与否的标记变量isAuthorizedApp进行赋值。

如果通过上述签名验证，判定第一应用已被审核平台授权，并具有文件加解密API的使用权限，则执行步骤206，正常调用加解密API对文件进行加密；如果未通过上述签名验证，则不进行加密操作并直接将原文件作为结果返回给第一应用。

步骤206，调用加解密API根据加密信息对第一文件进行加密。

该调用加解密API对第一文件进行加密过程可以是：首先，加密函数encryptFileByAES(sourceFile，encryptedSignature，developerKey，certificateFilePath，sourceFileKey)根据上述isAuthorizedApp的值来判断是否对第一文件进行加密。

若对第一文件进行加密，则建立一个与第一文件同类型的加密前临时文件，并用开发方私钥初始化加密密钥，加密函数将欲加密的第一文件的原文件以1024个字节循环读取到inputStream中，再将inputStream用已经初始化的加密密钥cipher加密成加密数据流cipherInputStream，然后将加密数据流写入到该加密前临时文件中，最后删除原文件并将加密前临时文件更名为原文件的文件名，从而获得加密了的第一文件。

步骤207，***接收第一应用对第一文件的访问请求，访问请求中包括用于对第一文件进行解密的解密信息。

该解密信息可以是第一应用开发方的私钥。

步骤208，调用加解密API根据解密信息对第一文件进行解密。

本步骤中，调用加解密API对第一文件进行解密过程可以是：可以首先用开发方私钥初始化解密密钥，解密函数decryptFileByAES(sourceFile，key)将欲解密的第一文件以1024字节为单位循环读入到inputStream中，然后由cipherOutputStream用初始化了的解密密钥进行解密。

步骤209，根据解密后的第一文件创建第一文件的临时文件。

将解密后的数据流写到临时文件中。

步骤210，输出第一文件的临时文件。

步骤211，根据第一应用对临时文件的操作，对第一文件和/或临时文件进行处理。

上述步骤207～211与前述实施例中的步骤101～105类似，此处不再赘述。

本实施例中采用平台审核、平台授权、自行鉴别的方式来管理Android***SD卡文件的加解密API，应用开发方若要使用该加解密API必须向平台申请，通过审核后，平台授予其加解密权限，在对文件进行加解密的过程中，Android***会校验该应用开发方是否具有SD卡加解密API的调用权限，然后再具有权限的条件下进行文件的加解密。

本实施例将增加了加密功能的SD卡文件***融入Android***的原有生态，并通过审核平台来管理该API的调用权限，开发方需要到该平台申请权限，还可以在此平台相互交流，该平台还可以增加新的类似功能，从而形成一个基于Android***的开发者互动社区。

本申请实施例对于用户而言可以保护用户的隐私，对于应用开发方而言可以保护应用程序的核心数据。例如，若App A调用了加密API对File A进行了加密，App B、App C以及其它程序读取到的File A均为File A的密文内容，但是File A对于App A本身却是透明的，App A可以读取到File A的明文。这样就在App之间进行了隔离，使得大家不能直接访问对方的文件，除非获得对方App的密钥，从而有效保障了用户隐私和数据安全。

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

参照图3，示出了本申请一种文件处理装置实施例的结构框图，具体可以包括如下单元：

第一请求接收单元301，被配置为接收第一应用对第一文件的访问请求，所述访问请求中包括用于对所述第一文件进行解密的解密信息。

解密单元302，被配置为根据所述解密信息对所述第一文件进行解密。

文件生成单元303，被配置为根据解密后的所述第一文件创建所述第一文件的临时文件。

文件输出单元304，被配置为输出所述第一文件的临时文件。

文件处理单元305，被配置为根据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理。

本申请实施例通过对应用程序运行文件的加密保护，使得在应用程序访问该文件时，只有其对应的应用程序也即文件的“宿主”应用才能实现对文件的解密，才能访问到文件的明文内容，从而减少了现有技术中恶意程序通过扫描存储卡里的文件即可获得文件内容而造成数据安全问题和隐私泄露情况，该装置提高了存储卡中存储文件的安全性。

在另一实施例中，如图4所示，该装置除了包括第一请求接收单元301，解密单元302，文件生成单元303，文件输出单元304，文件处理单元305之外，还可以包括：

第二请求接收单元401，被配置为在所述第一请求接收单元接收第一应用对第一文件的访问请求之前，接收所述第一应用对所述第一文件的加密请求，所述加密请求中包括用于对所述第一文件进行加密的加密信息；

加密单元402，被配置为根据所述加密信息对所述第一文件进行加密。

该装置还可以包括权限验证单元403，被配置为在所述加密单元402根据所述加密信息对所述第一文件进行加密之前，验证所述第一应用是否具有对所述第一文件进行加密的加密权限；

所述加密单元402，被配置为当所述权限验证单元403判定所述第一应用具有对所述第一文件进行加密的加密权限时，再根据所述加密信息对所述第一文件进行加密。

加密请求中还包括所述第一应用的权限验证信息，其中，所述权限验证信息是在所述第一应用向加密权限审核平台申请对所述第一文件进行加密的加密权限时，由所述加密权限审核平台审核通过并授予所述加密权限后返回的信息；

所述权限验证单元403，被配置为根据所述权限验证信息验证所述第一应用是否具有对所述第一文件进行加密的加密权限。

在本申请的另一实施例中，文件处理单元305，可以被配置为当所述第一应用对所述临时文件的操作为读取操作时，在所述第一应用读取所述临时文件后，删除所述临时文件；当所述第一应用对所述临时文件的操作为内容更新操作时，对更新后的所述临时文件进行加密后替换所述第一文件。

本申请实施例还公开了一种电子设备，包括数据总线，存储器和处理器，其中，存储器中存储有一段运行程序代码，处理器通过数据总线获取存储器中的程序代码，并执行以下步骤：

接收第一应用对第一文件的访问请求，所述访问请求中包括用于对所述第一文件进行解密的解密信息；

根据所述解密信息对所述第一文件进行解密；

根据解密后的所述第一文件创建所述第一文件的临时文件；

输出所述第一文件的临时文件；

根据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitory media)，如调制的数据信号和载波。

本申请实施例是参照根据本申请实施例的方法、终端设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种文件处理方法和一种文件处理装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种文件处理方法，其特征在于，包括：

接收第一应用对第一文件的访问请求，所述访问请求中包括用于对所述第一文件进行解密的解密信息；

根据所述解密信息对所述第一文件进行解密；

根据解密后的所述第一文件创建所述第一文件的临时文件；

输出所述第一文件的临时文件；

根据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理。

2.根据权利要求1所述的方法，其特征在于，在所述接收第一应用对第一文件的访问请求之前，所述方法还包括：

接收所述第一应用对所述第一文件的加密请求，所述加密请求中包括用于对所述第一文件进行加密的加密信息；

根据所述加密信息对所述第一文件进行加密。

3.根据权利要求2所述的方法，其特征在于，在所述接收对所述第一文件的加密请求之前，所述方法还包括：

验证所述第一应用是否具有对所述第一文件进行加密的加密权限；

若是，再根据所述加密信息对所述第一文件进行加密。

4.根据权利要求3所述的方法，其特征在于，所述加密请求中还包括所述第一应用的权限验证信息，其中，所述权限验证信息是在所述第一应用向加密权限审核平台申请对所述第一文件进行加密的加密权限时，由所述加密权限审核平台审核通过并授予所述加密权限后返回的信息；

所述验证所述第一应用是否具有对所述第一文件进行加密的加密权限，包括：

根据所述权限验证信息验证所述第一应用是否具有对所述第一文件进行加密的加密权限。

5.根据权利要求1至4中任意一项所述的方法，其特征在于，所述根据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理，包括：

若所述第一应用对所述临时文件的操作为读取操作，则在所述第一应用读取所述临时文件后，删除所述临时文件；

若所述第一应用对所述临时文件的操作为内容更新操作，则对更新后的所述临时文件进行加密后替换所述第一文件。

6.一种文件处理装置，其特征在于，包括：

第一请求接收单元，被配置为接收第一应用对第一文件的访问请求，所述访问请求中包括用于对所述第一文件进行解密的解密信息；

解密单元，被配置为根据所述解密信息对所述第一文件进行解密；

文件生成单元，被配置为根据解密后的所述第一文件创建所述第一文件的临时文件；

文件输出单元，被配置为输出所述第一文件的临时文件；

文件处理单元，被配置为根据所述第一应用对所述临时文件的操作，对所述第一文件和/或所述临时文件进行处理。

7.根据权利要求6所述的装置，其特征在于，所述装置还包括：

第二请求接收单元，被配置为在所述第一请求接收单元接收第一应用对第一文件的访问请求之前，接收所述第一应用对所述第一文件的加密请求，所述加密请求中包括用于对所述第一文件进行加密的加密信息；

加密单元，被配置为根据所述加密信息对所述第一文件进行加密。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

权限验证单元，被配置为在所述加密单元根据所述加密信息对所述第一文件进行加密之前，验证所述第一应用是否具有对所述第一文件进行加密的加密权限；

所述加密单元，被配置为当所述权限验证单元验证所述第一应用具有对所述第一文件进行加密的加密权限时，再根据所述加密信息对所述第一文件进行加密。

9.根据权利要求8所述的装置，其特征在于，所述加密请求中还包括所述第一应用的权限验证信息，其中，所述权限验证信息是在所述第一应用向加密权限审核平台申请对所述第一文件进行加密的加密权限时，由所述加密权限审核平台审核通过并授予所述加密权限后返回的信息；

所述权限验证单元，被配置为根据所述权限验证信息验证所述第一应用是否具有对所述第一文件进行加密的加密权限。

10.根据权利要求6至9中任意一项所述的装置，其特征在于，

所述文件处理单元，被配置为当所述第一应用对所述临时文件的操作为读取操作时，在所述第一应用读取所述临时文件后，删除所述临时文件；当所述第一应用对所述临时文件的操作为内容更新操作时，对更新后的所述临时文件进行加密后替换所述第一文件。