tika in action第十一章中文

自我的学习记录！

Chapter11 tika的扩展

目前全球范围内存在成千上万种不同的文件格式, 随着技术的发展与应用需求的变化, 新的文件格式也会不断被引入. 因此, Tika系统也不可能覆盖所有可能的文件格式. 然而每个Tika版本都新增了对一些新格式的支持, 这也就意味着Tika系统仍然无法提取或识别你所要处理的特定文件类型. 本章将详细阐述如何应对这类问题.

想象你正在处理一种新的基于XML的医学处方文件格式。每个文件专门描述单一的处方，并包含多种混合和自由格式的信息。在确保高度的安全性和隐私性方面，在传输过程中对数据进行数字签名和加密。第11.1节详细阐述了如何在实际应用中使用数字处方文件。

旨在通过利用具有自由格式特性和特定元数据（如病人姓名与标识符）的数据源来进行查找。最直接的方式是采用现有的搜索机制，并接着需要做的就是指导Tika如何解析这些文件。

旨在通过利用具有自由格式特性和特定元数据（如病人姓名与标识符）的数据源来进行查找。最直接的方式是采用现有的搜索机制，并接着需要做的就是指导Tika如何解析这些文件。

我们计划将这类数字处方文件作为扩展tika的参考案例。接下来，我们将教导系统如何检测和识别这类文件，并引导系统如何解析它们。

11.1增加类型的信息

在识别文件类型时进行第一步处理。我们采用实验性命名法确定处方文件的标准格式。前缀中的'x-'标识未被正式认可的此类类型，在此情况下指定了非标准扩展名；而后缀中的'+xml'则表明该格式基于XML。

为了辅助处方文件的自动识别, 我们收集了一些关键信息. 如前所述, 在第4章中讨论了相关技术基础. 其中提到, 文件扩展名以及XML根元素可作为类型检测的有效辅助. 因此, 我们假设处方文件命名".xpd"作为其扩展名. 此外, 进一步的研究假设该XML文档将以".xpd:prescription"元素开始, 并使用特定前缀标识结构.

在媒体类型中存在这一类信息的所有内容都可以被记录下来，请您参考第四章中的MIME-info数据库以获取更多关于媒体类型记录结构的信息

为了教授tika处理新文件类型的核心方法，请我们重点发展现有的媒体库系统

11.1.1自定义媒体类型配置

我们回顾一下第四章关于共享MIME-info数据库文件的内容。该库记录了Tika所认知的各种媒体类型及其对应的信息。因此，在现有库的基础上新增一种新的媒体类型需要将相关信息补充进去。本节将介绍如何实现这一目标。

在tika-core JAR文件中，默认情况下Toka会通过读取位于'org.apache.tik.a/mime/tik-a.mtypes.xml'文件中的信息来加载数据库配置。然而你也可以借助MimeTypesFactory类来命令Toka以实现加载替代文件的功能具体说明如下

在应用自定义参数的情况下，该代码块将返回指定类型的MIME格式。你可以通过调用‘MimeTypesFactory’获取‘MimeTypes’类实例来创建 AutoDetectParser 或者任何其他所需的检测器实例。

在应用自定义参数的情况下, 该代码块将返回指定类型的 MIME 格式。你可以通过调用 'MimeTypesFactory' 获取 'MimeTypes' 类实例来创建 AutoDetectParser 或者任何其他所需的检测器实例。

由于Tika当前不支持将多种MIME-info数据库进行整合,因此最优的做法是将自定义数据库包含在tika-coreJAR中。这使得每次新版本发布后都需升级自定义库以保持兼容性。未来 versions必然增强对数据库升级的支持机制,从而更容易维护多样化的自定义扩展选项.

随后,tika识别出我们定义了特定的类型;接下来,我们将通过自定义检测器类来增加更多类型的检测策略

11.2自定义类型检测

我们通过定制MIME-info数据库使tika能够识别基于公共特征的文件类型（如文件扩展名、魔数字节或XML元素）以及相应的检测规则。然而，在处理更为复杂的文件格式时这些机制似乎无法发挥作用怎么办？答案就藏在tika提供的检测器接口中它为此设计了专门的空间供我们添加自定义类型的检定算法。

为了更好地理解检测器接口及其作为扩展的应用方式, 我们首先快速浏览了接口的工作原理. 接着我们将重点深入并实现了加密处方文件的一种完整自定义类型检测器. 最后我们将探讨如何将自定义的检测器整合到Tika中.

11.2.1检测器接口

该接口配置了一个通用API用于完成文件类型的鉴定任务。在该接口中定义的操作 detect 负责识别基于文件未处理的部分以及获取的相关文档元数据以辅助确定文件类型。下文即为您呈现其工作流程图：

该检测器的功能模块能够识别预定义的字节数组存在于字节流中；当从文档元数据中提取文件名扩展和其他媒体类型提示时。在仅分析文件名或原始字节流的情况下，请确保该检测器做好相应的准备。如果该检测器无法根据收集到的信息判断文档类型，则应返回默认的应用/octet-stream媒体类型。

