CN113254263A

CN113254263A - Electronic terminal and file recovery method

Info

Publication number: CN113254263A
Application number: CN202010091036.0A
Authority: CN
Inventors: 姚巧丽
Original assignee: Hisense Mobile Communications Technology Co Ltd
Current assignee: Hisense Mobile Communications Technology Co Ltd
Priority date: 2020-02-13
Filing date: 2020-02-13
Publication date: 2021-08-13

Abstract

The invention relates to an electronic terminal and a file recovery method, relating to the technical field of Internet, and aiming at solving the problem that in the process of recovering a file corresponding to a lost directory structure in the related art, all files need to be recovered, and the corresponding files needing to be recovered are searched in all files, so that the recovery efficiency is lower, the method comprises the following steps: the user input unit is used for receiving a file type recovery instruction triggered by a user; the processor is used for responding to a file type recovery instruction triggered by a user and writing partition data in a preset partition of the built-in memory into the memory; searching corresponding partition data from a memory according to the file structure characteristics of the target file type corresponding to the file type recovery instruction; and restoring the partition data into a file corresponding to the target file type. The embodiment of the invention can recover all the files of the file type corresponding to the file which the user wants to recover, so that the user searches the corresponding wanted file from all the recovered files of the file type, and the efficiency of recovering the file is improved.

Description

Electronic terminal and file recovery method

Technical Field

The invention relates to the technical field of internet, in particular to an electronic terminal and a file recovery method.

Background

In the process of storing the file, the electronic terminal stores the related data in the built-in memory and establishes a directory structure for recording the corresponding position information when the built-in memory stores the related data, so that the data in the built-in memory can be checked through the directory structure. For example, when a user takes a photo through the electronic terminal, the photo is stored in the internal memory, the directory structure records the position of the photo in the internal memory, and when the user wants to view the photo, the photo can be accessed through the directory structure. When the electronic terminal is halted or the user presses the touch key for a long time to trigger the electronic terminal to be powered off and restart the electronic terminal, the above situation may cause part of the directory structure to be lost, that is, the user cannot access the file corresponding to the lost part of the directory structure.

In the existing process of recovering files corresponding to a lost directory structure, all data of a built-in memory in an electronic terminal are generally stored in other terminals, all data in the built-in memory are recovered on the other terminals, and then the files corresponding to the lost directory structure are found out through one-to-one searching. For example, when data of a picture in a mobile phone cannot be accessed, the mobile phone is connected with a computer, original data of a built-in memory in the mobile phone is stored in the computer, all files are restored on the computer, and a user can find the corresponding picture from the restored files.

In summary, in the process of recovering the file corresponding to the lost directory structure in the related art, the recovery process is complicated, and the recovery efficiency is low.

Disclosure of Invention

The invention provides an electronic terminal and a file recovery method, which are used for recovering a file corresponding to a target file type through a file structure characteristic of the target file type corresponding to a file type recovery instruction.

In a first aspect, an embodiment of the present invention provides an electronic terminal, including: a processor, a built-in memory and a user input unit;

the user input unit is used for receiving a file type recovery instruction triggered by a user;

the built-in memory is used for storing data of a plurality of file types;

the processor is used for responding to a file type recovery instruction triggered by a user and writing partition data in a preset partition of the built-in memory into the memory;

searching corresponding partition data from a memory according to the file structure characteristics of the target file type corresponding to the file type recovery instruction;

and restoring the partition data into a file of a corresponding target file type.

According to the electronic terminal, after a file type recovery instruction triggered by a user is responded, data in the built-in storage is written into the memory, partition data which accord with the target file type is searched from the memory according to the file structure characteristics of the target file type corresponding to the file recovery instruction, and therefore the partition data of the target file type can be recovered into the file.

In a possible implementation manner, the processor is specifically configured to search the corresponding partition data from the memory by one of the following manners:

the first method is as follows: searching data corresponding to the head characteristic of the file and data corresponding to the tail characteristic of the file from the memory;

determining partition data corresponding to the type of the target file according to the data corresponding to the head characteristic of the file and the data corresponding to the tail characteristic of the file;

the second method comprises the following steps: searching data corresponding to the file header characteristics from the memory;

determining the size of the file according to the offset address corresponding to the file header characteristic;

determining partition data corresponding to the type of the target file according to the data corresponding to the file header characteristics and the size of the file;

the third method comprises the following steps: searching data corresponding to the file header characteristics from the memory;

determining the size of the file according to the offset address corresponding to the file attribute object feature searched from the memory;

and determining partition data corresponding to the target file type according to the data corresponding to the file header characteristics and the file size.

The electronic terminal searches partition data corresponding to the target file type through the file head characteristic and the file tail characteristic, or searches the partition data corresponding to the target file type through the file head characteristic and the file size, or searches the partition data corresponding to the target file type through the file head characteristic, the file attribute object characteristic and the file size, and can search data of different file types through the three methods.

In one possible implementation form of the method,

when the corresponding target file type is a GIF file or a PNG file, searching corresponding partition data from a memory in a first mode;

when the corresponding target file type is a BMP file or an M4A file, searching corresponding partition data from the memory by adopting a second mode;

and when the corresponding target file type is the WMA file, searching corresponding partition data from the memory by adopting a third mode.

The electronic terminal can recover the type of the target file to be a GIF file, a PNG file, a BMP file, an M4A file or a WMA file.

In one possible implementation, the processor is specifically configured to:

determining that the searched partition data meets the limiting condition of the target file type;

if the target file type is a GIF file, the limiting conditions are as follows:

the data stored at the preset offset address is the version number of the file, wherein the preset offset address is an address with an interval preset offset behind the offset address corresponding to the file header characteristic; or

If the corresponding target file type is a BMP file, the restriction condition includes part or all of the following conditions:

the data stored at the first preset offset address is within the length range of a preset BMP file header; the first preset offset address is an address which is spaced by a first preset offset and behind an offset address corresponding to the file header characteristic;

the data stored at the second preset offset address is within the preset BMP picture width range; the second preset offset address is an address which is spaced by a second preset offset and behind an offset address corresponding to the file header characteristic;

the data stored at a third preset offset address is larger than the height of a threshold BMP picture, wherein the third preset offset address is an address which is spaced by a third preset offset after the offset address corresponding to the file header characteristic; or

If the corresponding target file type is a PNG file, the limiting condition comprises part or all of the following conditions:

the data stored at the first preset offset address is within a preset PNG picture height range; the first preset offset address is an address which is spaced by a first preset offset and behind an offset address corresponding to a first data block;

the data stored at the second preset offset address is within the preset PNG picture width range; the second preset offset address is an address which is spaced by a second preset offset and is behind an offset address corresponding to the first data block; or

If the corresponding target file type is a WMV file, the limiting condition comprises part or all of the following conditions:

storing data at the first preset offset address to be not less than a first preset value; the first preset offset address is an address which is spaced by a first preset offset and behind an offset address corresponding to the file header characteristic;

the data stored at the second preset offset address is not less than a second preset value; the second preset offset address is an address which is spaced by a second preset offset and behind an offset address corresponding to the file header characteristic;

the data stored at the third preset offset address is not equal to the third preset value; the third preset offset address is an address which is spaced by a third preset offset and behind an offset address corresponding to the file header characteristic; or

If the corresponding target file type is an M4A file, the restriction condition includes some or all of the following conditions:

the data stored at the first preset offset address is in a preset M4A file size range, wherein the preset offset address is an address of an interval preset offset after the offset address corresponding to the file header;

and the data of the M4A file type is contained in the size range corresponding to the data stored at the preset offset address.

