Abstract:
The invention receives a request to store a file having a filename written in a first text encoding, converts the filename into a Unicode filename and stores the Unicode filename and the file into memory. The invention then sets a flag, associated with the memory, indicating that a first text encoding has been used. To retrieve a Unicode filename, the invention receives a request to locate a Unicode filename from memory. Next, the invention uses a predetermined text encoding to convert the filename into Unicode. The invention then searches for the Unicode filename in the memory. If the Unicode filename is not found, the invention uses a next text encoding from the set of text encodings which have been used, to repeat the conversion and searches the memory until the Unicode filename is identified. Lastly, the Unicode file is retrieved.

Description:
[0001]     This application is a continuation application of co-pending U.S. patent application Ser. No. 11/360,797, filed Feb. 22, 2006, which is a continuation application of co-pending U.S. patent application Ser. No. 10/177,715, filed Jun. 20, 2002, now issued as U.S. Pat. No. 7,013,314, which is a continuation of co-pending U.S. patent application Ser. No. 09/213,199, filed Dec. 17, 1998, now issued as U.S. Pat. No. 6,434,574. 
     
    
     BACKGROUND OF THE INVENTION  
       [0002]     1. Field of the Invention  
         [0003]     This invention relates generally to computer operating systems and more particularly to storing and retrieving filenames in computer memory.  
         [0004]     2. Description of the Background Art  
         [0005]     The storing and retrieving of filenames in computer memory is extremely important to all computer users. When a computer user saves a file and filename into computer memory, it is important that the filename remain uniquely identifiable regardless of any other filenames or text encodings saved in the memory. If a filename is not uniquely identifiable, then a computer may be unable to retrieve the named file. Further, if the memory containing the filename is moved to a different computer then that filename must remain identifiable if the named file is to be retrievable.  
         [0006]     Conventionally, a filename identity is represented by a string of bytes (“encoding”) stored in computer memory. A conventional Roman character based computer system will interpret the encoding to represent Roman characters in the American Standard Code for Information Interchange (ASCII) character set, even if the encoding actually represents Japanese characters. For example, a Japanese computer user may save a file with a Japanese filename onto a removable memory device, such as a floppy disk. The Japanese filename encoding is interpreted by a conventional Japanese character based computer system to be Japanese characters. However, if the Japanese user then inserts the removable memory device into a conventional Roman character based computer system, the Roman computer system will assume the Japanese encoding actually represents a Roman character filename rather than a Japanese character filename.  
         [0007]     A problem with the conventional Roman character based computer system is that because it assumes that a filename is in Roman characters, it may equate two non-Roman character filenames as being identical. This is because a Roman computer system treats uppercase and lowercase letters in a filename as equivalent. Therefore, a Roman computer system would assume that the filenames “Example.txt” and “example.txt” (and their associated files) are the same even though they are represented by different strings of bytes, possibly leading to the assumption that two non-Roman filenames, which vary only by case, are identical. If a Roman computer system misinterprets a non-Roman filename, the system may mistakenly open the wrong file or may refuse to create a new file since it believes that that filename is already in use.  
         [0008]      FIG. 1  is a diagram of Japanese characters in which characters within any given column appear identical to a conventional Roman character based computer system. For example, characters  104 ,  106 ,  108  and  110  in column  102  appear identical to a prior art Roman computer system because it treats all filenames as if they were written in the Roman alphabet. Therefore, if two Japanese filenames differed by just one character, such as characters  104  and  106 , a prior art Roman computer system would actually consider them to be identical. Similar problems occur with other text encodings but the problem is most acute in Japanese and Chinese text encodings since in these languages each character is a word and therefore filenames are shorter and more likely to vary by just one character.  
         [0009]     A Roman character based prior art system can only store filenames in Roman text encodings as partially represented by ASCII text encoding table  200  of  FIG. 2 . Each Roman character has its own encoding. For instance, character  202 , the letter “A”, is stored as 7-bit encoding  204 . However, because ASCII only allows 7 bit encodings, which means that ASCII can encode only 128 characters, basic ASCII encoding table  200  contains no encodings for Japanese or any other language that uses non-Roman characters. Japanese and other east-asian languages can easily have several thousand characters that need to be encoded. Therefore, a prior art Roman character based computer system cannot always accurately store or retrieve some east-asian filenames or other non-Roman filenames.  
         [0010]     Therefore, an improved system and method are needed to store and retrieve filenames and files in a computer system.  
       SUMMARY OF THE INVENTION  
       [0011]     The present invention provides a system and method for accurately storing and retrieving filenames in computer memory by converting filenames into Unicode text encoding. The Unicode Standard, like the ASCII text encoding standard and others, encodes each character as a numerical value. However, instead of encoding simply in ASCII, Unicode text encoding encodes all the characters used in the world&#39;s major written languages, including Greek, Arabic, Tamil, Thai, Japanese, Korean and many others.  
         [0012]     The invention stores a filename into computer memory by first determining a default text encoding based upon which it converts the filename into Unicode text encoding. If the conversion is successful, the invention stores the Unicode text-encoded filename into computer memory and sets a bit that corresponds to the default text encoding in an Encoding Bitmap located in computer memory.  
         [0013]     If the conversion based on the default text encoding is unsuccessful, the invention tries using Roman text encoding to convert the filename into Unicode text encoding. Once the conversion is complete, the invention stores the filename into computer memory and sets the bit that corresponds to Roman text encoding in the encoding bitmap. The invention assumes that any sequence of bytes can be converted to Unicode using Roman text encoding, which assigns a meaning to every possible byte sequence. If conversion using the default encoding fails, conversion using Roman text encoding will definitely succeed, even if it produces the wrong Unicode characters.  
         [0014]     To retrieve a filename, the invention first converts the retrieval request into Unicode text encoding based on the default text encoding of the system. The invention then searches the computer memory for a matching Unicode text encoded filename. If the search is successful, the search result is returned. If the search is not successful, the invention determines if Roman text encoding is the default text encoding. If Roman text encoding is not the default text encoding, the invention uses Roman text encoding to convert the retrieval request into Unicode text encoding and then searches the computer memory for a matching Unicode filename. If the search is successful, a search result is returned.  
         [0015]     If the search is not successful, or if Roman text encoding is the default text encoding, the invention next retrieves a list of all text encodings previously used in the system as specified in an Encoding Bitmap located in the computer memory of the system. The invention then converts the retrieval request into Unicode text encoding based on each text encoding specified in the encoding bitmap and uses each conversion to search the computer memory for a match. If a match is found, the invention returns the search result.  
         [0016]     Finally, if the search is still not successful the invention converts the retrieval request into Unicode text encoding based on any other text encodings installed in the computer memory that have yet to be tried. The invention then uses each conversion in searching the computer memory for a matching Unicode filename. If the search is successful, the invention returns the search result. If the search is not successful, the invention returns an error message.  
         [0017]     Accordingly, the present invention not only more accurately and efficiently stores and retrieves filenames in computer memory but also allows multiple encodings to be used in computer memory over time.  
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0018]      FIG. 1  is a diagram of Japanese characters in columns that appear identical when storing or retrieving a filename using a prior art system;  
         [0019]      FIG. 2  is a diagram of ASCII text encodings used by a prior art system;  
         [0020]      FIG. 3  is a block diagram of a computer system suitable for use with the present invention;  
         [0021]      FIG. 4  is a block diagram of the preferred allocation of the memory shown in  FIG. 3 ;  
         [0022]      FIG. 5  is a block diagram of the preferred embodiment of the Unicode Table in the memory shown in  FIG. 4 ;  
         [0023]      FIG. 6  is a block diagram of the preferred embodiment of the Encoding Bitmap in the memory shown in  FIG. 4 ;  
         [0024]      FIG. 7  is a flowchart of preferred method steps for storing a filename into computer memory according to the present invention; and  
         [0025]      FIGS. 8   a  and  8   b  are a flowchart of preferred method steps for retrieving a filename from computer memory according to the present invention.  
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT  
       [0026]     The present invention relates to an improvement in storing filenames in, and retrieving them from, computer memory.  
         [0027]      FIG. 3  is a block diagram of a computer system suitable for use with the invention. Computer system  300  preferably includes a Central Processing Unit (CPU)  304 , a monitor  306 , a keyboard  308 , memory  310 , and an input and output (I/O) interface  312 , all connected by a system bus  302 . Memory  310  may comprise a hard disk drive, random access memory (RAM) or any other appropriate memory configuration.  
         [0028]      FIG. 4  is a block diagram of the preferred allocation of memory  310 , which stores a Unicode table  402  that contains 16 bit encodings for most modern written languages as discussed further in conjunction with  FIG. 5 . Memory  310  also stores a File Manager  404  which manages document  406  and other documents with their respective filenames that are stored in memory  310 , as discussed further in conjunction with  FIG. 7 ,  FIG. 8   a  and  FIG. 8   b . Memory  310  also stores text encodings  408  for various languages such as Roman, Greek and Japanese, and an encoding bitmap  410  which lists all previously used text encodings, as discussed further in conjunction with  FIG. 6 .  
         [0029]      FIG. 5  is a diagram of the preferred embodiment of the Unicode Table  402 , which contains bit encodings for most of the world&#39;s modern written languages. Unicode, published as The Unicode Standard, Worldwide Character Encoding, is now the standard for representing text. Unicode uses a 16-bit coding scheme that allows for 65,536 distinct characters—more than enough to include all languages in use today. Currently, Unicode text encoding covers 38,887 different characters. For example, the Roman character “A”  502  is represented by bit encoding  504 . The Greek character “α”  506  is represented by bit encoding  508 . The Chinese character for sky (“tian” in Mandarin Chinese and “tin” in Cantonese)  510  is represented by bit encoding  512 . Most modern written languages can be encoded using Unicode text encoding. However, some relatively obscure languages in current use, such as Cherokee and Mongolian, cannot be encoded using Unicode text encoding. Accordingly, almost any filename can be accurately represented in its native language using Unicode text encoding instead of having to be converted, possibly inaccurately, to Roman characters.  
         [0030]      FIG. 6  is a diagram of the preferred embodiment of the  FIG. 4  Encoding Bitmap  410 , which contain a list of all text encodings previously used in system  300 . Whenever a given text encoding is used in system  300 , file manager  404  sets a relevant field in encoding bitmap  410 . For instance, if field  602  represents Hebrew and Hebrew has not been used in system  300 , field  602  contains a 0. If field  604  represents Arabic and Arabic has been used in system  300 , field  604  contains a 1.  
         [0031]      FIG. 7  is a flowchart of steps in a preferred method  700  for file manager  404  to store a filename into computer memory  310  according to the invention. In step  703 , file manager  404  receives a “save” request, which contains filename information for document  406 . Alternatively, the “save” request can be a request to change a filename. In step  704 , file manager  404  creates a file and/or saves document  406  in memory  310 . If the save request in step  703  was a change filename request, step  704  can be skipped. The contents of the document  406  can also be saved in memory  310  after completion of the method  700 .  
         [0032]     In step  706 , file manager  404  determines a default text encoding of system  300 , which in this case is a text encoding used to view filenames on monitor  306 . In step  708 , file manager  404  uses the default text encoding determined in step  706  to convert the filename to a Unicode name.  
         [0033]     Step  710  determines whether the step  708  conversion using the default text encoding was successful. If the step  708  conversion was not successful, then in step  712  file manager  404  uses Roman text encoding to convert the user-entered filename to Unicode text encoding. Note that step  712  cannot fail. Even if the filename was not actually written in Roman characters, method  700  will still convert the user-entered filename to Unicode using Roman encoding. This is because all possible byte sequences yield valid Roman characters that can be converted into Unicode. The filename will not be in the intended characters, but the filename will be individually distinguishable.  
         [0034]     Once the step  712  conversion is complete, or if the step  708  conversion was successful, then in step  714  file manager  404  saves the Unicode name to memory  310 . In step  716 , file manager  404  sets a bit in encoding bitmap  410  that corresponds to the type of text encoding used to convert the user-entered filename. In step  718  method  700  ends.  
         [0035]      FIGS. 8   a  and  8   b  are a flowchart of steps in a preferred method  800  for file manager  404  to retrieve a filename from computer memory according to the invention. In step  804  file manager  404  receives a search request which was. generated when a system  300  user attempted to open document  406 , or any other document, stored in memory  310 . The search request contains a user-entered filename. In step  805  file manager  404  converts the user-entered filename to Unicode text encoding based on the default text encoding of system  300 . As discussed in conjunction with  FIG. 7 , the default text encoding in this example is the text encoding used to view filenames on monitor  306 . If the step  805  conversion was not successful, then file manager  404  proceeds to step  816  as discussed below. If the conversion was successful, then in step  807  file manager  404  searches memory  310  for the converted filename. If file manager  404  locates a matching filename, file manager  404  returns the search result and retrieves the file having the matching filename in step  812  and method  800  ends in step  814 .  
         [0036]     If the step  807  search did not locate a matching filename, or if the step  805  conversion was not successful, then in step  816  file manager  404  determines if Roman text encoding is the default text encoding of system  300 . If Roman text encoding is not the default text encoding, then in step  817  file manager  404  converts the user-entered filename to Unicode text encoding using Roman text encoding. In step  819 , file manager  404  searches memory  310  for the converted filename. If it finds a matching filename, then in step  822  file manager  404  returns a search result and retrieves the file having the matching filename, and method  800  ends in step  824 .  
         [0037]     If the step  819  search did not locate a matching filename, or if in step  816  file manager  404  determined that Roman text encoding is the default text encoding of system  300 , then in step  826  file manager  404  retrieves a list of text encodings from encoding bitmap  410 .  
         [0038]     Next, in step  827 , file manager  404  converts the user-entered filename into Unicode text encoding using a text encoding from the list retrieved in step  826  from encoding bitmap  410 . File manager  404  converts the filename into Unicode using only text encodings not already used in steps  805  and  817 . However, in practice system  300  will probably only have installed one or two text encodings—usually Roman and a local text encoding such as Japanese. The local text encoding is normally set as the default text encoding that is tried in step  805 . Therefore, method  800  generally is successful at either step  808  or step  820  and does not reach step  826 .  
         [0039]     If the step  827  conversion is not successful, then File Manager  404  proceeds to step  834 . If the step  827  conversion is successful, then in step  829  file manager  404  uses the converted user-entered filename to search memory  310  for a matching Unicode filename. If in step  830  the search is successful, then in step  832  file manager  404  returns a search result and retrieves the file having the matching filename, and in step  833  method  800  ends. If in step  830  the search was unsuccessful, or if the step  827  conversion was unsuccessful, then in step  834  file manager  404  determines if there are other text encodings listed in encoding bitmap  410  that have not been tried. If there are some text encodings that have not yet been tried, then file manager  404  returns to step  827 .  
         [0040]     If in step  834  all text encodings listed in encoding bitmap  410  have been tried, then file manager  404  proceeds to step  835  and tries to convert the user-entered filename into Unicode text encoding based on any other text encodings installed in system  300 . As in step  827 , file manager  404  tries conversions to Unicode text encoding using only previously untried text encodings. if the step  835  conversion is unsuccessful, then File Manager  404  proceeds to step  844 . Otherwise, in step  837 , file manager  404  searches memory  310  for a matching Unicode filename. If the search is successful, then in step  840  file manager  404  returns a search result and retrieves the file having the matching filename, and in step  842  method  800  ends. If the search is unsuccessful, but in step  844  not all text encodings have been tried, then file manager  404  returns to step  835  and tries to convert the user-entered filename to Unicode text encoding using another text encoding. If in step  844  all the text encodings installed in system  300  have been tried, then in step  846  file manager  404  returns an error result and in step  848  the method  800  halts.  
         [0041]     The invention has been explained with reference to a preferred embodiment. Other embodiments will be apparent to those skilled in the art in light of this disclosure. For example, the invention may readily be implemented using configurations other than those described in the preferred embodiment. Additionally, the invention may effectively be used in conjunction with systems other than the one described as the preferred embodiment. Therefore, these and other variations upon the preferred embodiments are intended to be covered by the appended claims.