PDFs in Blobs einlesen

[Mike90]

Hallo,

hat jemand eine Ahnung, wie man PDFs in Java einliest und dann in Datenbank Blobs speichert ?
Die PDFs sollen auch mit richtiger Formatierung eingelsen und gespeichert werden!

Beste Grüße,
Mike90

 

[r.w.]

Hallo,

hat jemand eine Ahnung, wie man PDFs in Java einliest und dann in Datenbank Blobs speichert ?
Die PDFs sollen auch mit richtiger Formatierung eingelsen und gespeichert werden!

Beste Grüße,
Mike90

Hallo Mike,

die folgenden Code-Fragmente habe ich per Copy/Paste mit einigen textuellen
Änderungen bzw. Löschungen aus einem meiner Projekte hier eingefügt.
Ich hoffe, ich habe dabei keine Fehler eingebaut. Die grundsätzliche
Vorgehensweise sollte aber daraus ersichtlich sein.


Beliebige Datei in BLOB speichern..

    void docSave(int id, String fn) {
      try {
	        FileInputStream  fis = new FileInputStream(new File(fn));
            PreparedStatement ps = deineDbConnection.prepareStatement("UPDATE your_pdf_table set document = ? WHERE id = ?;");
            ps.setBlob  ( 1, fis);            // blob-content
            ps.setInt   ( 2, id);             // satz-id
            System.out.println("Speichere Dokument");
            if (ps.executeUpdate()==1) {
               System.out.println("Dokument gespeichert.");
            } else {
               System.out.println("Speichern fehlgeschlagen.");
            }
      } catch (SQLException ex) {
         Logger.getLogger(BlobDoc.class.getName()).log(Level.SEVERE, null, ex);
      } catch (FileNotFoundException ex) {
         Logger.getLogger(BlobDoc.class.getName()).log(Level.SEVERE, null, ex);
      }
    }

...und wieder aus der Datenbank heraus in eine Datei kopieren...

    void docLoad(String docId, String fn) {
      {
         PreparedStatement ps = null;
         InputStream is       = null;
         FileOutputStream fos = null;
         ResultSet rs         = null;
         try {
            ps = deineDbConnection.prepareStatement("SELECT document FROM your_pdf_table WHERE doc_id = ?");
            ps.setString(1, docId);
            rs = ps.executeQuery();
            if (rs.next()) {
               is = rs.getBinaryStream("document");
               fos = new FileOutputStream(fn);
               byte[] buff = new byte[8192];
               int len=0;
               while ( (len=is.read(buff)) != -1 ){
                  fos.write(buff,0,len);
               }
               fos.close();
            }
            rs.close();
            ps.close();
         } catch (IOException ex) {
            Logger.getLogger(BlobDoc.class.getName()).log(Level.SEVERE, null, ex);
         } catch (SQLException ex) {
            Logger.getLogger(BlobDoc.class.getName()).log(Level.SEVERE, null, ex);
         } finally {
            try {
               fos.close();
               is.close();
            } catch (IOException ex) {
               Logger.getLogger(BlobDoc.class.getName()).log(Level.SEVERE, null, ex);
            }
         }
      }
    }

Ich hoffe, dass hilft Dir weiter.

VG ROlf
--------------
(EDIT: In Zeile 16 des 2. Code-Teils die Abbruchbedingung korrigiert.)

 

[HoaX]

while (0<(len=is.read(buff))){

Sollte besser auf != -1 prüfen. 0 darf und kann durchaus auftreten!

 

[SlaterB]

wann kann das auftreten?
bei Timeout in einer Netzwerkverbindung oder Eigenimplementierung könnte ich es mir vorstellen,
aber wie ist ansonsten ' This method blocks until input data is available, end of file is detected, or an exception is thrown. ' in
InputStream (Java Platform SE 6)
zu verstehen?

 

[musiKk]

Es kann genau dann passieren, wenn [c]buff[/c] die Länge null hat...

 

[SlaterB]

in diesem Fall oder sonstigen Fehler-0-read-Endlosschleifen-Gefahren wäre mir die >0-Schleifenvariante dann aber auch lieber 😉

 

[r.w.]

...
Returns:
the total number of bytes read into the buffer, or -1 is there is no more data because the end of the stream has been reached.
...

Wenn es schon so in den docs steht, sollte man es natürlich besser auch so prüfen. ;-)
Ich hab die Abbruchbedingung oben geändert.

 

[musiKk]

in diesem Fall oder sonstigen Fehler-0-read-Endlosschleifen-Gefahren wäre mir die >0-Schleifenvariante dann aber auch lieber 😉

Ich stimme dem prinzipiell zu. Ob man jetzt auf -1 prüft oder >0 oder >=0 ist relativ egal. Dennoch prüfe ich ohne jegliche Bedenken lieber auf -1. Da ist der Weg zwischen Code und Bedeutung geringer (von Streams lesen und -1 ist bei mir im Kopf automatisch EOF).

Bezüglich Endlosschleife mache ich mir keine Gedanken. Wenn ich mich nicht auf sowas verlassen kann, worauf dann? Lesbarkeit ist mir wichtiger.