Because the data of the target file type is searched through the corresponding data, the matching is not accurate generally, and based on the result, when the searched partition data meets the limiting condition of the target file type, the electronic terminal can determine that the data inside the data also meets the corresponding target file type, so that the correctness of searching the corresponding target file type can be improved. Specifically, the accuracy of restoring a GIF file, a PNG file, a BMP file, an M4A file, or a WMA file, which is a target file type, can be improved by determining whether the specific information in the searched partition data satisfies a restriction condition that the target file type is the GIF file, the PNG file, the BMP file, the M4A file, or the WMA file.

In one possible implementation, the processor is further configured to:

and responding to a file saving instruction selected by a user, and saving the target file indicated by the file saving instruction in an external memory from the restored files corresponding to the target file type.

After the partition data is restored to the files of the corresponding target file types, the electronic terminal responds to the file saving instruction selected by the user, and the target file indicated by the file saving instruction is saved in the external memory from the files, so that the user can access the restored files through the external memory.

In a second aspect, a file recovery method provided in an embodiment of the present invention includes:

responding to a file type recovery instruction triggered by a user, and writing partition data in a preset partition of a built-in memory into a memory;

In one possible implementation, the corresponding partition data is searched from the memory by one of the following methods:

In a possible implementation manner, when the corresponding target file type is a GIF file or a PNG file, searching corresponding partition data from a memory in a first manner;

In a possible implementation manner, after searching for corresponding partition data from a memory according to a file structure feature of a target file type corresponding to the file type recovery instruction and before recovering the partition data to a file of the target file type, the method further includes:

if the target file type is a GIF file, the limiting conditions are as follows:

In a possible implementation manner, after restoring the partition data to a file of a corresponding target file type, the method further includes:

In a third aspect, the present application further provides a computer storage medium having a computer program stored thereon, which when executed by a processing unit, performs the steps of the electronic terminal of the first aspect.

In addition, for technical effects brought by any one implementation manner of the second aspect to the third aspect, reference may be made to technical effects brought by different implementation manners of the first aspect, and details are not described here.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and together with the description, serve to explain the principles of the invention and are not to be construed as limiting the invention.

Fig. 1 is a schematic structural diagram of an electronic terminal according to an embodiment of the present invention;

fig. 2 is a schematic diagram of a software architecture of an electronic terminal according to an embodiment of the present invention;

FIG. 3 is a flowchart of a file recovery method according to an embodiment of the present invention;

FIG. 4 is a flowchart of another file recovery method according to an embodiment of the present invention;

FIG. 5 is a flowchart illustrating a method for searching for a GIF file in a memory according to an embodiment of the present invention;

FIG. 6 is a flowchart illustrating a method for searching for a BMP file in a memory according to an embodiment of the present invention;

fig. 7 is a flowchart of searching for a PNG file in a memory according to an embodiment of the present invention;

fig. 8 is a flowchart of searching for a WMA file in a memory according to an embodiment of the present invention;

fig. 9 is a block diagram of a Box file of M4A according to an embodiment of the present invention;

fig. 10 is a flowchart of searching for an M4A file in a memory according to an embodiment of the present invention;

FIG. 11 is a complete flow chart of file recovery provided by the embodiments of the present invention;

FIG. 12 is a flowchart of a method for restoring a GIF file according to an embodiment of the present invention;

FIG. 13 is a flowchart of a method for restoring a BMP file according to an embodiment of the present invention;

fig. 14 is a flowchart of a method for recovering a PNG file according to an embodiment of the present invention;

fig. 15 is a flowchart of a method for restoring a WMA file according to an embodiment of the present invention;

FIG. 16 is a flowchart of a method for restoring an M4A file according to an embodiment of the present invention;

FIG. 17 is a diagram illustrating a user interface of an electronic terminal when a user triggers a file restore instruction according to an embodiment of the present invention;

FIG. 18 is a schematic diagram of a user interface for file recovery function in an electronic terminal according to an embodiment of the present invention;

FIG. 19 is a schematic diagram of another user interface for file recovery functions in an electronic terminal according to an embodiment of the present invention;

fig. 20 is a structural diagram of another electronic terminal according to an embodiment of the present invention.

Detailed Description

In order to make those skilled in the art better understand the technical solution of the present invention, the technical solution in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings.

It should be noted that the terms "first," "second," and the like in the description and claims of the present invention and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the invention described herein are capable of operation in sequences other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the invention, as detailed in the appended claims.

Some of the words that appear in the text are explained below:

1. the term "and/or" in the embodiments of the present invention describes an association relationship of associated objects, and indicates that three relationships may exist, for example, a and/or B may indicate: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.

2. The term "electronic terminal" in the embodiments of the present invention refers to any intelligent electronic device capable of automatically processing a large amount of data at a high speed according to a program, and includes a mobile phone, a computer, a tablet, an intelligent terminal, a multimedia device, a streaming media device, and the like.

The application scenario described in the embodiment of the present invention is for more clearly illustrating the technical solution of the embodiment of the present invention, and does not form a limitation on the technical solution provided in the embodiment of the present invention, and it can be known by a person skilled in the art that with the occurrence of a new application scenario, the technical solution provided in the embodiment of the present invention is also applicable to similar technical problems. Wherein, in the description of the present invention, unless otherwise indicated, "a plurality" means.

When the electronic terminal is halted or the electronic terminal is restarted due to power failure abnormality caused by long-time pressing of the touch key, part of the directory structure is lost, so that the directory structure cannot be normally accessed to the lost part of the corresponding files.

The invention provides a file recovery method, which is characterized in that under the condition that a directory structure is lost, original data are still stored in a built-in memory, and therefore, a file type recovery instruction corresponding to a file with the lost directory structure is used for searching corresponding partition data from a memory according to the file structure characteristics of the file type corresponding to the file with the lost directory structure, so that the file with the corresponding target file type can be recovered, and the file corresponding to the lost directory structure can be recovered.

The method is applied to the electronic terminal. Fig. 1 shows a schematic configuration of a communication terminal 100.

The following describes an embodiment specifically taking the communication terminal 100 as an example. It should be understood that the communication terminal 100 shown in fig. 1 is only an example, and the communication terminal 100 may have more or less components than those shown in fig. 1, may combine two or more components, or may have a different configuration of components. The various components shown in the figures may be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and/or application specific integrated circuits.

A block diagram of a hardware configuration of a communication terminal 100 according to an exemplary embodiment is exemplarily shown in fig. 1. As shown in fig. 1, the communication terminal 100 includes: a Radio Frequency (RF) circuit 110, a memory 120, a display unit 130, a camera 140, a sensor 150, an audio circuit 160, a Wireless Fidelity (Wi-Fi) module 170, a processor 180, a bluetooth module 181, and a power supply 190.

The RF circuit 110 may be used for receiving and transmitting signals during information transmission and reception or during a call, and may receive downlink data of a base station and then send the downlink data to the processor 180 for processing; the uplink data may be transmitted to the base station. Typically, the RF circuitry includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier, a duplexer, and the like.

The memory 120 may be used to store software programs and data. The processor 180 executes various functions of the communication terminal 100 and data processing by executing software programs or data stored in the memory 120. The memory 120 may include high speed random access memory and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device. The memory 120 stores an operating system that enables the communication terminal 100 to operate. The memory 120 may store an operating system and various application programs, and may also store codes for performing the methods described in the embodiments of the present application.

The display unit 130 may be used to receive input numeric or character information and generate signal input related to user settings and function control of the communication terminal 100, and particularly, the display unit 130 may include a touch screen 131 disposed on the front surface of the communication terminal 100 and may collect touch operations of a user thereon or nearby, such as clicking a button, dragging a scroll box, and the like.

The display unit 130 may also be used to display a Graphical User Interface (GUI) of information input by or provided to the user and various menus of the terminal 100. Specifically, the display unit 130 may include a display screen 132 disposed on the front surface of the communication terminal 100. The display screen 132 may be configured in the form of a liquid crystal display, a light emitting diode, or the like. The display unit 130 may be used to display various graphical user interfaces described herein.

