Um PDF válido pode ser “dados de serialização Java”?

1

Eu tenho um arquivo PDF que meu leitor (Zathura) não abriria. Eu tenho outro leitor (mupdf) que abri-lo. Acredito que o Zathura depende da detecção do valor mágico do arquivo (primeiros bytes), pois ele pode abrir outros formatos além do PDF.

Na inspeção, notei que é detectado como Java serialisation data, version 5.

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

Inspecionando os primeiros bytes:

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

Normalmente, um PDF começaria com %PDF no byte 0.

Se eu despir os primeiros 27 bytes, posso abrir o arquivo:

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

Uma inspeção mais detalhada mostra que o arquivo foi gerado pelo Apache FOP Versão 1.1. Não consigo encontrar qualquer metion deste formato para um PDF, apesar de um pouco do Google.

Este é um formato válido para um PDF?


atualizar Tendo mergulhado um pouco no cabeçalho, ele parece ser um array serializado em java, onde o 'array' contém os dados do arquivo PDF. Olhei para o especificação para o protocolo de serialização e, em particular, o descrição gramatical a partir do qual eu poderia decodificar o cabeçalho de 27 bytes como:

  • AC ED = STREAM_MAGIC identifica o conteúdo do arquivo como protocolo de serialização.

  • 00 05 = STREAM_VERSION A versão de serialização.

  • 75 = TC_ARRAY
  • 72 = TC_CLASSDESC
  • 00 02 = Comprimento do nome da classe.
  • 5b 42 = o nome da classe ur
  • AC F3 17 F8 06 08 54 E0 = SerialVersionUID, o identificador da versão em série da classe.
  • 02 = flag SC_SERIALIZABLE - o objeto suporta serialização.
  • 00 00 = Número de campos nesta classe (zero!)
  • 78 = TC_ENDBLOCKDATA.
  • 70 = TC_NULL (Objeto não tem classe pai).
  • 00 03 89 95 = length of "array" = 231829 = tamanho dos dados em bytes

O PDF extraído é de fato 231829 bytes

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

Isso indicaria que o arquivo não está corrompido e é, de fato, um array serializado Java que contém um documento PDF. Mas isso seria considerado um PDF válido?

starfry
fonte

Respostas:

1

o referência tem isto a dizer:

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

Minha interpretação dessa linha é que, estritamente falando, o arquivo que você tem é não um arquivo PDF válido. A primeira linha termina com o valor correto, mas contém "lixo" adicional antes dele.

Dito isto, é mais provável que até a implementação do leitor de PDF como procurar o %PDF-x.x magia, e meu palpite é que a maioria lê até que eles atingiram o primeiro 0D 0A que no seu caso acontece logo após o marcador PDF.

Se os dados de serialização contivessem o 0D 0A valor, então meu palpite é que o mupdf também falharia em lê-lo.

Magnus
fonte
Eu estava escrevendo a mesma resposta, mas você foi um pouco mais rápido. Eu concordo totalmente. Nenhum leitor de PDF adequado deve aceitar tal arquivo como válido. Que alguns, independentemente dos dados extras, são pura sorte.
Tonny
É apenas um solitário 0A que segue o cabeçalho (na verdade, uma linha de comentário, como sugerido pela especificação - 0a 25aa abac ad0a mas seu ponto faz sentido porque um leitor mais relaxado pode lidar quando aqueles que aderem à especificação não o fazem.
starfry
Parece que qualquer combinação de 0A, 0D ou 0D 0A funciona .. Eu tenho dois arquivos PDF no meu desktop, e um tem 0D e o outro tem 0D 0A. :)
Magnus