文件处理方法、装置、电子设备及可读存储介质与流程

本申请涉及数据处理技术领域，具体而言，本发明涉及一种文件处理方法、装置、电子设备及可读存储介质。

背景技术：

在日常工作生活中，由于终端设备存储空间有限，难以容纳照片/音乐/视频/等大量文件，用户经常需要将文件存储到其他设备，以使设备正常工作，并能够长期保存所需的文件，实现备份的目的。

虽然现有备份的方案，能够释放终端设备的存储空间，以使设备能够更好的工作，但存储到其他设备上的文件的安全性较低，文件的内容容易被泄露，造成用户损失。

技术实现要素：

本申请的目的旨在至少能解决上述的技术缺陷之一，本申请采用的技术方案如下：

第一方面，本申请实施例提供了一种文件处理方法，该方法包括：

接收针对文件的操作请求，文件包括至少两个子文件，至少两个子文件分别存储于至少两个设备中；

根据操作请求对文件的至少一个子文件进行相应处理。

第二方面，本申请实施例提供了一种文件处理装置，该装置包括：

操作请求接收模块，用于接收针对文件的操作请求，文件包括至少两个子文件，至少两个子文件分别存储于至少两个设备中；

文件处理模块，用于根据操作请求对文件的至少一个子文件进行相应处理。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括存储器和处理器；存储器中存储有计算机指令；处理器，用于调用计算机指令，以执行本申请第一方面所示的文件处理方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，该存储介质中存储有计算机程序，计算机程序被处理器执行时实现本申请第一方面所示的文件处理方法。

本申请实施例提供的技术方案带来的有益效果是：本申请实施例提供的文件处理方法、装置、电子设备及可读存储介质，由于文件的至少两个子文件分别存储于至少两个设备中，即使一个设备中的子文件被泄露，也无法得到文件的原始内容，因此，采用本申请实施例的方案，能够有效提高文件的安全性。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。

图1示出了本申请实施例提供的一种文件处理方法的流程示意图；

图2a、2b、2c、2d分别示出了本申请实施例中核心部分和附加部分的四种不同的拆分方式示意图；

图3示出了本申请实施例适用的一种网络架构示意图；

图4示出了本申请实施例中文件拆分存储的原理示意图；

图5示出了本申请一示例中一种文件处理方法的流程示意图

图6示出了本申请一示例中基于频域特征和数据位特征的文件拆分方法的流程示意图；

图6a示出了本申请一示例中基于频域特征对文件进行拆分的示意图；

图6b示出了本申请一个示例中基于数据位特征对频域元素进行进一步拆分的示意图；

图7示出了本申请一示例中基于用户事件预测的自动存储管理方法的原理示意图；

图8示出了本申请一示例中基于用户相关信息提取特征信息的方法的示意图；

图9示出了本申请一示例中确定待拆分文件的目标拆分比例的方法的示意图；

图10示出了本申请一示例中一种文件处理方法的示意图；

图11示出了本申请一示例中基于链接特征值得到文件的方法示意图；

图12示出了本申请一示例中一种文件处理方法的流程示意图；

图13示出了本申请一示例中一种文件发送方法的原理示意图；

图14a示出了本申请一示例中一种文件发送方法的流程示意图；

图14b示出了本申请另一示例中一种文件发送方法的流程示意图；

图15示出了本申请一示例中实现文件内容验证的原理示意图；

图16示出了本申请一示例中一种实现文件内容验证的方法的流程示意图；

图17示出了本申请一示例中一种多设备协同方法的流程示意图；

图18示出了本申请实施例提供的一种文件处理装置的结构示意图；

图19示出了本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图1示出了本申请提供的一种文件处理方法的流程示意图，如图1中所示，该方法可以包括：

步骤s110：接收针对文件的操作请求，文件包括至少两个子文件，至少两个子文件分别存储于至少两个设备中；

步骤s120：根据操作请求对文件的至少一个子文件进行相应处理。

本申请中的文件可以但不限于包括文本文件、多媒体文件等，多媒体文件可以但不限于包括视频文件、图片文件、音频文件等各种类型中的一种。

本申请实施例提供的文件处理方法，文件的至少两个子文件分别存储于至少两个设备中，因此，即使一个设备中的子文件被泄露，也无法得到文件的原始内容，通过该方法，能够有效提高文件的安全性。

本申请的可选实施例中，文件的至少一个子文件可以存储于本地；和/或，文件的至少一个子文件可以存储于其他设备。

上述“本地”可以理解为执行上述文件处理方法的设备的本地，文件的至少一个子文件可以存储于本地，可以理解为将文件的至少一个子文件存储于执行上述文件处理方法的设备的本地存储空间。其中，“本地”和执行上述文件处理方法的设备也可以称为本地设备。

在实际应用中，文件的至少一个子文件设备存储于设备本地，能够使该设备更快、更方便的对该子文件进行处理。其他设备可以是本地设备之外的各类型的设备，如服务器、终端设备等等。

可以理解的是，在实际应用中，其他设备可以为一个或多个。例如，文件可以包括子文件1、子文件2和子文件3，其中，子文件1可以存储在本地，子文件2可以存储在一个云端服务器，子文件3可以存储在另一个云端服务器或其他终端设备上，通过将文件的各子文件存储在多个设备中，进一步提升了文件的安全性。

在一可选实施例方式中，其他设备可选为云端服务器。

现有的基于云端服务器的云存储方式中，如恶意用户(非上传用户本人)获取了云端访问密码，或用其他非正常方式通过/绕过身份验证，那么上传的用户隐私内容将被泄露。如恶意用户用非正常方式直接访问到云服务器存储内容，并破解了加密，上传的用户隐私内容将被泄露。如网络传输链路被恶意监听/劫持，用户隐私内容将被泄露。如云存储提供商本身不遵守商业道德和法律，私自访问用户信息，用户隐私将被泄露。而采用本申请实施例的一个可实现方案，由于文件的一部分存储在本地，另一部分存储于云端服务器，即使云端服务器的部分文件被泄露，也无法得到整个文件，提高了文件的安全性。

需要说明的是，图1中所示的文件处理方法的执行主体可以是本地设备，本地设备中可以存储文件的至少一个子文件，也可以是存储文件的至少一个子文件的其他设备。以其他设备为云端服务器为例，云端服务器可以根据接收到的终端设备发送的针对文件的操作请求，对存储的该文件对应的子文件进行相应处理，如根据操作请求，将存储的子文件发送给其他设备或对存储的子文件进行编辑或其他处理，还可以根据接收到的操作请求，指示存储子文件的其他设备进行相应处理。

本申请的可选实施例中，文件的各子文件可以是对文件进行拆分得到的，进一步的，可以是基于文件的频域特征和/或数据位特征拆分得到的。

其中，频域特征可以包括文件的频域元素的频域特征值，具体的，频域特征值可以为频域元素的频率分量的大小/幅值。可以通过将文件进行频域变换，得到文件对应的频域元素。

在实际应用中，根据文件的实际属性信息的不同，在将文件进行频域转换之前，可能需要对文件进行相应的预处理，以得到文件的原始数据。其中，预处理可以包括但不限于解压缩和/或解密等处理方式。

例如，在一示例中，如果文件是压缩编码格式的文件，在将文件进行频域转换之前，需要将解压缩为原始数据。需要说明是，此处的压缩编码格式指多媒体文件的压缩编码格式。例如，对于图片，jpeg格式，png格式为压缩编码格式，对于音视频，mp3格式，ogg格式为压缩编码格式。如果判断出多媒体文件为压缩编码格式，则可以先进行解压缩，获得多媒体文件的原始数据，以便后续对原始数据进行拆分。例如，对于jpeg，png等压缩编码格式的图片，可以解压缩为bmp(bitmap，比特位图)格式，对于mp3，ogg等压缩编码格式的音视频，可以解压缩为wav格式。

数据位特征是指文件在设备中存储时所对应的存储位置的高位或低位，可以理解的是，高位和低位是相对而言的，例如，在采用二进制的存储方式中，与高位相对，低位表示二进制数字右边部分，当然，高位和低位的位数也可以根据不同应用需求采用不同的方式。例如，对于一具体的二进制数据0011，左侧的部分为相对的高位，右侧的部分为相对的低位，如可以将11划分为低位，00划分为高位，也可以左侧的001为高位，最右侧的1为低位。

文件为多媒体文件时，如音频、图片、视频等文件，文件的各子文件可以是基于文件的频域特征、数据位特征中的一项或两项拆分得到，在文件为文本文件时，各子文件可以基于文件的数据位特征拆分得到。

本申请的可选实施例中，文件的至少一个子文件包括以下至少一项：

基于文件的频域特征拆分得到的第一部分或第二部分，其中，第二部分的频域元素的频域特征值大于第一部分的频域元素的频域特征值；

基于文件的数据位特征拆分得到的第三部分或第四部分，其中，第四部分的数据位高于第三部分的数据位；

基于第一部分的数据位特征或者基于第二部分的数据位特征，拆分得到的第五部分和第六部分，其中，第五部分的数据位高于第六部分的数据位；

基于第三部分的频域元素的频域特征或者第四部分的频域元素的频域特征，拆分得到的第七部分或第八部分，第八部分的频域元素的频域特征值大于第七部分的频域元素的频域特征值。

为了描述方便，将频域元素的频域特征值相对较大的部分称为高频分量，将频域元素的频域特征值相对较小的部分称为低频分量，将数据位较高的部分称为高位分量，将数据位较低的部分称为低位分量。对应的上述各项中，第一部分可以称为低频分量，第二部分可以称为高频分量，第三部分可以称为低位分量，第四部分可以称为高位分量，第五部分可以称为低频高位分量或者高频高位分量，第六部分可以称为低频低位分量或高频低位分量，第七部分可以称为低位低频分量或高位低频分量，第八部分可以称为低位高频分量或高位高频分量。

在实际应用中，上述各部分所对应的子文件的大小，可以基于各子文件的目标拆分比例得到(可参见在后文中的具体描述)，该目标拆分比例可以根据需要预先设定，也可以实时确定。