The touch screen 131 may cover the display screen 132, or the touch screen 131 and the display screen 132 may be integrated to implement the input and output functions of the communication terminal 100, and after the integration, the touch screen may be referred to as a touch display screen for short. In the present application, the display unit 130 may display the application programs and the corresponding operation steps.

The camera 140 may be used to capture still images or video. The object generates an optical image through the lens and projects the optical image to the photosensitive element. The photosensitive element may be a Charge Coupled Device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The light sensing elements convert the light signals into electrical signals which are then passed to the processor 180 for conversion into digital image signals.

The communication terminal 100 may further comprise at least one sensor 150, such as an acceleration sensor 151, a distance sensor 152, a fingerprint sensor 153, a temperature sensor 154. The communication terminal 100 may also be configured with other sensors such as a gyroscope, barometer, hygrometer, thermometer, infrared sensor, optical sensor, motion sensor, and the like.

The audio circuitry 160, speaker 161, microphone 162 may provide an audio interface between a user and the communication terminal 100. The audio circuit 160 may transmit the electrical signal converted from the received audio data to the speaker 161, and convert the electrical signal into a sound signal for output by the speaker 161. The communication terminal 100 may also be provided with a volume button for adjusting the volume of the sound signal. On the other hand, the microphone 162 converts the collected sound signal into an electrical signal, converts the electrical signal into audio data after being received by the audio circuit 160, and outputs the audio data to the RF circuit 110 to be transmitted to, for example, another terminal or outputs the audio data to the memory 120 for further processing. In this application, the microphone 162 may capture the voice of the user.

Wi-Fi belongs to a short-distance wireless transmission technology, and the communication terminal 100 may help a user to send and receive e-mails, browse webpages, access streaming media, and the like through the Wi-Fi module 170, which provides a wireless broadband internet access for the user.

The processor 180 is a control center of the communication terminal 100, connects various parts of the entire terminal using various interfaces and lines, and performs various functions of the communication terminal 100 and processes data by running or executing software programs stored in the memory 120 and calling data stored in the memory 120. In some embodiments, processor 180 may include one or more processing units; the processor 180 may also integrate an application processor, which mainly handles operating systems, user interfaces, applications, etc., and a baseband processor, which mainly handles wireless communications. It will be appreciated that the baseband processor described above may not be integrated into the processor 180. In the present application, the processor 180 may run an operating system, an application program, a user interface display, and a touch response, and the processing method described in the embodiments of the present application. Further, the processor 180 is coupled with the display unit 130.

And the bluetooth module 181 is configured to perform information interaction with other bluetooth devices having a bluetooth module through a bluetooth protocol. For example, the communication terminal 100 may establish a bluetooth connection with a wearable electronic device (e.g., a smart watch) having a bluetooth module via the bluetooth module 181, so as to perform data interaction.

The communication terminal 100 also includes a power supply 190 (such as a battery) to power the various components. The power supply may be logically connected to the processor 180 through a power management system to manage charging, discharging, power consumption, etc. through the power management system. The communication terminal 100 may also be configured with power buttons for powering the terminal on and off, and for locking the screen.

Fig. 2 is a block diagram of a software configuration of the communication terminal 100 according to the embodiment of the present invention.

The layered architecture divides the software into several layers, each layer having a clear role and division of labor. The layers communicate with each other through a software interface. In some embodiments, the Android system is divided into four layers, an application layer, an application framework layer, an Android runtime (Android runtime) and system library, and a kernel layer from top to bottom.

The application layer may include a series of application packages.

As shown in fig. 2, the application package may include applications such as camera, gallery, calendar, phone call, map, navigation, WLAN, bluetooth, music, video, short message, etc.

The application framework layer provides an Application Programming Interface (API) and a programming framework for the application program of the application layer. The application framework layer includes a number of predefined functions.

As shown in FIG. 2, the application framework layers may include a window manager, content provider, view system, phone manager, resource manager, notification manager, and the like.

The window manager is used for managing window programs. The window manager can obtain the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like.

The content provider is used to store and retrieve data and make it accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

The view system includes visual controls such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, the display interface including the short message notification icon may include a view for displaying text and a view for displaying pictures.

The phone manager is used to provide a communication function of the communication terminal 100. Such as management of call status (including on, off, etc.).

The resource manager provides various resources for the application, such as localized strings, icons, pictures, layout files, video files, and the like.

The notification manager enables the application to display notification information in the status bar, can be used to convey notification-type messages, can disappear automatically after a short dwell, and does not require user interaction. Such as a notification manager used to inform download completion, message alerts, etc. The notification manager may also be a notification that appears in the form of a chart or scroll bar text at the top status bar of the system, such as a notification of a background running application, or a notification that appears on the screen in the form of a dialog window. For example, text information is prompted in the status bar, a prompt tone is given, the communication terminal vibrates, and an indicator light flashes.

The Android Runtime comprises a core library and a virtual machine. The Android runtime is responsible for scheduling and managing an Android system.

The core library comprises two parts: one part is a function which needs to be called by java language, and the other part is a core library of android.

The application layer and the application framework layer run in a virtual machine. And executing java files of the application program layer and the application program framework layer into a binary file by the virtual machine. The virtual machine is used for performing the functions of object life cycle management, stack management, thread management, safety and exception management, garbage collection and the like.

The system library may include a plurality of functional modules. For example: surface managers (surface managers), Media Libraries (Media Libraries), three-dimensional graphics processing Libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), and the like.

The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications.

The media library supports a variety of commonly used audio, video format playback and recording, and still image files, among others. The media library may support a variety of audio-video encoding formats, such as MPEG4, h.264, MP3, AAC, AMR, JPG, PNG, and the like.

The three-dimensional graphic processing library is used for realizing three-dimensional graphic drawing, image rendering, synthesis, layer processing and the like.

The 2D graphics engine is a drawing engine for 2D drawing.

The kernel layer is a layer between hardware and software. The inner core layer at least comprises a display driver, a camera driver, an audio driver and a sensor driver.

The following exemplifies the workflow of the software and hardware of the communication terminal 100 in connection with capturing a photographing scene.

When the touch screen 131 receives a touch operation, a corresponding hardware interrupt is issued to the kernel layer. The kernel layer processes the touch operation into an original input event (including touch coordinates, a time stamp of the touch operation, and other information). The raw input events are stored at the kernel layer. And the application program framework layer acquires the original input event from the kernel layer and identifies the control corresponding to the input event. Taking the touch operation as a touch click operation, and taking a control corresponding to the click operation as a control of a camera application icon as an example, the camera application calls an interface of an application framework layer, starts the camera application, further starts a camera drive by calling a kernel layer, and captures a still image or a video through the camera 140.

The communication terminal 100 in the embodiment of the present application may be a mobile phone, a tablet computer, a wearable device, a notebook computer, a television, and the like.

The following describes the file recovery method according to an embodiment of the present invention in detail with reference to the accompanying drawings, as shown in fig. 3, the file recovery method specifically includes the following steps:

s300: and responding to a file type recovery instruction triggered by a user, and writing partition data in a preset partition of the built-in memory into the memory.

The built-in memory is used for storing file data in the electronic terminal.

S301: and searching corresponding partition data from the memory according to the file structure characteristics of the target file type corresponding to the file type recovery instruction.

The file structure feature refers to an inherent feature of a data structure of a file type, for example, in a file of a GIF type, a file header feature is: GIF, file tail characteristics: \ x00\ x3 b.

S302: and restoring the partition data into a file corresponding to the target file type.

Specifically, a function of partition data corresponding to a target file type is called to generate a file corresponding to the target file type. For example, when the partition data is the original data corresponding to the GIF, then the generation is invoked, GIF is a function of the file suffix, and the partition data generates the file of the GIF file suffix.

And when the partition data is the original data corresponding to the BMP, calling the generated BMP as a function of the file suffix, so that the partition data is generated.