Tika将采用Java提供的service提供机制来自动加载所有获取到的检测器。在处理文档类型时，在线可获得的所有检测器将按照队列顺序依次被调用，并返回最明确识别到的媒体类型作为结果。你可以通过开发自定义媒体类型检测算法来增强功能的能力，并相应地设置所需的服务者配置参数。在下一节中将介绍如何实现这些功能

11.2.2创建自定义类型检测器

例如，在前面讨论过的药房自动化系统中，默认情况下应能自动识别并处理来自加密邮件附件中的数字处方。我们拥有解密后的密钥库（key），但无法仅凭文件扩展名或其他类型标识来实现对这些文档的有效识别。

所以, 我们应该如何检查这些文档? 如前所述, 在Tika中实现了自定义的文本分类器, 这个分类器将被整合到Tika的类型识别系统中。

这里发生了什么？依次分析这里的代码：

首先，在默认构造方法中创建检测器类实例时，默认情况下检测器无法通过解析环境对象（ParseContext）访问其他设置；而相应的解析器类则能够进行相关操作。因此在这种情况下，则需要引入一个药房密钥的静态引用。

然后在Detect()方法中我们开始试图检测文档类型。该方法假设所指定的流具备标记特征，在返回前需将其归位至原始位置。org.apache.tika.io中的LookaheadInputStream类堪称完美工具，该类专注于管理所有流状态的信息。其Java文档提供了更多详细说明

3. 随后尝试利用标准Java加密算法API来解密lookahead流。无论发生何种情况（即使解密失败），我们假设该文档未被加密或者未能提供正确的文档密钥。该检测器类能够返回application/octet-stream作为响应类型。

当我们解密流之后

5. 最后，在所有标记点构成一个加密的数字处方文件的情况下，请返回application/x-prescription类型的指示向tika进行通知。并记录此操作源于从类型名中删除了 .xml 后缀的过程。鉴于加密使得该文档无法作为标准 XML 文件进行处理，请将这一新型媒体类型的识别包含在 MimeType-infodatabase 中，并将其归类为与现有 XML 类型相关的项目。

11.2.3加入新的检测器

完成对自定义检测器类的编译后, 最终需要完成的任务就是将其加入到Tika系统中。最简便的方法是将已经编译好的类文件放置于JAR档案以及META-INF/services/org.apache.tika.detect.Detector目录下, 并确保其中包含所有确认所需的类名. 接着导入该JAR至classpath路径中后, Tika系统会自动识别并采用这些新的检测器功能.

如果你希望在你的程序中更好地管理检测器的集合，则可以通过使用CompositeDetector类来清晰地组织这些检测器。以下代码段展示了如何扩展我们之前的检测示例以支持加密处方文件：

目前我们已经掌握了如何通过完善tika的媒体类型存储系统以及提升类型检测能力的方法来覆盖各类新文件类型的学习成果。在下一节中我们将重点指导tika解析此类文档

11.3自定义解析

识别文档类型具有实用性的同时，在信息提取方面表现得更为出色。需要你去做的文件格式解析工作，请参考第5章所述的解析器接口。为了使tika能够提取新类型的文档信息，请实现一个新的解析器类或扩展现有方案。本节将介绍两种方法：一种是实现新解析器类的方法；另一种是基于现有方案进行扩展的方法。

我们之前一直在探讨数字处方文件的相关内容。在他们的未加解密的形式中采用特殊结构的XML文档格式时，在加密形式中则对内部XML文件应用数字签名并将其包裹起来。为了更有效地处理这些文件类型，我们需要开发两个新的解析器类：一个是基于标准XML格式的基础解析器；另一个则是用于处理加密形式的解析器；如上图所示：

---

如图所示，在开发过程中

11.3.1自定义已存在的解析器

首先，在Tika中能找到现成的解析器。大多数情况下它们运行良好；然而如果你能够进行一些微小的优化来提升它们分析各种文档的效果可能会有所帮助。第5章介绍了解析环境的对象这一部分提供了一定程度上的自定义能力；有时候也需要让解析器进行更为复杂的配置以满足特定需求。

在Tika中存在许多解析器类采用了独特的设计。因此，在开发过程中你可以经常利用子类继承这些基类的方法来实现特定功能。通过查阅各解析器类的Javadoc文档，你可以了解到它们可继承的形式是什么。接下来将展示一个基于XMLParser的经典案例。

请回忆第十一章第1节中关于XML基础处方文档的内容？该文档包含被分隔开的不同元素例如医生病人药物以及所有相关的处方信息默认情况下XML解析器能够读取并解析这些元素使其成为可获取的结果如果其中至少有一部分字段具备元数据特征则是否能够应用？

该示例类具有以下特点：它继承了XMLParser的基本配置，并在元数据字段中同时将‘xpd:doctor’以及‘xpd:paitent’这两个元素进行了对应映射设置。

