Может ли действительный PDF быть «данными сериализации Java»?

У меня есть файл PDF, который мой читатель (Затура) не открыл. У меня есть другой читатель (mupdf), который открывает его. Я считаю, что Zathura зависит от определения магического значения файла (первые несколько байтов), потому что он может открывать другие форматы, кроме PDF.

При осмотре я заметил, что это обнаружено как Java serialisation data, version 5.

$ file document.pdf
document.pdf: Java serialization data, version 5

Проверка первых нескольких байтов:

00000000: aced 0005 7572 0002 5b42 acf3 17f8 0608 ....ur..[B......
00000010: 54e0 0200 0078 7000 0389 9525 5044 462d T....xp....%PDF-

Обычно PDF начинается с %PDFбайта 0.

Если я уберу первые 27 байтов, я могу открыть файл:

$ dd if=~/Downloads/file.pdf skip=27 bs=1 of=/tmp/file.pdf

Дальнейшая проверка показывает, что файл был сгенерирован Apache FOP версии 1.1. Я не могу найти какой-либо вариант этого формата для PDF, несмотря на немало Google.

Это правильный формат для PDF?

обновить , немного углубившись в заголовок, он выглядит как сериализованный массив Java, в котором «массив» содержит данные файла PDF. Я посмотрел спецификацию протокола сериализации и, в частности, описание грамматики, из которого я мог бы декодировать 27-байтовый заголовок как:

AC ED= STREAM_MAGICидентифицирует содержимое файла как протокол сериализации.
00 05= STREAM_VERSIONВерсия сериализации.
75 знак равно TC_ARRAY
72 знак равно TC_CLASSDESC
00 02 = Длина имени класса.
5b 42 = название класса ur
AC F3 17 F8 06 08 54 E0= SerialVersionUID, серийный идентификатор версии класса.
02= флаг SC_SERIALIZABLE- объект поддерживает сериализацию.
00 00 = Количество полей в этом классе (ноль!)
78= TC_ENDBLOCKDATA.
70= TC_NULL(Объект не имеет родительского класса).
00 03 89 95 = длина "массива" = 231829 = размер данных в байтах

Извлеченный PDF действительно имеет длину 231829 байт

$ dd if=document.pdf skip=27 bs=1 | wc -c
231829 bytes

Это указывает на то, что файл не поврежден и действительно является сериализованным массивом Java, который содержит документ PDF. Но будет ли это считаться действительным PDF?

pdf

— starfry
источник

Ссылка имеет это сказать:

3.4.1 File Header

The first line of a PDF file is a header identifying the version of the PDF
specification to which the file conforms. For a file conforming to PDF 1.7, 
the header should be

    %PDF−1.7

Моя интерпретация этой строки такова, что, строго говоря, файл, который у вас есть, не является допустимым файлом PDF. Первая строка заканчивается правильным значением, но она содержит дополнительный «мусор» перед ним.

Это говорит о том, что, скорее всего, до реализации PDF-ридера зависит, как искать %PDF-x.xмагию, и я предполагаю, что большинство читают до тех пор, пока они не достигнут первого, 0D 0Aкоторый в вашем случае оказывается сразу после PDF-маркера.

Если данные сериализации содержали бы 0D 0Aзначение, то я предполагаю, что mupdf также не сможет прочитать его.

— Магнус
источник

Я писал тот же ответ, но ты был немного быстрее. Я абсолютно согласен. Ни один правильный PDF-ридер не должен принимать такой файл как действительный. Что некоторые делают независимо от дополнительных данных, это просто удача.

— Тонни

За 0Aзаголовком следует только одиночество (на самом деле строка комментария, как это предлагается в спецификации - 0a 25aa abac ad0a ), но ваш смысл имеет смысл в том, почему более расслабленный читатель может справиться, если те, кто придерживается спецификации, этого не делают.

— Старфри

Кажется, что любая комбинация 0A, 0Dили 0D 0Aработает .. У меня есть два файла PDF на моем рабочем столе, и один имеет, 0Dа другой имеет 0D 0A. :)

— Магнус