Chunked zlib на FPC: почему FlateDecode требует один поток

Чанковый писатель FlateDecode под Free Pascal обязан держать одно состояние zlib живым через все чанки. Соблазнительный читсхак — сжимать каждый чанк 64 KB сам по себе — выдаёт каждому чанку собственный zlib-заголовок и контрольную сумму, так что вложение размером 1 MiB превращается в шестнадцать zlib-членов, склеенных встык. FlateDecode по ISO 32000-1 ожидает ровно один zlib-поток, и стандартный декодер останавливается на первом маркере конца потока, а значит, всё после первых 65 536 байт молча пропадает. PDF Library for Delphi держит одно состояние zlib живым через все чанки — и в DeflateStream, и в InflateStream

Ловушка живёт только в FPC-половине кросс-компиляторного юнита и только на чанковом потоковом пути — именно поэтому её легко пропустить: Delphi-ветка и строковые хелперы каждый выдают одиночный zlib-поток, а маленькие тестовые данные до чанкового кода вообще не добираются. Это близкий родственник ловушек из статьи о пяти FPC-ловушках портирования, которые Delphi склонна прятать, с той разницей, что здесь Delphi ничего не прикрывает. Читсхак просто держится на неверной модели того, что такое zlib-поток

Почему чанковый zlib-поток обрезается другими PDF-ридерами?

Потому что zlib-поток по определению RFC 1950 — это один контейнер, а не их последовательность, и корректный инфлейтер считает первый трейлер Adler-32 концом данных. Формат — это двухбайтовый заголовок, один непрерывный битовый поток deflate по RFC 1951, чей последний блок несёт флаг финального блока, и четырёхбайтовая контрольная сумма Adler-32 по всем несжатым байтам. ISO 32000-1 §7.4.4 определяет /FlateDecode ровно в этих терминах. Дойдя до трейлера, inflate возвращает Z_STREAM_END и оставляет остаток входа непрочитанным в avail_in. С её точки зрения всё в порядке, ошибку она не поднимает, а байты после трейлера просто игнорируются. Склеенные члены — легитимная идея в gzip (RFC 1952 разрешает несколько членов в одном файле), скорее всего, интуиция пришла оттуда, но у zlib такого правила нет, и PDF его не просил

Наивный FPC-DeflateStream читает источник порциями по 64 KB и передаёт каждый чанк в ZFPCCompress — хелпер, который выполняет собственный deflateInit2, сжимает с Z_FINISH и вызывает deflateEnd. В результате каждый чанк выходит полным, валидным, самозавершённым zlib-потоком, а функция склеивает их в одну AnsiString перед записью. Результат выглядит как Flate-данные, имеет корректный заголовок и декодируется без ошибки, но декодируется ровно в первые 65 536 байт. На стороне чтения — зеркальная ловушка: вызов ZFPCInflate один раз на каждые 64 KB сжатого входа каждый раз стартует свежий inflateInit2. Второй чанк начинается посреди битового потока deflate без zlib-заголовка, поэтому новый инфлейтер его отвергает, и совершенно нормальный одночленный поток от любого другого производителя декодируется лишь настолько, насколько хватает первых 64 KB сжатых байт

// Наивный чанковый FPC DeflateStream (упрощённо):
// ZFPCCompress выполняет deflateInit2 / deflate(Z_FINISH) / deflateEnd,
// поэтому каждый чанк 64 KB становится отдельным zlib-членом
Repeat
  ReadCount:= Source.Read(Input[1], ChunkSize);
  If (ReadCount> 0) Then
    Compressed:= Compressed+ ZFPCCompress(Copy(Input, 1, ReadCount), 6, False);
Until (ReadCount< ChunkSize);
If (Compressed<> '') Then
  Target.WriteBuffer(PAnsiChar(Compressed)^, Length(Compressed));

Какие вызовы PDF Library for Delphi добираются до чанкового пути?

На FPC чанковый путь записывает все встроенные файлы от 1 MiB и больше, а читает любой Flate-поток, извлечённый через потоковый API, как только его сжатый размер переваливает за один чанк. TPDFStream.ReadFromStream решает, как кодировать входящие данные. Когда Deflate равен true и Stream.Size >= 1048576, данные идут потоком через DeflateStream; ниже порога источник целиком читается в память и вызывается DeflateStr — одноразовый хелпер, сжимающий всё одним вызовом. Цепочка фильтров ASCII85 плюс Flate тест на размер пропускает и всегда идёт через DeflateStream, так что на этом пути любые данные больше 64 KB и так размазываются на несколько чанков. Публичные точки входа, которые кормят ReadFromStream со включённым сжатием, — это писатели встроенных файлов:

• TPDFlib.EmbedFile и TPDFlib.AddEmbeddedFile, читающие файл с диска в поток /EmbeddedFile
• TPDFlib.AddAssociatedFileFromStream и TPDFlib.AddAssociatedFileFromFile, писатели связанных файлов PDF/A-3, используемые для XML электронных счетов и других исходных данных
• На стороне чтения — TPDFlib.GetEmbeddedFileContentToStream и GetEmbeddedFileContentToFile, которые декодируют через TPDFStream.WriteDecodedToStream и дальше через InflateStream

Ошибка здесь тихо проваливается на каждом слое. Писатель сохраняет /Params /Size и MD5-/CheckSum, посчитанный по исходному файлу, так что словарь вложения анонсирует полный размер, даже когда поток держит шестнадцать членов. Любой соответствующий стандарту ридер, включая сборку библиотеки под Delphi, аккуратно останавливается на первом Z_STREAM_END и возвращает ровно 65 536 байт. GetEmbeddedFileContentToStream возвращает 1, потому что он сообщает, подняло ли декодирование ошибку, а не совпадает ли вывод с /Size. Кто гонялся за проблемой большого документа через слияние и разделение гигабайтных PDF, тот знает этот паттерн: файл открывается, число страниц верное, а повреждение всплывает, только когда кто-то открывает вложение

Одно deflate-состояние на все чанки

DeflateStream в PDFlibZLib.pas инициализирует один paszlib.TZStream, скармливает каждый чанк deflate с Z_NO_FLUSH и лишь в конце дренирует компрессор Z_FINISH до возвращения Z_STREAM_END. На выходе — ровно один заголовок, один битовый поток deflate, чьи обратные ссылки дотягиваются через границы чанков, и один Adler-32 по всему входу. FPC-ветка имеет ту же структуру, что и Delphi-ветка. Заодно вывод пишется по мере производства, вместо того чтобы сначала склеивать весь сжатый результат в AnsiString, так что писатель никогда не строит в памяти вторую полную копию сжатых данных перед копированием в цель

// FPC DeflateStream с одним состоянием zlib (ветки ошибок опущены)
If (deflateInit2(strm, Level, Z_DEFLATED, 15, 8, Z_DEFAULT_STRATEGY)<> Z_OK) Then
  Exit;
Try
  Repeat
    ReadCount:= Source.Read(Input[0], ChunkSize);
    If (ReadCount> 0) Then
    Begin
      strm.next_in:= Pointer(Input);
      strm.avail_in:= ReadCount;
      While (strm.avail_in> 0) Do
      Begin
        strm.next_out:= Pointer(Output);
        strm.avail_out:= ChunkSize;
        Status:= deflate(strm, Z_NO_FLUSH);   // то же состояние, без разрыва на члены
        Produced:= ChunkSize- strm.avail_out;
        If (Produced> 0) Then
          Target.WriteBuffer(Output[0], Produced);
        If (Status<> Z_OK) Then
          Break;
      End;
    End;
  Until (ReadCount< ChunkSize);
  Repeat                                    // один трейлер на весь вход
    strm.next_out:= Pointer(Output);
    strm.avail_out:= ChunkSize;
    Status:= deflate(strm, Z_FINISH);
    Produced:= ChunkSize- strm.avail_out;
    If (Produced> 0) Then
      Target.WriteBuffer(Output[0], Produced);
  Until (Status= Z_STREAM_END);
Finally
  deflateEnd(strm);
End;

InflateStream идёт по тому же шаблону: один inflateInit2, внутренний цикл, который продолжает вызывать inflate, пока текущий чанк не исчерпан и выходной буфер перестал быть полным, и остановка на Z_STREAM_END. Есть один побочный эффект, о котором стоит знать. Писатель вызывает deflateInit2 сам, вместо того чтобы идти через хелпер с фиксированным уровнем, поэтому он уважает PLDeflateLevel, и уровень, заданный через TPDFlib.SetCompressionLevel(1..9), действует и на большие встроенные файлы на FPC. Это важно, если вы уже настраиваете сжатие под архивный вывод, как описано в статье о уменьшении размера PDF в Delphi

Как убедиться, что Flate-поток — это один zlib-член?

Распакуйте его обычным zlib-декодером и при возвращении Z_STREAM_END проверьте две вещи: длина распакованного равна длине источника, а avail_in равен нулю. Остаток входа после маркера конца — подпись склеенного потока. Процедура ниже — FPC-версия этой проверки, построенная прямо на paszlib, чтобы не доверять тестируемому коду, а за ней идёт проба, прогоняющая 200 000 байт, четыре чанка по 64 KB, через DeflateStream

uses Classes, SysUtils, paszlib, PDFlibZLib;