让我们一步步地浏览这些代码来更好地理解怎么工作的：

首先,该类继承了现有的XMLParser,并实现了protectedgetContentHandler()方法。该方法负责将解析XML文件时产生的SAX事件映射为Tika中的XHTML输出结果。在此情况下,我们自定义了将项目映射选择的XML文档部分对应至相关元数据字段。

为了达到这一目的, 我们采用org.apache.tika.parser.xml包中的ElementMatadataHandler工具类. 该工具能够解析所接收到的所有SAX事件流, 并将提取的信息按照预设规则映射至对应的元数据字段. 在当前情境下, 我们特别关注处方中的医生和病人的名称, 因此我们需要为处理这两种类型的数据分别建立两个不同的handler实例.

我们利用TeeContentHandler类将这些元数据及其默认父类返回的XMLParser属性进行整合，在第5章中提及的TeeContentHandler则用于进一步的信息查询。

最后实现getSupportedTypes()方法，并使其仅返回application/x-prescription/xml这一媒体类型。这使得我们能够定义的类能够与仅支持标准application/xml媒体类型的XMLParser类实现兼容存在。

这不是太难，对吧？下面是创建一个全新的解析器类。

11.3.2写一个新的解析器

你可能猜测：我们也也得开发一种能分析加密处方文件的方法。由于Tika不具备一般性地处理加密文件格式的能力，所以我们得开发出一种能够从加密处方中提取信息的新工具。

我们已经收集了所有基本构造块之前的学习中，并且现在只剩下将这些块整合到新的解析器类中的任务了。详细说明了各种实现方案及其性能特点。

你或许能概述代码中各部分的功能表现；但即使如此，在深入分析每一部分之前，请确保不遗漏任何细节。

我们基于抽象的AbstractParser类进行继承，而不是去实现Parser接口。这个简单的类预设了一个默认的实现方案，默认情况下会为那些可能过时的方法提供解决方案。

核心功能的方法在parse函数中执行，在第五章我们详细学习了这一属性。在这里，我们的目标是解析那些经过加密的文件流，并将XML内容传递给我们的自定义XML解析器进行处理。

由于我们将其繁琐的分析流程授权给另一个解析器类以便不再担心该类中的XHTML输出我们可以直接利用'XHTMLContentHandler'工具来处理相关数据这一工具在第五章中已经进行了介绍。

在此之后, 我们开发一个名为getSupportedTypes的方法用于通知tika该解析器类适用于处理哪些文件类型. 返回的结果应与相关检测器输出的一致.

目前

11.3.3加入新的解析器

在Tika环境中，默认情况下插件会采用服务提供者模式来加载从classpath路径中所有可获取的实现。为了向Tika系统介绍你的两个新开发的解析器，请将编译好的JAR文件放置在其META-INF目录下的services子目录中（具体路径为：META-INF/services/org.apache.tika.parser.Parser），并列出所有经过验证的解析器名称以供确认。建议在添加JAR文件后重启相关组件以确保新功能能够自然地启用工作

JAR文件这是一种简便的方法增强Tika的功能。例如,你可以将所有代码放入一个新的Tika扩展包（如tika-xpd-1.0.0.jar）以及META-INF/services中的两个服务提供文件。这样就能创建一个完整的Tka插件,在任何系统中易于部署,并支持数字处方功能以提取元数据和内容抽取。

如果你想要复制现有的解析器，在有两个都支持相同 MIME 类型的解析器的情况下会发生什么？

11.3.4覆写已存在的解析器

当面对应于同一MIME类型时，在一段代码中你可以确认希望选用该解析器时会被Tika激活。

在上图中，请首先声明一个MyCustomPreservationParser实例。
这应该由指定为处理application/x-prescription-mm应用的自定义解密程序来完成，默认解密程序无法处理此格式。
然后，请通过创建一个AutoDetectParser实例，并将其作为解密程序供体来修饰你的自定义解密程序。
这种解密程序修饰模式称为元解密程序模式

11.4总结

在本章中我们将探讨一种假定性数字处方文件格式 这种看似简单但却是目前广泛使用的新兴文档格式中的一个典范例子 该方法虽然基于假设 但在实际应用中却显示出极高的实用价值

在简短介绍示例文件格式之后,我们开始探讨如何利用基本类型检测功能向Tika的媒体类型数据库注入类型信息。随后,我们深入研究并掌握了更为复杂的检测策略,通过编写自定义检测器来提升检测效果。最后,我们成功开发了两个自定义解析器类——一个是继承类,另一个是独立类——以从我们的示例文档中提取文件信息及其元数据。所有这些功能都被整合到一个可执行的JAR文件中,它不仅提供了便捷的功能扩展接口,还能随时在Tika系统中添加新的插件以增强其核心功能。

作为本书的第3章内容，在这一章节中你已经熟悉了大量关于Tika的知识；即使是在本程序内部的应用也非常实用。接下来的部分将介绍Tika在其他地方的应用。