我需要索引用户上传的doc / docx / pdf文件的内容，并使用Solr（1.4.1）ExtractingRequestHandler组件（817165）。如果这很重要，我不会请求从中进行索引 - 始终使用extractOnly参数调用该组件，仅返回文档的文本内容，而不是直接将其添加到索引中（然后将内容添加到索引中）外部“作为遵循标准程序的文件的文本字段。”
但是，某些文件未被解析，组件返回500内部服务器错误而未提供其他详细信息。在我们的用户提交的所有* .doc文件中，大约30％的文件无法解析。
Solr加载不是问题 - 如果一次又一次地解析相同的列表，那么无法解析的文件总是相同的。它也不是关于它们的大小 - 它们中的许多都比成功解析的其他的小。显然，这不是特殊的格式化（或者至少不是很明显） - 几乎所有无法解析的文档都有彩色字体，表格和图像，但许多成功解析的文档也具有相同的格式。
所有这些文件都在Word中打开，没有任何警告或错误。如果您将它们保存为docx Solr开始正确解析它们，但使用相同的内容以相同的doc格式重新保存它们无济于事。尽管如此，如果所有内容都被删除并被一些lorem ipsum文本替换，然后保存为doc，它们就会变得正确。
由于内容替换有帮助，它应该是文档中使用的一些元素，但没有关于Tika Formats页面的描述，告诉在哪种情况下解析文档失败。
我上传的sample file无法解析，以防万一有人好奇地尝试它（它被存档以防止Windows Live将其转换为“在线文档”）。
目前，作为一种解决方法，我使用古老的antiword实用程序来解析Solr失败的那些* .doc（并且antiword完美地解析它们）。不过，这显然是一个拐杖，我想知道是否还有其他人面临同样的问题 - 我没有谷歌，所以可能是我做错了。
或者，如果这是一个已知问题，那么解决它的方法可能更为优雅（我不喜欢依赖反词）？
答案 0 :(得分：0)
如果我是你，我会尝试升级Tika
我已经拿走了您的示例文件，并使用最新版本的Tika进行了尝试。提取到文本工作正常，我看到了
LOREM IPSUM
Lorem ipsum dolor sit amet
------
Home Phone: 000000000
Work : 00000000
（等）
所以我怀疑这是旧版POI + Tika的一个问题，现在已经修复了。
（如果您正在使用SOLR的自定义构建副本，那么您可能只需要提升pom中的Tika依赖并重新构建，maven会为您处理它。否则新的SOLR应该有一个较新的Tika标准）