And when the partition data is the original data corresponding to the PNG, calling the generated PNG as a function of the file suffix, so that the partition data generates a file of the PNG file suffix.

And when the partition data is the original data corresponding to the WMV, calling the generated WMV as a function of the file suffix, so that the partition data generates a WMV file suffix.

When the partition data is the original data corresponding to M4A, the generate.m 4a is invoked as a function of the file suffix, such that the partition data generates the file of the.m 4a file suffix.

According to the scheme, the method and the device for restoring the file type respond to the file type restoring instruction triggered by the user, find out the data of the corresponding target file type in the built-in memory according to the file structure characteristics of the file type restoring instruction corresponding to the target file type, and restore the data into the file of the corresponding target file type, so that the file restoring efficiency is improved.

In view of the fact that the size of data in the internal storage is larger than the size of data storable in the internal storage, the present invention proposes to perform processing on a partition-by-partition basis, and for an example, with reference to fig. 4, a file recovery method includes:

s400: and responding to a file type recovery instruction triggered by a user, and writing partition data in a preset partition of the built-in memory into the memory.

S401: and traversing the data in the memory according to the file structure characteristics of the target file type corresponding to the file type recovery instruction, and searching the corresponding partition data.

S402: and restoring the partition data into a file corresponding to the target file type.

S403: and judging whether all data in the memory are completely traversed. If yes, step S404 is executed, and if no, the process returns to step S401.

S404: and judging whether the partition in the built-in memory is not read into the memory. If yes, step S400 is executed, and if no, the process is ended.

In detail, the partition data in one partition is written into the memory, the corresponding partition data is searched from the memory according to the file structure characteristics of the target file type corresponding to the file type recovery instruction, the corresponding partition data is recovered to the file of the target file type, then the partition data in another partition is written into the memory, and the processing is continued until the partition data in all the built-in memories are processed according to the steps, and then the processing is finished.

In addition, the invention can read according to the subareas, and can write the data with the preset size in the built-in memory into the memory when responding to a file type recovery instruction triggered by a user, wherein the data with the preset size can be adjusted according to the residual condition of the memory.

In order to enable a user to normally access the files with the lost directory structure on the electronic terminal, the invention also provides a method for responding to the file saving instruction selected by the user after restoring the partition data into the files with the corresponding target file types, and saving the target files indicated by the file saving instruction in the external memory from the restored files with the corresponding target file types. Thus, a user can view the file by accessing the external memory.

The external memory may be a T-card (T-Flash card, Flash memory card). The T card is installed on the electronic terminal and is used as an external memory.

Specifically, after the target file type selected by the user is recovered, the target file type is displayed to the user for viewing, the user triggers a file storage instruction, the corresponding file is selected from the files corresponding to the target file type and stored in the external memory, and then the recovered file is changed from the internal memory to the external memory in the access path.

Because the file structures corresponding to each file type are different, the modes of searching the corresponding partition data from the memory are also different according to the file structure characteristics of the target file type corresponding to the file type recovery instruction.

1. The corresponding target file type is a GIF (Graphics Interchange Format) file.

The GIF file stores information about an image in units of data blocks (blocks). One GIF file is composed of a Data block representing graphics/images, a Data sub-block, and a control information block displaying graphics/images, and is called a GIF Data Stream (Data Stream). All control information blocks and data blocks in the data stream must be between the Header (Header) and the end of file block (Trailer).

As shown in table 1, the File structure corresponding to the GIF File includes three parts, i.e., a File Header (File Header), a GIF Data Stream (GIF Data Stream), and a File terminator (Trailer). The header contains the GIF file Signature (Signature, specified as "GIF") and Version number (Version, which may be "87a" or "89 a"); the GIF data stream is composed of a control identifier, an Image Block (Image Block) and other extension blocks; the file terminator has only one character (';') with a value of 0x3B to indicate the end of the file.

TABLE 1

The file structure characteristic corresponding to the GIF file is a file head characteristic 'GIF', and a file tail characteristic \ x00\ x3 b. Therefore, when the corresponding target file type is the GIF file, the manner of searching the corresponding partition data from the memory is as follows:

searching data corresponding to the head characteristic of the file and data corresponding to the tail characteristic of the file from the memory;

and determining partition data corresponding to the type of the target file according to the data corresponding to the head characteristic of the file and the data corresponding to the tail characteristic of the file.

In practical applications, the memory includes memory addresses and storage units, and each memory address corresponds to one or more data in the storage unit. When the memory address of the data stored in the memory is known, the data stored at the memory address can be determined. Therefore, the method specifically comprises the following steps:

finding out an offset address corresponding to data corresponding to the file head characteristic in the memory and an offset address corresponding to data corresponding to the file tail characteristic in the memory from the memory; the offset address is a memory address of offset calculated from the base address, for example, the memory address is 0F00H — 0F0FH, 0F00H is the base address, when the address previously offset by 05H bytes from the base address is 0F05H, 0F05H is the offset address, and 05H is the offset.

Determining a plurality of memory addresses between an offset address corresponding to the file head characteristic and an offset address corresponding to the file tail characteristic; and taking the partition data corresponding to the plurality of memory addresses as the partition data corresponding to the target file type. The plurality of memory addresses comprise an offset address corresponding to a file head characteristic, an offset address corresponding to a file tail characteristic, and addresses between the offset address corresponding to the file head characteristic and the offset address corresponding to the file tail characteristic.

As an example, in connection with fig. 5, the process of GIF file recovery is:

s500: traversing data in the memory, searching for the GIF data, and recording an offset address corresponding to the GIF data; finding the file header characteristics of the GIF file;

s501: traversing data in the memory, searching for the "\ x00\ x3 b" data, and recording the offset address corresponding to the "\ x00\ x3 b" data; finding the tail characteristic of the GIF file;

s502: and obtaining the partition data of the GIF file according to the offset address corresponding to the 'GIF' data and the offset address corresponding to the '\ x00\ x3 b' data.

2. The corresponding target file type is a BMP (Bitmap) file.

BMP files, also known as bitmaps or DIB (Device-Independent Bitmap), are widely used image file formats in Windows systems. Since it can store data of an image pixel domain without any transformation, it becomes an important source for obtaining RAW data. The graphical user interface (graphical user interfaces) of Windows also provides support for BMP formats in its built-in image subsystem GDI.

As shown in table 2, the file structure corresponding to the BMP file is: the file header, the bitmap information header, the color information and the graphic data. The image file header is specifically as follows in table 2:

TABLE 2

The file structure characteristic corresponding to the BMP file is a file header characteristic 'BM', and after an offset address corresponding to the file header characteristic is shifted backwards by 2 bytes, the offset address occupies 4 bytes and stores the size of the BMP file. Therefore, when the corresponding target file type is a BMP file, the manner of searching the corresponding partition data from the memory is as follows:

searching data corresponding to the file header characteristics from the memory;

determining the size of the file according to the offset address corresponding to the file header characteristic; namely, determining an offset address corresponding to data corresponding to the file header feature in the memory, and taking data stored in 4 bytes after shifting the offset address corresponding to the file header feature backward by 2 bytes as a file size. The storage format of the BMP file is small-end storage, where the small-end storage means that the low order of the data is stored in the low address of the memory, and the high order of the data is stored in the high address of the memory. Extracting the size of the file according to the characteristics of small-end storage;

and determining partition data corresponding to the type of the target file according to the data corresponding to the file header characteristics and the size of the file.

As an example, referring to fig. 6, the process of restoring the BMP file is as follows:

s600: traversing data in the memory, searching BM data, and recording offset addresses corresponding to the BM data; namely finding the file header characteristics of the BM files;

s601: shifting an offset address corresponding to BM data by 2 bytes backwards, occupying 4 bytes, and determining the size of a file;

s602: and obtaining partition data of the BMP file according to the offset address corresponding to the BM data and the file size.

