докладываю результаты экспериментов
я оказался прав - все дело в интерпретации драйвером
теперь подробно
--------------------------------------
исследуя исходники IBX, наткнулся на
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
function TIBXSQLVAR.GetCharsetSize: Integer;
begin
case SQLVar.SQLSubtype and $FF of
0, 1, 2, 10, 11, 12, 13, 14, 19, 21, 22, 39,
45, 46, 47, 50, 51, 52, 53, 54, 55, 58 : Result := 1;
5, 6, 8, 44, 56, 57, 64 : Result := 2;
3 :
begin
// System Tables incorrectly state they are in Unicode_Fss character set but they are not
if POS('RDB$', SQLVar.RelName) = 1 then
Result := 1
else
Result := 3;
end;
59 : Result := 4;
else
Result := 1;
end;
end;
как видно, в код жестко зашиты идентификаторы чарсетов, причем для UTF8=59
это очень нехорошо, но для IBX, предназначенных для работы с InterBase, это простительно
однако простой анализ таблицы RDB$CHARACTER_SETS в БД на FireBird показывает, что там для UTF8 идентификатор=4, а код 59 соответствует чарсету WIN1256
для эксперимента подсоединяемся к БД с этим чарсетом (хоть через IBX, хоть через dbExpress) и - вуаля! - размер поля на клиенте становится корректным
из всего этого можно сделать несколько выводов:
1. в момент разветвления IB6 и FB1 идентификаторы чарсетов совпадали, но дальше каждый разработчик добавлял новые чарсеты со своими ID по своему усмотрению и в свой момент
2. драйвер dbxfb.dll явно делался по исходникам для dbxint.dll, возможно, условной компиляцией отдельных кусочков (в бинарнике четко прослеживаются имена модулей с "IB", а также присутствует SQL-тип данных BOOLEAN, которого в 2010 г в FB еще не было)
3. программисты драйвера наверняка тоже зашили в код ID чарсетов вместо того, чтобы считать и интерпретировать корректно данные из RDB$CHARACTER_SETS
