String и AnsiString

b

String и AnsiString: правда и вымыслы

Типы строк в Delphi обрастают легендами. Одни считают AnsiString архаизмом, другие боятся Unicode в String, третьи уверены в непомерной «тяжести» обоих. Давайте разберём самые устойчивые мифы — и увидим, что за ними скрывается.

Миф №1: AnsiString — это устаревший мусор

Многие полагают: раз Delphi перешла на Unicode, AnsiString потерял смысл. На деле этот тип никуда не исчез. Он по-прежнему живёт в RTL, поддерживается компилятором и активно используется в библиотеках WinAPI. AnsiString остаётся идеальным решением для взаимодействия со старым C/C++ кодом или данными в однобайтовых кодировках (ANSI, OEM). Удаление AnsiString нарушило бы совместимость с миллионами проектов — разработчики Embarcadero не стали этого делать.

Миф №2: String (UnicodeString) всегда медленнее AnsiString

Заблуждение основано на том, что Unicode-символ занимает 2 байта вместо 1. Да, память расходуется больше. Но скорость доступа к элементам строки и копирования часто оказывается выше для UnicodeString: современные процессоры оптимизированы под 16-битные операции, а менеджер памяти Delphi великолепно справляется с блоками Unicode. Более того, для операций поиска, сравнения и конкатенации разница заметна лишь на миллионах операций — в обычном приложении вы её не почувствуете.

Миф №3: AnsiString нельзя кодировать нормально — всё в одной кодировке

На самом деле AnsiString содержит кодовую страницу (CodePage), которая хранится в служебном поле. Благодаря этому одна и та же переменная может работать с CP1251, CP1252, UTF-8 (читается как AnsiString с CP_UTF8) и даже с однобайтовыми кодировками символов. Проблемы начинаются только если вы явно не указываете кодировку при конвертации — но это уже вопрос аккуратности программиста, а не типа данных.

Миф №4: String в Delphi — это просто последовательность символов, как в C

Люди, перешедшие с C++ или C#, часто думают, что Delphi String — аналог std::string или char*. Разочаруем: String (UnicodeString и AnsiString) — это управляемые строки с подсчётом ссылок (reference-counted), копированием при записи (copy-on-write) и нулевым символом в конце для совместимости с WinAPI. Они передаются по значению, но физическое копирование памяти происходит только при изменении строки, совместно используемой несколькими переменными. Это даёт безопасность и скорость, недоступную голым указателям.

Миф №5: Для работы с UTF-8 нужно специальное API, String не подходит

В Delphi достаточно написать: var s: UTF8String; — и вы получите полноценную строку в кодировке UTF-8, которая по поведению идентична AnsiString, но с кодовой страницей 65001. Не требуется внешних библиотек. Конвертация в String (Unicode) и обратно происходит автоматически при присваивании. Разработчики часто этого не замечают, потому что привыкли к статическим типам.

Практические рекомендации: как не ошибиться

Заключение: факты побеждают страхи

String и AnsiString в Delphi — зрелые, продуманные типы, которые десятилетиями доказывают свою надёжность. Мифы рождаются из непонимания механизма работы с памятью и кодировками. Надеемся, этот разбор поможет вам смотреть на строки Delphi без предубеждений и использовать их сильные стороны по назначению.

  1. String (UnicodeString) — быстрее для операций внутри приложения, занимает больше памяти.
  2. AnsiString — экономнее по памяти, незаменим при взаимодействии с системой и старыми библиотеками.
  3. UTF8String — мост к современному вебу и серверам.
  4. Не существует «лучшего» типа — есть подходящий для конкретной задачи.

Добавлено: 27.04.2026