function IsSingleZlibMember(Packed: TMemoryStream; out Decoded: Int64): Boolean;
var
  strm: TZStream;
  Buf: array[0..65535] of Byte;
  Status: Integer;
begin
  Result:= False;
  Decoded:= 0;
  FillChar(strm, SizeOf(strm), 0);
  if inflateInit2(strm, 15) <> Z_OK then
    Exit;
  try
    strm.next_in:= Packed.Memory;
    strm.avail_in:= Cardinal(Packed.Size);
    repeat
      strm.next_out:= @Buf;
      strm.avail_out:= SizeOf(Buf);
      Status:= inflate(strm, Z_NO_FLUSH);
    until Status <> Z_OK;
    Decoded:= strm.total_out;
    // Один член заканчивается ровно на последнем байте входа
    Result:= (Status = Z_STREAM_END) and (strm.avail_in = 0);
  finally
    inflateEnd(strm);
  end;
end;

// Прогоняем 200 000 байт через DeflateStream с дефолтным чанком 64 KB
// и требуем один член, распаковывающийся обратно в полную длину
Source.Position:= 0;
DeflateStream(Source, Packed);
if not (IsSingleZlibMember(Packed, Decoded) and (Decoded = Source.Size)) then
  raise Exception.Create('DeflateStream produced more than one zlib member');

На уровне приложения полезное утверждение — то, которое библиотека за вас не делает: сравните то, что выходит из вложения, с /Params /Size, записанным при его добавлении. GetEmbeddedFileIntProperty с тегом 5 возвращает этот записанный размер, индексы встроенных файлов начинаются с 1, а полезная нагрузка должна быть не меньше 1 MiB, чтобы задействовать потоковый путь. Прогоняйте тот же тест на каждом компиляторе, с которым поставляетесь, ведь ошибки этого класса на Delphi проходят, а падают только на FPC

procedure CheckLargeAttachmentRoundTrip(const PayloadFile, OutFile: string);
var
  PDF: TPDFlib;
  Extracted: TMemoryStream;
  I, Declared: Integer;
begin
  PDF:= TPDFlib.Create;
  try
    PDF.NewDocument;
    PDF.AddStandardFont(4);
    PDF.DrawText(80, 100, 'Large attachment round trip');
    // От 1 MiB и больше идёт через чанковый путь DeflateStream в ReadFromStream
    if PDF.EmbedFile('Payload', PayloadFile, 'application/octet-stream') <> 1 then
      raise Exception.Create('EmbedFile failed');
    if PDF.SaveToFile(OutFile) <> 1 then
      raise Exception.Create('SaveToFile failed');
  finally
    PDF.Free;
  end;

  PDF:= TPDFlib.Create;
  Extracted:= TMemoryStream.Create;
  try
    if PDF.LoadFromFile(OutFile, '') = 0 then
      raise Exception.Create('LoadFromFile failed');
    for I:= 1 to PDF.EmbeddedFileCount do
    begin
      Extracted.Clear;
      if PDF.GetEmbeddedFileContentToStream(I, Extracted) <> 1 then
        raise Exception.CreateFmt('Attachment %d could not be decoded', [I]);
      Declared:= PDF.GetEmbeddedFileIntProperty(I, 5);   // /Params /Size
      if Extracted.Size <> Declared then
        raise Exception.CreateFmt('Attachment %d truncated: %d of %d bytes',
          [I, Extracted.Size, Declared]);
    end;
  finally
    Extracted.Free;
    PDF.Free;
  end;
end;

Пограничные случаи FPC-ветки

FPC-ветка использует снисходительные правила декодирования. При достижении MaxOutput FPC-InflateStream обрезает по лимиту и возвращается, тогда как Delphi-ветка поднимает ERangeError, и FPC по-прежнему принимает частично распакованный вывод, когда inflate сообщает об ошибке данных, — некоторые производители PDF выдают обрезанные или битые по контрольной сумме потоки. PDF, уже содержащий склеенные члены, — кто бы его ни писал, — останавливается на первом Z_STREAM_END в любом ридере. Не пытайтесь лечить такой файл, декодируя и пережимая поток внутри библиотеки, — это лишь навсегда закрепит обрезку 64 KB. Перевложите вложение из его исходного источника. FPC-цикл считает чтение, вернувшее меньше полного чанка, концом данных, а это верно для потоков вроде TFileStream и TMemoryStream, поэтому кастомный TStream, переданный в AddAssociatedFileFromStream, безопаснее всего сначала скопировать в TMemoryStream

FPC DeflateStream и InflateStream с единым состоянием входят в PDF Library for Delphi, которая собирает Delphi, C++Builder и Free Pascal из одного исходного дерева, так что большое вложение возвращается из FPC-сборки байт в байт — точно так же, как и из Delphi