Оператор startxref
обычно находится в конце файла, а перед ним стоит трейлер.
Обновление: Выше вводное предложение было сформулировано недостаточно четко, как правильно заметил Джереми Уолтон (хотя более поздние комментарии в моем ответе намекали на исключения). Он должен был прочитать: "Оператор startref
обычно появляется в конце файла как один экземпляр, с трейлером перед ним (если только ваш файл не подвергался инкрементным обновлениям, в этом случае у вас могут быть разные экземпляры перекрестные ссылки с различными трейлерами. "
Если есть комментарии, добавленные в PDF, они учитываются так же, как и "настоящий" код описания страницы PDF, когда дело доходит до подсчета байтов для расчета смещения в байтах таблицы внешних ссылок. Поэтому нетрудно разобрать его правильно.
Цитировать прямо "изо рта лошади" ( PDF спецификация ISO 32000-1 , раздел 7.5.5):
" трейлер файла PDF позволяет соответствующему считывателю быстро находить таблицу перекрестных ссылок и определенные специальные объекты. Соответствующие читатели должны читать файл PDF с конца. Последняя строка файла должен содержать только маркер конца файла, %%EOF
. Две предыдущие строки должны содержать, по одной на строку и по порядку, ключевое слово startxref
и смещение байта в декодированном потоке от начала файла до начало xref keyword
в последнем разделе перекрестных ссылок. Строке startxref должен предшествовать трейлерный словарь , состоящий из ключевого слова trailer
, за которым следует ряд пар ключ-значение, заключенных в двойные угловые скобки [...] "
Здесь необходимо принять во внимание ключевое выражение: "LAST раздел перекрестных ссылок" .
Если вы имеете в виду обновленные трейлеры, то посмотрите Раздел 7.5.6.
Да, вы должны разобрать в обратном порядке. Первый раздел перекрестных ссылок, который нужно прочитать, является последним в файле, и у него будет предыдущий последний трейлер. Второй, который нужно прочитать, - это последний, но один, появляющийся в файле, с предшествующим последним, но единственным трейлером. Etc.pp .... Если вам нужно прочитать более одного раздела трейлера / ссылки, каждый из прочитанных должен содержать ссылку на следующий, который нужно прочитать.
Если вы думаете, что «комментарии» - это то, что вы можете свободно вставить в PDF, не повреждая его структуру, тогда думайте иначе. После того, как вы вставили комментарии, вы должны обновить хотя бы таблицу внешних ссылок (и, возможно, /Length
ключи объектов).
Обновление 2: Словарь trailer<<...>>
, созданный Джереми, вероятно, вообще не является допустимым словарем, поэтому он также не является действительным трейлером словарем. ..
В любом случае, согласно спецификации, словарь трейлера должен состоять из «серии пар ключ-значение» . «Правильные» ключи в словаре трейлера ограничены довольно узким набором, некоторые из которых даже являются необязательными (см. Таблицу 15 в разделе 7.5.5).
Джермей, кажется, построил свой пример таким образом, чтобы (неправильно) понять этот фрагмент как потенциально допустимый словарь трейлера:
trailer<<%) >>
% test test )
Что, конечно, вовсе не словарь, поскольку здесь мы не видим пары ключ-значение.
Его полный пример также недействителен, потому что «ключ» с именем /Key
не входит в число допустимых имен ключей для трейлера (которые, согласно таблице 15: /Size
, /Prev
, /Root
, /Encrypt
, /Info
, /ID
, /XRefStm
).
Таким образом, Джереми должен сделать в своем коде парсинга PDF то же самое, что делают все здравомыслящие и даже самые безумные библиотеки обработки PDF: отказаться от явно недопустимых конструкций вместо поиска смысла в них и сказать пользователю, что "ваш проклятый PDF поврежден, потому что мы не можем определить действительные ключи в предполагаемом разделе трейлера файла ".