例如，在一可选实施方式中，可以基于设定的频域特征值阈值或频域元素的数量阈值，来划分高频分量和低频分量，可以基于数据位特征阈值或数据位的数量阈值来划分高位分量和低位分量。具体的，可以将文件的频域元素中频域特征值小于第一阈值的频率元素所对应的部分作为第一部分，其余部分可以为第二部分；也可以将文件的频域元素中数量等于第二阈值的较低频域特征值的频域元素所对应的部分作为第一部分，其余作为第二部分；可以将文件的数据位特征中数量等于第三阈值的较高数据位所对应的部分作为第四部分，其余部分为第三部分；也可以将文件的数据位中按照从低位到高位的顺序，数据位大于第四阈值的数据位所对应的部分作为第四部分，其余部分为第三部分。

同样的，基于第一部分、第二部分、第三部分、第四部分，再拆分得到第五部分、第六部分、第七部分和第八部分时，也可以采用相同的方式。作为一个示例，例如，可以将第一部分对应的数据位特征中数量等于第五阈值的较高数据位所对应的部分作为第五部分，第一部分的其余部分作为第六部分。

本申请的可选实施例中，基于文件的频域特征和/或数据位特征得到的上述各部分中，包括第一部分的子文件存储于本地，包括第二部分的子文件存储于其他设备(方式1)；或者，包括第四部分的子文件存储于本地，包括第三部分的子文件存储于其他设备(方式2)；或者，包括基于第一部分得到的第五部分的子文件存储于本地，包括第二部分和基于第一部分得到的第六部分的子文件存储于其他设备(方式3)；或者，包括第一部分和基于第二部分得到的第五部分的子文件存储于本地，包括基于第二部分得到的第六部分的子文件存储于其他设备(方式4)；或者，包括基于第四部分得到的第七部分的子文件存储于本地，包括第三部分和基于第四部分得到的第八部分的子文件存储于其他设备(方式5)；或者，包括第四部分和基于第三部分得到的第七部分的子文件存储于本地，包括基于第三部分得到的第八部分存储于其他设备(方式6)。

方式1中，存储在本地的子文件为文件的低频分量对应的部分文件，存储在其他设备中的子文件为文件的高频分量对应的部分文件。

对于文件的频域元素而言，低频分量通常包含了文件内容的主体结构信息，高频分量包含了文件内容(去除主体结构信息后)的细节信息，前者(即低频分量)可以称为核心部分，后者可以称为附加部分。核心部分一般占用存储空间较小，包含信息主体，可以独立使用，附加部分只包含信息细节，无法被单独使用(缺乏信息主体，无法被人类理解)。核心部分保存在设备本地，附加部分保存于其他设备(如云端服务器)，由于其他设备存储的内容不包含内容信息主体，即使泄露，也不会对用户隐私产生影响。本地内容已包含内容信息主体，当与其他设备中存储的附加部分合并时，可还原原始内容，核心也可以独立使用，等效于原始内容的低质量版本。采用该方式，进一步提升了文件的安全性，并可方便快捷的基于核心部分进行相应处理。

方式2中，存储在本地的子文件为文件的高位分量对应的部分文件，存储在其他设备中的子文件为文件的低位高频分量对应的部分文件。

对于文件的数据位特征而言，高位分量所对应的文件内容中通常包含人类可理解的信息，一般可以被独立使用，可以作为核心部分，低位分量所对应的文件内容通常无法被人类理解，无法被独立使用，可以作为附加部分。因此，文件的各子文件是基于文件的数据位特征拆分得到的时，可以将包括高位分量的部分可以存储于本地，包括低位分量的部分存储在其他设备，以进一步更好的保证文件的安全。

方式3是对低频分量即第一部分部分进一步拆分得到第五部分和第六部分所对应的方案。该方案中，文件包括低频高位分量、低频低位分量和高频分量三部分。此时，低频高位分量包含人类可理解的信息，可作为核心部分，存储于设备本地，低频低位分量和高频分量均不包含人类可理解信息，必须附加在低频高位分量上方可使用，低频低位分量和高频分量一起，可以作为附加部分，存储于其他设备。如图2a中所示，以f1表示第一部分，f2表示第二部分，f1b1为基于f1拆分得到的第五部分，f1b2为第六部分，则该方案中，f1b1存储于本地，f1b2+f2存储于其他设备。

方式5则是对高位分量即第四部分进一步拆分得到第七部分和第八部分所对应的方案。该方案中，高位低频分量对应的部分文件存储于本地，高位高频分量和低位分量存储于其他设备。如图2b中所示，b1表示第四部分，b2表示第三部分，b1f1为基于b1拆分得到的第七部分，b1f2为第八部分，则该方案中，b1f1存储于本地，b1f2+b2存储于其他设备。

基于方式3或方式5中的方案，可最大化的实现人类可理解信息和人类不可理解信息的分离，在保护用户隐私的前提下，尽可能多的拆分出人类不可理解数据，缩小核心部分。采用该方案，可尽可能多的释放本地设备的存储空间。

方式4是对高频分量即第二部分进一步拆分得到第五部分和第六部分所对应的方案。该方案中，低频分量和高频高位分量存储于设备本地，高频低位分量存储与其他设备。如图2c中所示，f1表示第一部分，f2表示第二部分，f2b1为基于f2拆分得到的第五部分，f2b2为第六部分，则f1+f2b1存储于本地，f2b2存储于其他设备。

方式6是对低位分量即第三部分进一步拆分得到第七部分和第八部分所对应的方案。该方案中，高位分量和低位低频分量对应的部分文件存储于本地，低位高频分量存储于其他设备。如图2d中所示，b1表示第四部分，b2表示第三部分，b2f1为基于b2拆分得到的第七部分，b2f2为第八部分，则b1+b2f1存储于本地，b2f2存储于其他设备。

在需要尽可能多的将文件的部分内容存储于本地时，基于方式4或方式6中的方案，可实现将尽可能多的人类容易理解的信息存储于本地。

基于方式1或方式2的方案，可以只对文件拆分一次，运算负载稍小。

可以理解的是，上述图2a、图2b、图2c和图2d所示的四个示例中的f1和f2只是用于示意性的表示低频分量和高频分量，b1和b2只是示意性的表示高位分量和低位分量，不同图中的f1、f2、b1和b2的所对应的文件的部分很可能是不同的，如图2a和图2b中的f1、f2、b1和b2则是不同的，2a和2c中的f1和f2则可能是相同的，也可能是不同的，而2a和2c中的b1和b2则是不同的。

由前文描述可知，在实际应用中，在基于文件的频域特征和数据位特征进行拆分时，可以先基于频域特征对文件进行拆分，再对拆分后的子文件基于数据位特征进行拆分；也可以先基于数据位特征对文件进行拆分，再对拆分后的子文件基于频域特征进行拆分。

本申请的可选实施例中，文件的各子文件与文件的文件相关信息、存储子文件的至少一个设备的设备相关信息、用户相关信息中的至少一项信息关联。

其中，文件相关信息可以包括文件类型、文件大小、文件标签、文件等级、文件的内容、文件操作信息、文件质量、文件存储位置等信息中的至少一项；和/或，

设备相关信息可以包括存储空间、电量、网络状态、负载状态等信息中的至少一项；和/或

用户相关信息可以包括用户属性信息、用户行为相关信息、用户联系人信息、用户设置信息等信息中的至少一项。

对于文件相关信息，文件类型可以包括但不限于文本文件、视频文件、图片文件、音频文件等各种类型中的一种。文件标签可以是文件在设备中存储时的默认标签，也可以是用户自定义的文件标签，可以包括但不限于文件大小、文件名称、文件创建时间等等。文件的内容可包括整个文件内容和/或文件的至少一个子文件的内容等。文件操作信息可以是文件创建时间、文件的打开时间(如最近一次打开时间)、使用频率等。文件质量可以是文件的大小、清晰度等信息，文件存储位置可以是文件在本地设备的存储位置信息、也可以是各个子文件的存储位置信息等。

对于设备相关信息，则包括但不限于本地设备和/或存储各子文件的其它设备的相关信息。其中，存储空间可以是设备的整体存储空间和/或剩余存储空间等。网络状态可以是设备的网络类型(如无线局域网、移动网络等)、网速、可用流量的信息中的一个或多个。负载状态则可以包括但不限于设备的内存使用状态、设备中安装的应用的数量、正在运行的应用的数量等信息中的一个或多个。

对于用户相关信息，用户属性信息可以根据实际需要配置，例如，可以包括但不限于用户的性别、年龄、学历、地域、婚姻等等。用户行为信息可以包括但不限于包括用户的日程，酒店预定/机票/火车票，聊天/短信文本，当前位置等信息中的一个或多个。用户联系人信息可以是指用户的通信录、最近一段时间内的联系人等信息。用户设置信息可以是指用户对设备的设置信息、对文件的设置信息等。

在实际应用中，可以根据上述信息中的一项或多项来确定或调整文件的各子文件的大小，在各子文件的大小变化的同时，各子文件的内容也相应的会发生变化。具体的，对于未拆分的文件，可以基于文件相关信息、设备相关信息及用户相关信息中的一项或多项信息，来确定拆分时各子文件的拆分比例，对于已拆分的子文件，则可以基于这些信息中的一项或多项信息，来确定是否需要对该子文件对应的文件的子文件的比例进行调整。

本申请的可选实施例中，该文件处理方法还可以包括：

确定待拆分文件对应的各子文件的目标拆分比例；

根据目标拆分比例，对待拆分文件进行拆分，得到待拆分文件对应的各子文件。

其中，待拆分文件可以是终端设备中所有未拆分的文件和/或已拆分的子文件。

本申请的可选实施例中，待拆分文件可以为基于文件相关信息、存储待拆分文件的子文件的至少一个设备的设备相关信息、用户相关信息中的至少一项信息确定的至少一个文件。关于文件相关信息、设备相关信息、用户相关信息的具体描述可参见前文中相应的描述，例如，用户相关信息可以包括用户属性信息、用户行为相关信息、用户联系人信息、用户设置信息等信息中的至少一项，待拆分文件可以是基于用户相关信息中的至少一项信息确定的至少一个文件。

在一示例中，待拆分文件可以由用户预先设置，也就是说，待拆分文件可以是基于用户设置信息确定。例如，用户预先设置需要进行拆分的一个或多个文件，或设置需要拆分的文件的相关信息，例如，可以设置需要拆分的文件对应的存储位置，创建时间，包含的内容等相关信息中的一项或多项，终端设备根据该相关信息确定需要拆分的文件，即上述待拆分文件。

