导语

在上一篇文章最后,咱们尽管跑通了ES文件查找的全部流程,可是依然呈现了1个大的问题:ES7.3实测无法索引docx和doc文档,content有值可是无法解析到附件成为可读的可查找的内容,附件内容为空(附件中底子没有content这个字段,并非内容为空)。解决的思路是能够直接运用tika解析它的内容直接传递给ES,而不必通过pipline的黑盒。

系列文章传送门

1. 完成ES检索pdf等文件内容的插件

2. 基于GitBucket的Hook构建ES检索PDF等文档全栈计划

3. Java完成读取转码写入ES

4. ES文件查找的细节优化与完成

排查过程

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版本运行时报错:

ES解析word内容为空的问题和直接运用Tika解析文档的计划

从报错看,这个方法与文件版本有依赖关系,适应性太差!

扫除途径字符问题

尝试了修正文件名为全英文,途径也不包含中文字符或空格,可是都不打印内容!

运用最新的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的黑盒计划。