问题标签 [apache-tika]

我能找到的所有文档似乎都表明我只能提取整个文件的内容。但我需要单独提取页面。我需要为此编写自己的解析器吗？是否有一些我遗漏的明显方法？

我正在使用 Solr 3.1、Apache Tika 0.9 和 Solrnet 0.3.1 像 .doc 和 .pdf 文件一样索引文档。

我已使用此代码在本地成功索引和提取文档

但是我遇到了使用相同代码从远程提取或索引文档的问题，我收到了错误：

信息

信息

描述

我正在尝试扫描目录中的所有 pdf/doc 文件。这工作正常，我能够扫描所有文档。

我要做的下一件事也是在搜索结果中接收文件的文件名。但是文件名永远不会出现。我尝试了几件事，但文档对于如何做到这一点并不是很有帮助。

我正在使用 solr 发行版中的 solr 配置：apache-solr-3.1.0/example/example-DIH/solr/tika/conf

这是我的数据配置：

我对如何正确配置它的方式以及我可以找到特定文档的任何其他地方感兴趣。

我有一个带有自定义搜索引擎的 jsp Web 应用程序。

搜索引擎基本上建立在 SQL Server 数据库的“文档”表之上。

例如，每个文档记录具有三个字段：

• 文件编号
• “描述”（文本字段）
• 'attachment'，文件系统中 pdf 文件的路径。

搜索引擎实际上是在描述字段中搜索关键字，并在 HTML 页面中返回结果列表。现在我什至想在 pdf 文件内容中搜索关键字。

我正在调查 Lucene、Tika、Solr，但我不明白如何将这些框架用于我的目标。

一种可能的解决方案：使用 Tika 提取 pdf 内容并存储在一个新的文档表字段中，这样我就可以在这个字段上编写 SQL 查询。

有更好的选择吗？我可以将 Solr/Lucene 索引功能用作基于 SQL 的搜索引擎的集成，而不是完全替代它吗？

谢谢

我希望能够创建一个新的 Tika 解析器来从文件中提取元数据。我们已经在使用 Tika，元数据提取将始终如一地完成。

我认为我遇到了 Tika 的这个问题/增强请求：

允许将文件或内存缓冲区传递给解析器

我有一个控制台 c++ 可执行文件，它接受输入文件的路径，然后输出它找到的元数据，每行由名称/值对组成。
c++ 代码依赖于在访问数据时需要文件路径的库。用 Java 重写这个可执行文件是不可能的。我认为将其插入 Tika 会相当容易。但是 Tika 解析器需要在 Java 中，并且需要被覆盖的 Tika 解析器方法需要一个开放的输入流：

void parse（InputStream 流、ContentHandler 处理程序、元数据元数据、ParseContext 上下文）

所以我想我唯一的解决方案是获取输入流并将其写入临时文件，然后处理写入的文件，然后最终清理文件。我讨厌弄乱临时文件，然后可能不得不担心临时文件的清理，如果出现问题并且它不会被删除。

有没有人对如何干净地处理这样的事情有一个聪明的想法？

请问有人可以帮我解决吗？

可以这样做

但是如果你不直接使用 Tika，像这样：

无法设置它，因为您不与WriteOutContentHandler. 顺便说一句，它-1默认设置为没有限制。但由此产生的限制是 100000 个字符。

我正在尝试使用基于 curl 的请求进行索引

请求是

在提交请求时，我收到此错误，

可以请任何设法做到这一点的人解释如何做到这一点:-)

我需要为我需要添加的语言获取 n-gram 文件吗？

是创建tika.language.override.properties，添加一些其他语言代码并在 classPath 上添加 lang-code.ngp n-gram 文件的问题吗？在那种情况下，我从哪里得到它，为什么 Tika 不支持更多语言，如果只是这个问题？

目前支持这些语言进行语言检测

并且 tika 使用传统的 n-gram 表示法

此语言检测应用程序当前支持这些语言，但具有不同的 n-gram 文件

JSON 表示法

我正在寻找基于 Java 的Apache Tika框架的 C/C++ 替代方案。具体来说，我正在一个框架下搜索文件数据和结构化文本提取。经过一些在线搜索和浏览后，我拥有的最接近的东西是GNU libextractor和一堆单独的文件过滤器，它们解析文档以提取文本数据（pdftoext、xls2csv ..etc）

任何人都可以推荐一个可以与 Apache 的 Tika 相媲美的好图书馆吗？

谢谢

I need to index content of doc/docx/pdf files uploaded by users and use Solr (1.4.1) ExtractingRequestHandler component (817165) for that. If that matters, I don't request indexing from it - the component is always called with extractOnly parameter returning text content of the document only and not adding it to the index on its own straight away (the content is then added to the index "outside" as a text field of the document following the standard procedure).

However, some files are not parsed and the component returns 500 Internal Server Error with no other details provided. Of all *.doc files submitted by our users about 30% of them fail to parse.

It is not the problem with Solr load - the files that cannot be parsed are always the same if you parse the same list of them again and again. It is also not about their size - many of them are smaller than other ones parsed successfully. Apparently, it is not about peculiar formatting (or at least that is not obvious) - almost all documents that fail to parse have coloured fonts, tables and images but many of the ones parsed successfully also have the same.

All these files open in Word without any warnings or errors. If you save them as docx Solr starts parsing them correctly but re-saving them in the same doc format with the same content doesn't help. Still, if all the content is removed and replaced by some lorem ipsum text, then saved as doc, they become correct.

As the content replacing helps, it should be something with some elements used in the documents but there is no description on Tika Formats page telling in which cases parsing of the document fails.

I've uploaded a sample file which fails to be parsed in case if anyone is curious enough to try it (it is archived to prevent Windows Live from converting it into "online document").

Currently as a way around I use an ancient antiword utility to parse those *.doc on which Solr fails (and antiword parses them perfectly). Still, it is obviously a crutch and I wonder if anybody else is facing the same issue - I failed to google it so probably that's me doing something wrong.

Or, if that's a known problem, what could be more elegant ways to solve it (I don't like relying on antiword)?