Разбор формата истории RnQ

сообщение всегда кодируется:
f_info:=critted(info_, StrToIntDef(who.uid, 0))
2-е поле наз-ся Kind. Вам лучше расшифровывать когда Kind=EK_msg
ExInfoSize совсем не всегда =21.
Msg - Совсем не AnsiString, а RawByteString.
И текст там не только зашифрован, но и может быть в разных кодировках. Последнее время в основном в UTF8.

StrToIntDef(IntToStr(Res.UIN), 0) - странный код

По поводу ExInfo - в исходниках 1105 всё и написано:
function extraInfo:string;
begin
result:=TLV2(EI_flags, int2str(flags));
if not isOnlyDigits(who.UID) then
result:= Result + TLV2(EI_UID, int2str(length(who.UID))+who.UID);
result:=int2str(length(result))+result;
end; // extrainfo

Т.е. если UIN=0, то туда пишется строка с, например, почтой (если это mail.ru контакт или AIM).

Очень жаль, что в файл истории не пишется Никнейм собеседника, а только UIN. При импорте практически не реально понять кто же прячется за определенным номером

Может есть планы по доработке формата истории? Добавить пару полезных полей, такие как Никнейм и Количество сообщений. А то пока не прочитаешь весь файл, то не понятно сколько же всего в нем сообщений, накладно это очень. Про отсутствие Ника уже написал.

Единственный баг, это очень редко, но некоторые сообщения остаются все же абра-кадаброй.
Возможно дело в кодировке, хотя после расшифровки я проверяю строку, если она UTF8, то декодирую её.

procedure FastDetectCharset(S: AnsiString; var CountUTF8, CountWin, CountUTF, CountUTFBE: Integer);

Поля переменной длинны, это не последние сюрпризы, которые вам могут встретится. Смотрим, например, в сторону протокола мыл-агента и плагинов, пихающих в историю картинки неприличных размеров.

Если любопытно, взгляните на исходники и историю создания RnQ_Repair. Могу также поделится не выложенными более свежими.

Никнеймы берутся элементарно из {%Root_RNQ%}\{%UIN%}\db5:db. Файлик db5 распаковываем любым алгоритмом с поддержкой Zip. Я пользуюсь zlib + minizip, последний в собственной адаптации.

Файлы истории уже достаточно перегружены "пестрым" составом данных, имхо.
А писать избыточные данные (которые могут быть получены путем вычисления или доступа к другим объектам), вообще плохой стиль.

А количество сообщений все равно станет известно, так как файл все равно придется читать весь,
для конвертации. Это же связанный список, типа Next->Next. Хоть на стриммерную ленту пиши.

Единственный баг, это очень редко, но некоторые сообщения остаются все же абра-кадаброй.
Возможно дело в кодировке, хотя после расшифровки я проверяю строку, если она UTF8, то декодирую её.

procedure FastDetectCharset(S: AnsiString; var CountUTF8, CountWin, CountUTF, CountUTFBE: Integer);

Был бы очень благодарен, если поделитесь исходниками. Обещаю что никуда не уйдут.
...
в WideStrUtils есть функция IsUTF8String, вот её я и использую для определения UTF8 строка или нет. Если UTF8, то делаем UTF8Decode. Конечно если строка в какой-нибудь другой кодировке, то получается абра-кадабра.

Не поделитесь своей процедуркой FastDetectCharset?

Смотрите файл Decode.pas в исходниках на предмет FastDetectCharset.
Ссылка на исходники и пароль в теме утилиты/плагина RnQ_Repair.

Не выложенные более свежие, тоже кину, как только откопаю на диске.
Их содержимое касается некоторых хитро-мудростей нечасто встречающихся данных в истории, а также увеличения производительности класса файлового I/O.