[ https://issues.apache.org/jira/browse/PDFBOX-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16171152#comment-16171152 ]
Tilman Hausherr commented on PDFBOX-3933: ----------------------------------------- Please try this code with the file from PDFBOX-2079: {code} static public void testEmbeddedZipFile() throws IOException { //there should be 17660 bytes in the zip file. //in PDFBox 1.8.5, windows newline is appended to the byte stream //yielding 17662 bytes, which causes a problem for ZipFile in Java 1.6 boolean ok = false; PDDocument doc = PDDocument.load(new File("embedded_zip.pdf")); PDDocumentCatalog catalog = doc.getDocumentCatalog(); PDDocumentNameDictionary names = catalog.getNames(); PDEmbeddedFilesNameTreeNode node = names.getEmbeddedFiles(); int bytes = 0; int numAttach = 0; for (Map.Entry<String, COSObjectable> ent : node.getNames().entrySet()) { PDComplexFileSpecification spec = (PDComplexFileSpecification) ent.getValue(); PDEmbeddedFile file = spec.getEmbeddedFile(); InputStream input = file.createInputStream(); File testZip = new File("testzip.zip"); OutputStream os = new FileOutputStream(testZip); IOUtils.copy(input, os); os.flush(); os.close(); ZipFile zipFile = new ZipFile(testZip); System.out.println(testZip.length()); System.out.println(zipFile.getName()); numAttach++; } doc.close(); } } {code} This never made it to the official tests for some reason but I remember the case because it was traumatizing at that time (LOL). It should print 17660 but it prints 17661. > PDFParser swallows a CR at the end of a stream > ---------------------------------------------- > > Key: PDFBOX-3933 > URL: https://issues.apache.org/jira/browse/PDFBOX-3933 > Project: PDFBox > Issue Type: Bug > Affects Versions: 1.8.14 > Reporter: Petr Slaby > Attachments: EndlinePrediction.patch > > > I have a PDF which I cannot share at the moment, maybe later if I get a > permission from the customer. > The PDF is protected by an empty password, all streams are encrypted using > AES. The PDF consistently uses the LF character for line endings. One of the > streams looks like this: > {code} > 10 0 obj > <</Length 9 0 R/Filter/FlateDecode/N 3/Range[0 1 0 1 0 1 ]>> > stream > ....<0x0D><0x0A> > endstream > {code} > i.e. Length field is a reference to an object, in the content, the length > object is stored immediately after the stream as > {code} > 9 0 obj > 2624 > endobj > {code} > The byte <0x0D> belongs to the stream and is not to be treated as line > separator in this case. The parser is not able to read the length field so it > manually searches for the stream end in the class EndstreamOutputStream. This > class searches both for the pair <0x0D><0x0A> and the single <0x0A>, so it > strips off the <0x0D> from this particular stream content. Since the stream > is encrypted, PDFBox runs into a BadPaddingException later on when trying to > decrypt the stream. > The problem is reproducible using org.apache.pdfbox.PDFToImage in current > 1.8.14-SNAPSHOT. The same works fine in current PDFBox 2.0.x, presumably > because it uses the non-sequential parser by default. > The proposed fix is to analyze the PDF content while reading it and search > for the CR character only if it was ever encountered as a line separator > prior to the stream being parsed. > Note: I do not exactly know or understand the usage of the other classes > inherited from BaseParser, like PDFObjectStreamParser. Maybe the line ending > heuristic should be kept "as before" in these classes, by setting the new > field BaseParser.hasCR to true already in the constructor. > A patch is attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org