3. The corresponding target file type is a PNG (Portable Network Graphic Format) file.

The PNG file is a lossless compressed bitmap graphics format. The design objective is to try to replace GIF and TIFF file formats while adding features that some GIF file formats do not have. PNG uses lossless data compression algorithms derived from LZ77, and is typically applied in JAVA programs, web pages, or S60 programs because it has a high compression ratio and a small volume of generated files.

As shown in table 3, the file structure corresponding to the PNG file is: the header is always described by a fixed-bit byte:

TABLE 3

Decimal number	137 80 78 71 13 10 26 10
		Hexadecimal number	89 50 4E 47 0D 0A 1A 0A

The first byte, 0x89, is out of range of ASCII characters to avoid some software from handling the PNG file as a text file. The remaining part of the file consists of more than 3 PNG data blocks (Chunk) in a specific order, so a standard PNG file structure should be as follows:

TABLE 4

PNG file mark

PNG data block

……

PNG data block

PNG data block (Chunk)

PNG defines two types of data blocks, one called critical chunks, which are standard data blocks, and the other called auxiliary chunks, which are optional data blocks. The key data blocks define 4 standard data blocks, each PNG file must contain them, and the PNG read-write software must support these data blocks. Although the PNG file specification does not require the PNG codec to encode and decode the optional data blocks, the specification calls for supporting the optional data blocks.

Table 5 below is the category of data blocks in the PNG, where the key data block parts we distinguish using a dark background.

TABLE 5

For simplicity we assume that in the PNG file we use, these 4 data blocks are stored in the above sequential order and all appear only once.

Data block structure

In the PNG file, each data block consists of 4 parts, as follows:

TABLE 6

The file structure characteristics corresponding to the PNG file are file head characteristics of \ x89\ x50\ x4e \ x47\ x0d \ x0a \ x1a \ x0a and file tail characteristics of IEND. Therefore, when the corresponding target file type is a PNG file, the manner of searching the corresponding partition data from the memory is as follows:

As shown in fig. 7, the process of recovering the PNG file is as follows:

s700: traversing data in a memory, searching for '\ x89\ x50\ x4e \ x47\ x0d \ x0a \ x1a \ x0 a' data, and recording offset addresses corresponding to the '\ x89\ x50\ x4e \ x47\ x0d \ x0a \ x1a \ x0 a' data; namely, finding the file header characteristic of the PNG file;

s701: traversing data in the memory, searching for 'IEND' data, and recording an offset address corresponding to the 'IEND' data; namely finding the file end character of the PNG file;

s702: and obtaining the partition data of the PNG file according to the offset addresses corresponding to the data of \ x89\ x50\ x4e \ x47\ x0d \ x0a \ x1a \ x0a and the data of 'IEND'.

4. The corresponding target file type is a WMV (Windows Media Video, Windows Media Video format) file.

WMV is a generic term for a series of video codecs developed by microsoft and its associated video coding formats, and is part of the microsoft Windows media framework. WMV contains three different codecs: as a competitor to RealVideo, WMV-original video compression technology was originally designed and developed for streaming applications over the Internet; another is a compression technique of WMV screens and WMV images to meet the needs of specific contents; after being standardized by the SMPTE (society of Motion Picture and Television Engineers), WMV version 9 was adopted as a distribution format for physical media, such as HD DVD and Blu-ray disc, so-called VC-1.

As shown in table 4, the file structure corresponding to the WMV file is: the basic unit of a WMV file is an "object", that is, a WMV is composed of a great many objects. The top-level objects are 3 commonly used, and the sequence of the objects in the file is as follows: a header Object (HeaderObject), a data Object (DataObject), an Index Object (Index Object), or a Simple Index Object (Simple Index Object). The first two objects are necessary and the index object is optional, but the index object is very important for the operations of lookup and fast forward and fast backward. User-defined objects may also be inserted between the data objects and the index objects.

All objects are distinguished by a 32-bit GUID, which is a globally unique object identifier, referred to simply as an "object ID". The top-level objects include a Header Object (Header Object), a Data Object (Data Object), a Simple Index Object (Simple Index Object), an Index Object (Index Object), a Media Object Index Object (Media Object Index Object), and a Time Code Index Object (Time Code Index Object); the second layer Object includes a file property Object (file properties Object), a stream property Object (stream properties Object), a header extension Object (header extension Object), a Codec List Object (Codec List Object), and an Extended directory Description (Extended Content Description Object). The corresponding object identifier, as shown in table 7.

The header object describes some information of all media streams. Such as author, song information, user's added command information, code rate of code stream, etc. The head object is also the only one in the top-level object that can contain two-level sub-objects, each sub-object corresponding to an information descriptor. The information in the header object must be parsed before the media stream data of the data object is used. The structure of the head object is shown in Table 8.

The stream attribute object is a two-layer object, which is a necessary object among the head objects. It defines the attributes of the media data in the file, as many streams as there are stream attribute objects. Its structure is shown in Table 9.

TABLE 7

Name (R)	Object ID
		Top level objects
Head object	3026B2758E66CF11A6D900AA0062CE6C
		Data object	3626B2758E66CF11A6D900AA0062CE6C
Simple index object	90080033B1E5CF1189F400A0C90349CB
		Indexing objects	D329E2D6DA35D111349000A0C90349BE
Media object index object	F803B1FEAD12644C0F842A1D2F7AD48C
		Time code index object	D03FB73C4A0C03483D95EDF7B6DD8F0C
Two-layer object
		File property object	A1DCAB8C47A9CF118EE400C00C205365
Stream attribute object	9107DCB7B7A9CF118EE600C00C205365
		Head extension object	B503BF5F2EA9CF118EE300C00C205365
Codec list object	4052D1861D31D011A3A400A0C90348F6
		Extended directory description	40A4D0D207E3D21197F000A0C95EA850

TABLE 8

Name (R)	Occupied byte	Description of the invention
			Object ID	16
Object size	8	> 30 bytes
			Number of children	4	Number of children in two layers
Retention
	1	1	Fixed value of 1
Retention 2				1	Fixed value of 2

TABLE 9

The file structure characteristic corresponding to the WMA file is a file header characteristic

"\\ x30\ x26\ xb2\ x75\ x8e \ x66\ xcf \ x11\ xA6\ xD9\ x00\ xAA \ x00\ x62\ xCE \ x 6C", the file attribute corresponds to the characteristic

"\\ xA1\ xDC \ xAB \ x8C \ x47\ xA9\ xCF \ x11\ x8E \ xE4\ x00\ xC0\ x0C \ x20\ x53\ x 65", and the offset address corresponding to the file attribute corresponding to the characteristic is shifted backwards by the offset address corresponding to 24 byte bytes to store data as the file size. Therefore, when the corresponding target file type is a WMA file, the way to search the corresponding partition data from the memory is:

Specifically, as shown in fig. 8, the process of restoring the WMA file is as follows:

s800: traversing data in the memory and searching

"\\ x30\ x26\ xb2\ x75\ x8e \ x66\ xcf \ x11\ xA6\ xD9\ x00\ xAA \ x00\ x62\ xCE \ x 6C" data are recorded and recorded

The offset address corresponding to the data of \ x30\ x26\ xb2\ x75\ x8e \ x66\ xcf \ x11\ xA6\ xD9\ x00\ xA \ x00\ x62\ xCE \ x 6C'; finding the file header characteristics of the WMA file;

s801: traversing data in the memory and searching

"\\ xA1\ xDC \ xAB \ x8C \ x47\ xA9\ xCF \ x11\ x8E \ xE4\ x00\ xC0\ x0C \ x20\ x53\ x 65" data are recorded and recorded

The offset address corresponding to the data of \ xA1\ xDC \ xAB \ x8C \ x47\ xA9\ xCF \ x11\ x8E \ xE4\ x00\ xC0\ x0C \ x20\ x53\ x65 "; finding the file attribute object characteristics of the WMA file;

