一种文件处理方法及移动终端
本申请要求于2017年6月16日提交中国专利局、申请号为201710459557.5、发明名称为“一种图片管理应用中的回收站自恢复方法和设备”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本申请涉及终端应用领域,尤其涉及一种文件处理方法及移动终端。
背景技术
随着智能手机的普及,以及智能手机拍照功能的逐渐强大,越来越多的用户将智能手机作为摄影工具使用,并将智能手机作为相片以及视频的存储介质,因此手机上往往存储了大量的相片和视频,而用户在清理相片或在执行其他操作时很可能会将一些重要的相片误删掉。对于一般的手机而言,相片从相册中删除后,相片就会被彻底删除,用户无法找回。
为了避免用户由于误删而导致相片永久丢失,一些手机增加了回收站功能,用户删除的图片以及视频会被移到回收站中,相片或视频移到回收站一段时间才后会被清除,而在此期间用户可以将回收站中的相片或视频恢复到原相册中。
发明内容
本申请实施例提供了一种文件处理方法和移动终端,用于在应用数据被清除后,在回收站界面中显示多媒体文件,使得用户可以在回收站界面中对多媒体文件进行彻底删除或恢复,提升用户体验。
有鉴于此,本申请第一方面提供了一种文件处理方法,该方法包括:
用户在移动终端上输入第一操作,响应于第一操作,移动终端在第一应用的第一界面显示第一文件;用户在第一界面上输入第二操作,响应于第二操作,移动终端在第一应用的第一界面不显示第一文件,在回收站界面显示第一文件。
移动终端将第一应用的第一数据表删除,第一文件由于第一数据表的删除而在第一应用的回收站界面中对用户不可见,即,移动终端在无法在回收站界面中显示第一文件。
移动终端删除第一数据表后,用户在移动终端上输入第三操作,响应于第三操作,移动终端生成第二数据表,第一文件由于第二数据表的删除而在第一应用的回收站界面中对用户可见,即,移动终端可以在回收站界面中显示第一文件。
其中,第一数据表和第二数据表指的是回收站数据表,用于记录属于回收站的文件的元数据,第一应用基于回收站数据表实现属于回收站的文件的显示。第一数据表是移动终端中原先存有的,第二数据表是在第一数据被删除后生成的,两个数据表记录的元数据类型可以相同,也可以不同。
本实施例中,移动终端回收站数据表被删除后,可以重新生成回收站数据表,从而在
应用数据被清除后,移动终端也可以在回收站界面中显示第一文件,使得用户可以在回收站界面中对第一文件进行彻底删除或恢复,提升用户体验。
结合本申请第一方面,在本申请第一方面的第一种实现方式中,在移动终端获取用户在第一界面输入的第二操作之前,第一文件属于第一应用的第一相册;在移动终端获取用户在第一界面输入的第二操作之后,第一文件属于第一应用的回收站相册;
移动终端在回收站界面中显示第一文件之后,用户在该回收站界面中输入第四操作对第一文件进行恢复,移动终端响应于第四操作,将第一文件所属的相册从回收站相册更改为第一相册,移动终端可以在第一相册对应的界面中显示第一文件。
本实施例中,应用数据被清除后,用户可以在回收站界面中将第一文件恢复到原相册进行显示,提高了方案的灵活性。
结合本申请第一方面,在本申请第一方面的第二种实现方式中,在移动终端获取用户在第一界面输入的第二操作之前,第一文件属于第一应用的第一相册;在移动终端获取用户在第一界面输入的第二操作之后,第一文件属于第一应用的回收站相册;
移动终端在回收站界面中显示第一文件之后,用户在该回收站界面中输入第四操作对第一文件进行恢复,移动终端响应于第四操作,将第一文件所属的相册从回收站相册更改为目标相册,移动终端可以在目标相册对应的界面中显示第一文件。
其中,目标相册指的是系统或用户指定的一个相册,用于用户管理从回收站显示界面中恢复的多媒体文件。
本实施例中,应用数据被清除后,用户可以在回收站界面中将第一文件恢复到系统指定相册进行显示,提高了方案的灵活性。
结合本申请第一方面,在本申请第一方面的第三种实现方式中,移动终端生成第二数据表之后会在第一应用的回收站界面中显示第一文件,用户在回收站界面中输入第五操作以将第一文件彻底删除,移动终端响应于该操作,将第一文件彻底删除,即将第一文件从移动终端中删除,彻底删除后移动终端中不再存储有第一文件。
本实施例中,应用数据被清除后,用户可以将第一文件彻底删除,以释放存储空间,提升了用户体验。
结合本申请第一方面,在本申请第一方面的第四种实现方式中,移动终端生成第二数据表之后会在第一应用的回收站界面中显示第一文件,用户在回收站界面中输入第六操作以查看第一文件的元数据,响应于该操作,移动终端显示第一文件的元数据,其中,该元数据可以包括如下至少一项:第一文件的原文件名称,第一文件的原文件标识,第一文件的删除时间,第一文件存储的原存储路径,第一文件的当前存储路径,第一文件的拍摄时间,第一文件的图片方向,第一文件的云端全局唯一标识符,第一文件的哈希值,第一文件原所属相册的云端识别码。
其中,原文件名称指的是在移动终端获取第二操作之前第一文件的文件名称;原文件标识指的是在移动终端获取第二操作之前第一文件在对应数据表中的标识;原存储路径指的是在移动终端获取第二操作之前第一文件的存储路径;当前存储路径指的是在移动终端获取第六操作时第一文件的存储路径;原所属相册指的是在移动终端获取第二操作之前第
一文件所属的相册。
本实施例中,应用数据被清除后,用户可以在回收站界面中查看第一文件的元数据,以了解第一文件的详细信息,提升了用户体验。
结合本申请第一方面,第一方面的第一至第四种实现方式中的任意一种实现方式,在本申请第一方面的第五种实现方式中,移动终端响应于第三操作还可以执行如下流程:
移动终端不在第一应用的回收站界面显示云端服务中存储的与第一文件相同的文件。
本实施例中,移动终端不会回收站界面显示与第一文件相同的文件,避免了重复显示,提升用户体验。
结合本申请第一方面,第一方面的第一至第五种实现方式中的任意一种实现方式,在本申请第一方面的第六种实现方式中,移动终端生成第二数据表之后可以显示选择界面,用户在该选择界面上输入第七操作以选择需要在回收站界面中显示的文件,响应于该操作,移动终端在第一应用的回收站界面中显示用户选择的第一文件,而对于用户未选择的文件,移动终端可以将这些文件彻底删除。
本实施例中,应用数据清除后,移动终端可以根据用户的选择决定要在恢复到回收站中进行显示的文件,提高了方案的灵活性。
结合本申请第一方面,第一方面的第一至第六种实现方式中的任意一种实现方式,在本申请第一方面的第七种实现方式中,移动终端响应于第二操作还可以执行如下流程:
移动终端将第一文件的存储位置从第一目录更改为第二目录,并将第一文件的文件名称从第一命名更改为第二命名,其中,第二目录用于存储第一应用的回收站界面中显示的文件。移动终端第一文件的存储位置从第一目录更改为第二目录后,移动终端即可实现在回收站界面中显示第一文件。
本实施例提供了一种实现移动终端在回收站界面显示第一文件的具体方式,提高了方案的可实现性。
结合本申请第一方面的第七种实现方式,在本申请第一方面的第八种实现方式中,第二命名为通过预设编码方式对第一文件的元数据进行编码得到的目标字符串。
本实施例提供了一种移动终端可以将第一文件的元数据通过预设编码方式存储在第二命名中,提供了一种在移动终端获取删除指令后,对元数据进行存储的方式,提高了方案的可实现性。
结合本申请第一方面的第八种实现方式,在本申请第一方面的第九种实现方式中,移动终端具体可以通过如下方式生成第二数据表:
移动终端通过预设编码方式对第二命名进行解码得到第一文件的元数据,根据解码得到的元数据生成第二数据表。
本实施例提供了一种生成第二数据表的方式,提高了方案的可实现性。
结合本申请第一方面的第七种实现方式,在本申请第一方面的第十种实现方式中,第二命名为第一文件的删除时间;
则移动终端将第一文件的存储位置从第一目录更改为第二目录的过程中,移动终端还执行如下流程:
通过预设编码方式对第一文件的元数据进行编码得到目标字符串,并将目标字符串以及第一文件的删除时间对应存储在第二目录的二进制文件中。
本实施例提供了另一种在移动终端获取删除指令后,对元数据进行存储的方式,提高了方案的灵活性。
结合本申请第一方面的第十种实现方式,在本申请第一方面的第十一种实现方式中,移动终端可以通过如下方式生成第二数据表:
根据第二命名确定第一文件的删除时间,确定该二进制文件中与该删除时间对应的目标字符串,通过预设编码方式对目标字符串进行解码得到第一文件的元数据,再根据解码得到的元数据生成第二数据表。
本实施例提供了另一种生成第二数据表的方式,提高了方案的灵活性。
结合本申请第一方面,第一方面的第一至第六种实现方式,在本申请第一方面的第十二种实现方式中,移动终端将第一数据表删除之前可以对第一数据表进行备份,得到第三数据表;在第一数据表删除后,移动终端根据该第三数据表生成第二数据表。
本实施例提供了另一种生成第二数据表的方式,提高了方案的灵活性。
本申请第二方面提供了一种移动终端,该移动终端包括:触摸屏,其中,所述触摸屏包括触敏表面和显示器;一个或多个处理器;存储器;多个应用程序;以及一个或多个计算机程序,其中所述一个或多个计算机程序被存储在所述存储器中,所述一个或多个计算机程序包括指令,当所述指令被所述移动终端执行时,使得所述移动终端执行以下步骤:
获取用户输入的第一操作,响应于第一操作,在第一应用的第一界面显示第一文件;获取用户在第一界面上输入的第二操作,响应于第二操作,在第一应用的第一界面不显示第一文件,在回收站界面显示第一文件。
将第一应用的第一数据表删除,第一文件由于第一数据表的删除而在第一应用的回收站界面中对用户不可见,即,无法在回收站界面中显示第一文件。
删除第一数据表后,获取用户输入的第三操作,响应于第三操作,生成第二数据表,第一文件由于第二数据表的删除而在第一应用的回收站界面中对用户可见,即,可以在回收站界面中显示第一文件。
其中,第一数据表和第二数据表指的是回收站数据表,用于记录属于回收站的文件的元数据,第一应用基于回收站数据表实现属于回收站的文件的显示。第一数据表是移动终端中原先存有的,第二数据表是在第一数据被删除后生成的,两个数据表记录的元数据类型可以相同,也可以不同。
结合本申请第二方面,在本申请第二方面的第一种实现方式中,在获取用户在第一界面输入的第二操作之前,第一文件属于第一应用的第一相册;在获取用户在第一界面输入的第二操作之后,第一文件属于第一应用的回收站相册;
移动终端在生成第二数据表之后,还执行如下步骤:
在回收站界面中显示第一文件获取用户在该回收站界面中输入对第一文件进行恢复的第四操作,响应于第四操作,将第一文件所属的相册从回收站相册更改为目标相册,在目标相册对应的界面中显示第一文件。
其中,目标相册指的是系统或用户指定的一个相册,用于用户管理从回收站显示界面中恢复的多媒体文件。
结合本申请第二方面,在本申请第二方面的第二种实现方式中,在获取用户在第一界面输入的第二操作之前,第一文件属于第一应用的第一相册;在获取用户在第一界面输入的第二操作之后,第一文件属于第一应用的回收站相册;
移动终端在生成第二数据表之后,还执行如下步骤:
在回收站界面显示第一文件;
获取用户在该回收站界面中输入对第一文件进行恢复的第四操作,响应于第四操作,将第一文件所属的相册从回收站相册更改为第一相册,在第一相册对应的界面中显示第一文件。
结合本申请第二方面,在本申请第二方面的第三种实现方式中,移动终端在生成第二数据表之后,还执行如下步骤:
在第一应用的回收站界面中显示第一文件;
获取用户在回收站界面中输入的将第一文件彻底删除的第五操作,响应于第五操作,将第一文件彻底删除,即将第一文件从移动终端中删除,彻底删除后移动终端中不再存储有第一文件。
结合本申请第二方面,在本申请第二方面的第四种实现方式中,移动终端在生成第二数据表之后,还执行如下流程:
在第一应用的回收站界面中显示第一文件;
获取用户在回收站界面中输入的查看第一文件的元数据的第六操作,响应于第六操作,显示第一文件的元数据,其中,元数据可以包括如下至少一项:第一文件的原文件名称,第一文件的原文件标识,第一文件的删除时间,第一文件存储的原存储路径,第一文件的当前存储路径,第一文件的拍摄时间,第一文件的图片方向,第一文件的云端全局唯一标识符,第一文件的哈希值,第一文件原所属相册的云端识别码。
其中,原文件名称指的是在处理器获取第二操作之前第一文件的文件名称;原文件标识指的是在处理器获取第二操作之前第一文件在对应数据表中的标识;原存储路径指的是在处理器获取第二操作之前第一文件的存储路径;当前存储路径指的是在处理器获取第六操作时第一文件的存储路径;原所属相册指的是在处理器获取第二操作之前第一文件所属的相册。
结合本申请第二方面,第二方面的第一至第四种实现方式中的任意一种实现方式,在本申请第二方面的第五种实现方式中,移动终端还可以执行如下步骤:
不在第一应用的回收站界面显示云端服务中存储的与第一文件相同的文件。
结合本申请第二方面,第二方面的第一至第五种实现方式中的任意一种实现方式,在本申请第二方面的第六种实现方式中,移动终端生成第二数据表之后,还可以执行如下步骤:
显示选择界面;
获取用户在选择界面中输入的第七操作,响应于第七操作,在第一应用的回收站界面
中显示用户选择的第一文件,而对于用户未选择的文件,可以将这些文件彻底删除。
结合本申请第二方面,第二方面的第一至第六种实现方式中的任意一种实现方式,在本申请第二方面的第七种实现方式中,处理器响应于第二操作,还可以执行如下流程:
将第一文件的存储位置从第一目录更改为第二目录,并将第一文件的文件名称从第一命名更改为第二命名,其中,第二目录用于存储第一应用的回收站界面中显示的文件。移动终端第一文件的存储位置从第一目录更改为第二目录后,即可在回收站界面中显示第一文件。
结合本申请第二方面的第七种实现方式,在本申请第二方面的第八种实现方式中,第二命名为通过预设编码方式对第一文件的元数据进行编码得到的目标字符串。
结合本申请第二方面的第八种实现方式,在本申请第二方面的第九种实现方式中,移动终端可以通过如下方式生成第二数据表:
通过预设编码方式对第二命名进行解码得到第一文件的元数据,根据解码得到的元数据生成第二数据表。
结合本申请第二方面的第七种实现方式,在本申请第二方面的第十种实现方式中,第二命名为第一文件的删除时间;
移动终端还执行如下步骤:
通过预设编码方式对第一文件的元数据进行编码得到目标字符串,并将目标字符串以及第一文件的删除时间对应存储在第二目录的二进制文件中。
结合本申请第二方面的第十种实现方式,在本申请第二方面的第十一种实现方式中,处理器可以通过如下方式生成第二数据表:
根据第二命名确定第一文件的删除时间,确定该二进制文件中与该删除时间对应的目标字符串,通过预设编码方式对目标字符串进行解码得到第一文件的元数据,再根据解码得到的元数据生成第二数据表。
结合本申请第二方面,第二方面的第一至第六种实现方式,在本申请第二方面的第十二种实现方式中,移动终端将第一数据表删除之前可以对第一数据表进行备份,得到第三数据表;在第一数据表删除后,移动终端根据该第三数据表生成第二数据表。
本申请第三方面提供了一种移动终端,该移动终端包括:
显示模块,用于响应第一操作,在第一应用的第一界面显示第一文件;
获取模块,还用于获取用户在第一界面输入的第二操作;
显示模块,还用于响应第二操作,在第一应用的回收站界面显示第一文件;
删除模块,用于将第一数据表删除,第一文件因为第一数据表的删除而在第一应用的回收站界面中对用户不可见;
获取模块,还用于获取用户输入的第三操作;
生成模块,用于响应第三操作,生成第二数据表,第一文件因为第二数据表而在第一应用的回收站界面中对用户可见。
结合本申请第三方面,在本申请第三方面的第一种实现方式中,在获取模块获取第二操作之前,第一文件属于第一应用的第一相册;在获取模块获取第二操作会后,第一文件
属于第一应用的回收站相册;
在生成模块生成第二数据表之后:
显示模块,还用于在第一应用的回收站界面中显示第一文件;
获取模块,还用于获取用户在回收站界面输入的第四操作;
显示模块,还用于响应于第四操作,在第一应用的第一相册对应的界面中显示第一文件;
在获取模块获取第四操作后,第一文件属于第一应用的第一相册。
结合本申请第三方面,在本申请第三方面的第二种实现方式中,在获取模块获取第二操作之前,第一文件属于第一应用的第一相册;在获取模块获取第二操作会后,第一文件属于第一应用的回收站相册;
在生成模块生成第二数据表之后:
显示模块,还用于在第一应用的回收站界面中显示第一文件;
获取模块,还用于获取用户在回收站界面输入的第四操作;
显示模块,还用于响应于第四操作,在第一应用的目标相册对应的界面中显示第一文件;
在获取模块获取第四操作后,第一文件属于第一应用的目标相册。
结合本申请第三方面,在本申请第三方面的第三种实现方式中,在生成模块生成第二数据表之后:
显示模块,还用于在第一应用的回收站界面中显示第一文件;
获取模块,还用于获取用户在回收站界面输入的第五操作;
删除模块,还用于响应于第五操作,将第一文件从移动终端中删除。
结合本申请第三方面,在本申请第三方面的第四种实现方式中,在生成模块生成第二数据表之后:
获取模块,还用于获取用户输入的第六操作,响应于第六操作,显示第一文件的元数据;
显示模块,还用于响应于第六操作,显示第一文件的元数据,元数据包括如下至少一项:第一文件的原文件名称,第一文件的原文件标识,第一文件的删除时间,第一文件的原存储路径,第一文件的当前存储路径,第一文件的拍摄时间,第一文件的图片方向,第一文件的云端全局唯一标识符,第一文件的哈希值,第一文件原所属相册的云端识别码。
结合本申请结合本申请第三方面,在本申请第三方面的第五种实现方式中,
显示模块,还用于响应于第三操作,不在第一应用的回收站界面中显示第二文件,第二文件为云端服务器中存储的与第一文件相同的文件。
结合本申请结合本申请第三方面,在本申请第三方面的第六种实现方式中,在生成模块生成第二数据表之后:
显示模块,还用于显示选择界面;
获取模块,还用于获取用户在选择界面输入的第七操作;
显示模块,还用于响应于第七操作,在第一应用的回收站界面显示第一文件。
结合本申请第三方面,第三方面的第一至第六种实现方式的任意一种实现方式,在本申请第三方面的第七种实现方式中,移动终端还包括;
处理模块,用于将第一文件的存储位置从第一目录更改为第二目录,并将第一文件的文件名称从第一命名更改为第二命名,第二目录用于存储第一应用的回收站界面中显示的文件。
结合本申请第三方面的第七种实现方式,在本申请第三方面的第八种实现方式中,第二命名为通过预设编码方式对第一文件的元数据进行编码得到的目标字符串。
结合本申请第三方面的第八种实现方式,在本申请第三方面的第九种实现方式中,生成模块,具体用于通过预设编码方式对第二命名进行解码得到第一文件的元数据;根据元数据生成第二数据表。
结合本申请第三方面的第七种实现方式,在本申请第三方面的第十种实现方式中,第二命名为第一文件的删除时间;
移动终端还包括:
处理模块,用于通过预设编码方式对第一文件的元数据进行编码得到目标字符串,并将目标字符串以及第一文件的删除时间对应存储在第二目录的二进制文件中。
结合本申请第三方面的第十种实现方式,在本申请第三方面的第十一种实现方式中,生成模块具体用于:根据第二命名确定第一文件的删除时间;二进制文件中与第一文件的删除时间对应的目标字符串;预设编码方式对目标字符串进行解码得到第一文件的元数据;根据第一文件的元数据生成第二数据表。
结合申请第三方面,第三方面的第一至第六种实现方式中的任意一种实现方式,移动终端还包括:
备份模块,用于对第一数据表进行备份得到第三数据表;
生成模块,具体用于根据第三数据表生成第二数据表。
本申请第四方面提供了一种计算机可读存储介质,包括指令,当该指令在计算机上运行时,该计算机执行上述各项方法。
本申请第五方面提供了一种包含指令的计算机程序产品,当该计算机程序产品在计算机上运行时,该计算机执行上述各项方法。
本申请实施例中,移动终端回收站数据表被删除后,可以重新生成回收站数据表,从而在应用数据被清除后,移动终端也可以在回收站界面中显示第一文件,使得用户可以在回收站界面中对第一文件进行彻底删除或恢复,提升用户体验。
附图说明
图1A为多媒体文件的管理界面的一个示意图;
图1B为多媒体文件的管理界面的另一示意图;
图1C为用户在多媒体文件的管理界面上输入删除指令的一个示意图;
图1D为用户在多媒体文件的管理界面上输入删除指令的另一个示意图;
图1E为移动终端将第一文件从原目录移动至回收站目录的示意图;
图1F为删除第一文件后的多媒体文件管理界面示意图;
图1G为删除第一文件后回收站界面的示意图;
图1H为用户在移动终端输入第一应用的数据删除指令的示意图;
图1I为用户输入的启动多媒体管理应用的指令的示意图;
图1J为应用数据被删除后回收站对应操作界面的示意图;
图2为本申请实施例中文件处理方法的一个实施例流程图;
图3A为本申请实施例中移动终端将第一文件从第一目录移动至第二目录的一个示意图;
图3B为本申请实施例中移动终端将第一文件从第一目录移动至第二目录的另一示意图;
图3C为本申请实施例中移动终端将第一文件从第一目录移动至第二目录的另一示意图;
图3D为本申请实施例中移动终端将第一文件从第一目录移动至第二目录的另一示意图;
图3E为本申请实施例中二进制文件的一个示意图;
图4为本申请实施例中选择界面的一个示意图;
图5A为本申请实施例中移动终端在回收站界面显示第一文件的一个示意图;
图5B为本申请实施例中移动终端在回收站界面显示第一文件的另一个示意图;
图5C为本申请实施例中移动终端显示第一文件的元数据的另一个示意图;
图5D为本申请实施例中移动终端显示第一文件的元数据的另一个示意图;
图5E为本申请实施例中移动终端显示第一文件的元数据的另一个示意图;
图6A为本申请实施例中用户在回收站界面上输入恢复指令的一个示意图;
图6B为本申请实施例中用户在回收站界面上输入恢复指令的另一个示意图;
图6C为本申请实施例中移动终端将第一文件从第二目录移动至目标目录的一个示意图;
图6D为本申请实施例中移动终端将第一文件恢复到目标相册的一个示意图;
图7A为本申请实施例中移动终端将第一文件从第二目录移动到第一目录的一个示意图;
图7B为本申请实施例中移动终端将第一文件恢复到原相册的一个示意图;
图8A为本申请实施例中用户在回收站界面上输入删除指令的一个示意图;
图8B为本申请实施例中用户在回收站界面上输入删除指令的一个示意图;
图8C为本申请实施例中移动终端将第一文件从移动终端中删除的一个示意图;
图9为本申请实施例中移动终端的一个实施例示意图;
图10为本申请实施例中移动终端的另一实施例示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、
“第四”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。为了便于理解本申请实施例,下面对本申请实施例涉及的一些词语进行介绍:
元数据:又称中介数据、中继数据,为描述数据的数据(data about data),主要是描述数据属性(property)的信息,用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。元数据算是一种电子式目录,为了达到编制目录的目的,必须在描述并收藏数据的内容或特色,进而达成协助数据检索的目的。
本申请实施例中图片或视频的元数据可以包括如下一项:文件扩展名,文件名称(display name),删除时间(recycled time),文件标识(local media identifier),当前存储路径,原存储路径(sourcepath),拍摄时间(datataken),图片方向(orientation),原所属相册的云端识别码(album identifier),文件的哈希值(hash),文件的云端全局唯一标识符(cloud globally unique identifier,Cloud GUID),拍摄位置。
其中,原文件名称指的是在移动终端获取第二操作之前第一文件的文件名称;原文件标识指的是在移动终端获取第二操作之前第一文件在对应数据表中的标识;原存储路径指的是在移动终端获取第二操作之前第一文件的存储路径;当前存储路径指的是在移动终端获取第六操作时第一文件的存储路径;原所属相册指的是在移动终端获取第二操作之前第一文件所属的相册。
相册:图片管理应用用于管理移动终端中的图片和视频,一些图片管理应用会依据图片或视频的获取方式将移动终端上的图片和视频分成多个组进行管理,相片或视频所属的相册指的就是这个相片或视频所在的分组。例如,可以将从微信应用中下载的图片和视频归为一组,均归属于微信相册;将通过相机应用拍摄的图片和视频归为一组,均归属于相机相册。
回收站相册是一个特殊的分组,用户在图片管理应用中删除的图片和视频会从原来的分组移到这个分组中,即所属相册从原相册更改为回收站相册。应理解,在一些实施例中,回收站相册还可以称为最近删除相册,已删除相册等名称,具体本申请不作限定。
此外,需要说明的是,在本申请如下的实施例中,还有诸如“第一文件属于第一应用的第一相册”的描述。此处的属于,可以理解为,用户打开第一应用(如相册应用),点击某一相册,在该相册中呈现有第一文件。从用户感知的角度,可理解为用户在该第一相册中看到了第一文件。
应理解,图片管理应用可以按照相册对图片和视频分组显示,也可以按照图片和视频的获取位置,获取时间进行显示。
回收站:本申请实施例中的回收站指的是被删除的图片、视频等多媒体文件所属于的分组。应理解,回收站可以分为本地回收站和云端回收站,本地回收站用于用户管理在移
动终端本地删除的多媒体文件,云端回收站用于用户管理在云端服务器删除的多媒体文件,当移动终端与云端服务器连接时,用户在可以将本地回收站中的多媒体文件上传到云端回收站中。也可以将云端回收站中的多媒体文件下载到本地回收站中。
应用数据:本申请实施例中应用数据指的是应用在运行过程中所记录下来的数据。比如对于通讯类应用,其应用数据可以包括用户账号信息,聊天记录等;比如浏览器应用,其应用数据可以包括浏览记录,搜索记录等;比如媒体管理应用,其应用数据可以包括用户对多媒体文件进行管理的过程中产生的记录,比如用户对多媒体文件的分类记录,用户对多媒体文件的修改记录,各个多媒体文件对应的元数据信息等。
文件扩展名:也称为文件的后缀名,是操作系统用来标志文件类型的一种机制。通常来说,一个扩展名是跟在主文件名后面的,由一个分隔符分隔。在一个像“example.txt”的文件名中,example是主文件名,txt为扩展名,表示这个文件被认为是一个纯文本文件。
数据表:本申请中的数据表指的是媒体管理应用中用于记录该媒体管理应用所管理的多媒体文件的元数据的载体。媒体管理应用基于数据表中记录的元数据对多媒体文件进行展示。
文件标识(local media identifier):本实施例中的文件标识指的是多媒体文件在数据表中的标识,不同的多媒体文件在同一数据表中对应的标识是不一样的,本申请的一些实施例中采用原文件标识进行命名,可以保证文件名称的唯一性,原文件标识指的是在用户输入第二操作之前文件在数据表中的标识。
目录:本申请实施例中目录指的是移动终端上用于存储多媒体文件的文件夹,第一目录指的是多媒体文件在被删除前所述存储的目录,第二目录指的是用于存储本地回收站对应的多媒体文件的目录。键值对(key-value):数据保存的一种形式,键(key)代表存储的值的编号,值(value)代表要存放的数据。根据一个键可以获得唯一对应的一个值。本申请将目标字符串作为值,将删除时间作为键,通过一个删除时间可以查询到唯一对应的一个目标字符串。
Base64:Base64是网络上最常见的用于传输8Bit字节码的编码方式之一,Base64就是一种基于64个可打印字符来表示二进制数据的方法。Base64的编码规则如下:(1)把3个字符变成4个字符;(2)每76个字符加一个换行符;(3)最后的结束符也要出来。
多媒体数据库:用于存储手机上的多媒体文件(包括音频,视频和图片)的数据库。手机在启动时,会启动媒体扫描服务进程(Media Scanner Service)扫描手机上包含jpg,mp4等后缀的多媒体文件,然后将这些多媒体文件的信息加入到多媒体数据库中,手机上的应用程序通过该多媒体数据库调取需要的多媒体信息。
为了方便用户对手机内存进行管理,很多手机会设置有数据删除功能,用户可以通过在手机的系统设置上将某些应用的应用数据和/或缓存数据删除,以释放更多的存储空间。用户通过系统设置将图片管理应用(例如图库应用,相册应用等)的应用数据清除后,当用户再次启动图片管理应用时,图片管理应用会从多媒体数据库中获取手机上存储的图片和视频的元数据,根据获取的元数据在图片管理应用中对手机上图片和视频进行展示。
但是,对于被移除至回收站相册中图片和视频,图片管理应用为了屏蔽第三方应用显
示,在移除至回收站相册的时候会对图片和视频的格式做特殊处理,如去除jpg、MP4等后缀名。则在用户清除图片管理应用的应用数据后,再次启动图片管理应用时,虽然回收站相册中的图片和视频仍然存储在系统中,但是由于媒体扫描服务进程无法扫描到不包含jpg、mp4等后缀的文件,因此图片管理应用通过媒体数据库无法获取回收站相册中的图片和视频的元数据,无法重新构建图片管理应用中回收站相册对应的数据表,从而图片管理应用无法显示回收站相册中的图片和视频,用户也不能对回收站相册中的图片和视频进行彻底删除和恢复,影响用户体验,并且占用系统存储空间。
本申请实施例提供了一种文件处理方法及移动终端,用于在应用数据被清除后,在回收站界面中显示的多媒体文件,使得用户可以对回收站界面中的多媒体文件进行彻底删除或恢复,提升用户体验。
为了便于理解本申请实施例,下面对本申请的文件处理方法及移动终端所适用的场景进行简单介绍:
本申请实施例中的移动终端包括但不限于:手机、平板电脑、电子阅读器、手持游戏机、车载电子设备等电子设备,其操作系统可以是Android、Windows Phone、BlackBerry、iOS等系统,具体本申请实施例不作限定。需要说明的是,本申请实施例中的终端具有回收站功能。
本申请实施例中的多媒体文件包括但不限于:相片、视频、音频等文件。
本申请实施例中的多媒体管理应用具体可以是图片管理应用(例如图库应用,相册应用等),也可以是音频文件管理应用(录音机应用等),还可以是其他用于管理多媒体文件的应用,具体本申请实施例不作限定。
在一些方案中,移动终端中存储有若干多媒体文件,多媒体管理应用为管理这些多媒体文件的应用,其通过数据表记录这些多媒体文件对应的元数据。具体地,多媒体管理应用支持回收站功能,其对应的数据表包括非回收站数据表和回收站数据表。其中,非回收站数据表用于记录非回收站对应的多媒体文件的元数据(例如文件名称,存储路径,拍摄时间,图片方向等),回收站数据表用于记录回收站中多媒体文件的元数据(例如原存储路径,删除时间,拍摄时间,图片方向等)。如下表1所示,为非回收站数据表的一个示例,表中记录了相机相册对应的八个多媒体文件的元数据,应理解。
表1
移动终端接收到进入多媒体管理应用的指令,在屏幕上呈现多媒体文件的管理界面,如图1A或图1B所示。用户在多媒体文件显示界面上输入删除指令,如图1C或图1D所示,用户在多媒体文件显示界面上选择需要删除的多媒体文件,然后点击删除图标将选择的多媒体文件删除。移动终端在接收该删除指令后,去除被删除的多媒体文件的后缀名,并将被删除的多媒体文件从原目录移动至回收站目录中(如图1E所示),同时将被删除的多媒体文件对应的元数据从非回收站数据表中移除,移除后的非回收站数据表如下表2所示。此外,在回收站数据表中增加移动至回收站目录中的多媒体文件(即被删除的多媒体文件)对应的元数据,增加后回收站数据表如下表3所示。
表2
表3
用户在多媒体文件显示界面上输入删除指令后,移动终端呈现的多媒体文件显示界面中不包含被删除的多媒体文件,如图1F所示。而当移动终端接收到进入回收站的指令时,移动终端会在回收站对应的显示界面中呈现被删除的多媒体文件,如图1G所示,用户可以在该操作界面中将删除的多媒体文件进行恢复处理或彻底删除处理。
移动终端接收媒体管理应用的应用数据清除指令,如图1H所示,移动终端将媒体管理应用的应用数据清除,被清除的应用数据至少包括媒体管理应用中非回收站数据表以及回收站数据表。
移动终端将媒体管理应用的应用数据清除后,移动终端接收启动媒体管理应用的指令,该指令具体可以由用户点击第一应用的应用图标触发,如图1I所示,可以由用户在其他应用中点击第一应用的接口触发,也可以由移动终端在特定条件下自动触发,具体此处不作限定。
移动终端启动媒体管理应用后,在一些方案中,移动终端通过媒体数据库调取移动终端中的多媒体文件的元数据,并根据元数据建立多媒体管理应用的数据表。由于回收站对应目录(例如上述图1E中的BIN目录)中的多媒体文件不包含文件后缀名,媒体扫描服务
进程扫描不到回收站对应目录中的多媒体文件,媒体数据库中不包含回收站对应目录中的多媒体文件,因此建立的多媒体管理应用的数据表中不包含回收站数据表中多媒体文件的元数据。在本方案中,媒体管理应用数据清除后,重新启动媒体管理应用时,接收到进入回收站的指令时,移动终端呈现的回收站界面中不显示任何多媒体文件,如图1J所示。
在本申请实施例中,移动终端接收到针对某一多媒体文件的删除指令后,将被删除的多媒体文件从原目录移动至回收站目录的过程中,会提取被删除的多媒体文件的元数据进行存储,并对被删除的多媒体文件进行重命名。在媒体管理应用的应用数据被清除后,移动终端可以重新构建非回收站数据表以及回收站数据表,然后根据非回收站数据表以及回收站数据表,在媒体管理应用中显示回收站相册以及非回收站相册中的多媒体文件。
基于上述场景为例,下面对本申请实例中移动终端对多媒体文件进行重命名以及重新构建回收站数据表的过程进行详细描述,请参阅图2,本申请实施例中文件处理方法的一个实施例包括:
201、移动终端获取用户输入的第一操作,响应于第一操作,在第一应用的第一界面显示第一文件;用户在点击第一应用的图标,响应于该操作,移动终端启动第一应用,并在第一应用的第一界面显示第一文件,其中,第一应用指的是多媒体管理应用,第一界面指的是多媒体文件的管理界面,该管理界面可提供对多媒体文件进行编辑、删除、分类等操作的功能按钮。第一界面可以是多个多媒体文件(包含第一文件)的管理界面,如图1A所示;也可以是第一文件的管理界面,如1B所示,具体此处不作限定。
202、移动终端获取用户在第一界面输入的第二操作,响应于第二操作,在第一应用的回收站界面显示第一文件;
具体地,第二操作可以是针对某个第一文件的单项删除指令,如图1C或1D所示;也可以是对多个第一文件的批量删除指令,如在图1C所示的场景中,用户可以选择多个多媒体文件后再点击删除图标发起多个多媒体文件的批量删除指令,具体此处不作限定。
移动终端接收删除指令之后,将第一文件从第一目录移动至第二目录,即,将第一文件的存储位置从第一目录更改为第二目录,其中,第一目录指的是用户输入删除指令前存储第一文件的目录,第二目录指的是用于存储回收站界面所显示的文件的目录。移动终端将第一文件从第一目录移动至第二目录的过程中,会对第一文件进行重命名,即将第一文件的文件名称从第一命名更改为第二命名,同时还会提取第一文件的元数据进行存储。
需要说明的是,移动终端将第一文件移动至第二目录之后,移动终端就可以在第一应用的回收站界面上显示第一文件。图1G所示,用户在第一应用的相册选择界面中选择回收站相册,移动终端根据该指令在屏幕上显示回收站界面,该界面中包含有第一文件对应的略缩图。应理解,进入回收站界面的指令不限于上述图1G所示的形式,第一文件在回收站界面的显示形式也不限于图1G所示的形式。
具体地,本申请实施例中,移动终端提取的元数据至少需要包括:第一文件的原文件名称的文件扩展名。具体地,根据需要恢复的程度,移动终端提取的元数据还可以包括如下一项或多项:原文件名称(第一命名)的主文件名,原文件标识,删除时间,回收站文件路径,第一文件的原存储路径,拍摄时间,图片方向,第一文件原所属相册在的云端识
别码,第一文件的哈希值,第一文件的云端全局唯一标识符。而提取的元数据可以存储在第一文件的第二命名中,也可以存储在第二目录下新建的二进制文件中,还可以存储在其他存储空间中,具体本实施例不作限定。
应理解,原文件标识指的是第一文件被删除前在非回收站数据表中的文件标识;回收站文件路径指的是回收站界面所显示的多媒体文件对应的存储路径;原存储路径指的是第一文件被删除前所存储的位置;第一文件原所属相册的云端识别码指的是第一文件被删除前所属的相册在云端服务器中的相册标识;第一文件的云端全局唯一标识符指的是第一文件在云端服务器中的标识。
下面对其中几种存储方式进行介绍:
方式一、移动终端将第一文件从第一目录移动至第二目录的过程中,会生成一个随机数,然后将提取的元数据与该随机数拼接得到字符串,然后将该字符串作为第一文件在第二目录中的文件名称(第二命名),即将元数据与随机数结合存储在第二命名中。其中,移动终端提取的元数据为第一命名中的文件扩展名。举例说明:移动终端生成的随机数为“4531265”,第一文件的在第一目录中的文件名称(第一命名)为“相片3.jpg”,移动终端提取第一文件的文件扩展名“jpg”,然后将该文件扩展名与该随机数拼接得到字符串“jpg4531265”,移动终端将第一文件重新命名为“jpg4531265”。
方式二、移动终端将第一文件从第一目录移动至第二目录的过程中,通过预置编码方式对提取的元数据进行编码得到目标字符串,将该目标字符串设为第一文件在第二目录中的文件名称(第二命名),即,将单个元数据通过编码的方式存储在第二命名中。其中,移动终端提取的元数据为第一文件在第一目录中的文件名称,即原文件名称。以上述图1C或图1D对应的场景为例进行说明:第一文件的原文件名称(第一命名)为“相片3.jpg”,通过base64编码得到目标字符串“55u454mHMy5qcGc=”,移动终端将第一文件重新命名为“55u454mHMy5qcGc=”。
方式三、移动终端将第一文件从第一目录移动至第二目录的过程中,可以将提取的多个元数据进行拼接得到的字符串作为第一文件在第二目录中的文件名称(第二命名),即将多个元数据拼接后存储在第二命名中。
可选地,在一些实施例中,上述方式三中移动终端提取的多个元数据分别为第一文件在原文件名称、第一文件的原文件标识。
可选地,在一些实施例中,上述方式三中移动终端提取的多个元数据分别为第一文件的原文件名称和第一文件的删除时间。
可选地,在一些实施例中,上述方式三中移动终端提取的多个元数据分别为第一文件的原文件名称、第一文件的原文件标识和第一文件的删除时间。
下面以上述图1C或图1D对应的场景为例进行说明:第一文件的原文件名称(第一命名)为“相片3.jpg”,原文件标识为“0003”,删除时间为“2017年1月16日”,移动终端将三者拼接后得到字符串“0003相片3.jpg2017年1月16日”,移动终端将第一文件重新命名为“0003相片3.jpg2017年1月16日”,如图3A所示。
方式四、移动终端将第一文件从第一目录移动至第二目录的过程中,可以先将提取的
多个元数据进行拼接得到字符串,然后通过预置编码方式对该字符串进行编码得到目标字符串,再将该目标字符串作为第一文件在第二目录中的文件名称(第二命名),即将多个元数据拼接后通过编码的方式存储在第二命名中。其中,预置编码方式可以包括base64或其他方式,具体此处不作限定。
可选地,本实施例中,移动终端在通过预置编码方式对拼接得到的字符串进行编码之前可以先将该字符串进行压缩,然后再对压缩后的字符串进行编码得到目标字符串。
可选地,在一些实施例中,上述方式四中移动终端提取的多个元数据分别为第一文件的原文件名称和第一文件的原文件标识。
可选地,在一些实施例中,上述方式四中移动终端提取的多个元数据分别为第一文件的原文件名称和第一文件的删除时间。
可选地,在一些实施例中,上述方式四中移动终端提取的多个元数据分别为第一文件的原文件名称、第一文件的原文件标识和第一文件的删除时间。
如上述方式三对应的例子中,移动终端将三个元数据拼接得到的字符串“0003相片3.jpg2017年1月16日”后,移动终端通过base64编码得到目标字符串“MDAwM+ebuOeJhzMuanBnMjAxN+W5tDHmnIgxNuaXpQ==”,移动终端将第一文件重新命名为“MDAwM+ebuOeJhzMuanBnMjAxN+W5tDHmnIgxNuaXpQ==”,如图3B所示。
需要说明的是,移动终端会对文件名称的长度进行限制,在上述方式四中,如果提取的元数据包含第一文件的原文件名称(第一命名),文件名称是可以由用户编辑的,当原文件名称的字符长度较长时,可能会使得拼接后的字符串或编码后的目标字符串的字符长度超过移动终端的限制长度。对于这种情况,移动终端在拼接得到字符串的过程中,可以将原文件名称中的主文件名的尾部截断,以使得拼接后的字符串或编码后的目标字符串的字符长度不超过限制长度。以安卓(Android)为例:基于Base64的编码规则可知,经过Base64编码后的字符串与原字符串与原字符串的字符长度之比为4:3,而基于安卓系统的手机能支持的文件名称的最大字符长度为256字节,为保证base64编码后的字符串不超过该长度(256字节),则编码前的字符串长度不得超过192字节,即拼接后的字符串不得超过192字节。第一文件的原文件名称(第一命名)为“我在家门口和妈妈一起拍照wozaitianmnenhemamayiqipaizhaowozaitiananmenhemamayiqipaizhaowozaitianammenhemamayiqipaizhaowozaitianmnenhemamayiqipaizhaowozaitianmnenhemamayiqipaizhaoasaaaanjkhkjhkjh.jpg”,第一文件的原文件标识为“0003”,第一文件的删除时间为“2017年1月16日11:11:03”,三者拼接得到的字符串长度超过192字节,则移动终端将原文件名称的主文件名的尾部截断得到“我在家门口妈妈一起拍照.jpg”,再将截断后的文件名称与原文件标识以及删除时间进行拼接得到字符串“0003我在天安门和妈妈一起拍照.jpg2017年1月16日11:11:03”,该字符串长度小于192字节。然后再通过base64编码方式对该字符串进行编码得到长度小于256字节的目标字符串。
方式五、移动终端将第一文件从第一目录移动至第二目录的过程中,可以先将提取的多个元数据进行拼接得到字符串,然后通过预置编码方式对该字符串进行编码得到目标字符串。若该目标字符串的字符长度不大于系统限制长度,则移动终端将该目标字符串确定
为第一文件在第二目录中的文件名称(第二命名);若该目标字符串的字符长度大于系统限制长度,则移动终端以以键-值(key-value)的方式将目标字符串作为值(value),将元数据中的删除时间作为键(key)存储在第二目录下新建的二进制文件中,同时将该删除时间确定为第一文件在第二目录中的文件名称(第二命名)。
可选地,本实施例中,移动终端在通过预置编码方式对拼接得到的字符串进行编码之前可以先将该字符串进行压缩,然后再对压缩后的字符串进行编码得到目标字符串。
可选地,本实施例可以将多个第一文件对应的值(即目标字符串)以及键(即删除时间)都存储在同一二进制文件中。该二进制文件的文件命名可以是任意设定,本实施例不作限定。该二进制文件的文件类型(即文件扩展名)可以是xml,或txt,或bin,或其他扩展名,具体本实施例也不作限定。
可选地,在一些实施例中,上述方式五中移动终端提取的多个元数据分别为:删除时间,回收站文件路径,原存储路径,拍摄时间以及图片方向。
可选地,在一些实施例中,上述方式五中移动终端提取的多个元数据分别为:删除时间,回收站文件路径,原存储路径,拍摄时间,图片方向以及云端全局唯一标识符。
可选地,在一些实施例中,上述方式五中移动终端提取的多个元数据分别为:删除时间,回收站文件路径,原存储路径,拍摄时间,图片方向,原所属相册的云端识别码以及哈希值。
可选地,在一些实施例中,上述方式五中移动终端提取的多个元数据分别为:删除时间,回收站文件路径,原存储路径,拍摄时间,图片方向,原所属相册的云端识别码,哈希值以及云端全局唯一标识符。
下面以上述图1C或图1D对应的场景为例进行说明:被删除的多媒体文件(第一文件)的删除时间为“2017年1月16日11:11:03:01”,回收站文件路径为“手机存储\DCIM\Bin”,原存储路径为“手机存储\DCIM\Camera\相片3.jpg”,拍摄时间为“2017年1月2日12:20”,图片方向为“90°”,上述元数据拼接得到字符串“手机存储\DCIM\Bin手机存储\DCIM\Camera\相片3.jpg2017年1月16日11:11:03:012017年1月2日12:2090°”,然后通过Base64对上述字符串进行编码得到目标字符串“50mL5py65a2Y5YKoX…(后面字符省略)”,该目标字符串的字符长度小于255字节,故移动终端将该目标字符串确定为第二命名,如图3C所示。
下面以另一场景为例进行说明:被删除的多媒体文件(第一文件)的删除时间为“2017年1月16日11:11:03:01”,回收站文件路径为“手机存储\DCIM\Bin”,第一文件的原存储路径为“手机存储\DCIM\Camera\相片3.jpg”,拍摄时间为“2017年1月2日12:20”,图片方向为“90°”,原所属相册的云端识别码为“464135132428731234534”,哈希值为“8a21589c6ac2413295d41d8955bbdcc1asdaa3542a1sd21a2sd1asd3sa56hth41464h131rD”,第一文件的云端全局唯一标识符为“6F9619FF-8B86-D011-B42D-00C04FC964FF”,将这些元数据拼接得到的字符串通过base64编码得到目标字符串(本示例的目标字符串字符长度较长,此处不作展示,为了便于描述以“A”表示该目标字符串),目标字符串“A”的长度大于255字节,则移动终端将目标字符串作为value存储在二进制文件中,将删除时间
“2017年1月16日11:11:03:01”作为该value对应的key存储在第二目录下新建的二进制文件中,如图3E所示,同时将第一文件重新命名为“2017年1月16日11:11:03:01”,如图3D所示。
方式六、本实施例中,移动终端会对回收站数据表(第一数据表)进行备份得到第三数据表,第三数据表可以存储在除了第一应用对应目录以外的其他目录中,则当移动终端在清除第一应用的应用数据时,不会将该第三数据表删除。
具体地,移动终端在接收到删除指令后,将非回收站数据表中第一文件的元数据删除,在回收站数据表中增加第一文件对应的元数据,并将回收站数据表中第一文件对应的元数据全部备份到第二数据表中。即移动终端将第一文件从第一目录移动至第二目录的过程中,会将回收站数据表中第一文件对应的所有元数据存储到第三数据表中。
应理解,移动终端接收到删除指令后,除了上述方式,移动终端还可以通过其他方式存储第一文件的元数据,还可以通过其他方式重命名第一文件,具体本申请实施例不作限定。
还应理解,移动终端提取元数据进行存储以及对第二文件进行重命名的流程,可以在将第一文件从第一目录移动至第二目录的过程中执行,可以在将第一文件从第一目录移动至第二目录之前执行,也可以在将第一文件从第一目录移动至第二目录之后执行,具体本本申请不作限定。
203、移动终端将第一数据表删除;
移动终端获取第一应用的应用数据清除指令,删除第一应用的应用数据,其中,应用数据包括回收站数据表(第一数据表)。具体地,该应用数据清除指令可以由用户在移动终端的屏幕上输入的操作所触发,如图1H所示;也可以由操作系统或第一应用出现异常时自动触发,具体此处不作限定。
204、移动终端获取用户输入的第三操作,响应于第三操作,生成第二数据表。
移动终端删除第一应用的应用数据后,当接收到启动第一应用的指令时,移动终端根据存储的元数据生成第二数据表,生成第二数据表具体可以是重新构建新的回收站数据表,或者恢复被删除的回收站数据表。
针对元数据存储位置的不同,移动终端可以有不同的回收站数据表构建方式,下面对其中几种进行介绍:
方式一、移动终端解析第二目录中第一文件的文件名称(即第一文件的第二命名)得到第一文件的元数据,移动终端根据该元数据构建回收站数据表。
下面举例进行说明,第二目录中的第一文件的文件名称为“0003相片3.jpg2017年1月16日”,如图3A右图所示,则移动终端解析第一文件的文件名称得到原文件名称“相片3.jpg”,删除日期“2017年1月16日”,构建的回收站数据表如下表4所示。
文件标识 |
原文件名称 |
删除时间 |
0001 |
相片3.jpg |
2017年1月16日 |
表4
方式二、移动终端通过base64编码方式对第二目录中第一文件的文件名称进行解码得
到第一文件的元数据,再根据该元数据构建回收站数据表。
下面以图3B右图所示的文件名称为例进行说明,第二目录中的第一文件的文件名称为“MDAwM+ebuOeJhzMuanBnMjAxN+W5tDHmnIgxNuaXpQ==”,移动终端通过base64编码对该目标字符串进行解码得到字符串“0003相片3.jpg2017年1月16日”,解析该字符串得到第一文件的原文件名称“相片3.jpg”以及第一文件的删除日期“2017年1月16日”,构建的回收站数据表如上表4所示。
下面以图3C右图所示的文件名称为例进行说明,第二目录中的第一文件的文件名称为“50mL5py65a2Y5YKoX…(字符串较长,此处后省略后面字符)”,移动终端通过base64编码对该目标字符串进行解码得到字符串“手机存储\DCIM\Bin手机存储\DCIM\Camera\相片3.jpg2017年1月16日11:11:03:012017年1月2日12:2090°”,解析该字符串得到回收站路径为“手机存储\DCIM\Bin”,第一文件的原存储路径“手机存储\DCIM\Camera\相片3.jpg”,第一文件的删除时间“2017年1月16日11:11:03:01”,第一文件的拍摄时间“2017年1月2日12:20”以及第一文件的图片方向“90°”,构建的回收站数据表如下表5所示。
表5
方式三、移动终端判断第二目录中第一文件的文件名称是否为时间戳,即判断其格式是否满足时间格式,若否,则通过base64编码方式对第二目录中第一文件的文件名称进行解码得到第一文件的元数据,若是,则读取第二目录中新建的二进制文件中的数据,查找与第一文件的文件名称(删除时间)匹配的目标字符串,再通过base64编码方式对该目标字符串进行解码得到第一文件的元数据,再根据该元数据构建回收站数据表。
下面以图3D右图所示的文件名称为例进行说明,第二目录中第一文件的文件名称为“2017年1月16日11:11:03:01”,移动终端确定该文件名称为时间戳,移动终端读取第二目录中新建的二进制文件中的数据,并确定该二进制文件中与“2017年1月16日11:11:03:01”对应的目标字符串为“A”,如图3E所示,移动终端通过base64编码方式对目标字符串“A”进行解码得到字符串“手机存储\DCIM\Bin手机存储\DCIM\Camera\相片3.jpg2017年1月16日11:11:03:012017年1月2日12:2090°4641351324287312345348a21589c6ac2413295d41d8955bbdcc1asdaa3542a1sd21a2sd1asd3s a56hth41464h131rD6F9619FF-8B86-D011-B42D-00C04FC964FF”,移动终端解析该字符串得到回收站文件“手机存储\DCIM\Bin”,第一文件的原存储路径“手机存储\DCIM\Camera\相片3.jpg”,第一文件的删除时间“jpg2017年1月16日11:11:03:01”,第一文件的拍摄时间“012017年1月2日12:20”,第一文件的图片方向“90°”,第一文件原所属相册的云端识别码“464135132428731234534”,第一文件的哈希值“8a21589c6ac2413295d41d8955bbdcc1asdaa3542a1sd21a2sd1asd3sa56hth41464h131r”,
第一文件的云端全局唯一标识符“D6F9619FF-8B86-D011-B42D-00C04FC964FF”,构建的回收站数据表如下表6所示。
表6
方式四、移动终端判断第二目录中第一文件的文件名称是否为时间戳,即判断其格式是否满足时间格式,若否,则通过base64编码方式对第二目录中第一文件的文件名称进行解码,然后再对解码得到的数据进行解压到第一文件的元数据,若是,则读取第二目录中新建的二进制文件中的数据,查找与第一文件的文件名称(删除时间)匹配的目标字符串,再通过base64编码方式对该目标字符串进行解码,然后再对解码得到的数据进行解压得到第一文件的元数据,再根据该元数据构建回收站数据表。
方式五、移动终端根据第三数据表生成第二数据表,具体可以是拷贝第三数据表中的内容得到第二数据表,也可以是将第三数据表移动至第一应用对应的目录中作为第二数据表。
应理解,移动终端可以在构建回收站数据表之前呈现选择界面,如图4所示,该选择界面用于提示用户选择需要恢复的回收站文件以及需要恢复的元数据,然后再根据用户在该选择界面上选择的文件以及元数据构建回收站数据表。移动终端也可以在构建回收站数据表之后呈现选择界面,该选择界面用于提示用户选择需要恢复的回收站文件,然后根据构建的回收站数据表在回收站界面中显示用户选择的文件。可选地,对于用户未选择的回收站文件,移动终端可以自动将该回收站文件彻底删除。
回收站界面移动终端生成第二数据表之后,当接收到进入回收站界面的指令时,移动终端根据第二数据表在该回收站界面上显示第一文件。
具体地,该回收站界面可以是回收站文件的缩略图显示界面,如图5A所示,用户点击回收站相册对应的图标,移动终端显示第一文件的缩略图。
该回收站界面也可以是回收站文件的编辑界面,如图5B所示,用户点击第一文件的缩略图,移动终端显示第一文件的编辑界面。
本申请实施例中,移动终端回收站数据表被删除后,可以重新生成回收站数据表,从而在应用数据被清除后,移动终端也可以在回收站界面中显示第一文件,使得用户可以在回收站界面中对第一文件进行彻底删除或恢复,提升用户体验。
其次,本申请实施例提供了多种生成第二数据表的方式,提高了方案的灵活性。
基于上述图2对应的实施例,在一些实施例中,移动终端在回收站界面显示第一文件后,用户可以在该界面上输入第六操作,响应于第六操作,移动终端可以显示第一文件的元数据。如图5C,用户在第一文件的编辑界面点击详细信息功能键(第六操作),移动终端根据第二数据表显示第一文件的元数据。应理解,基于第二数据表所包含的元数据类型的不同,移动终端显示的元数据也有所不同,图5C仅示出第一文件的删除时间和原文件名称。进一步地,在一些场景中,移动终端还可以显示第一文件当前所在路径,第一文件的原存储路径,第一文件的拍摄时间,第一文件的图片方向,如图5D所示。更进一步地,移动终端还可以显示第一文件所属原册的相册标识,第一文件的云端全局唯一标识符以及第一文件的哈希值,如图5E所示。
本实施例中,移动终端可以显示第二数据表中包含的元数据,从而用户可以了解第一文件的详细信息,提升了用户体验。
在一些实施例中,移动终端与云端服务器建立连接时,移动终端在删除应用数据后,会自动从云端服务器中下载多媒体文件,并在回收站界面中显示从云端回收站下载的多媒体文件,这些多媒体文件中可能会存在于第一文件相同的文件,这就会使得回收站界面中显示了多张相同的相片或多个相片的视频。
作为一种可选的方式,在本实施例中,移动终端在回收站界面中显示第一文件之前,若第二数据表中包含第一文件的云端全局唯一标识符(Cloud GUID)不为0,则移动终端可以将云端服务器中与该云端全局唯一标识符对应的第二文件与第一文件关联,将第二文件与第一文件进行融合显示,即只显示第一文件或只显示第二文件。具体地,移动终端可以不从云端服务器中的第二文件下载到本地,在回收站界面中仅显示第一文件;移动终端也可以从云端服务器中的第二文件下载到本地后,选择第一文件和第二文件中的其中一个文件在回收站界面中进行显示,从而可以避免移动终端重复显示相同内容。
如上述表6对应的场景,第一文件对应的云端全局唯一标识符为“D6F9619FF-8B86-D011-B42D-00C04FC964FF”,则移动终端可以在查找云端服务器全局唯一标识符为“D6F9619FF-8B86-D011-B42D-00C04FC964FF”的第二文件,然后在回收站界面中仅显示第一文件,而不显示该第二文件。
本实施例中,移动终端可以避免在回收站界面上重复显示相同文件的方式,提高了方案灵活性。
作为一种可选的方式,在本实施例中,移动终端在回收站界面中显示第一文件之前,若回收站数据表中包含第一文件原所属相册的云端识别码以及第一文件的哈希值,则移动终端可以将云端服务器中与该原所属相册的云端识别码以及该哈希值对应的第二文件与第一文件关联,将第二文件与第一文件进行融合展示,即只显示第一文件或只显示第二文件。具体地,移动终端可以不从云端服务器中的第二文件下载到本地,会在回收站界面中仅显示第一文件,移动终端也可以从云端服务器中的第二文件下载到本地后,选择第一文件和第二文件中的其中一个文件在回收站界面中进行显示,从而可以避免移动终端重复显示相同内容。
如上述表6对应的场景,第一文件对应的哈希值为“8a21589c6ac2413295d41d8955bbdcc1asdaa3542a1sd21a2sd1asd3sa56hth41464h131r”,第一文件原所属相册的云端识别码为“464135132428731234534”,则移动终端可以在云端服务器中查找哈希值与该哈希值一致,且原所属相册云端识别码与该原所属相册识别码一致的第二文件,然后在回收站界面中仅显示第一文件,而不显示该第二文件。
本实施例提供了另一种避免在回收站界面上重复显示相同文件的方式,提高了方案灵活性。
需要说明的是,移动终端在回收站界面显示第一文件后,可以根据用户在该操作界面上输入的恢复指令对第一文件进行恢复。应理解,基于第二数据表中包含的元数据类型不同,第一文件所能恢复的程度也不同。
作为一种可选的方式,第一文件原所属相册为第一相册,即,在用户在第一界面上将第一文件删除(移动终端获取用户在第一界面输入的第二操作)之前,第一文件属于第一相册。若第二数据表不包含第一文件的原存储路径,则移动终端无法将第一文件恢复到原相册,移动终端获取恢复指令后,将第一文件恢复到目标相册中。
其中,目标相册指的是系统或用户指定的一个相册,用于用户管理从回收站显示界面中恢复的多媒体文件。恢复到目标相册指的是将第一文件所属相册从回收站相册更改为目标相册。下面以表4对应的场景为例进行说明,第二数据表中包含第一文件的删除时间和原文件名称。
本场景中,移动终端接收到用户在操作界面上输入的恢复指令,如图6A或图6B所示,用户选择需要恢复的第一文件,并点击恢复图标对第一文件进行恢复。移动终端接收到该恢复指令后,将第一文件从第二目录移动至目标目录中,同时将第一文件的文件名称恢复为原文件名称(第一命名),如图6C所示,其中,目标目录用于存储目标相册中的多媒体文件。用户在回收站界面上输入恢复指令后,移动终端呈现的回收站界面中不包含被恢复的第一文件,当移动终端接收到进入目标相册的指令时,移动终端会在目标相册对应的界面中显示被恢复的第一文件,如图6D所示。
本实施例中,移动终端可以在应用数据删除后,将第一文件恢复到系统指定相册中,提高了方案的灵活性。
作为一种可选的方式,第一文件原所属相册为第一相册,即,在用户在第一界面上将第一文件删除(移动终端获取用户在第一界面输入的第二操作)之前,第一文件属于第一相册。若第二数据表包含第一文件的原存储路径,则移动终端可以将第一文件恢复到原相册,移动终端获取恢复指令后,将第一文件恢复到第一相册中,即将第一文件所属的相册从回收站相册更改为第一相册。
下面以表5对应的场景为例进行说明,第二数据表中包含第一文件的回收站路径,原存储路径,删除时间,拍摄时间及图片方向。
本场景中,移动终端接收到用户在操作界面上输入的恢复指令后,根据原存储路径将第一文件从第二目录移动至第一目录中,并将第一文件的文件名称恢复为原文件名称(第一命名),即将第一文件从回收站目录恢复到原目录中,如图7A所示。用户在回收站界面
上输入恢复指令后,移动终端呈现的回收站界面中不包含被恢复的第一文件,当移动终端接收到进入原相册的指令时,移动终端会在原相册中显示被恢复的第一文件,如图7B所示。
本实施例中,移动终端可以在应用数据删除后,将第一文件恢复到原相册中,提高了方案的灵活性。
还需要说明的是,移动终端在回收站界面显示第一文件后,可以根据用户在该操作界面上输入的删除指令将第一文件彻底删除,即将第一文件从移动终端中删除。
如图8A或图8B所示,用户在回收站界面中选择需要删除的第一文件,并点击删除空间对第一文件进行删除,移动终端获取该操作后,将第一文件从第二目录中删除,即将第一文件从移动终端中彻底删除,如图8C所示。
本实施例中,移动终端可以在应用数据删除后,将第一文件彻底删除,以增加移动终端的可用存储空间。
上面介绍了本申请中的文件处理方法,下面对本申请中的移动终端进行介绍,请参阅图9,本申请中移动终端的一个实施例包括:
显示模块901,用于响应第一操作,在第一应用的第一界面显示第一文件;
获取模块902,还用于获取用户在第一界面输入的第二操作;
显示模块901,还用于响应第二操作,在第一应用的回收站界面显示第一文件;
删除模块903,用于将第一数据表删除,第一文件因为第一数据表的删除而在第一应用的回收站界面中对用户不可见;
获取模块902,还用于获取用户输入的第三操作;
生成模块904,用于响应第三操作,生成第二数据表,第一文件因为第二数据表而在第一应用的回收站界面中对用户可见。
本申请实施例中,回收站数据表被删除后,移动终端可以通过生成模块904可以重新生成回收站数据表,从而在应用数据被清除后,移动终端也可以在回收站界面中显示第一文件,使得用户可以在回收站界面中对第一文件进行彻底删除或恢复,提升用户体验。
可选地,在一些实施例中,在获取模块902获取第二操作之前,第一文件属于第一应用的第一相册;在获取模块902获取第二操作会后,第一文件属于第一应用的回收站相册;
在生成模块904生成第二数据表之后:
显示模块901,还用于在第一应用的回收站界面中显示第一文件;
获取模块902,还用于获取用户在回收站界面输入的第四操作;
显示模块901,还用于响应于第四操作,在第一应用的第一相册对应的界面中显示第一文件;
在获取模块902获取第四操作后,第一文件属于第一应用的第一相册。
可选地,在一些实施例中,在获取模块902获取第二操作之前,第一文件属于第一应用的第一相册;在获取模块902获取第二操作会后,第一文件属于第一应用的回收站相册;
在生成模块904生成第二数据表之后:
显示模块901,还用于在第一应用的回收站界面中显示第一文件;
获取模块902,还用于获取用户在回收站界面输入的第四操作;
显示模块901,还用于响应于第四操作,在第一应用的目标相册对应的界面中显示第一文件;
在获取模块902获取第四操作后,第一文件属于第一应用的目标相册。
可选地,在一些实施例中,在生成模块904生成第二数据表之后:
显示模块901,还用于在第一应用的回收站界面中显示第一文件;
获取模块902,还用于获取用户在回收站界面输入的第五操作;
删除模块903,还用于响应于第五操作,将第一文件从移动终端中删除。
可选地,在一些实施例中,在生成模904块生成第二数据表之后:
获取模块902,还用于获取用户输入的第六操作,响应于第六操作,显示第一文件的元数据;
显示模块901,还用于响应于第六操作,显示第一文件的元数据,元数据包括如下至少一项:第一文件的原文件名称,第一文件的原文件标识,第一文件的删除时间,第一文件的原存储路径,第一文件的当前存储路径,第一文件的拍摄时间,第一文件的图片方向,第一文件的云端全局唯一标识符,第一文件的哈希值,第一文件原所属相册的云端识别码。
可选地,在一些实施例中,显示模块901,还用于响应于第三操作,不在第一应用的回收站界面中显示第二文件,第二文件为云端服务器中存储的与第一文件相同的文件。
可选地,在一些实施例中,生成模块904生成第二数据表之后:
显示模块901,还用于显示选择界面;
获取模块902,还用于获取用户在选择界面输入的第七操作;
显示模块901,还用于响应于第七操作,在第一应用的回收站界面显示第一文件。
可选地,在一些实施例中,移动终端还包括;
处理模块,用于将第一文件的存储位置从第一目录更改为第二目录,并将第一文件的文件名称从第一命名更改为第二命名,第二目录用于存储第一应用的回收站界面中显示的文件。
可选地,在一些实施例中,第二命名为通过预设编码方式对第一文件的元数据进行编码得到的目标字符串;
生成模块904,具体用于通过预设编码方式对第二命名进行解码得到第一文件的元数据;根据元数据生成第二数据表。
可选地,在一些实施例中,第二命名为第一文件的删除时间;
移动终端还包括:
处理模块,用于通过预设编码方式对第一文件的元数据进行编码得到目标字符串,并将目标字符串以及第一文件的删除时间对应存储在第二目录的二进制文件中。
可选地,在一些实施例中,生成模块904具体用于:根据第二命名确定第一文件的删除时间;二进制文件中与第一文件的删除时间对应的目标字符串;预设编码方式对目标字符串进行解码得到第一文件的元数据;根据第一文件的元数据生成第二数据表。
可选地,在一些实施例中,移动终端还包括:备份模块,用于对第一数据表进行备份得到第三数据表;
生成模块904,具体用于根据第三数据表生成第二数据表。
应理解上述图9对应移动终端中各模块所执行的流程与前述图2所示的实施例中描述的方法流程类似,此处不再赘述。
上面从功能模块的角度介绍了本申请中的移动终端,下面从实体硬件的角度介绍本申请中的终端,如图10所示,为了便于说明,仅示出了与本发明实施例相关的部分,具体技术细节未揭示的,请参照本申请实施例方法部分。该移动终端可以为包括手机、平板电脑、PDA(Personal Digital Assistant,个人数字助理)、POS(Point of Sales,销售终端)、车载电脑等任意终端设备,以终端为手机为例:
图10示出的是与本发明实施例提供的终端相关的手机的部分结构的框图。参考图10,手机包括:射频(Radio Frequency,RF)电路1010、存储器1020、输入单元1030、显示单元1040、传感器1050、音频电路1060、无线保真(wireless fidelity,WiFi)模块1070、处理器1080、以及电源1090等部件。本领域技术人员可以理解,图10中示出的手机结构并不构成对手机的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
下面结合图10对手机的各个构成部件进行具体的介绍:
RF电路1010可用于收发信息或通话过程中,信号的接收和发送,特别地,将基站的下行信息接收后,给处理器1080处理;另外,将设计上行的数据发送给基站。通常,RF电路1010包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low Noise Amplifier,LNA)、双工器等。此外,RF电路1010还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议,包括但不限于全球移动通讯系统(Global System of Mobile communication,GSM)、通用分组无线服务(General Packet Radio Service,GPRS)、码分多址(Code Division Multiple Access,CDMA)、宽带码分多址(Wideband Code Division Multiple Access,WCDMA)、长期演进(Long Term Evolution,LTE)、电子邮件、短消息服务(Short Messaging Service,SMS)等。
存储器1020可用于存储软件程序以及模块,处理器1080通过运行存储在存储器1020的软件程序以及模块,从而执行手机的各种功能应用以及数据处理。存储器1020可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等;存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外,存储器1020可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
输入单元1030可用于接收输入的数字或字符信息,以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地,输入单元1030可包括触控面板1031以及其他输入设备1032。触控面板1031,也称为触摸屏,可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板1031上或在触控面板1031附近的操作),并根据预先设定的程式驱动相应的连接装置。可选的,触控面板1031可包括触摸检测装置和触摸控制器两个部分。其中,触摸检测装置检测用户的触摸方位,并检测触摸操
作带来的信号,将信号传送给触摸控制器;触摸控制器从触摸检测装置上接收触摸信息,并将它转换成触点坐标,再送给处理器1080,并能接收处理器1080发来的命令并加以执行。此外,可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板1031。除了触控面板1031,输入单元1030还可以包括其他输入设备1032。具体地,其他输入设备1032可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。
显示单元1040可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元1040可包括显示面板1041,可选的,可以采用液晶显示器(Liquid Crystal Display,LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板1041。进一步的,触控面板1031可覆盖显示面板1041,当触控面板1031检测到在其上或附近的触摸操作后,传送给处理器1080以确定触摸事件的类型,随后处理器1080根据触摸事件的类型在显示面板1041上提供相应的视觉输出。虽然在图10中,触控面板1031与显示面板1041是作为两个独立的部件来实现手机的输入和输入功能,但是在某些实施例中,可以将触控面板1031与显示面板1041集成而实现手机的输入和输出功能。
手机还可包括至少一种传感器1050,比如光传感器、运动传感器以及其他传感器。具体地,光传感器可包括环境光传感器及接近传感器,其中,环境光传感器可根据环境光线的明暗来调节显示面板1041的亮度,接近传感器可在手机移动到耳边时,关闭显示面板1041和/或背光。作为运动传感器的一种,加速计传感器可检测各个方向上(一般为三轴)加速度的大小,静止时可检测出重力的大小及方向,可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等;至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器,在此不再赘述。
音频电路1060、扬声器1061,传声器1062可提供用户与手机之间的音频接口。音频电路1060可将接收到的音频数据转换后的电信号,传输到扬声器1061,由扬声器1061转换为声音信号输出;另一方面,传声器1062将收集的声音信号转换为电信号,由音频电路1060接收后转换为音频数据,再将音频数据输出处理器1080处理后,经RF电路1010以发送给比如另一手机,或者将音频数据输出至存储器1020以便进一步处理。
WiFi属于短距离无线传输技术,手机通过WiFi模块1070可以帮助用户收发电子邮件、浏览网页和访问流式媒体等,它为用户提供了无线的宽带互联网访问。虽然图10示出了WiFi模块1070,但是可以理解的是,其并不属于手机的必须构成,完全可以根据需要在不改变发明的本质的范围内而省略。
处理器1080是手机的控制中心,利用各种接口和线路连接整个手机的各个部分,通过运行或执行存储在存储器1020内的软件程序和/或模块,以及调用存储在存储器1020内的数据,执行手机的各种功能和处理数据,从而对手机进行整体监控。可选的,处理器1080可包括一个或多个处理单元;处理器1080可集成应用处理器和调制解调处理器,其中,应用处理器主要处理操作系统、用户界面和应用程序等,调制解调处理器主要处理无线通信。可以理解的是,上述调制解调处理器也可以不集成到处理器1080中。
手机还包括给各个部件供电的电源1090(比如电池),电源可以通过电源管理系统与处理器1080逻辑相连,从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。
尽管未示出,手机还可以包括摄像头、蓝牙模块等,在此不再赘述。
上述实施例中由移动终端所执行的步骤可以基于图10所示的移动终端结构。
本申请实施例还提供了计算机存储介质,该计算机存储介质用于储存为上述终端所用的计算机软件指令,其包括用于执行为上述移动终端所设计的程序。
本申请实施例还提供了计算机程序产品,该计算机程序产品包括计算机软件指令,该计算机软件指令可通过处理器进行加载来实现上述图2中文件处理方法中的流程。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。
所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出
来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(英文全称:Read-Only Memory,英文缩写:ROM)、随机存取存储器(英文全称:Random Access Memory,英文缩写:RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。