You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Andreas Lehmkühler (JIRA)" <ji...@apache.org> on 2014/11/10 12:37:35 UTC

[jira] [Closed] (PDFBOX-1011) Incorrect metadata for encrypted PDFs with non-ASCII characters

     [ https://issues.apache.org/jira/browse/PDFBOX-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andreas Lehmkühler closed PDFBOX-1011.
--------------------------------------
       Resolution: Fixed
    Fix Version/s: 1.8.0
         Assignee: Andreas Lehmkühler

This was fixed some time ago. It works fine starting with 1.8.0

> Incorrect metadata for encrypted PDFs with non-ASCII characters
> ---------------------------------------------------------------
>
>                 Key: PDFBOX-1011
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-1011
>             Project: PDFBox
>          Issue Type: Bug
>          Components: Parsing
>    Affects Versions: 1.5.0
>         Environment: I'm on Mac OS X 10.6, but I would think it affects all.
>            Reporter: Neil McErlean
>            Assignee: Andreas Lehmkühler
>            Priority: Minor
>             Fix For: 1.8.0
>
>         Attachments: MHH_Torque_convertor2.pdf, testcase.patch
>
>
> I have a document which has Author metadata = "Jırg Boettger". That second character is not an 'i', it is a dotless lower case i.
> It is also an encrypted pdf, with user password = "".
> The problem is that if I load the document, decrypt it and then try to examine the document-level metadata (such as author) I see problems with the non-ASCII chars.
> I will attach a testcase & the sample PDF that reproduces the problem for me.
> A bit of detail that may be useful: COSObject 19 0 at the end of the PDF defines the Author. It is represented as byte[] = {-95, -118, -50, 122, -127, 105, 53, 105, 50, 14, -27, 122, 120}
> SecurityHandler.encryptData() line 223 - which decrypts the string gives: J?rg Boettger. bytes = [74, -102, 114, 103, 32, 66, 111, 101, 116, 116, 103, 101, 114]
> Note the -102 in the second character.
> The second character, whose byte-value is -102 is not a displayable ASCII char (even at 256 -102 = 154) and it just gets dropped from the COSString & so we get an author of Jrg Boettger from PDDocumentInformation.
> I'm not sure what the requirements are for handling non-ASCII chars in this situation. But Adobe Reader 9, 10 & Mac OS X's Preview application all show the correct author value.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)