s802: will be provided with

The data stored by shifting the offset address corresponding to the \ xA1\ xDC \ xAB \ x8C \ x47\ xA9\ xCF \ x11\ x8E \ xE4\ x00\ xC0\ x0C \ x20\ x53\ x 65' backward by 24 bytes is determined as the file size;

s803: according to

"\\ x30\ x26\ xb2\ x75\ x8e \ x66\ xcf \ x11\ xA6\ xD9\ x00\ xA \ x00\ x62\ xCE \ x 6C" data and file size, so as to obtain the partition data of the WMA file.

5. The corresponding target file type is an M4A file.

M4A is an extension of a file of the MPEG (Moving Picture Expert Group) 4 audio standard, which is an audio file. Currently, the mainstream mobile phones support the recording file format as M4A format. The advantages of the M4A document include mainly the following:

the M4A file can be compressed and has lossless sound quality, and can be stored in a smaller file on the premise of original quality.

The M4A audio file is unprotected and can be easily transferred without license or payment.

The M4A audio can be set as an iPhone ring tone by directly changing the file extension M4A to M4R.

The file structure corresponding to the M4A file is: the M4A format is a box tree composed of individual boxes, and all data is contained in the boxes, and the basic structure of the boxes will be described below. A box is composed of a box header and data contained within the box, as shown in connection with FIG. 9.

The entire box is started with a box header, which includes information such as the size (size) and type (type) of the box. Wherein size indicates the size occupied by the whole box, including the header portion; type is box type, and the legal types currently defined are: free, mdat, wide, PICT, trak, mp3, moov, and the like.

The file structure characteristic corresponding to the M4A file is a file header characteristic "ftyp", and an offset address corresponding to the file header characteristic is shifted backwards by 4 bytes, and the size of the M4A file is stored. Therefore, when the corresponding target file type is the M4A file, the manner of searching the corresponding partition data from the memory is as follows:

As shown in fig. 10, the process of recovering the M4A file is as follows:

s1000: traversing data in the memory, searching for 'ftyp' data, and recording an offset address corresponding to the 'ftyp' data; namely, finding the file header characteristic of the M4A file;

s1001: the offset address corresponding to the ftyp data is offset backwards by 4 bytes, and the size of a box file is determined;

s1002: and obtaining partition data of the M4A file according to the offset address corresponding to the ftyp data, the size of one box file and the number of the box files. Determining the number of box files of the M4A file according to the ftyp data and the size of the file box;

although the data of the target file type can be obtained in the above manner, it is often inaccurate to find the target file type through the data of the corresponding characteristics, for example, for a file type with the main recorded data, some special data is likely to be recorded in the data, for example, "ftyp", and when the target file type is an M4A file, the file type with the main recorded data is likely to be recovered as an M4A file, so that the recovered file type is likely to be wrong in the above manner. Based on the above, the invention determines the searched partition data as the data of the corresponding target file type by adopting the restriction condition whether the interior of the data of the target file type also meets the corresponding target file type. Referring to fig. 11, an embodiment of the present invention provides another file recovery method, including:

s1100: responding to a file type recovery instruction triggered by a user, and writing partition data in a preset partition of a built-in memory into a memory;

s1101: searching corresponding partition data from a memory according to the file structure characteristics of the target file type corresponding to the file type recovery instruction;

s1102: determining that the searched partition data meets the limiting conditions of the target file type;

s1103: and restoring the partition data into a file corresponding to the target file type.

Due to different file types, the corresponding restriction conditions are also different.

1. If the target file type is a GIF file, the limiting conditions are as follows:

and the data stored at the preset offset address is the version number of the file, wherein the preset offset address is an address with an interval preset offset after the offset address corresponding to the file header characteristic.

Wherein, hereinafter, found is a variable.

The invention also provides a complete GIF file recovery method, which is shown in the combined figure 12 and comprises the following steps:

s1200: responding to a file type recovery instruction triggered by a user, and writing partition data in a preset partition of a built-in memory into a memory;

s1201: traversing the memory data, searching whether the GIF data exists or not, and if the GIF data exists, entering S1202; otherwise, jumping to 1206;

s1202: recording the offset address of the GIF data in the memory, and marking the offset address as found;

s1203: judging whether the found continuously deviates 4 bytes and is 9a or 7a, if so, jumping to S1204, otherwise, jumping to S1206; wherein, the version number introduced to the GIF file when introducing the file structure corresponding to the GIF file is: 9a or 7a, step 1203, is to determine whether the font continues to be shifted by 4 bytes is the version number corresponding to the GIF file.

S1204: continuously traversing the memory data to find whether the "\ x00\ x3 b" data exists. Finding out the GIF file when finding out the "\ x00\ x3 b" data, and jumping to S1205; otherwise, jumping to S1206;

s1205: taking the recorded 'GIF' data and the '\ x00\ x3 b' data and the data between the 'GIF' data and the '\ x00\ x3 b' data as corresponding partition data;

s1206: the current partition data is an illegal GIF file. That is, the data is not processed, and the file recovery is finished.

2. If the corresponding target file type is a BMP file, the constraint condition includes part or all of the following conditions, as shown in table 10:

watch 10

Based on the above limitation, an embodiment of the present invention provides a complete BMP file recovery method, which is shown in fig. 13 and includes:

s1300: responding to a file type recovery instruction triggered by a user, and writing partition data in a preset partition of a built-in memory into a memory;

s1301: traversing the memory data, searching whether BM data exist or not, and entering S1302 if the BM data exist; otherwise, jumping to S1308;

s1302, recording the offset address of the BM data in the memory, and marking as offset, wherein the offset address is used for subsequently positioning the position of the BMP file header;

s1303, offsetting the offset backwards by 14 bytes, occupying 4 bytes, and judging whether the stored data is between 0bytes and 1000bytes, wherein the offset backwards offsets by 14 bytes and occupies 4 bytes, the stored data is the length of a file header, the size of the BMP file header is generally larger than 1000bytes, and if so, jumping to S1304; otherwise, performing S1308;

s1304, offsetting the offset backwards by 18 bytes, occupying 4 bytes, and judging whether the stored data is between 0 and 3000bytes, wherein the offset is offset backwards by 18 bytes, occupying 4 bytes, the stored data is a picture bit width, the picture bit width of the BMP file is generally between 0 and 3000bytes, and if so, jumping to S1305; otherwise, performing S1308;

s1305, offsetting the offset backwards by 22 bytes and occupying 4 bytes, and judging whether the stored data is larger than 0, wherein the offset is offset backwards by 22 bytes and occupies 4 bytes, the stored data is the horizontal height of a picture, the horizontal height of the picture of the BMP file is generally larger than 0, and if so, jumping to S1306; otherwise, performing S1308;

s1306, the offset is shifted backwards by 2 bytes, and occupies 4 bytes, which is the size of the file;

s1307, restoring the data with offset position and file size in the memory;

s1308: determining that the data in the memory is a non-BMP file, and marking the current position as found + size of (BM), that is, the current position is an offset address corresponding to a file header plus a file size, where the current position indicates that none of the data above the current position is a BMP file.

It should be noted that the above process is only exemplary, and in an alternative embodiment, between S1302 and S1303, the following is further included:

recording the length from the BM data to the tail of the data read into the memory and marking as buf _ len;

judging whether buf _ len is smaller than 100; the size of the BMP file is generally larger than 100bytes, if so, reading data which takes offset as a starting point and size of 10M in the built-in memory to the memory, and continuously analyzing the BMP file;

otherwise, S1303 is executed.

After S1306, further comprising:

shifting the offset backward by 2 bytes, occupying 4 bytes, being the file size, and judging whether the stored data is larger than buf _ len, if so, indicating that the BMP file in the current memory is incomplete, reading the data which takes the offset as a starting point and has the size of 10M in the built-in memory to the memory, and continuing to analyze the BMP file, otherwise, performing S1307;

