Un PDF valido può essere "Dati di serializzazione Java"?

Ho un file PDF che il mio lettore (Zathura) non avrebbe aperto. Ho un altro lettore (mupdf) che lo apre. Credo che Zathura dipenda dal rilevamento del valore magico del file (primi pochi byte) perché può aprire altri formati oltre al PDF.

All'ispezione, ho notato che è stato rilevato come Java serialisation data, version 5.

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

Ispezione dei primi pochi byte:

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

Normalmente inizierebbe un PDF %PDF al byte 0.

Se tolgo i primi 27 byte, posso aprire il file:

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

Un'ulteriore ispezione mostra che il file è stato generato da Apache FOP Versione 1.1. Non riesco a trovare nessuna metion di questo formato per un PDF nonostante un bel po 'di Google.

È un formato valido per un PDF?

aggiornare avendo approfondito un po 'l'intestazione, sembra essere un array serializzato java in cui l'array contiene i dati del file PDF. Ho guardato il spec per il protocollo di serializzazione e, in particolare, il descrizione grammaticale da cui ho potuto decodificare l'intestazione di 27 byte come:

AC ED = STREAM_MAGIC identifica il contenuto del file come protocollo di serializzazione.
00 05 = STREAM_VERSION La versione di serializzazione.
75 = TC_ARRAY
72 = TC_CLASSDESC
00 02 = Lunghezza del nome della classe.
5b 42 = il nome della classe ur
AC F3 17 F8 06 08 54 E0 = SerialVersionUID, l'identificativo della versione seriale della classe.
02 = bandiera SC_SERIALIZABLE - l'oggetto supporta la serializzazione.
00 00 = Numero di campi in questa classe (zero!)
78 = TC_ENDBLOCKDATA.
70 = TC_NULL (L'oggetto non ha una classe genitore).
00 03 89 95 = lunghezza di "array" = 231829 = dimensione dei dati in byte

Il PDF estratto è infatti lungo 231829 byte

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

Ciò indicherebbe che il file non è corrotto ed è in effetti un array serializzato Java che contiene un documento PDF. Ma questo sarebbe considerato un PDF valido?

pdf

— starfry
fonte

Il riferimento ha questo da dire:

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

La mia interpretazione di questa linea è che, in senso stretto, il file che hai è non un file PDF valido. La prima linea estremità con il valore corretto, ma contiene ulteriori "garbage" prima di esso.

Detto questo, è molto probabile fino all'attuazione del lettore PDF come cercare il %PDF-x.x magia, e la mia ipotesi è quella più letta fino a quando non colpiscono la prima 0D 0A che nel tuo caso si trova subito dopo il marcatore PDF.

Se i dati di serializzazione avessero contenuto il file 0D 0A valore, quindi la mia ipotesi è che anche il mupdf non riuscirebbe a leggerlo.

— Magnus
fonte

Stavo scrivendo la stessa risposta, ma tu eri solo un po 'più veloce. Sono totalmente d'accordo. Nessun lettore PDF appropriato dovrebbe accettare un file come valido. Che alcuni facciano a parte i dati extra è pura fortuna.

— Tonny

È solo un solitario 0A che segue l'intestazione (in realtà una riga di commento come suggerito dalla specifica - 0a 25aa abac ad0a ) ma il tuo punto ha senso sul perché un lettore più rilassato potrebbe far fronte quando quelli che aderiscono alle specifiche non lo fanno.

— starfry

Sembra che qualsiasi combinazione di 0A, 0D o 0D 0A funziona .. Ho due file PDF sul desktop e ce n'è uno 0D e l'altro ha 0D 0A. :)

— Magnus