此外，终端设备也可以自动确定待拆分文件，在一示例中，终端设备可以根据用户历史设置，设备相关信息等信息确定待拆分文件。例如，用户之前在设置待拆分文件时，一般都设置包含某个特定人物的图片，因此，终端设备可以自动确定包含该特定人物的图片为待拆分文件。再例如，终端设备可以根据设备的存储空间、电量等信息自动确定待拆分文件的数量，如当存储空间较小或电量较少时，可以只拆分创建时间最近的设定数量个文件为待拆分文件。

可以理解的是，上述只是列举了待拆分文件的几种可选的确定方式，在实际应用中，可以根据实际需要和/或应用场景的不同，选择上述列举的方式中的一种或多种来确定待拆分文件，或者，基于文件相关信息、设备相关信息、用户相关信息中的至少一种信息，采用其他的待拆分文件的确定方式。

本申请的可选实施例中，上述根据目标拆分比例，对待拆分文件进行拆分，可以包括：

当满足设定的文件拆分条件时，根据目标拆分比例，对待拆分文件进行拆分。

其中，文件拆分条件可以是基于文件相关信息、设备相关信息、用户相关信息中的一种或多种信息确定的条件，也可以是根据实际应用需要设置的条件。一种可选方式中，可以根据用户的指示，对待拆分文件进行拆分处理，例如，用户可以一次选择一个或多个文件进行拆分，或者，也可以自动对文件进行拆分处理。另一种可选方式中，还可以在设备在空闲时，自动对待拆分处理的文件(即待拆分文件)进行拆分处理，例如，在终端设备空闲时，将终端设备上所有未拆分的文件进行拆分处理。

作为一个示例，用户使用终端设备拍摄了一些视频和照片，设备将这些新产生的文件标记为待处理，当设备空闲(负载低于阈值)时，设备对待处理文件进行拆分处理，当设备空闲且无线局域网(如wifi)可用时，设备将拆分出的附加部分上传到云上，并删除本地附加部分，释放出存储空间。

本申请的可选实施例中，该文件处理方法还可以包括：

当待拆分文件为已拆分的子文件，且目标拆分比例和当前拆分比例之间的差值大于设定阈值时，根据目标拆分比例，对待拆分文件所对应的拆分前的文件进行拆分。

其中，根据目标拆分比例，对待拆分文件所对应的拆分前的文件进行拆分，可以是对待拆分文件所对应的拆分前的文件重新进行拆分，也可以是对待拆分文件所对应的拆分前的文件的至少一个子文件进行相应处理，以使处理后的各子文件的目标拆分比例等于目标拆分比例。

具体的，对待拆分文件所对应的拆分前的文件重新进行拆分，可以是基于拆分前的文件的当前的各个子文件得到拆分前的文件，再基于目标拆分比例，对拆分前的文件进行重新拆分。对待拆分文件所对应的拆分前的文件的至少一个子文件进行相应处理，可以是将拆分前的文件的当前的各个子文件中的一个或多个子文件进行重新分割、合并，使重新分割、合并后的各个子文件的比例尽量接近目标拆分比例。

在一示例中，如待拆分文件所对应的拆分前的文件包括两个子文件，待拆分文件为两个子文件中存储在本地的子文件(简称本地子文件)，另一子文件存储在云端服务器(简称云端子文件)。当本地子文件与云端子文件的目标拆分比例与当前拆分比例不同(此时上述设定阈值可以为零)时，可以对待拆分文件或云端服务器存储的子文件进行调整。例如，当本地子文件与云端子文件的目标拆分比例大于当前拆分比例时，可以从云端服务器下载一部分文件与本地子文件合并，并将从云端服务器下载的一部分文件从云端服务器删除，处理后的本地子文件与云端子文件的比例等于目标拆分比例；当本地子文件与云端子文件的目标拆分比例小于当前拆分比例时，可以对本地子文件进行重新分割，并上传分割后的部分文件至云端服务器，与云端子文件合并，删除本地中对应的部分文件，处理后的本地子文件与云端子文件的比例等于目标拆分比例。

可见，如果待拆分文件处于未拆分处理状态，则可以按照预测出的目标拆分比例对其进行拆分处理，如果待拆分文件处于已拆分状态，则可以依据目标拆分比例，对待拆分文件对应的拆分前的文件进行重新拆分，或者对拆分前的文件的至少一个子文件进行相应处理。

由前文的描述可知，文件的各子文件可以基于文件的频域特征和/或数据位特征拆分得到的，因此，在根据目标拆分比例，对待拆分文件进行拆分时，可以基于文件的频域特征和/或数据位特征，按照目标拆分比例对待拆分文件进行拆分，得到对应的各子文件。

本申请的可选实施例中，该文件处理方法还可以包括：

将拆分得到的至少一个子文件发送到至少一个其他设备中进行存储。

可以理解的是，在待拆分文件为未拆分文件时，本地设备在完成待拆分文件的拆分后，需要将拆分得到的至少一个子文件发送到其他设备中进行存储。其他设备可以是其他终端设备、服务器、云端服务器中的一种或多种。将至少一个子文件发送到其他设备后，便可以将本地设备中对应的该子文件进行删除，以释放本地设备的存储空间，实现设备的优化。在待拆分文件为已拆分的子文件时，由上文描述可知，如果是对待拆分文件对应的拆分前的文件进行重新拆分，则可以将重新拆分得到的至少一个子文件发送到其他设备中进行存储，如果是对拆分前的文件的至少一个子文件进行相应处理时，则可能是需要将至少一个子文件的部分文件发送到至少一个其他设备中进行存储，也可能是需要从其他设备获取至少一个子文件的部分文件。

本申请的可选实施例中，确定待拆分文件对应的各子文件的目标拆分比例，可以包括：

针对待拆分文件的文件相关信息、存储待拆分文件的子文件的至少一个设备的设备相关信息、用户相关信息中的至少一项信息，提取对应的特征信息；

通过深度学习网络，基于提取的特征信息，确定待拆分文件对应的各子文件的目标拆分比例。

需要说明的是，在实际应用中，各子文件的目标拆分比例可以是采用该方式确定的，也可以是设定的拆分比例。

其中，深度学习网络的具体网络类型可以根据实际需要确定。通过对深度学习网络进行训练，使得在将提取的待拆分文件的特征信息输入到深度学习网络时，该网络可以输出各子文件的目标拆分比例。在一可选方案中，深度学习网络可以包括但不限于神经网络、多层感知机、决策树、词嵌入、自然语言处理模型等网络中的一种或多种。

需要说明的是，在特征信息为多项信息对应的特征信息时，多项信息对应的特征信息可以输入至同一深度学习网络，由该神经网络输出得到目标拆分比例，也可以是多项对应的特征信息先通过一种或多种深度学习网络的预处理后，预处理结果再输入至被训练为输出目标拆分比例的深度学习网络，得到目标拆分比例。

本申请的可选实施例中，若文件的至少一个子文件存储于本地，至少一个子文件存储于其他设备，则对文件的至少一个子文件进行相应处理，可以包括以下方式中的至少一种：

对本地存储的至少一个子文件进行相应处理；

对其他设备存储的至少一个子文件进行相应处理。

在实际应用中，在文件的核心部分存储在本地时，可以根据用户的操作请求，只对存储于本地的核心部分进行处理。如果文件的核心部分存储在其他设备时，则可以根据操作请求对其他设备存储的子文件进行相应处理。当然，也可以是同时对本地存储的至少一个子文件和对其他设备存储的至少一个子文件进行相应处理。

本申请的可选实施例中，对其他设备存储的至少一个子文件进行相应处理，可以包括以下方式中的至少一种：

从其他设备获取文件的至少一个子文件，对获取的子文件进行相应处理；

指示其他设备对存储的至少一个子文件进行相应处理；

获取不同设备存储的至少两个子文件，将获取的至少两个子文件进行合并处理。

在需要对其他设备存储的至少一个子文件进行相应处理时，可以通过向其他设备发送文件获取请求，从其他设备获取文件的至少一个子文件，再根据操作请求对获取的子文件进行相应处理。

指示其他设备对存储的至少一个子文件进行相应处理，可以是指示其他设备对该设备存储的至少一个子文件进行相应处理，也可以指示其他设备对另外的其他设备进行相应处理。例如，一个文件包括三个子文件，其中一个存储在本地，一个存储在云端服务器，一个存储在另外的终端设备，本地设备可以直接对本地存储的子文件直接进行相应处理，本地设备在需要对云端服务器上存储的子文件进行处理时，可以向云端服务器发送相应的操作请求，该操作请求用于指示云端服务器对其存储的子文件进行相应处理，还可以向云端服务器发送指示指令，该指示指令用于指示云端服务器其向另外的终端设备发送相应的操作指令，以使另外的终端设备对其存储的子文件进行相应的操作。

需要说明的是，在获取不同设备存储的至少两个子文件，将获取的至少两个子文件进行合并处理时，合并处理可以只是对至少两个子文件进行合并，也可以是对至少两个子文件先合并，对合并后的文件再进行相应处理，还可以是对至少两个子文件分别进行相应处理后，再对处理后的至少两个子文件进行合并。

其中，获取不同设备存储的至少两个子文件中的不同设备，可以是指本地设备和本地设备之外的其它设备，也可以是不同的其它设备。作为一个示例，例如一个文件包括三个子文件a、b、c，其中子文件a存储于本地设备，子文件b存储于一个云端服务器，子文件c存储于另一个云端服务器，本地设备在接收到对文件的操作请求时，可以根据操作请求的具体内容对文件进行相应处理。例如，在操作请求为浏览请求时，本地设备可以分别获取存储于两个云端服务器的子文件b和子文件c，以及存储在本地的子文件a，并将三个子文件合并后显示给用户。再例如，在操作请求为编辑请求和浏览请求时，本地设备可以分别对获取到的三个子文件a、b、c分别进行相应编辑后再合并，将编辑合并后的文件显示给用户，本地设备也可以是先对获取到的子文件a、b、c进行合并，再对合并后的文件进行编辑后显示给用户。