after S1307, further comprising: setting the current data position, and marking the current data position as found as offset + file _ size, namely the current partition position of the data already analyzed;

judging whether the last position of the memory data is read or not, if so, reading the data in the next partition into the memory, ending the BMP file analysis process until all the data in the built-in memory are analyzed, otherwise, executing S1301 and continuously traversing the data in the memory;

3. if the corresponding target file type is a PNG file, the restriction condition includes part or all of the following conditions, as shown in table 11:

TABLE 11

The first data block of the PNG file is a PNG file flag, and the subsequent data blocks are description contents. Therefore, the first data block is the first data block after the PNG file flag. The way of finding the offset address corresponding to the first data block is as follows: and finding the head characteristic of the PNG file, wherein the head characteristic of the PNG file is offset backwards by 8 bytes to be an offset address corresponding to the first data block.

Based on the above limitation, an embodiment of the present invention provides a complete PNG file recovery method, which is shown in fig. 14 and includes:

s1400: responding to a file type recovery instruction triggered by a user, and writing partition data in a preset partition of a built-in memory into a memory;

s1401, traversing the memory data, searching whether the data is "\ x89\ x50\ x4e \ x47\ x0d \ x0a \ x1a \ x0 a", and entering S1402 if the data is found; otherwise, jumping to S1406;

s1402, recording offset addresses of '\\ x89\ x50\ x4e \ x47\ x0d \ x0a \ x1a \ x0 a' in a memory, marking the offset addresses as buf, and recording a starting address of a data block, namely, buf +8 (the buf is offset backwards by 8 bytes);

s1403, recording whether the data stored in each 4 bytes of the found [8] and the found [12] is between 1 and 3000bytes, if so, considering the format of the picture as PNG, and jumping to S1404; otherwise, jumping to S1406; wherein, found [8] indicates that found is shifted backward by 8 bytes for the start position, and found [12] indicates that found is shifted backward by 12 bytes for the start position. The data stored at the foundation [8] is the width of the picture, the data stored at the foundation [12] is the height of the picture, and 3000bytes are the maximum width and the maximum height of the PNG picture.

In S1404, the data stored in the font [0] is the length of the current data block, and is marked as size, and when the font + [12], it is determined whether the data stored in the font + [4] is a character string, and whether the data stored in the font + [4] is "IEND", if yes, S1405 is executed, and if no, S1406 is executed. Where, found + size +12, indicates that found + is equal to the size of the current data block plus 12 characters. found + [4], found + is a 4 character shift backwards of the starting address.

S1405, determining the corresponding partitioned data by taking buf as the start and IEND as the end;

s1406: and determining that the data in the memory is a non-PNG file.

It should be noted that the above process is only exemplary, and in an alternative embodiment, after S1404, the method further includes:

the length of the data which is read from the subsequent found [0] to the memory and is not analyzed is marked as buf _ len, if the size is between 0 and buf _ len, the data in the memory is considered to be complete, whether the data stored at found + [4] is a character string or not is judged, and whether the data stored at found + [4] is 'IEND' or not is judged; otherwise, reading the data with offset as the starting point and size of 10M in the built-in memory to the memory, and continuing to analyze the BMP file.

After S1404, the method further includes:

calculating the file size, wherein the file size is file _ size ═ found-buf + found [0] +12, the data between the data corresponding to the position of the last marked found and the data corresponding to the file header feature, the length of the data block corresponding to the file header feature, the 12 characters, and the position of the last represented found of found is "IEND";

judging whether the file _ size is smaller than the buf _ len, if so, taking the data corresponding to the buf as initial data, and taking the data with the file _ size as the partition data of the corresponding PNG file;

otherwise, reading the data with offset as the starting point and size of 10M in the built-in memory to the memory, and continuing to analyze the BMP file.

After S1406, the method further includes:

when the data in the memory is determined to be a non-PNG file, setting the currently analyzed data position as found (the corresponding position is changed for the second time), changing found into offset + file _ size, judging whether found reaches the last position of the read memory data, if found points to the last position of the read data, reading the partition data which is not read before from the built-in memory into the memory for analysis until all the data in the built-in memory are analyzed.

Otherwise, continuously traversing the data in the memory and searching the PNG file.

4. If the corresponding target file type is a WMV file, the constraint condition includes part or all of the following conditions, as shown in table 12:

TABLE 12

Based on the above limitation, an embodiment of the present invention provides a complete PNG file recovery method, which is shown in fig. 15 and includes:

s1500, responding to a file type recovery instruction triggered by a user, and writing partition data in a preset partition of the built-in memory into a memory;

s1501, traversing the memory data to find whether the memory data exists

"\\ x30\ x26\ xb2\ x75\ x8e \ x66\ xcf \ x11\ xA6\ xD9\ x00\ xAA \ x00\ x62\ xCE \ x 6C" data, if found, go to S1502; otherwise, jumping to S1506;

s1502 recording

The offset address of the \ x30\ x26\ xb2\ x75\ x8e \ x66\ xcf \ x11\ xA6\ xD9\ x00\ xA \ x00\ x62\ xCE \ x6C "data in the memory is found;

s1503: judging whether the data stored in the found [16] is not less than 0, whether the data stored in the found [24] is not less than 0, and whether the data stored in the found [28] is not equal to 1, if yes, executing S1504, and if no, executing S1506; wherein, the found [16] is "\\ x30\ x26\ xb2\ x75\ x8e \ x66\ xcf \ x11\ xA6\ xD9\ x00\ xAA \ x00\ x62\ xCE \ x 6C" data, that is, the data corresponding to the file header characteristic is stored at the position of the offset address in the memory, which is offset backwards by 16 characters, the found [24] is the data corresponding to the file header characteristic, which is offset backwards by 24 characters in the memory, the data stored at the found [24] is the number of objects, the found [28] is the offset address in the memory, which is offset backwards by 28 characters, of the data corresponding to the file header characteristic, and the data stored at the found [28] is reserved.

S1504, continuously traversing the memory data to search

"\\ xA1\ xDC \ xAB \ x8C \ x47\ xA9\ xCF \ x11\ x8E \ xE4\ x00\ xC0\ x0C \ x20\ x53\ x 65" data, if found

"\\ xA1\ xDC \ xAB \ x8C \ x47\ xA9\ xCF \ x11\ x8E \ xE4\ x00\ xC0\ x0C \ x20\ x53\ x 65" is a file attribute object, and the file jumps to S1505; otherwise, jumping to S1506;

s1505: taking data with the starting position of the foundation and the size of total _ sz as partition data corresponding to the WMV file; wherein, in the following

The total size of a file stored at a position shifted backwards by 24 bytes and marked as total _ sz corresponding to the data of \ xA1\ xDC \ xAB \ x8C \ x47\ xA9\ xCF \ x11\ x8E \ xE4\ x00\ xC0\ x0C \ x20\ x53\ x65 ";

s1506: and determining the data in the memory partition as an illegal WMV file.

5. If the corresponding target file type is M4A file, the restriction conditions include part or all of the following conditions, as shown in table 13:

watch 13

It should be noted that the preset offset address is an address of a first preset offset at an interval after the offset address corresponding to the file header. Wherein, the process of obtaining the offset address corresponding to the file header of the start box is as follows: since the M4A file is composed of a box and the starting box includes a file header feature, the size of the starting box is found by shifting forward by 4 bytes from the "ftyp" data according to the file header feature "ftyp" data, and then the offset address corresponding to the file header of the starting box is determined according to the size of the starting box.

It should be noted that the data of the M4A file type is included in the size range corresponding to the data stored at the preset offset address, where the data stored at the preset offset address is the size of a box, and the data of the M4A file type is included in the size range of the box.

The data stored at the second preset offset address comprises data of the M4A file type.

