Модифицировать анализ Apache Tika ODF и старых (1997-2003) документов MS Word?

Question

Я разрабатываю приложение, которое будет выполнять индексирование больших файлов Lucene (разделение их на несколько документов org.apache.lucene.document.Documents) разных форматов. В первоначальном подходе, по крайней мере, каждый «документ Луцен» состоит из одного «абзаца».

Как правило, Apache Tika, по-видимому, является находкой для этого: вы просто бросаете в него документ и, похоже, высасываете весь текст независимо от формата.

Но я хотел получить подробное представление о том, как он обрабатывает более сложные аспекты, и в ходе моего первого взгляда, как он обрабатывает сноски и концевые сноски, я нахожу, что в то время как в файле .docx он даст это " линия», для линии с 3 сносками:

|Tecum optime[footnoteRef:2], deinde etiam[footnoteRef:3] cum mediocri amico[footnoteRef:4]. 
[2: Sed quoniam et advesperascit et mihi ad villam revertendum est, nunc quidem hactenus; 
Quod si ita sit, cur opera philosophiae sit danda nescio.] [3: Si quae forte-possumus. 
Immo videri fortasse.] [4: Huius ego nunc auctoritatem [sequens idem faciam]. Confecta 
res esset. Primum Theophrasti, Strato, physicum se voluit; Ut proverbia non nulla veriora 
sint quam vestra dogmata.]| 

(Н.Б.„|“символы добавляются моим кодом для ясности)

... с тем же файлом в формате .doc Тик дает вам несколько «линий»:

|Tecum optime| 
|, deinde etiam| 
| cum mediocri amico| 
|.| 
... 

|??| 
| ? Sed quoniam et advesperascit et mihi ad villam revertendum est, nunc quidem 
hactenus; Quod si ita sit, cur opera philosophiae sit danda nescio. | 
|??| 
| ? Si quae forte-possumus. Immo videri fortasse. | 
|??| 
| ? Huius ego nunc auctoritatem [sequens idem faciam]. Confecta res esset. Primum 
Theophrasti, Strato, physicum se voluit; Ut proverbia non nulla veriora sint quam 
vestra dogmata. | 

... он не только разбивает исходный «абзац» на несколько строк, разбивая каждую ноту ссылки, но также подталкивает все сноски к концу обработки.

С обработкой файла .docx вы можете извлекать сноски и легко связывать их с предложением, к которому они принадлежат. Способ обработки .doc, конечно, довольно бесполезен для моих целей индексирования. В самом деле, я не могу понять, как исходные 4 "линии" могут быть идентифицированы как действительно принадлежащие к одному и тому же парафрагу.

Возможно, следует ожидать, что обработка Тикой устаревшего формата, такого как .doc, не так уж и прекрасна. Я теперь собираюсь взглянуть на фактический исходный код, который здесь задействован, предполагая, что я могу найти его среди многих, многих исходных банок, которые загрузил Gradle, но вместо того, чтобы настраивать код, есть более «обычный» способ модификации Tika's разбор заданного формата? Я немного искал, но ничего не нашел.

Конечно, другой подход может заключаться в преобразовании .doc-файлов (и .odt-файлов, см. Ниже) в .docx «на лету» для более качественного анализа.

PS Разбор LibreOffice .odt файлов (Open Document Format, ODF), не устаревший формат, также проблематичен. В частности, строка сноски/концевой сноски аналогично разделяется на несколько строк.

Answer 1

Мои выводы через пару дней для всех, кто интересуется.

Во-первых, похоже, что люди Apache на самом деле не хотят, чтобы вы играли с классами Tika.

При попытке настроить обработку формата MS Word 97-2003 (aka .doc), основным классом здесь является HWPFDocument («Horrible Word Processing Format»). Часть проекта POI Apache, который поставляется вместе с Tika.

Этот класс обычно захватывает InputStream из файла .doc и, похоже, бесполезно разбивает различные элементы файла, так что сноски и т. Д., Похоже, хранятся отдельно от текста. HWPFDocument - final, что является только началом проблемы: многие из этих файлов полагаются на другие классы в пакете или в подпакетах, многие из которых являются final или нет public (или protected).Я пришел к выводу, что в основном мне придется клонировать весь пакет org.apache.poi.hwpf, доктор и снова упакуйте его. Меня не беспокоило.

.odt (ODF) filetype действительно гораздо важнее для меня в конечном счете: не устаревшие и не-микро-доллары. Здесь ключевой класс оказывается org.apache.tika.parser.odf.OpenDocumentContentParser. Проблема здесь в том, что он содержит внутренний класс private final (т. Е. Они действительно не хотят, чтобы вы подклассифицировали его или даже использовали его экземпляр по какой-либо причине!), Который называется OpenDocumentElementMappingContentHandler, который реализует, в конечном счете, org.xml.sax.ContentHandler. Есть сотни (ну, лоты) ContentHandler - здесь задействованы классы, многие из которых «декораторы». Но в конечном итоге вам нужно скопировать весь код этого класса OpenDocumentContentParser, а затем объединиться с внутренним классом. Я сделал это так, чтобы в startElement и endElement, на основе значения параметра qName, он переключается в режим «синтаксического разбора» или «из режима разбора» возможных значений «НЕ УКАЗАНО» «NOTE_CITATION» или «NODE BODY» ... и on в основе этой настройки режима может отменить вызов

super.endElement(namespaceURI, localName, qName); 

в endElement. Это вызов super, который, как представляется, вызывает конец одной строки и начало следующего. Для того, чтобы поместить текстовые указания о том, что номер сноски или тело начало/окончание в выходном тексте вы можете создать String injectedText и затем

super.characters(injectedText.toCharArray(), 0, injectedText.length()); 

, если и когда это необходимо. Это происходит потому, что в конечном итоге ContentHandler, который на самом деле делает что-то является экземпляром ToTextContentHandler, то characters(...) метод, который только добавляет последовательность chars к java.io.Writer примеру (да, я никогда не слышал о том, что либо: очень простой) ,

Надеюсь, это поможет. Теперь я представил этот новый класс в проект Tika, чтобы посмотреть, нравится ли им его внешний вид.