Я просматривал класс TDataset и его строковые поля в Delphi XE2 и заметил, что AsWideString возвращает тип UnicodeString. Однако он получает значение из функции TField.AsString: String, которая в свою очередь вызывает TFIeld.AsAnsiString: AnsiString. Поэтому любые символы Юникода будут потеряны? Также буфер, который передается в TDataset.GetFieldData, объявляется как массив AnsiChar.
Я правильно понимаю это?
Нет, вам следует изучить класс TWideStringField, который предназначен для полей Unicode и TStringField, который предназначен для строк, отличных от Unicode. TField - это только базовый класс и TField.GetAsWideString - это виртуальный метод с возвратной реализацией, который переопределяется потомками, которые знают Unicode.
ДА, вы поняли это правильно. Это VCL и его документация, которые разбиты. Ваша неразбериха совершенно понятна!
В реализации Delphi 2009+ вы должны использовать свойство AsString для AnsiString и AsWideString для string=UnicodeString.
Фактически, свойства As*String определяются как таковые:
property AsString: string read GetAsString write SetAsString;
property AsWideString: UnicodeString read GetAsWideString write SetAsWideString;
property AsAnsiString: AnsiString read GetAsAnsiString write SetAsAnsiString;
Как мы можем узнать, что AsString возвращает AnsiString? Это просто не имеет смысла вообще, по сравнению с остальной частью VCL/RTL.
Выполняется реализация, использующая класс TStringField для AnsiString и TWideStringField для string=UnicodeString.
Кроме того, документация также нарушена:
Data.DB.TField.AsString
Представляет значение поля в виде строки (Delphi) или AnsiString (С++).
Это не означает string в Delphi, но AnsiString! Тот факт, что свойство использует простой тип string=UnicodeString, отлично пропускает.
В точке базы данных драйвер DB может обрабатывать Unicode или работать с определенной кодировкой. Но с точки зрения VCL в Delphi 2009+ вы должны знать только тип string и быть уверенным, что использование AsString: String будет готово к использованию в Unicode.