Based on the above limitation, an embodiment of the present invention provides a complete PNG file recovery method, which is shown in fig. 16 and includes:

s1600, responding to a file type recovery instruction triggered by a user, and writing partition data in a preset partition of the built-in memory into the memory;

s1601: traversing the memory data, searching whether the ftyp data exists, and if the ftyp data exists, entering S1602; otherwise, jumping to S1608;

s1602: the starting position of the recording file header is buf, and box _ size is stored at the position where buf is read out and shifted forward by 4 bytes. Wherein buf is used to subsequently locate the position of the M4A audio file header;

s1603: judging whether the box _ size is larger than 0 and smaller than the threshold of the maximum data size of M4A; if yes, go to S1604, if no, go to S1608;

s1604, whether any one of free, mdat, wide, PICT, trak, mp3, or moov exists in the box _ size data; if so, executing S1605; if not, execute S1608;

s1605: determining that type of the current Box is true, and reading a threshold value of whether data stored at a position of found + Box _ size +4 is larger than 0 and smaller than the maximum data size of M4A, wherein the position of found + Box _ size +4 is the position of the start data of the Box with the head characteristic plus the size of the Box with the head characteristic is shifted backwards by 4 characters; if not, go to S1606; if yes, go to step S1604, continue to judge the type information in the current box until finding the last box in the M4A file;

s1606: judging whether the type in the current box records the information of true, if so, executing S1607, otherwise, executing S1608;

s1607: determining the current box as the last box of the M4A file, and determining partition data corresponding to the M4A file according to buf as a starting position, the number of the previously determined boxes and the size of the boxes;

s1608: and determining the corresponding partition data as the data corresponding to the non-M4A file.

In some optional embodiments, in step S1607, partition data corresponding to the M4A file is determined according to buf as a starting position, the number of previously determined boxes, and the size of the boxes, and may alternatively be determined according to the size of the last box satisfying the defined conditions of size and type, the last data of the last box satisfying the defined conditions is determined, and partition data corresponding to the M4A file is determined according to buf and the last data of the last box satisfying the defined conditions.

When the data in the memory is determined to be a non-M4A file, judging whether the current position has read the last position of the memory data, if so, reading the partition data which is not read before from the built-in memory into the memory for analysis until all the data in the built-in memory are analyzed.

Otherwise, the data in the memory is continuously traversed, and the M4A file is searched.

The file recovery method introduced above can be implemented by setting a file recovery function in an application in an electronic terminal, and the process of the user triggering a file recovery instruction is as follows: referring to fig. 17, a user clicks an icon of a setting application of the electronic terminal, and submenus such as "picture file", "audio/video file", and "text file" are provided under "file recovery";

as shown in fig. 18, when the user clicks the "picture file", selection buttons such as "BMP type picture", "JPG type picture", "GIF type picture", and "PNG type picture" are provided;

when a user clicks the selection buttons such as the MP3 file, the AMR file, the M4A file, the MP4 file and the like under the audio and video file;

when a user clicks a selection button such as a DOC file, an XLS file, a PDF file, a PPT file and the like under the text file;

after the file type needing to be restored is selected, a restoring button is clicked, the restoring button is used for clicking a restoring picture file, clicking a restoring audio/video file and clicking a restoring text file, and restoring of the corresponding file is carried out. The user clicks the corresponding type of file, for example, clicks the GIF type picture and the PNG type picture, and the electronic terminal responds to a GIF type and PNG type recovery instruction triggered by the user, so that the files of the GIF type and the PNG type can be recovered.

In addition, the file recovery method provided by the invention can also be realized by file recovery application in the electronic terminal, and the specific process is as follows: clicking the 'file recovery' APK to display four menus of 'text file', 'picture file', 'audio and video file', 'all recovery', as shown in fig. 19, wherein clicking the first three menus can pop up an option sub-menu, and clicking 'all recovery' can recover all supported type files;

as shown in fig. 18, when the "picture file" is clicked, selection buttons such as "BMP type picture", "JPG type picture", "GIF type picture", and "PNG type picture" are provided;

as shown in fig. 18, when the "audio/video file" is clicked, selection buttons such as "MP 3 file", "AMR file", "M4A file", "MP 4 file" are provided;

as shown in fig. 18, when the "text file" is clicked, selection buttons such as "DOC file", "XLS file", "PDF file", and "PPT file" are provided;

and after the type of the file to be restored is selected, clicking a restoring button to restore the corresponding file.

Fig. 20 is an electronic terminal according to an embodiment of the present invention, which includes: a processor 2010, an internal memory 2020, and a user input unit 2030;

the user input unit 2030 is configured to receive a file type recovery instruction triggered by a user.

The built-in memory 2020 for storing data of a plurality of file types;

the user input unit 2030 may be a touch display screen or a microphone, where the file type may be displayed through the touch display screen, and the file type required to be restored and input by the user may be received, and the voice of the user may be collected through the microphone, and the file type required to be restored and selected by the user may be determined through voice analysis.

The internal memory 2020 may be the same memory as the memory 120 described in fig. 1.

The processor 2010 is configured to respond to a file type recovery instruction triggered by a user, and write partition data in a preset partition of the internal storage into the memory;

Optionally, the processor 2010 is specifically configured to search the corresponding partition data from the memory by one of the following manners:

Optionally, when the corresponding target file type is a GIF file or a PNG file, searching for corresponding partition data from a memory in a first manner;

Optionally, the processor 2010 is specifically configured to:

and determining that the searched partition data meets the limiting condition of the target file type.

Optionally, if the type of the target file is a GIF file, the limiting condition is:

Optionally, the processor 2010 is further configured to:

In an exemplary embodiment, there is also provided a storage medium comprising instructions, such as a memory comprising instructions, executable by the processor 2010 of the electronic terminal 2000 to perform the above-described method. Alternatively, the storage medium may be a non-transitory computer readable storage medium, which may be, for example, a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.

The embodiment of the present invention further provides a computer program product, which, when running on an electronic terminal, enables the electronic terminal to execute any one of the file recovery methods described above in the embodiments of the present invention.

Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the invention and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

It will be understood that the invention is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the invention is limited only by the appended claims.

Claims

1. An electronic terminal, comprising: a processor, a built-in memory and a user input unit;

the built-in memory is used for storing data of a plurality of file types;

2. The electronic terminal according to claim 1, wherein the processor is specifically configured to search the corresponding partition data from the memory by one of the following methods:

3. The electronic terminal of claim 2, wherein:

when the corresponding target file type is a GIF file in an image conversion format or a PNG file in a stream network graphic format, searching corresponding partition data from a memory in a first mode;

when the corresponding target file type is a bitmap BMP file or an audio M4A file, searching corresponding partition data from the memory by adopting a second mode;

and when the corresponding target file type is a window operating system media video format WMA file, searching corresponding partition data from the memory by adopting a third mode.

4. The electronic terminal of claim 1, wherein the processor is specifically configured to:

if the target file type is a GIF file, the limiting conditions are as follows:

5. The electronic terminal of any of claims 1-4, wherein the processor is further configured to:

6. A file recovery method, comprising:

7. The file recovery method according to claim 6, wherein the corresponding partition data is searched from the memory by one of the following methods:

8. The file recovery method according to claim 7, characterized in that:

9. The method according to claim 7, wherein after the corresponding partition data is searched from the memory according to the file structure characteristic of the target file type corresponding to the file type recovery instruction and before the partition data is recovered to the file of the corresponding target file type, the method further comprises:

if the target file type is a GIF file, the limiting conditions are as follows:

the data stored at the preset offset address is in the size range of a preset M4A file, wherein the preset offset address is an address of an interval preset offset after the offset address corresponding to the file header;

10. The file recovery method according to any one of claims 6 to 9, wherein after recovering the partition data into a file of a corresponding target file type, the method further comprises: