Нижняя половина кодов ANSI [# 0 .. # 127] не изменяется после преобразования в Unicode, поэтому вам не стоит об этом беспокоиться. Верхняя половина [# 128 .. # 255] сложнее. Компилятор интерпретирует строки
const s1:AnsiString = #200;
const s2:UnicodeString = #200;
в зависимости от директивы {$ HIGHCHARUNICODE}
{$HIGHCHARUNICODE OFF} // default setting on Delphi 2009
const s1:AnsiString = #200; // Ord(s1[1]) = $C8 = 200
const s2:UnicodeString = #200; // Ord(s2[1]) depends on Codepage
// on my Win1251 = $418
{$HIGHCHARUNICODE ON}
const s1:AnsiString = #200; // Ord(s1[1]) depends on Codepage
// on my Win1251 = $45
const s2:UnicodeString = #200; // Ord(s2[1]) = $C8 = 200
# 200 - это «И» на кодовой странице Win1251. Код Unicode для 'И' составляет $ 418.
С другой стороны, в Unicode # 200 есть «È». Win1251 не имеет символа «È», а преобразование Unicode -> Win1251 преобразует его в «E», что составляет $ 45 для всех кодовых страниц ANSI.
При {$ HIGHCHARUNICODE OFF} компилятор интерпретирует символы # 128 .. # 255 как символы ANSI в зависимости от системной кодовой страницы и, при необходимости, преобразует их в кодовые точки Unicode.
При {$ HIGHCHARUNICODE ON} компилятор интерпретирует # 128 .. # 255 символов как кодовые точки Unicode и, при необходимости, преобразует их в символы ANSI с возможной потерей.
Обновление
Теперь я вижу код проблемы из статьи Ника , который неправильно работает на Unicode Delphi:
var
Buf: array[0..32] of Char;
begin
FillChar(Buf, Length(Buf), #9);
ShowMessage(Format('%d %d %d', [Ord(Buf[0]), Ord(Buf[0]), Ord(Buf[16])]));
end;
но это пример неправильного использования FillChar
процедуры; FillChar
просто заполняет буфер назначения байтами (кстати, только в первой половине Buf в приведенном выше примере) и игнорирует весь новый персонал Unicode. FillChar
лучше теперь переименовывать с помощью FillBytes, и запрещено использовать символ (# 9) в качестве третьего аргумента.