If your existing programs don't handle Unicode data, your program and its files will be fully backwards compatible.īut what if a program does handle Unicode data? Let's suppose we have a string list with lines written in different languages48, like in the following design-time form of the StreamEncoding project:Ĥ8 These lines have been extracted from the 'What is Unicode?' page of the Unicode Consortium web site, which has its text translated in many different languages using a variety of alphabets. If you don't change the existing Delphi code, your programs will save files as ANSI. Not having an exception can help in case the encoded file was saved without a BOM, and still should not be considered as an ASCII file, but a UTF one.īut let us focus on the file saving operation. I'd rather expect an exception in case of such a discrepancy, saving a file with one code page and forcing to upload it with a different one is certainly a developer error.

What if you specify an encoding in LoadFromFile? The encoding you provide will be used for reading the file, regardless of the actual BOM in the file, often producing an error. As you do the corresponding LoadFromFile operation, if you don't specify an encoding, the loading method will end up calling the GetBufferEncoding method of the TEncoding class that will determine the encoding depending on the presence of a BOM (of its absence, in which case it will use the default ANSI encoding). This saves the file with a Unicode BOM or preamble. Of course, you can also easily force the file to a different format, for example the UTF-16 format: In other words, if you save a file you'll get the same ANSI file as before. If you write a string list to text file without providing a specific encoding, the class will use TEncoding.Default, which uses the internal DefaultEncoding in turn extracted at the first occurrence by the current Windows code page. The ReadFromFile and WriteToFile methods of the TStrings class can be called with an encoding.

Delphi listbox save to file