当然，如果本地设备接收到操作请求后，需要对文件的子文件a和子文件b进行相应的合并处理，则可以分别从云端服务器获取子文件b的部分或全部内容，对子文件a和子文件b的部分或全部内容进行合并处理。例如，对于一个时长为50秒，大小为200mb的视频，视频中的20mb(核心部分)存储于终端设备，90mb存储于一个云端服务器a，90m存储于另一个云端服务器b。在操作请求为浏览请求(如用户在终端设备上点开该文件)时，终端设备可以立刻加载此文件的核心部分并展示，如果当前网络较慢，终端设备可以根据当前网速，计算50秒能够从云端服务器下载30m的文件内容，此时，终端设备可以从其中一个云端服务器获取30m大小的文件(如从云端服务器a中获取30m大小的文件)，将获取的30m文件和本地核心部分合并后展示给用户。

本申请的可选实施例中，操作请求包括以下请求中的至少一种：

浏览请求、编辑请求、删除请求、发送请求、获取请求。

其中，在操作请求为发送请求时，可以是本地设备将本地存储的至少一个子文件发送给接收方的设备，也可以是本地设备将本地存储的至少一个子文件和从其它设备获取的至少一个子文件发送给接收方，还可以是其他设备(如云端服务器)在接收到发送请求后，根据该请求将存储的至少一个子文件发送给请求对应的接收方的设备。获取请求可以包括接收请求，如接收文件的终端，可以从本地设备和/或其它设备接收至少一个子文件。

本申请的可选实施例中，从其他设备获取文件的至少一个子文件，可以包括下述至少一项：

基于设备相关信息，从其他设备获取文件的至少一个子文件；

从其他设备获取文件的至少一个子文件的部分或全部内容；

基于文件对应的链接特征值，从其他设备获取文件的至少一个子文件。

在实际应用中，可以基于设备的存储空间、电量、网络状态、负载状态等信息中的一项或多项，来确定是否向其他设备获取至少一个子文件。例如，在设备网络处于wifi或数据流量充足的情况下，可以从其它设备获取至少一个子文件。再例如，在设备电量大于电量阈值时，可以从其它设备获取至少一个子文件。

在从其它设备获取至少一个子文件时，可以根据配置或实际应用需要，可以是获取至少一个子文件的部分内容，也可以是获取全部内容。具体的，可以基于设备相关信息和/或文件相关信息中的一项或多项信息，来确定是获取部分内容还是全部内容。

例如，作为一个具体示例，用户在设备上点开一个已被拆分存储的视频文件。视频时长为60s，大小为70mb的视频，视频中的10mb存储于终端设备，60mb存储于云端服务器。用户在终端设备上点开该文件时，终端设备可以立刻加载此文件的核心部分并展示，效果等同于此视频的低清晰度版本。如果网络可用(如有wifi或剩余数据流量充足，网速足够快)，终端设备在展示文件的核心部分的同时，可以从云上下载此文件对应的附加部分，将其与核心部分拼合为完整原始文件并展示，用户可以观看原始清晰度的视频。如果网络情况不佳(网速有限，数据流量不充足等)，终端设备在展示文件的核心部分的同时，可以从云上下载此文件对应的一部分附加部分，而非完整的附加部分。假设当前网速较慢，只有0.5mb/s。那么，60s时长内，最多可以下载30mb内容。考虑到网络速度可能不稳定，云端服务器可以返回20mb的附加部分内容。从而使用户可以在无延迟(延迟很小，用户基本感知不到)的情况下，观看相当于30mb清晰度的视频(本地10mb，服务器返回20mb)。

可以看出，本申请实施例的方案，可以根据实际应用需求和/或设备相关信息等，来选择是只处理本地存储的核心部分，以及是否需要获取其他设备中的附加部分，由于可以只对本地存储的核心部分进行相应处理，因此，该方案降低了对网络连接的依赖，能够更加满足实际应用需求。

本申请的可选实施例中，基于设备相关信息，从其他设备获取文件的至少一个子文件，包括：

当本地设备和/或存储子文件的其他设备的设备相关信息满足设定的处理条件时，从其他设备获取文件的至少一个子文件；

设备相关信息包括以下信息中的至少一项：存储空间、电量、网络状态、负载状态。

可以理解的是，处理条件可以根据实际需要配置，例如，处理条件可以为本地设备的网络状态为wifi链接且设备电量大于50％。

文件对应的链接特征值用于唯一的标识文件。存储在其他设备上的至少一个子文件的实际存储位置或者url(uniformresourcelocator,统一资源定位符)可以与对应的链接特征值关联存储，需要在从其他设备获取文件的至少一个子文件时，可以向其他设备发送包括该链接特征值的文件获取请求，其它设备基于该请求中的链接特征值，可以快速的将对应的至少一个子文件反馈。

设备(本地设备或其他设备)可以在需要时再根据链接特征值随时获取所需的至少一个子文件。如文件的子文件分别存储于本地和云端服务器时，本地设备在需要向其他用户发送文件时，可以只发送本地存储的部分和文件对应的链接特征值，其他用户接收到链接特征值后，可以在需要时再向云端服务器获取云上存储的部分文件，而无需向本地设备重新发送获取请求，且获取部分文件的时限也不受限制。

此外，由于设备能够基于链接特征值从云端服务器或其他设备上自动获取到所需子文件，因此，用户无需记住每个子文件的存储位置，减轻了用户的文件管理负担，极大减低了用户文件管理难度，解决了现有云存储等方式中用户需要记住每个文件存储位置，造成用户不便的问题。

本申请的可选实施例中，链接特征值可以与下述至少一项关联：文件的内容、时间信息、用户信息、本地设备信息。

例如，可以基于文件的核心部分的内容得到链接特征值，具体的，可以使用哈希算法计算核心部分所对应的哈希值，将该哈希值作为文件的链接特征值。为避免不同文件哈希值碰撞的情况发生，还可以基于文件的核心部分的内容和用户标识等得到该链接特征值，例如，可以将核心部分对应的哈希值与用户标识拼接得到链接特征值。

本申请的可选实施例中，存储在其他设备上的至少一个子文件为基于存储在本地的至少一个子文件的内容进行加密后的子文件。基于该可选实施例，该文件处理方法还可以包括：

根据存储在本地的至少一个子文件的内容，对存储在其他设备上的至少一个子文件进行解密，若解密成功，则确认存储在本地的至少一个子文件的内容未发生变化。

在实际应用中，有些特定情况下，用户需要证明自己所记录的内容是可靠的(时间真实未被修改，内容真实未被修改)，例如，在发生交通事故或其他特殊事件时，用户需要记录现场状况的照片/视频，或者重要谈话内容等，并需要证明其在事故或其他事件发生时所拍摄的照片、或者录音或者视频等文件的真实可靠性。本申请实施例提供的该内容验证的方案，基于存储在本地的至少一个子文件的内容对存储在其他设备上的至少一个子文件进行加密处理，此时，由于只有未修改的核心部分，才能对加密的附加部分进行解密，因此，可以基于存储在本地的至少一个子文件的内容，能否对存储在其他设备上的至少一个子文件解密成功，来证明存储在本地的核心部分是否发生了变化，即可以基于其它设备上存储的附加部分验证本地存储的核心部分。

本申请的可选实施例中，存储在其他设备上的基于存储在本地的至少一个子文件的内容进行加密后的子文件，还可以与其它设备的时间戳关联存储，该时间戳可以是其它设备接收到子文件的时间。例如，在其它设备为云端服务器时，可以是云端服务器接收到解密后的子文件的服务器时间戳，由于时间戳这一信息很难被篡改，因此，可以证明文件的真实产生时间。

在实际应用时，可以在终端设备上配置与该验证功能对应的设置选项，该功能设置选项默认可以是关闭的，用户在特定情况下需要使用该功能时，如需要在获取照片、录音或者视频等文件，且需要对获取到的文件使用该功能时，可以使用点击/手势/按键组合/语音等多种方式，激活该功能。对于激活该功能后获取到的文件进行拆分处理，并使用拆分后的核心内容对附加部分进行加密，加密后的附加部分发送至云端服务器等其他设备中存储，云端服务器在存储时为该加密的附加部分设置时间戳。

为了更好的理解本申请实施例的方案，下面结合一些具体示例对本申请实施例的文件处理方法进行说明。

图3示出了本申请实施例的文件处理方法所适用的一种网络架构的结构示意图，如图3中所示，该网络架构可以包括终端设备100和云端服务器200，终端设备100为本地设备，云端服务器200为其他设备。终端设备100中的文件可以被拆分为至少两个子文件，至少两个子文件分别存储于终端设备100和云端服务器200中。

可以理解的是，在实际应用中，终端设备100可以包括但不限于智能手机、平板电脑、个人电脑、智能手表/智能眼镜等可穿戴设备、智能冰箱/智能电视等智能家居设备、智能汽车等。云端服务器200可以是公司厂商提供的公有服务器和/或自行搭建的私有服务器，子文件手动或自动上传至云上后，可以通过网页/管理应用程序(app)等方式对子文件进行处理。

基于图3中所示的系统架构，结合以下示例对本申请实施例的文件处理方法进行说明。

图4示出了对终端设备100中存储的完整文件(即原始文件)进行文件的处理与上传的原理示意图。由图中可以看出，完整文件可以被拆分为两部分，即核心部分和附加部分，核心部分存储于终端设备100本地，附加部分存储于云上(即云端服务器200上)。

作为一示例，图5示出了对原始文件进行拆分得到核心部分和附加部分的原理示意图。由图5中可以看出，原始文件可以按照文件信息内容拆分为“低频高位”和“高频+低频低位”两部分，前者称为核心部分，后者称为附加部分。核心部分包含信息主体，附加部分只包含信息细节。此外，可选的，如图5中所示，还可以通过核心部分生成一个哈希值，使用此哈希值作为秘钥或通过此哈希值生成一个秘钥，使用此秘钥将附加部分加密后，将加密的附加部分保存于云上。可以理解的是，此操作并非必要，如果执行，可进一步提升隐私安全性。

作为一个示例，图6中示出了根据原始多媒体文件的频域特征和数据位特征(如二进制的数据位特征)将文件拆分为核心部分和附加部分的流程示意图。本示例中，以先基于频域特征进行拆分，再基于数据位特征进行拆分为例说明。

如图6中所示，在拆分前，终端设备可以首先判断原始多媒体文件是否为压缩编码格式，如果是，则将其解压缩为原始数据。对于常见多媒体文件，如音频/图片/视频，其原始数据可以表示为一维/二维/三维矩阵，分别表征声音振幅在时间上的分布/像素三原色亮度在空间上的分布/逐帧图片在时间上的分布。

