iTextsharp用長密碼保護PDF文件

我正在使用以下代碼來使用iTextsharp庫來保護PDF文件。iTextsharp用長密碼保護PDF文件

public Boolean ProtectPDF(String sourceFile, String newFile, String UserPassword, String OwnerPassword) 
    { 
     try 
     { 
      byte[] USER = System.Text.Encoding.ASCII.GetBytes(UserPassword); 
      byte[] OWNER = System.Text.Encoding.ASCII.GetBytes(OwnerPassword); 
      PdfReader reader = new PdfReader(sourceFile); 
      PdfStamper stamper = new PdfStamper(reader, new FileStream(newFile, FileMode.Create)); 
      stamper.SetEncryption(USER, OWNER, PdfWriter.AllowPrinting, PdfWriter.ENCRYPTION_AES_128); 
      stamper.Close(); 
      reader.Close(); 

      return true; 
     } 
     catch (Exception) 
     { 
      return false; 
     } 
    }

它可以很好地用於「短」的密碼，如1234567890ABCDE = GHIJ12。

如果我嘗試用「長」的密碼申請如2017DgFLcnODOy8 = 7D-+ 0 | FK/2 = G-02D^XZ-D3S @ 2 |？WiuXjQJoRBU =，我發現只有前32個字符被認爲是密碼，似乎這對我輸入的字符無關緊要，但PDF文件仍然會打開。

對PDF或ITextsharp庫有任何限制，或者問題存在於代碼中？

請指教，謝謝。

來源

2017-09-15 Trowa

這是PDF規範固有的限制，而不是iText的限制。

這是ISO 32000-1的相關部分。它討論了一個32字節的字符串。

ISO 32000-1是當你產生PDF 1.7文件的規範。由於您仍然提到iTextSharp（而不是iText for .NET），因此我假設您使用的是舊版iText版本。

幾個月前，ISO 32000-2發佈了，又名PDF 2.0。 iText 7.1將支持PDF 2.0。 PDF 2.0中提供更長的密碼（最多48個字節）。

如果您使用的密碼長度超過規範允許的值，iText將忽略所有額外的字節。

來源

2017-09-15 09:46:46

很高興再次見到你，那麼這是否意味着PDF只能識別前32個字符作爲密碼？ – Trowa

我已經更新了我的答案，添加了ISO 32000-1的相關部分。一旦你決定創建PDF 2.0，你應該將你的iText版本升級到iText 7.我們將在7.1版本中支持PDF 2.0（即將發佈）。從那一刻起，您將被允許使用48字節的密碼。 –

感謝您的解釋，我將決定是否升級到iText 7. – Trowa

iTextsharp用長密碼保護PDF文件

回答

相關問題