Hi,
Excel strings can indeed exceed 255 characters, and FlexCel should report them right. But there are some concepts we need to know about strings in Delphi to further understand the problem.
Since Delphi 2009, there are 3 main types of strings in delphi:
1. ShortStrings. Those strings seems to be the ones you are using. They are array of bytes (or ASCII chars) with a maximum length of 255. The length of the string is stored in s[0], and being a byte, it can't be longer than 256.
You can declare a short string like
var
a: string[255];
2. AnsiStrings. Those strings are stored in the heap, and can have any length. In those strings the length is not stored at s[0] and accessing s[0] is an error. But each character of the string is still a byte.
You declare AnsiStrings like:
var
a: AnsiString;
3. Unicode Strings. These are the ones FlexCel uses everywhere, and the ones you get if you declare
var
a: String;
They have the following characteristics:
3.1. Their length is not limited to 255 characters. s[0] does not have the length of the string and it is an error to read s[0]
3.2. Each character in the string is 2 bytes, not one. A "Char" in delphi since 2009 is 2 bytes, holding unicode characters from 0 to 65535. If you declare:
var
c: Char;
This is not a byte, but 2 bytes.
c:AnsiChar would be 1 byte.
You can read more about strings here:
Now, about your problem. FlexCel returns an UnicodeString when it reads the file. If you want to convert them to an array of ASCII bytes, you can use
TEncoding.ASCII.GetBytes(s);
This will return an array of bytes (not limited to 255 characters) with the ASCII characters. Any special unicode character (like ñ or é) will be converted to ?
As an alternative,
TEncoding.ANSI.GetBytes(s);
will return a string where character are still bytes, but using your codepage to encode special characters like é. The problem of this is that other apps with a different encoding will read all those special characters wrong. For example, if your codepage is 1252 (most common in western locales), é is character 233:
But if some other machine with Cyrillic locale (1251, used in Russian countries) opens the file. he will see an й instead of an é since й is char 233 in cyrillic:
If you have special characters, it is best to use UTF8 (and you can use TEncoding.UTF8 to convert strings to utf8 array of bytes and array of bytes to strings). If you don't have special characters, you can use ASCII, which is the same everywhere. ANSI is an ASCII extension that depends in the locale of the machine for chars > 127, so it is not great to use it, unless the HFSQL export expects the results in ANSI.