基于文件的信息频率(即频域特征)进行拆分时，首先将原始数据变换到频域数据，可以使用fft(fastfouriertransform，快速傅里叶变换)/dct(discretecosinetransform，离散余弦变换)/stft(short-timefouriertransform，短时傅里叶变换)/wt(wavelettransform，小波变换)等方法，或其他时空域-频域变换方法，将原始数据变换到频域。频域数据为与原始数据维度相同的矩阵。

作为一个示例，频域数据形式可以表示为：

[[f00，f01，f02，...，f0n]，

[f10，f11，f12，...，f1n]，

…

[fm0，fm1，fm2，...，fmn]]

其中，每个频域元素fij代表对应频率元素的频域特征值，即频域元素的频域分量的大小/幅度。一般约定i、j较小的元素对应低频分量，i、j较大的元素对应高频分量。m和n为频域数据矩阵的高和宽。低频分量包含了内容的主体结构信息，高频分量包含了内容(去除主体结构后)的细节信息。

需要说明的是，在实际应用中，在对原始数据进行频域转换时，采用的频域转换方式不同，所得到的频域数据矩阵的形式也可能不同，有的转换方式得到的频域数据矩阵中可能满足i、j较小的元素对应低频分量，i、j较大的元素对应高频分量，有的可能不满足。本示例中，为了描述方便，以i、j较小的元素对应为低频分量，以i、j较大的元素对应为高频分量为例进行说明。

本示例中，以控制量r1(取值范围0-1)和控制量r2(取值范围0-1)共同来表征文件的目标拆分比例，其中，控制量r1控制低频部分和高频部分的比例，控制量r2控制高数据位和低数据位的比例。

基于频域特征，根据控制量r1，将频域数据拆分为低频分量和高频分量两部分。具体而言，如果下标小的频域元素对应低频分量，则可以将所有符合i＜m*r1且j＜n*r1的fij划归为低频分量部分，包含低质量的主体结构信息；将其他fij划归为高频分量部分，不能独立使用。

作为一个示例，图6a中示出了一种拆分方式的示意图，如图中所示，f00、f01、f10、f11为划分出的低频分量部分，其余为高频分量部分。

可选的，在完成低频分量部分和高频分量部分的划分后，可以基于数据比特位(即数据位特征)，根据控制量r2将低频分量部分进一步拆分。在一个示例中，以二进制为例，对于每个低频元素fij，均可表示为如图6b中所示意的一系列的二进制位，其中，q+1表示二进制位的位数，如果以下标小的二进制位代表高数据位，则可以将所有符合i＜q*r2的biti划归为低频高位分量部分；将其余biti划归为低频低位分量部分。

通过上述两步拆分，原始数据被拆分为低频高位分量，低频低位分量，高频分量三部分。其中只有低频高位分量包含人类可理解的信息，作为核心部分，存储于设备本地；低频低位分量和高频分量均不包含人类可理解信息，必须附加在低频高位分量上方可使用，低频低位分量+高频分量一起，作为附加部分，存储于云上。

本示例中，两步拆分最大化的实现了人类可理解信息和人类不可理解信息分离，在保护用户隐私的前提下，尽可能多的拆分出人类不可理解数据，缩小核心部分。

可以理解的是，在实际应用中，也可以只依据频域特征或数据位特征进行原始数据的划分。例如，在本示例中，可以不进行按数据位特征的拆分，直接将按频域特征拆分的结果低频分量和高频分量分别作为核心部分和附加部分。也可以达到信息分离的效果。如果跳过按数据位特征的拆分，分离效果不如两步拆分(两步拆分得到的核心部分体积更小)，但运算负载稍小。

对于本示例，在拆分过程中，r1和r2控制拆分比例，较小的r1和r2将产生质量较低但体积较小的核心部分+体积较大的附加部分，较大的r1和r2将产生质量较高但体积较大的核心部分+体积较小的附加部分。r1控制按频域特征拆分的比例，具体而言，低频分量部分大小/完整大小＝r1^n_dim即r1^n_dim(对于音频，n_dim＝1；对于图片，n_dim＝2；对于视频，n_dim＝3)。r2控制按数据位特征拆分的比例，具体而言，低频高位分量部分大小/低频分量部分大小＝r2。

在实际应用中，r1和r2可以取预先设定的默认值，例如，按经验将r1和r2设置为0.1。此外，也可以在初始使用时，按照当前设备状态来实时设定r1/r2，例如，设备当前可用存储空间较小，则将r1和r2设定的较小，设备当前可用存储空间较大，则将r1和r2设定的较大。还可以由用户手动设置，或由其他模块自动设置(如后文中描述的，基于待拆分文件的文件相关信息、存储待拆分文件的子文件的至少一个设备的设备相关信息、用户相关信息中的至少一项信息所对应的特征信息，通过深度学习网络，确定待拆分文件对应的各子文件的目标拆分比例)，或由其他应用/设备操作系统等自动设置。无论r1/r2如何设置，附加部分中的信息均为不可被人类理解，实现了安全性极高的隐私保护。

作为一个示例，图7中示出了基于用户事件预测的自动存储管理方法的原理示意图。其思想是：根据待拆分文件的文件相关信息、存储待拆分文件的子文件的至少一个设备的设备相关信息、用户相关信息中的至少一项信息，调整各个文件本地和其他设备上的存储比例，即确定文件的各子文件的目标拆分比例。图7中的图片作为待拆分文件的一个示意，终端设备通过可获取的信息如图中所示的文件的评级高低、文件的使用频率、终端设备的存储空间是否充足等信息，还可以分析预测用户近期未来将要/计划进行的事件，如公务差旅，个人旅行，家庭聚会等。同时，终端设备还可以通过可获取的信息，分析本地每个文件特性，得到其与未来事件的相关度/匹配度。在此基础上，还可以考虑终端剩余存储空间，得到待拆分文件的目标拆分比例，对每个文件进行调整。

如果待拆分文件为未拆分的文件，对文件的调整，指的是确定文件的核心部分和附加部分的拆分比例。对于已拆分的文件，如果目标拆分比例与文件的各子文件的当前拆分比例的差值大于设定阈值，对文件的调整，则是指改变文件的分割比例，获得更大的核心部分+更小的附加部分(更好的本地文件质量，加载完整文件的流量/时间开销较小)，或更小的核心部分+更大的附加部分(较低的本地文件质量，占用本地存储较少)。通过针对用户事件的逐文件调整，确保用户在各种情况下，有充足的终端存储空间可用，以及确保用户将用到的文件，尽量多存储于终端本地，尽可能保障用户可能将要使用的文件的可用性，更要的满足用户实际需求。

在图7中，若文件评级低、文件不常使用、终端存储不足、预测到重大事件或未预测到相关事件，则在拆分待拆分文件时，可以获取更小的核心部分以及更大的附加部分，以便得到较低质量的本地存储子文件质量，使得本地存储较少。若文件评级高、文件常被使用、终端存储充足、未预测到重大事件或预测到相关事件，则在拆分待拆分文件时，可以获取更大的核心部分以及更小的附加部分，以便得到较高质量的本地存储子文件质量，使得加载完整文件的流量/时间开销较小。

例如，在预测到用户即将出去旅游等重大事件时，由于旅游时很需要拍照或者录视频等，终端设备需要更多的存储空间，在拆分待拆分文件时，则可以拆分为更小的核心部分以及更大的附加部分，以释放更多的存储空间。再例如，在预测到用户需要参见朋友聚会等相关事件时，很可能需要用到与参加聚会的相关人员的照片、视频等相关文件，则可以将相关文件的更大的核心部分存储在终端设备，以便于用户使用。

作为一个具体示例，图8中示出了针对用户相关信息，提取对应的特征信息的方法的示意图。该示例中，可以使用多种方法处理可获取的用户相关信息，预测用户的近期未来事件的特征(即用户相关信息对应的特征信息)。如图8中所示，可获取的用户相关信息包括但不限于用户日程，酒店预定/机票/火车票，聊天/短信文本，当前位置，最近联系人等。除终端设备可直接获取的信息，属于同一账号/同一网络/相互连接的其他终端设备、同一用户在各个网络平台的信息等其余可获取信息，也可以作为输入。使用多种方法对用户相关信息进行预处理。预处理模块将多模态的非结构化的信息转换为表征信息特征的向量。

一般而言，对于结构化信息(如日程等)，可以使用基于规则的分析(如决策树)等处理方式，生成确定性的结果向量，用于后续处理。相比于其余模型输出，此结果具有更高的可信度，因此，在后续使用中，可以具有更高的权重。一种实现更高权重的方法为，此结果不与预处理模块的其他结果结合一起输入自动编码器，而是直接输入到进行用户事件特征预测的多层感知机。

可以对词汇/实体信息等(如当前位置，酒店预定/机票/火车票、日程中的关键词等)进行词嵌入处理，可以转换为保持原有词汇/实体信息结构的向量，用于后续处理。

对自然语言文本类信息(如聊天/短信文本等)使用lstm(longshorttermmemory，长短时记忆网络)/gru(gatedrecurrentunit，门控循环单元)等自然语言处理技术，生成表征其关键特征(如主题/关键词/用户意图等)的向量，用于后续处理。

对可量化/数值类(如最近联系人/当前位置坐标等)信息，使用多层感知机，生成表征其特性的向量，用于后续处理。

将预处理模块中词嵌入、自然语言处理和多层感知机的输出，合并为一个向量，输入一个自动编码器，对信息进行压缩提取。

将基于规则的分析(如决策树)的输出向量和自动编码器的输出向量合并，输入到一个多层感知机，得到预测事件特征向量。此向量表征了终端预测出的近期未来事件的多种特性，可以包括但不限于事件类型，持续时间，地点，相关人物，重要性等等，(如：旅行，一周，美国，家人，较高。)。此信息输入到后续网络，可以用于决定如何调整终端中每个文件的拆分比例。

可以理解的是，图8中只是示出了该示例中一种可行的用户相关信息的预处理流程，在实际应用中，可以改变输入数据或输入数据到预处理模块的连接方式。

作为一个具体示例，图9中示出根据待拆分文件的文件相关信息、终端相关信息，提取对应的特征信息，根据提取的特征信息得到目标拆分比例的方法的示意图。该示例中，基于预测出的事件特征向量，分析每个文件自身特征及其与预测事件相关性，再考虑到终端设备剩余存储空间等终端设备信息，决定如何调整每个文件，即文件分析及自动调整的方案。

