PDFs mit WebCrawler Indexieren - Best Practice? (haupia2 2.0.59)

[chbo]

Hallo Zusammen,

ich muss für einen Kunden PDF auf seiner Webseite indexieren. Die PDF sind irgendwo auf Webseite verlinkt.

Wenn jemand von Euch einen guten Einfall hat, wäre für Hinweise dankbar.

Mein aktuelle Ansatz:

1) Wir iterieren über alle HTMLs und PDFs des Kunden. (HTMLs sind nötig um die komplette Seite zu durchsuchen)

boolean followUrl(String url, String baseHost) {
  // ==~  entspricht einem Java "Mein String".matches("<regex>");
  def isHtml = (url ==~ /.*\.html$/)
  def isPdf = (url ==~ /.*\.pdf$/)
  def isCustomerHost = (url ==~ "^https://example.com/.*")
  return (isCustomerHost && isPdf) || (isCustomerHost && isHtml)
}

2) Beim Enhancer entfernen wir alle HTMLs:

void manipulate(final Document document, final String html, final org.jsoup.nodes.Document jsoupDocument)  {
  def link = document.getData('link').get(0)
  if(link ==~ /.*\.pdf$/) {
    def orgContent = document.getData('content').get(0) // wurde Automatisch befüllt mit Tika
    // DO SOMETHING with PDF
  } else {
    // Skip non PDF files
    document.removeData('content');   // Das erzeugt eine Warnung im Log
  }
}

Diese Lösung hat folgende Probleme:

• HTML Seiten werden automatisch mit Tika indexiert ohne das Parameter gesetzt werden können.
  Folge: Es können nur die ersten 10.000 Zeichen von PDF indexiert werden, denn da greift default CharLimit von Tika
• Es gibt keine Möglichkeit Dokumente ohne Warnung zu verwerfen. Oder?

Für das 10.000 Zeichen Limit fällt mir nur ein nochmal das PDF im Enhancer zu parsen.

void manipulate(final Document document, final String html, final org.jsoup.nodes.Document jsoupDocument)  {
  ...
  def charLimit = -1
  def textHandler = new org.apache.tika.sax.BodyContentHandler(charLimit)
  def metadata = new org.apache.tika.metadata.Metadata()
  def parser = new org.apache.tika.parser.pdf.PDFParser()  //pdf parser
  def stream = new java.net.URL(link).newInputStream()
  try {
    parser.parse(stream, textHandler, metadata);
    document.removeData('content')
    document.addData('content', textHandler.toString())
    ...
  }
  ...
}

Ich könnte noch testen ob weniger als 10.000 Zeichen im Content Feld sind, bevor nochmal anfange zu Parsen.

[granato · Accepted solution]

Ohne deine genaue Version zu kennen, hätte ich folgende Anmerkungen:

Filtern der HTML Seiten:

Statt das Content-Feld zu leeren, bitte setze den Boost des Documents auf 0:

// Skip non PDF files 
document.setBoost(0.0)

Die Warnung die du siehst entsteht beim Versuch aus deinen HTMLs ein valides SOLR-Dokument zu machen. Den Boost auf 0 zu setzten sollte verhindern dass deine HTMLs diesen Schritt überhaupt erreichen.

10000-Zeichen Limit:

Tatsächlich ist dies wie du anmerkst eine Beschränkung die durch das Default-Verhalten von Tika hervorgerufen wird. Derzeit gibt es noch keine Möglichkeit in haupia dies konfigurativ zu beeinflussen, ich werde das Thema ins Team tragen. Danke fur die Anregung.

Da Dir dies akut aber nicht hilft, ist hier dein Ansatz zu lange PDFs nochmal im Groovy nachzuparsen vermutlich kein schlechter. Hinweis: Tika verarbeitet die PDFs in-memory, also ist eventuell ein hohes Limit statt '-1' sinnvoll. Das Ergebnis ist hier natürlich Systemabhängig.

Ich hoffe dir helfen diese Infos weiter!

[chbo]

Luca, danke für die Antwort.

Die Version mit der wir Arbeiten ist die haupia2-2.0.59.

Es wäre gut, gut wenn wir das automatische PDF Indexieren steuern könnten. Folgende Optionen wären cool:

• PDF indexieren mit eigenen CharLimit (inkl. CharLImit -1)
• PDF Indexieren deaktiviert