导语
在上一篇文章最后,咱们尽管跑通了ES文件查找的全部流程,可是依然呈现了1个大的问题:ES7.3实测无法索引docx和doc文档,content有值可是无法解析到附件成为可读的可查找的内容,附件内容为空(附件中底子没有content这个字段,并非内容为空)。解决的思路是能够直接运用tika解析它的内容直接传递给ES,而不必通过pipline的黑盒。
系列文章传送门
2. 基于GitBucket的Hook构建ES检索PDF等文档全栈计划
排查过程
base64码是否存在?
答案是存在的! 首先是在Java应用程序增加打印入ES库前转码的base64对象的内容长度,均为十几万字符数,看不出与pdf文件有什么本质的差异。
扫除转码问题!
数据流传输失败?
其次,我修正了pipline,取消自动删去content的源字段,成果content中具有正常的大段base64内容但无法阅读,ES的attachment中仍是没有解析后的内容! 留意,入库是成功的,ES有这一次提交的成果,比如作者、文件名、标签等其他信息,只是看不了文件正文内容!
word文档存在问题?
那么有可能是我的word文档有问题吗? 于是我新建了一个测验文件,类型为docx,同时增加了一个测验文件类型为docx,成果表明docx文件仍是无法正常解析!
doc文件则直接在运行时报错找不到某个临时文件。
ES在处理时报错?
在复测docx类型文件入库时,我也检查了Java应用程序的日志,ES的master服务以及data节点的日志,全都没有任何相关的错误与正告。
Excel解析有问题吗?
实际上,我加测了xlsx的表格文件,也是无法解析内容的,一部分word文件被解析为zip压缩文件,还有一部分被解析为xml文件格局,阐明即便都是docx类型文件,ES的管道附件的识别也不一样,这与用户的直观感触不相符!
至此,这个问题陷入了泥潭!
在查询问题的过程中,GPT总是提示我该pipline已经被抛弃,不推荐运用。
终究计划
既然官方指出该插件基于tika库完成,咱们何不直接运用tika解析word等文件呢?这尽管失去了分布式的效果,可是一来更加可靠和可控,二来针对pdf类文件的业务场景体量都很小,犯不上运用分布式架构。
tika测验找不到office解析类
import org.apache.tika.parser.microsoft.OfficeParser;
尝试了tika库1.7/1.27和1.28版本均找不到该类!
在引证最新的2.9.0版本运行时报错:
从报错看,这个方法与文件版本有依赖关系,适应性太差!
扫除途径字符问题
尝试了修正文件名为全英文,途径也不包含中文字符或空格,可是都不打印内容!
运用最新的Tika库
最后查阅Tika官网的示例,修正成功的代码如下:
public static String getConteByTika(String filePath) throws IOException, TikaException, SAXException {
// 创立一个输入流
InputStream inputStream = Files.newInputStream(new File(filePath).toPath());
AutoDetectParser parser = new AutoDetectParser();
BodyContentHandler handler = new BodyContentHandler(-1);
Metadata metadata = new Metadata();
// 解析文件以提取元数据和内容
parser.parse(inputStream, handler, metadata);
inputStream.close();
return handler.toString();
}
这个方法的返回值作为es的一个一般文本字段内容即可,ES侧不需要额外装备任何插件pipline。
通过验证已经能够解析pdf、docx/excel/ppt和markdown、txt等6种格局的文件内容,实际上可支持的类型要远超这六种。
小结
综上,咱们完全能够基于Tika库来设计可控的文档解析,并写入ES,弃用ES的插件。在这种计划里咱们能够拥有更高的自由度,并随时能够进行任何的调试,不再是pipline的黑盒计划。