本示例中，如图9中所示，可获取的文件相关信息包括但不限于：文件类型/大小，标签/评级，文件打开时间，文件内容等。其中，评级可以由用户手动设定，也可以从用户行为自动确定得到。比如，如果用户将某张照片标记为喜欢，或者对其进行了编辑修改或美化处理，或者分享了某张照片，或者常常打开某张照片等，均表示此张照片评级较高。对于已被拆分过处理过的文件，文件内容指其核心部分内容，对于尚未被拆分处理过的文件，文件内容指其完整内容。

本示例中，可以使用多种方法对文件信息进行预处理。预处理模块将多模态的非结构化的信息转换为表征信息特征的向量。

一般而言，可以使用多层感知机处理文件类型/大小，标签/评级，文件打开时间等信息，将其编码为向量，用于后续处理。本示例中，可以使用rnn(recurrentneuralnetwork，递归神经网络)/cnn(convolutionalneuralnetwork，卷积神经网络)/递归cnn来处理文件内容，具体使用哪种网络可以视文件类型而定，例如，rnn可以对应音频，cnn可以对应图像，递归cnn可以对应视频。文件内容被编码为表征其特征的向量，用于后续处理。

可以理解的是，图9中也只是示出了该示例中对文件相关信息的一种可行的预处理流程，在实际应用中，可以改变输入数据或者输入数据到预处理模块的连接方式。

图9中预处理模块的输出、设备相关信息(即终端设备信息，如终端剩余存储空间等)、图8中得到的预测事件特征向量、以及其他可以获取到的信息可以合并为一个向量，输入一个多层感知机，此多层感知机被训练为，输出对于预测的事件，在当前剩余存储空间情况下，当前文件即待拆分文件的目标拆分比例，即目标r1和/或r2。

需要说明的是，在实际应用中，图8中所示的用户预测事件特征预测、图9中所示的文件分析及自动调整、以及设备相关信息也都可以独立工作，即可以只基于预测事件特征向量，或图9中预处理模块输出的与文件相关信息对应的特征向量，或设备相关信息，通过深度学习网络(如多层感知机)得到每个待拆分文件的目标r1和/或r2。具体而言，对于用于输出目标r1和/或r2的多层感知机，可以被训练为在输入为预测事件特征向量的情况下工作，或者被训练为在输入为与文件相关信息对应的特征向量的情况下即在预测事件特征向量为空的情况下工作，或者被训练为在输入为终端设备相关信息的情况下工作。以输入为与文件相关信息对应的特征向量和终端剩余存储空间的情况为例，此时，多层感知机可以不依赖于用户事件特征预测独立工作，其效果相当于，在只考虑每个文件热度/用户喜爱度和终端设备存储空间的情况下，对文件/存储空间进行管理。

在得到目标拆分比例(即目标r1和/或r2)之后，如果待拆分文件当前处于未拆分处理状态，则可以按照预测出的目标r1和/或r2对其进行拆分处理，并上传附加部分，删除本地附加部分；如待拆分文件为已被拆分过的子文件，且当前的拆分状态不是目标r1和/或r2，则可以对其进行调整(如重新分割并上传一部分文件，或者下载一部分文件并合并)，使调整后的核心部分与附加部分的比例尽量接近目标拆分比例。

本申请中，可以针对每个待拆分文件，分别执行图8和图9所示的特征提取以及目标拆分比例预测，得到每个待拆分文件对应的目标拆分比例，即r1和/或r2，也就是说，针对每个待拆分文件，分别输出r1和/或r2，以控制该待拆分文件的调整方式，即拆分方式。

图8和图9中所示的各网络(如基于规则的分析、词嵌入、自然语言处理模型、多层感知机、自编码器、rnn、cnn等)，均可被预先训练好，也可以在用户实际使用中，根据用户行为持续优化更新，如在某特定环境条件下，用户可以手动调整了某文件的拆分比例，此行为可被用作训练数据，用于后续更新网络。

作为一个具体示例，假设用户将要出国旅行，终端剩余存储空间较小。终端可以使用图8中所示的方法，预测出用户将要出国旅行。对应此事件，应留出较多的存储空间(用户可能会拍摄大量照片/视频，且在国外可能不便访问云存储)。此外，针对出国旅行，应准备一些休闲类音乐/视频，供飞机上/无聊时使用。终端可以使用图9中所示的方法，逐个分析文件，如文件不相关，则将其更多的上传到云上，以保证本地存储空间。如文件属于用户喜爱的歌曲，或较新的符合用户喜好的电影，则可以将其更多的移动到本地，以便用户在飞机上使用。

作为另一具体示例，假设用户将要参加一个朋友聚会，终端剩余存储空间充足。终端使用图8中所示的方法，预测出用户将要参加的聚会及相关人员。对应此事件，应留出适当的存储空间，并准备相关人员的照片/视频。终端使用图9中所示的方法，逐个分析文件，由于存储空间充足，对于无关文件，并不需要调整。如文件相关(如，包含参加聚会人员的照片/视频，适合聚会的音乐，可活跃气氛的有趣视频片段等)，则将其更多的移动到本地，以便用户在聚会上使用。

在完成本地原始文件的拆分之后，终端设备可以在wifi可用和/或设备空闲时，将拆分得到的附加部分上传到云上，并删除本地附加部分，释放出存储空间。

在需要对文件进行操作处理时，如需要对文件进行优化删除/编辑等操作。一种实现方法是，用户需要删除文件时，接收指令的终端设备向云服务器发送请求，并删除自身所存储的核心部分，云服务器根据接收到的请求，移除自身所存储的附加部分。

用户编辑文件时，终端设备可以从云服务器获取附加部分，合成完整文件，此文件被编辑后，视为一个新文件，进行拆分上传等处理。另一种可能的同步编辑方法为，用户在终端设备上对核心部分进行编辑，终端设备将对应的修改内容或编辑步骤上传至云服务器，云服务器根据核心部分修改内容或编辑步骤，对附加部分进行对应的编辑，将其修改为同样的效果。

作为一个示例，图10中示出了基于链接特征值实现核心部分-附加部分自动链接的方法的流程图。图11中示出了链接特征值生成及基于链接特征值得到原始文件的方法示意图。由核心部分内容计算出一个唯一的链接特征值，在云上维护一个映射表(也可以是其他形式的对应关系)，记录每个链接特征值对应的附加部分存储位置。

如图10和图11所示，对原始文件(如图片、音频或视频等)进行拆分，得到核心部分和附加部分后，终端设备可以使用md5(messagedigestalgorithmv5，消息摘要算法第五版)/sma(securehashalgorithm，安全哈希算法)或其他哈希算法，计算出核心部分所对应的哈希值，可以称为“文件哈希值”。哈希算法的特性保证了，除极其罕见的情况外，不同文件的哈希值是不同的。即，通过哈希值可以唯一确定对应的文件。除了上述哈希算法，也可以使用其他算法生成文件对应的唯一链接特征值。

在极少情况下，两个不同的文件可能会产生相同的哈希值，称为碰撞。为处理这种情况，终端设备可以将时间戳和/或用户id(uid)和/或设备相关信息(如设备id等)等添加到哈希值中，这是可选步骤。时间戳可以是文件创建时间，或拆分处理发生的时间。在一可选方式中，可以将文件哈希值+时间戳+uid直接拼接到一起，此结果具备唯一性，称为链接特征值，不同的文件具备不同的链接特征值。链接特征值存储在终端设备本地。也可以使用【文件哈希值+时间戳】，或【文件哈希值+uid】等方式产生链接特征值，还可以使用其他算法，通过【文件哈希值+时间戳和/或uid】等方式产生一个唯一值，作为链接特征值。

此外，如图10中所示，可选的，类似于生成链接特征值的过程，可通过另一个哈希算法，或设置为不同参数的同一哈希算法，生成另一个哈希值。此哈希值本身，或哈希值+时间戳和/或uid，可作为加密秘钥，用于云上附加部分的加密/解密。

对于所有待处理的文件即待拆分文件，终端设备对文件进行拆分，得到核心部分和附加部分后，可以采用上述方式中生成每个待拆分文件对应的链接特征值。

在设备空闲，wifi可用或网络流量充足时，设备将文件附加部分上传到云上，同时云服务器更新映射表。该映射表维护了链接特征值和附加部分存储位置信息的对应关系，例如，在表中添加一项纪录：【链接特征值→对应附加部分的实际存储位置/url】。在需要时，云上附加部分的实际存储位置可以发生变化，在调整附加部分实际存储位置的同时，云端服务器更新映射表，将链接特征值对应的实际存储位置或url更新为调整后的值，保证始终可以使用链接特征值+映射表，找到附加部分实际存储位置。其中，存储于云上的附加部分可以为使用上述加密密钥进行加密后的附加部分。

用户在需要对终端设备上已被拆分的文件进行操作处理时，如图12所示，例如需要在终端上点击/打开已被拆分上传的文件时，终端设备可以立刻展示文件的核心部分，如果网络状态允许，如wifi可用或剩余流量充足，终端设备可以将文件对应的链接特征值上传到云端服务器上，云端服务器通过检索映射表，获取文件对应附加部分的实际存储位置/url，得到文件的附加部分，云端服务器将文件附加部分传回终端设备。终端设备接收到文件的附加部分后，如果附加部分被加密，则设备将其解密(可以云端解密后发给终端，也可以终端收到后解密)，终端设备将核心部分与附加部分/解密后的附加部分合并获得完整原始文件并展示，如图11中所示。其中，图11中的设备是指终端设备，云是指云端服务器。

如果网络状况中等(网速受限，剩余流量不很充足)，云端服务器也可以返回附加部分中的一部分，而非完整附加部分。终端设备将部分附加部分与核心部分合并后，可生成中等质量的文件并展示。具体返回附加部分的比例，可以由网络状况与文件内容决定。在实际应用中，在不造成明显使用延迟的情况下/在合理适当的流量范围内，可以尽量多的下载附加部分，以尽可能提高所展示的文件的质量。

作为一个示例，图13中示出了一种简便的节约流量的文件分享方法的原理示意图，发送方用户发送文件的核心部分，接收方用户可以直接预览其内容，并按需自行下载附加部分得到完整文件。如图13中所示，用户a发送文件给用户b，用户a本地存储有该文件的核心部分，用户a将该核心部分发送给用户b，同时可以将链接特征值发送给用户b，用户b接收到用户a发送的核心部分后，可以直接预览核心部分的内容，并可以按需自行根据链接特征值自动获取附加部分，并和核心部分合并得到原始文件，即重建原始文件。

