While a processor may access resources, such as a text file, on a hard drive, this accessing process may take time and reduce the performance efficiency for an application. The processor may access a compressed resource file more quickly than an uncompressed resource file, when stored on a hard drive. However, any gains in the efficient reading of a compressed resource file may be eliminated in the decompression of that compressed resource file.
The language characters in a text file may be represented by any number of binary encoding systems. A software application may use the Unicode industry standard to represent and manipulate text in multiple written languages. A character in a text string may be represented in Unicode by two bytes. Independent of the Unicode standard, a single byte may usually be used to represent all the characters in two written languages. Most existing single byte encoding standards may be unreliable and relatively slow in decoding, as these single byte encoding standards were designed for a particular language and not multiple languages. Eight-bit Unicode Transformation Format (UTF-8) and other mixed single/multi byte encodings may reduce the size of just a small group of languages.
One type of single language encoding standard that a software application may use is the American Standard Code for Information Interchange (ASCII). ASCII may be used to encode text containing English language characters.
This Summary is provided to introduce a selection of concepts in a simplified form that is further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Embodiments discussed below relate to a computing device compressing a text file for storage by dynamically creating an encoding table. A storage device of the computing device may store an encoding table generated from a text file and populated by string characters from the text file. A processor of the computing device may encode the text file by replacing a string character in a text string of the text file with a table index position of that string character in the encoding table. The processor of the computing device may decode the text file by replacing the table index position with the string character at the table index position in the encoding table.
In order to describe the manner in which the above-recited and other advantages and features can be obtained, a more particular description is described below and will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments and are not therefore to be considered to be limiting of its scope, implementations will be described and explained with additional specificity and detail through the use of the accompanying drawings.
Embodiments are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the subject matter of this disclosure.
A computing device may compress a text file using a dynamically created encoding table. A storage device of the computing device may store an encoding table generated from a text file and populated by string characters from the text file. A processor of the computing device may encode the text file by replacing a string character in a text string of the text file with a first table index position of that string character in the encoding table or by replacing a character set in the text string with a second table index position of that character set in the encoding table. The processor of the computing device may decode the text file by replacing the table index position with the string character or character set at the table index position in the encoding table.
Processor 120 may include at least one conventional processor or microprocessor that interprets and executes instructions. Memory 130 may be a random access memory (RAM) or another type of dynamic storage device that stores information and instructions for execution by processor 120. Memory 130 may also store temporary variables or other intermediate information used during execution of instructions by processor 120. ROM 140 may include a conventional ROM device or another type of static storage device that stores static information and instructions for processor 120. Storage device 150 may include any type of media, such as, for example, magnetic or optical recording media and its corresponding drive.
Input device 160 may include one or more conventional mechanisms that permit a user to input information to computing device 100, such as a keyboard, etc. Output device 170 may include one or more conventional mechanisms that output information to the user, including a display, a printer, a medium, such as a memory, or a magnetic or optical disk and a corresponding disk drive, or other type of medium. Communication interface 180 may include any transceiver-like mechanism that enables processing device 100 to communicate with other devices or networks. The interface may be a wireless, wired or optical interface.
Computing device 100 may perform such functions in response to processor 120 executing sequences of instructions contained in a computer-readable medium, such as, for example, memory 130, a magnetic disk, or an optical disk. Such instructions may be read into memory 130 from another computer-readable medium, such as storage device 150, or from a separate device via communication interface 180.
Processor 120 may seek to access a localization resource file or other text file stored in storage device 150.
Unencoded text file 200 may be used to generate an encoding table.
Processor 120 may sort string characters 220 in order of appearance in unencoded text file 200, by number of appearances in unencoded text file 200, or other schema based upon the unencoded text file 200. If string character 220 is an extended American Standard Code for Information Interchange (ASCII) character 320, processor 120 may reorder string characters 220 to align extended ASCII characters 320 with an extended ASCII position.
As an example of creating an encoding table 300, a processor may seek to compress an unencoded text file 200 containing fragments of the Lewis Carroll poem, “Jabberwocky.” The size of the encoding table in this example may be limited to 16 characters, or four bits. The first unencoded text string 210 may contain the following string of characters: “Twas brillig when the slithey”. The second unencoded text string 210 may contain the following string of characters: “toves Did gyre and gimble”.
This unencoded text file may result in the following encoding table, with the table index position 310 shown in both decimal notation and hexadecimal notation:
As characters in the second text string are not mapped to the encoding table 300, the second text string may be marked unencoded, or having unmapped characters. Encoding table 300 may be rearranged so that characters are sorted by number of appearances in the unencoded text file, as follows:
The encoding table 300 may be generated by using frequent character sets 230, as well as string characters 220, as follows:
Returning to the “Jabberwocky” example, the unencoded text file 200 may be encoded using the encoding table 300. Using TABLE 2 above, the first text string 210 of the “Jabberwocky” text file (which when unencoded read: “Twas brillig when the slithey”) may read when encoded “de8940af233250861b07610432761c”. Using TABLE 3 above, the first text string 210 of the “Jabberwocky” text file may read when encoded “203405010617”. The second text string 210 (which contained unmapped characters 520 such as “o”, “v”, “D”, and “d” in TABLE 2) may be stored unencoded as “toves Did gyre and gimble”.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms for implementing the claims.
Although the above description may contain specific details, they should not be construed as limiting the claims in any way. Other configurations of the described embodiments are part of the scope of the disclosure. For example, the principles of the disclosure may be applied to each individual user where each user may individually deploy such a system. This enables each user to utilize the benefits of the disclosure even if any one of a large number of possible applications do not use the functionality described herein. Multiple instances of electronic devices each may process the content in various possible ways. Implementations are not necessarily in one system used by all end users. Accordingly, the appended claims and their legal equivalents should only define the invention, rather than any specific examples given.
Number | Name | Date | Kind |
---|---|---|---|
5936636 | Gelfenbain | Aug 1999 | A |
6138086 | Rose et al. | Oct 2000 | A |
6204782 | Gonzalez et al. | Mar 2001 | B1 |
6480867 | Kwan | Nov 2002 | B1 |
7199729 | Chen et al. | Apr 2007 | B2 |
20040006455 | Fux et al. | Jan 2004 | A1 |
20040172601 | Rettiget et al. | Sep 2004 | A1 |
20060218133 | Atkin et al. | Sep 2006 | A1 |
20070159366 | Lin | Jul 2007 | A1 |
20080072142 | Yao | Mar 2008 | A1 |
Number | Date | Country | |
---|---|---|---|
20090315744 A1 | Dec 2009 | US |