作为一个示例，图14a示出了一种文件分享方法的流程示意图。基于该方法，用户a可以向用户发送缩略版文件。当发送用户终端接收到用户a通过应用程序(app，application)向接收用户b发送文件的指令时，如接收到用户a的“发送某文件到b”的指令，如果用户a未指明发送完整/原始文件，可以按照当前app管理，默认发送缩略后的文件。

具体的，用户终端设备可以将文件的核心部分质量与app默认质量进行对比。以使用某通信应用分享图片为例，该应用默认将过大的图片压缩到约100kb，可认为该应用分享图片的默认尺寸为100kb。

如核心部分质量高于app默认质量，将核心部分压缩至app默认质量，发送给接收用户。如核心部分质量低于app默认质量(本地核心部分过小，质量过低)，可以直接发送，也可以使用核心部分对应的链接特征值，从云上获取对应的附加部分中的一部分，使得核心部分+部分附加部分可合并得到相当于app默认质量的文件，其中，可以根据app默认质量确定需要从云上获取多少附加部分。得到合并后的文件后，可以将合并后文件直接发送，也可以将合并后的文件随机翻转部分比特(以保护核心部分信息)后，再发送至接收用户。采用该方式，接收用户b能够接收到小尺寸/低质量的文件。如果后续发送用户想要将完整文件发送给接收用户，发送用户终端在接收到用户a发送给用户b的指令后，可以将该文件的链接特征值发送给接收用户，接收用户可以使用该链接特征值自动获取云端的附加部分，和核心部分合并得到原始文件。

可以理解的是，将合并后的文件随机翻转部分比特后再发送时，接收用户仍然可以使用该文件，即翻转处理后的文件不影响接收用户使用，如文件为图片时，仍然可以看到图片中的内容，只是通过翻转处理后，可以避免接收方能够基于接收到的文件得到原始文件，通过该方式，发送用户可以实现对其所发送文件的权限控制。

对比现有方法，发送用户不需要任何额外操作，当核心部分质量高于app默认质量时，发送动作所消耗的流量与现有方法一致；当核心部分质量低于app默认质量时，如果直接发送核心部分，则发送动作消耗的流量小于现有方法。接收用户体验也得到了提高，接收用户无需等待过长时间接收完整文件，可以快速的接收并浏览核心部分。

图14b示出了另一种文件分享方法的流程示意图。基于该方法，当发送用户终端接收到用户a向接收用户b发送文件的指令，且发送用户指明发送完整/原始文件时，如接收到用户a的“发送某完整/原始文件到b”的指令，终端将核心部分，及其对应的加密秘钥(如果对附加部分进行了加密处理)和链接特征值，一并发送到接收用户。接收用户基于接收到的核心部分，可直接预览核心部分，获取关于此文件的信息。接收用户可随时使用核心部分对应的链接特征值，从云上获取对应的完整附加部分，将附加部分与核心部分合并，得到完整/原始文件，若附加部分经过了加密处理，则可以使用加密密钥对其进行加密后与核心部分合并得到完整/原始文件。

基于该方式，发送用户在需要将完整/原始文件发送给接收用户时，将文件的核心部分及链接特征值等信息发送给接收用户，接收用户收到的是小尺寸/低质量的文件，并可随时获取完整/原始文件，即可基于接收到的信息得到完整文件，与现有需要直接将整个文件发送给接收用户的方式相比，发送动作所消耗的流量对比现有方法有明显降低(只需发送核心部分即可)。接收用户体验也得到了提高，接收用户无需等待过长时间接收完整文件，可以快速的接收并浏览核心部分。

作为一个示例，图15中示出了一种文件内容验证方法的原理示意图。如图15中所示，本地设备将文件拆分为核心部分和附加部分，针对附加部分，可以基于核心部分的内容对附加部分进行加密后上传至云端(该示例中其它设备为云端服务器)，而加密的附加部分的内容则可以用于验证本地的核心部分的内容是否发生改变。

作为一个具体示例，图16中示出了对需要进行真实性验证的文件的一种处理方法的流程示意图。待验证文件可以为图片、音频、视频等。如图16中所示，将文件内容实时拆分为较大的核心部分和很小的附加部分，并将附加部分实时上传到云上，云上附加部分可用于验证本地核心部分的内容进行内容真实性验证。在文件产生时，基于文件的频域特征和/或数据位特征对文件进行拆分。具体的，对于录音文件，由于录音具有时间持续性，随着文件的产生，终端设备可以按时间滑动窗对其进行切片，对每个切片实时处理。对于视频文件，可以随着文件的产生，逐帧进行处理，当然，也可以通过设置时间滑动窗，每次对时间滑动窗对应的一段时长内的图像帧进行处理，还可以设置每次处理的帧数，每次对固定帧数的图像帧进行处理。对于图片，可以直接对每张图片进行处理。

终端设备对每个切片/每帧图片本身，可以基于频域特征和/或数据位特征进行拆分。图中所示的频域元素的矩阵和数据位的具体含义可参见前文对待拆分文件进行拆分得到子文件的示例中的描述，根据图16，可以对文件拆分得到低频高位分量部分作为核心部分，拆分得到高频部分和低频低位分量部分作为附加部分。

在一可选实施方式中，本示例中，在拆分操作中，目标拆分比例中的控制量r1和控制量r2均可以设定为接近于1。采用该目标拆分比例，可以使文件的主体内容均被拆分到核心部分，终端本地保存了几乎相当于原始记录的信息内容(即原始内容)，可最大程度的保证文件的安全；同时，由于附加部分很小(非常小的高频分量部分和低频低位分量部分)，将划分后的附加部分对应的子文件上传至其他设备(如图中所示的云端服务器)时，整个过程不会产生太大的流量开销。

在按频率分量即基于频域特征进行拆分时，由于r1很接近于1，绝大部分文件内容会被划归到低频分量部分，很小一部分文件内容被划归到高频分量部分。对于低频分量部分进行进一步处理时，由于r2很接近于1，绝大部分数据位会被划归到低频高位分量部分，很小一部分数据位被规划到低频低位分量部分。

完成划分后，可以使用低频高位分量部分(核心部分)计算哈希值，并用此哈希值对高频部分+低频低位分量部分(附加部分)进行加密。将加密后的高频部分+低频低位分量部分(加密的附加部分)上传到云上，并加上时间戳。

对于音频和视频，以上过程可以在文件产生过程中实时处理；对于照片即图片，在拍摄后可以立刻处理。

哈希算法和加密算法的特性保证了，只有未修改的核心部分，才能对加密的附加部分进行解密，也就是说，当对附加部分解密成功时，可以证明本地核心部分的未修改性，即未被篡改。同时，云上的附加部分带有服务器时间戳，此信息很难被篡改，可以证明文件的真实产生时间。

在实际应用中，在iot(internetofthings，物联网)等场景，随着各种智能家居的普及，需要多设备协同工作场景越发常见。很多情景下，同一个文件内容会被多个设备使用。例如：用户经常会使用iot设备发出指令：“在智能电视上展示上次聚会的视频”，“在智能音箱上播放我昨天录的歌曲”等等。而如果采用在所有可能使用文件的设备上保存一份副本，会大大造成存储空间的浪费。而如所有设备从同一个云存储上获取文件内容，又会大大降低文件加载速度，同时产生隐私泄露风险。

本示例中所提供的多设备协同方法的核心思想是，属于同一个用户/同一个系统的智能终端，可以各自存储所需文件的核心部分，而文件的附加部分可以存储于云端服务器中，各智能终端设备在需要时从云上获取附加部分。因此能够使iot等场景中各设备能够高效安全的存储数据，并在能够快速使用数据(在从云端下载附加部分时可先展示核心部分)。

图17中示出了一具体示例中多设备协同方法的流程示意图。如17图中所示，用户用语音发出指令，如“在电视上播放上次旅行的照片/视频”的语音指令，接收到语音指令的设备使用asr(automaticspeechrecognition，自动语音识别技术)+nlu(naturallanguageunderstanding，自然语言理解)技术理解指令意图，包括动作，目标内容，目标设备等。当然，用户也可以用其他方式发出同等效果的指令。

目标设备接收处理后的指令，检查自身存储是否包含目标内容的核心部分。如果包括，立刻展示核心部分，同时从云上获取附加部分，如果附加部分经过加密处理，则可以对附加部分进行解密，与核心部分合并为完整/原始文件并展示。如不包括，则搜索所有相关设备，试图在相关设备上搜索目标内容的核心部分。相关设备包括但不限于：注册为同一用户id的设备，处于同一wifi内的设备，相互之间连接的设备等。如果在相关设备中找到核心部分，目标设备从相关设备获取核心部分，存储核心部分，并立刻展示核心部分，同时，目标设备从云上获取附加部分，如果附加部分经过加密处理，则可以对附加部分进行解密，与核心部分合并为完整/原始文件并展示。

若未在相关设备中搜索到核心部分，则可以提示用户：未找到对应内容等。

针对iot/多设备协同环境，可进一步的优化对文件的删除/编辑等操作。一种实现方法是，在云上映射表中维护一系列反向链接。反向链接指向所有属于同一用户/同一系统的本地智能终端中所存储的同一文件核心部分。对于每个文件，首次上传附加部分时，在云上创建指向核心部分的反向链接；其他设备转存此核心部分时，通知云服务器添加对应的反向链接。通过反向链接，可以找到系统中同一文件的所有本地核心部分。

用户删除文件时，可选择只删除本终端存储的该文件，删除某几个或所有终端存储的该文件。对于只删除本终端的情况，接收指令的终端设备向云服务器发送请求，移除指向自己的反向链接，并删除自身所存储的核心部分；对于删除某几个或所有终端的情况，接收指令的终端向云服务器发送请求，云服务器根据反向链接，向所选的几个或所有终端发出删除指令，对应的几个或所有的终端删除该文件的本地核心部分，云端服务器移除对应的反向链接；如果所有终端均删除了本地部分/云服务器反向链接数为零，云服务器可以移除自身所存储的附加部分。

用户编辑文件时，可选择只编辑本终端中的文件或同步编辑多个设备中的文件。对于前者，终端从云服务器获取附加部分，合成完整文件，此文件被编辑后，视为一个新文件，对该新文件进行拆分上传等处理。

对于后者(同步编辑)，终端可以从云服务器获取附加部分和反向链接，在本地合成完整文件，在用户编辑后，终端拆分文件并上传附加部分以更新云服务器存储的附加部分，云端服务器根据所获取的对应的反向链接将更新后的核心部分发送至其他设备，以更新其他设备上的核心部分。

另一种可能的同步编辑方法为，用户在终端本地存储的核心部分上进行编辑，终端将修改内容/编辑步骤上传至云端服务器，云端服务器根据核心部分修改内容/编辑步骤，对对应的附加部分进行对应的编辑，将其修改为同样的效果，之后，根据对应的反向链接，向其他设备发送相应的修改内容/编辑步骤，以使其他设备更新其他设备上的核心部分。

现有技术中通过云端服务器存储文件的方案，便于用户将终端设备中的文件上传到云上，释放设备存储空间，在有网络连接时，用户可随时访问/下载文件内容。

但是现有的文件存储方案存在下述问题：

1)现有技术无法确保云端服务器存储文件中隐私内容的安全性。

存储在云端服务器的用户文件内容有多种泄露的可能性，对用户隐私造成严重威胁。

2)当前在云端存储文件需要强烈依赖于网络，用户使用不方便。

当用户的文件只存储在云上，而网络连接受限/不可用时(如用户位于飞机/高铁等无网络连接的场景，或者用户终端设备移动网络流量不足/流量费用较高等)，用户无法正常访问文件内容。

3)当前在云端存储文件对用户产生额外管理负担，使用繁琐。

如果用户的文件非常多，用户需记住每个文件的存储位置(本地/云存储服务a/云存储服务b等)，用户操作非常繁琐。

4)用户需要手动进行本地/云上文件管理，使用繁琐。

在某些情况下，用户需预先下载计划使用的文件内容，以供无网络情况下使用，或用户需手动上传部分文件，以释放存储。

例如，用户希望在飞机上观看某段视频，而这段视频只存储在云上，则用户需提前下载好此文件，如忘记下载，则无法观看视频。

又如，终端设备存储空间不足，而用户即将出国旅行，用户需手动选择并上传部分文件，为旅行照片/视频留出足够存储空间，如忘记处理，则在旅行中可能面临存储不足的情况。

5)当前云存储技术只能作为存储扩展，并没有内容验证功能。

在特定情况下，用户可能希望证明通过终端设备所记录的内容是真实未修改的。例如，交通事故后，记录现场状况的照片/视频，或重要谈话的录音等，当前云存储技术无法满足此需求。

6)基于当前云存储技术，用户分享文件操作繁琐或消耗较多流量。

当用户希望分享云端存储的文件时，需要打开对应的管理网页/app，获取文件对应的url或分享码，将其发送给目标用户。接收文件用户需要进行后续操作才可获取文件内容。

当用户希望分享本地文件时，需要向接收文件用户传送整个文件，如果使用移动网络时，会消耗较多流量。

7)当前云存储技术不使用多设备协同工作场景。

在iot场景中，如在所有可能使用文件的设备上保存一份副本，会造成存储空间的浪费。如所有设备从同一个云存储上获取文件内容，会降低文件加载速度，同时产生隐私泄露风险。

综上，面对数字文件内容的迅速增长和有限的设备存储空间，用户面临着隐私泄露，网络依赖，文件管理繁琐等多种问题，导致用户难以安全简便的存储和使用大量文件，对用户使用终端设备造成了很大的不便。

针对以上现有技术的问题，本申请提出了一种安全、网络依赖低和管理简便灵活的云存储解决方案，极大提升了云存储安全性；降低了云存储对网络连接的依赖；免除了云存储带来的额外繁琐用户操作；极大减小了终端设备存储有限对用户的困扰；同时也带来了其他便利性提升，如自动管理终端文件/存储空间；允许用户在无额外操作的情况下省流量分享文件；提高多设备协同场景下的存储效率和安全性。具体的：

1)针对当前云存储文件隐私内容的安全性和云存储文件强烈依赖于网络的问题，本申请提出了一种基于文件内容拆分的云存储方法。其核心思想是，将文件拆分成至少两部分，如只包含内容信息主体的核心部分和只包含内容信息细节的附加部分。文件的各部分(即各子文件)分别存储在至少两个设备中，如将核心部分保存于设备本地，将附加部分保存于云端服务器。由此，云端存储的内容不包含内容信息主体，即使泄露，也不会对用户隐私产生影响。本地存储的内容已包含内容信息主体，当与云上附加部分合并时，可还原原始内容；核心部分也可以独立使用，等效于原始内容的低质量版本。

通过上述方案，可以实现极高的隐私安全性，同时允许文件内容可以在没有网络连接的情况下被使用，使用户终端设备的存储能力被极大扩展，提升了用户使用文件的方便性。

2)针对当前云存储对用户产生额外管理负担，使用繁琐的问题，本申请提出了一种核心部分-附加部分自动链接的方法。其核心思想是，由核心部分内容计算出一个唯一特征值(称为链接特征值)，在云上维护一个映射表，记录每个链接特征值对应的附加部分存储位置。

由此，用户可以通过统一界面使用本地核心部分，用户可以像使用本地文件一样使用所有云上内容，极大降低用户文件管理难度；终端设备可以自动找到云端存储的附加部分，并视网络情况下载部分或全部附加部分，极大简化了用户操作。

3)针对用户需要手动进行本地/云上文件管理，使用繁琐的问题，本申请提出了一种基于用户事件预测的自动存储管理方法。其核心思想是，预测用户将要/计划进行的事件，基于事件特性，本地存储空间和各文件特性，自动调整各个文件本地/云上存储比例。从而可以使用户总有足够的可用存储空间，且将用户将要使用的文件更多的存储在终端设备本地，保证了用户将要使用的文件的可用性，使用户可以无负担的获取更好的文件管理体验。

4)针对当前云存储只能作为存储扩展，没有内容验证功能的问题，本申请提出了基于拆分式安全云的内容验证方法。其核心思想是，将文件内容实时拆分为较大的核心部分和很小的附加部分，并将附加部分实时上传到云端，云端存储的附加部分可用于验证本地核心部分。从而实现了网络负载很低的内容验证，使用户的内容验证需求得到满足。

5)针对当前云存储技术下，用户分享文件操作繁琐或消耗较多流量的问题，本申请提出了一种简便的节约流量文件分享方法。其核心思想是，发送方用户发送文件的核心部分，接收方用户可以直接预览其内容，并按需自行下载完整文件，使发送和接收双方均可以在无需额外操作的情况下，实现省流量文件分享，从而简化了发送和接收双方的操作，并节约了双方的流量消耗。

6)针对当前云存储技术不适应多设备协同工作场景的问题，本申请提出了基于拆分式安全云的多设备协同方法。其核心思想是，属于同一个用户/同一个系统的终端设备，各自存储所需文件的核心部分，并在需要时从云端获取附加部分，兼顾了存储效率、响应速度和隐私安全。

此外现有技术中，若用户需要将文件送给接收方用户，则需要在固定的专门网页/软件/app中进行发送；发送原始文件会消耗双方较多的数据流量，发送效率较低；应用对应的云端服务器还需要保存原始文件副本，产生额外服务器负担；文件也可能具有时效性，如果接收方没有及时下载原始文件，云端服务器存储的原始文件可能会过期失效；接收用户必须一次性在同一界面上接收整个文件。

本申请技术方案中，文件拆分得到的各子文件可以通过多种渠道进行传输，且接收文件的用户可以将子文件存储在本地，并在之后不通过任何专门网页/软件/app，可以自由下载其他子文件，合并得到完整文件；当发送用户发送完整文件给接收方时，不需要消耗完整文件的流量，只需要消耗发送子文件的流量；云端服务器只需要保存文件的附加部分，服务器负担较小；接收方可以随时根据链接特征值从云端下载附加部分，不存在过期失效的问题；接收用户可以先接收核心部分，再获取附加部分，无需一次性在同一界面上接收整个文件。

基于与图1中所示的文件处理方法相同的原理，本申请实施例还提供了一种文件处理装置，如图18所示，该文件处理装置110可以包括操作请求接收模块111和文件处理模块112。

操作请求接收模块111，用于接收针对文件的操作请求，文件包括至少两个子文件，至少两个子文件分别存储于至少两个设备中；

文件处理模块112，用于根据操作请求对文件的至少一个子文件进行相应处理。

可以理解的是，本申请实施例的文件处理装置的各模块，可以具有实现本申请实施例所示的文件处理方法中的相应步骤的功能。其中，该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。上述各模块可以是软件和/或硬件，各模块可以单独实现，也可以多个模块集成实现。对于文件处理装置的各模块的功能描述具体可以参见上述文件处理方法中的相应描述，在此不再赘述。

此外，本申请实施例的文件处理装置的各功能模块，在实际应用中，可以根据实际应用场景，运行于智能终端即终端设备和/或服务器。

本申请实施例提供了一种电子设备，如图19所示，图19所示的电子设备2000包括处理器2001和存储器2003。其中，处理器2001和存储器2004相连，如通过总线2002相连。可选的，电子设备2000还可以包括收发器2004。需要说明的是，实际应用中收发器2004不限于一个，该电子设备2000的结构并不构成对本申请实施例的限定。

其中，处理器2001应用于本申请实施例中，用于实现图18中所示的文件处理装置各模块的功能。收发器2004包括接收机和发射机，收发器2004应用于本申请实施例中，用于实现电子设备2000与其他设备之间的通信，实现数据的接收和发送。

处理器2001可以是cpu，通用处理器，dsp，asic，fpga或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器2001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，dsp和微处理器的组合等。

总线2002可包括一通路，在上述组件之间传送信息。总线2002可以是pci总线或eisa总线等。总线2002可以分为地址总线、数据总线、控制总线等。为便于表示，图19中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器2003可以是rom或可存储静态信息和指令的其他类型的静态存储设备，ram或者可存储信息和指令的其他类型的动态存储设备，也可以是eeprom、cd-rom或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

可选的，存储器2003用于存储执行本申请方案的应用程序代码，并由处理器2001来控制执行。处理器2001用于执行存储器2003中存储的应用程序代码，以实现本申请实施例提供的装置的动作。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现本申请任一实施例中所示的文件处理方法。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。