tika in action第四章中文
自我学习记录！
Charpter4文档类型检测
让我们探讨一下分类系统。分类学是一种科学的分类方法，在生物学和其他领域都有广泛的应用。它不仅用于识别和归类的概念帮助更好地理解和共享关于事物的术语，并且在不同的上下文中具有不同的具体应用方式。例如，在拉丁命名法中（如林纳氏系统the Linnaean taxonomy），所有生物物种都被系统地命名，并用于确定属类以及具体种类。在生物学中这一方法已经被用来区分物种之间的关系；而在互联网领域则被用来确定数字文件格式，并称为互联网媒体类型系统（IMT）。同样的方法也被用来确定数字文件格式，并称为互联网媒体类型系统（IMT）。
通常情况下，在识别及特定事物的过程中涉及分类法。例如，在生物学领域中进行分类时会依据物种的信息描述以及其表型特征或生长模式等多方面因素来判断动植物物种。类似的机制也被应用于数字文档格式分析中。
在这一章节中,我们将全面探讨文档格式分类及其解析过程,并详细说明如何利用分类与其他机制来确定文档的实际类别.首先,我们介绍互联网媒体类型系统以及其与tika协同工作的基本原理.接着,我们将深入分析tika所采用的不同检测策略.最后,通过一个简单的示例程序演示如何利用tika来进行文档类型的自动识别.
4.1互联网媒体类型
如你在第1.1.1节所学，在RFC 2046标准下所定义的互联网媒体类型系统是最佳的标准以用于识别文档类型。而媒体类型的即MIME类型的（也被称为Internet Multiline Message Extensions Type）无论是在浏览网页还是在阅读邮件时都起到关键作用。总体而言，在你的电脑与某个特殊文件交互时会正确地执行相应的程序。例如，请问你曾经想过你的浏览器如何判断什么时候显示视频播放器而不是以二进制或文本形式展示？
大多数的浏览器（展示的Firefox对应的程序）明确地或暗示地必须理解文件中的媒体类型，并且知道如何处理。如果你不了解互联网上的媒体类型及其相关程序的话，你的浏览器只会以纯ASCII文本的形式呈现绝大多数内容，并觉得这毫无意思。
本节深入探讨互联网媒体类型名称的核心概念，并在此基础上展开详细阐述。随后将介绍8个具有重要地位的媒体类别，并参考IANA（Internet Assigned Names and Numbers Authority）官方分类系统。在此框架下，我们将简述IANA注册与其他相关项之间的关系，并重点分析Tika如何通过对其 Media Type registration信息进行处理来实现精准可靠的 Media Type识别功能。
4.1.1媒体类型名的使用
The media type name is constructed by a combination of a type/subtype definition and an optional parameter named 'name=value', which can be seen in the figure below. The type/subtype component and parameter name are restricted to US-ASCII characters, with case insensitivity applied.
Type/subtype部分指示您正在处理的文档格式，并提供可选参数以增加所需的特定格式信息以管理文档。例如，在媒体类型中使用"text/plain; charset=UTF-8"表示使用UTF-8编码的标准纯文本文档。同样的情况适用于media types中的"image/jpeg"文件类型表示以JPEG/JFIF图像格式存储的照片。
当处理大量文档和媒体类型时，偶尔会遇到问题。常见的错误案例出现在媒体类型名称的部分顺序颠倒上，例如'charset=utf-8；text/html'。其中一个解决方案是使用Tika工具来简化这些问题。
我们对……媒体类型的特征是什么已经有了一定认识。于是乎/进而地去探究哪些类型被采用，并思考如何进行管理这些已识别的媒体类别集合。
4.1.2媒体类型的种类
目前存在八种经过官方认可的顶级媒体类别（如图所示是其中的主要类别），此外还包括数以千计已注册或确认存在的子类目。这种分类体系与林奈所建立的经典生物分类系统相仿，在构建互联网媒体类别框架时具有重要意义。
除了已被正式认可的8个顶级文件格式外，还有一些专门用于演示或保留特定内容的保留类文件格式'example/'被预先定义好了。然而，在某些情况下，一些实验性质的程序可能偶尔使用未经注册的标准文件格式'x-/*'。但更普遍的做法是采用尚未正式注册的子类文件格式来处理这些问题或数据存储需求。
一旦 Media Types被确定, 这些 Media Types需以一种特定的方式进行持久化, 以便人们能查找这些 Media Types 的定义并了解其相互关系。Media Types得以存储在一个称为"media type registry" 的数据库中。在尝试创建自己的 Media Type 之前, 已经存在了一些 Media Type 是值得深入研究的重要来源, 包括最重要的易于理解的来源, IANA负责注册.
4.1.3IANA与其他类型注册
IANA负责维护一份标准的注册媒体类型清单。该清单公开发布于"www.iana.org/assignments/media-types/"网站上,任何欲注册新类型的机构均需遵循RFC4288和4289所详细说明的流程。
数量庞大的正式注册类别不断增添中，在维持最佳状态的同时,IANA注册具有重要意义,因为它所定义的各种媒体类型的品质都很高,不论是直接分类还是子分类,这是因为每个类别都包含了经过评审的有效信息（如魔法字节、文件扩展名等）。作为备受尊敬的互联网标准,IAN A内部拥有大量有价值的信息资源,由众多数据管理者负责确保信息数据的高度准确性和完整性。
也有许多尚未正式注册的媒体类型或社区通过广泛的审查而被普遍采用。这类类型的相关信息往往难以获取，因此需要依赖线上与线下的各种资源来收集信息，并需注意其中可能存在混乱甚至错误的信息来源。一些网站如"filext.com"和"file-extension.net"等运营着大型数据库系统，在此系统中存储了大量的最佳媒体格式提示或其他相关信息。遗憾的是这些信息通常并不完整或存在矛盾性然而令人欣慰的是Tika通过采用了多种其他方式成功解决了部分问题例如它能够整合多个现有的媒体格式注册组合信息并采用常见的XML格式来进行编辑与管理最终则选择一种易于理解的方式来代表不同的媒体类型考虑到它们之间的相似性并进行了必要的扩展工作以便更好地进行分类与管理
4.2tika中的媒体类型
文件与计算机交互的基本媒介是媒体类型。它指示计算机中的文件与哪些应用程序相关联。精确且可靠的媒体类型识别至关重要，这也是tika所擅长的功能。
你了解到处理媒体类型所面临的诸多挑战。这些挑战包括八种主要类别外加成百上千种细分类型，并涉及命名方式及分类原则。此外，在存储位置这一问题上也值得探讨：(通常在注册阶段)我们会将不同类别的数据分别存放在一起以确保高效管理。然而，在真正掌握这些细节之前，请耐心听我道出一个关键点：Tika是如何以一种更加简便的方式降低处理媒体类型复杂性的
首先，在程序内部管理了一个丰富且功能齐全、便于升级维护、易于理解和使用的MIME数据库，并降低了外部注册依赖的问题。随后，在内部实现了Java应用程序接口配合分类机制的支持，并对外提供了包括魔数字节识别和文件扩展字识别在内的各种媒体类型检测方法。
媒体类型检测的方法完全地由tika内部的MIME数据库驱动。
在深入到源码例子和在这章节MIME-info数据库之前，请你想起在2.1节中使用tika源码的相关内容。
Tika项目不仅负责维护自己的媒体类型注册，并且涵盖了IANA正式注册的类别以及实际应用中已知的具体类型。该系统对媒体类型的识别与分类具有完整的追溯机制，并存储了关键信息如类型关系及文件格式标识符等数据。本章将介绍如何建立媒体类型的注册基础及其相关的分类机制
4.2.1共享的MIME-info数据库
Unix系统长期没有一种标准的方法来在程序间传递文档类型信息。这个问题主要针对常用的开源桌面环境（如Linux内核基于Gnome或KDE的操作系统）。这些操作系统致力于提升用户体验与各种文档类型的标准化图标及相关应用程序之间的关联，并且这种体验与商业环境中常见的Windows或Mac操作系统的体验具有相似性。为了独立管理这些文档类型的元数据信息而提出了一种名为MIME-inf的数据库方案，并将其存储为XML格式文件。这种XML文件格式目前被广泛使用，并由Tika工具所采用。
一个mime-info文件包括了一系列记录了描述单个媒体类型的mime-type。每个类型记录显示了正式名称及其已知别名。比如那些通常在早期就注册但随后才得到正式认可的实验性分类标记如「x-*」。每个类型记录可能包含人们日常交流中常用的名称标识。类似于人们通常将家中的猫咪简单称为「a cat」而非精确地说成「feliscatus成员」。同样地，在语言交流习惯中普遍更倾向于使用像PDF这样的非正式名称而非精确的应用程序文件格式名称如application/pdf。
通过解析位于tika-mimetypes.xml源码中的mime-info文件中的媒体类型信息提供单一访问管理tika的媒体类型方式。尽管tika-mimetypes.xml源码提供的 mimeTypeInfo 信息非常丰富且准确，并没有阻止你根据特定需求增加或删除某些 mimeTypeInfo 来满足你的使用场景。只要确保你参考表4.1中的相关信息项，在实际应用中能够更精准地识别不同类型的 mimeTypeInfo 信息，并相应地为每个类型的 mimeTypeInfo 找到合适的处理程序。
为了进一步深入分析该数据库中各类详细信息，在此之前我们需要了解如何通过调用Tika API获取记录类型的相关信息
4.2.2MediaType类
Tika采用了MediaType类来表示媒体类型。该类的实例无法更改，并仅包含媒体类型的"Type/_subtype"配对以及可选属性"Name=Value"。其中类型名称及参数名通常为小写。MediaType类实现了Java对象相等性与顺序比较功能，并在附图中以UML形式表现
静态实现 MediaType::parse(string $string) 方法用于将给定的字符串转换为 MediaType 实例中的媒体类型标识符（例如："text/plain; charset=utf-8"）。该方法支持灵活输入并尝试解析有效的媒体类型标识符；然而，在遇到无效或无法识别的有效 media type 时会返回 null 值。
下面的例子讲解了如何使用MediaType类中的关键方法。这个类的所有详细信息均可在tika官网的API文档中获取：
无效实例 MediaType 不会进行过多操作 但它们构建了更高层次 'MediaTypeRegistry' 的概念 这个概念将在下一节中被提及
4.2.3MediaTypeRegistry类
通过该类可以访问Mime-info相关的XML数据库文件以及其他源文件中的类型信息。该实例作为媒体类型及相关信息的注册记录存在。该实例作为媒体类型及相关信息的注册记录存在，并且其关键特性已在图4.5中进行了详细说明。
Tika支持一个具有相当不错扩展能力的媒体类型数据库文件集。该库可通过静态方法$MediaTypeRegistry.getDefaultRegistry()获取支持。举个例子来说,我们可以利用此方法来遍历并打印出所有可用的媒体类型及其对应的别名,目前总计已超过近一千种！
现在我们已经掌握了媒体类型的注册方法，并能够体现基于其媒体类型信息驱动下的tika媒体类型检测机制的独特优势与强大功能。换句话说，在使用tika进行媒体类型注册时会体现出更高的识别精度、无需额外配置就能方便使用的优势以及支持快速迭代更新的功能更加完善的特点；这对于提升你的程序与软件的工作效率具有重要意义，并且能够帮助你更好地处理各种文件类型。
构建丰富多样的 media types 注册系统的关键要素在于掌握 media types 层次结构的概念。
层次概念表明, application/xml 作为 text/plain 的子类, 可以在特定软件中直接打开, 而无需使用其他类型的程序来处理.
4.2.4类型层次
大量多媒体类型遵循一个更通用的文件格式。例如，包括所有text/*类型的如text/html应被视为纯文本，并像在大多数网页浏览器中查看源代码一样。因此可言之即通常将text/html视为text/plain的一个常见特例。
这些复杂的层次结构并不是标准互联网媒体类型的type/subtype分类体系所涵盖的内容。然而，在text/*中的超文本类型虽然包含text/plain，在image/*中却没有类似的格式。事实上，SVG和image/svg+xml都是基于XML的技术。这项研究通过图4.6进行说明。这种类型的命名前缀通常带有+xml后缀（如：application/xml）。例如，在许多电子书格式中使用application/epub+zip时会结合zip（application/zip）结构。
Tika内置了处理文本类型及前缀名称的功能，
类似于+xml与+zip。
此外,Tika还知道几乎所有的文件都可以被视为application/octet-stream字节流。
然而,为了获得更明确的文件类型层次信息,
通常需要使用子类型元素来定义在元数据库中。
这个种类的类型层次信息通常用于确定一个特殊文件如何被处理。例如，即使没有所需工具来处理Keynote文件, 也可以从其中提取相关信息.
该系统支持这种情况下通过 MediaTypeRegistry类中的getSuperType()和isSpecializationOf()方法来更容易地获取类型层次信息。前面提到的是一个Java API返回的结果，在这种情况下会返回最接近指定媒体类型的supertype（如果指定类型正好是application/octet-stream，则会返回null）。另一个方法用于确定给定类型是否属于其他常见类别的一种辅助方法.GetSuperType()方法用于实现这一功能。
这是涉及对媒体类型的深入了解的问题。现在转向如何确定给定文件的媒体类型，请注意我们将在获取信息的基础上进行分析。随着对大量媒体类型的了解以及利用获取信息的方法（即捕获和表示），检测文件的媒体类型同样具有挑战性。Tika则简化了这一过程，请注意我们将展示其工作原理并指导您完成操作步骤
4.3文件格式判断
生物学家利用植物叶形特征作为依据区分不同物种的大树。鸟类羽毛的颜色与形态特征被用来鉴别它们所属的不同种类。同样地,研究者可依据数字文件中所含字符特性来识别这些文件类型。本节旨在为这类分析者提供指导,并介绍一种全面的方法用于识别不寻常类型的文件。
我们采用基于文件名模式的一种广泛采用且最为基础的媒体类型检测方法。为了识别文件类型,我们将学习内容类型提示、魔数字节以及字符编码等信息,并基于Tika提供的大量易于理解的关键字来完成这一过程。更为复杂的特性则包括XML结构或通过组合文件名与数字指纹来进行更深入的内容分析。
这一整节基于tika和媒体类型注册的导引和记录的信息。
4.3.1文件名
最基本且最普遍的文件类型检测机制是通过查看文件名来实现。
大多数现代的操作系统和程序依赖于
. txt 或者 . png 这样的扩展名来判断文件类型。
然而这种方法虽然显得不够正式，并且缺乏可靠依据。
你可以较为轻易地利用文件扩展名这一概念以实现欺骗目的。无论你所使用的操作系统是Windows还是MacOS平台，在任意一个程序中都可以随意更改一个图像的扩展名为“.txt”。试想当你双击该文件时会发生什么？计算机可能会误以为这是一个文档并试图用编辑器打开它。这种基于文件扩展名的设计属性容易被修改。现代操作系统通常会引入更为复杂的机制以确定如何处理不同类型的文件类型
使用文件扩展名的概念可以追溯至40年前，在那个时期由DEC开发的计算机操作系统首次将文件命名分为基本名称与类型扩展名两部分。这一做法后来被其他供应商效仿，其中最著名的包括微软和DOS操作系统的引入。如今，在微软Windows系统中已经取消了对文件名称长度的限制（尽管仍然需要注意的是路径长度的问题），但无论如何File extension始终是决定程序处理方式的关键因素之一。同样地，当前在Mac OS和Unix系统中也采用了相同的方式处理文件名称。
不局限于仅指文件扩展名, 也存在一些特殊的名称模式, 用于区分不同类型的文档。例如, 许多软件项目包含如README,LICENSE和MakeFile等文本文件, 它们不具有任何后缀。Unix系统中常用的配置参数标记为（.*rc）, 星号代表任意一串字符。
这些大量与其他已知的文件名模式与扩展字都被tika通过
如果试图在系统中引入非标准的文件扩展字，则这并非tika所支持的功能；建议修改相关配置参数以实现这一目标；为了实现这一目标，请在tika-mimetypes.xml配置文件中添加必要的信息设置，并将其更新到编辑器中即可完成设置
4.3.2内容类型提示
通常情况下
例如网页浏览器采用HTTP协议向服务器发起请求HTML页面和其他文件以明确说明其内容类型该服务器则响应于这些请求提供相应的HTML页面。
另外一个例子则是通过程序设置文件的元数据来作为内容类型提示的方式，在某些情况下类似于你在使用Word时所创建的文档。
4.3.3魔数字节
通常情况下, 文件扩展名及其他内容类型的提示非常可靠; 然而, 在某些场景中, 并不具备绝对的可靠性. 在某些情况下, 外部信息可能无法获取或存在错误; 因此, 在缺乏外部信息的情况下，默认通过查看文件内部来确定其类型是最合理的做法.
文件编码方式：一种信息解析的标准表示方法。绝大多数编码方式具备能在字节流中被识别的独特特征。许多编码方式通常会在头端添加特定的魔数来帮助识别内容类型。例如，在不同版本中常见的如GIF图像通常会在头端标识为ASCII码序列'GIF87a'或'GIF89a'。
魔数字节被用作一种媒体类型检测的方法非常有效,但这仅是解决问题的一环.另一个问题是准确识别文件的编码,也就是我们常说过的charset.
4.3.4字符编码
在识别异常的字节数值模式，并推断文件类型标识及内容属性推断后
就像前面所讨论，在text/plain媒体类型中通常包含charset参数来表示文件的字符编码。即便这些信息是可以获取的,但它们往往存在错误.为了准确检测字符编码的方式是非常有必要的.
BOMMARKERS
识别字符编码方式的一种最直接的方法是通过查找可选的字节顺序标记（BOM, byte order mark）用作标识符来确定文件中使用的编码顺序。Table4.5说明了BOM在常用Unicode编码体系中的应用。
如果文件的第一部分字节序列与已知的标准开头标识符匹配，则通常可以让开发人员推断出该文件所采用的文字编码方案。此外，在不幸的情况下——即当其他编码方案通常会利用字节顺序来标识文字顺序时——这种简单的判断方法就不再适用了。
BYTEFREQUNENCY
通过分析前面几个字节中的不同频率来确定文件类型和编码方案通常采用的方法。纯ASCII文本一般没有对字符进行特殊控制, 仅限于换行符与制表符. 大多数其他字符编码方案在常见情况下一般不采用这些低码字节.
当文件不是纯文本时，请确定其字符编码。这些多字节字符编码的技术有助于在如UTF-8等情况下识别特定的byte模式。这些特定的字节值通常未被广泛使用（例如，在ASCII编码中仅占用7位）。
STATISTICALMATCHING
在排除了简单匹配不可能产生的替换后，在最后阶段进行重排时会采用统计匹配的方法来确定哪种字符编码能够最有效地生成与输入文件类似的字节序列。许多常见的字符编码通常与特定语言相关联，并且通过分析这些代码中的频率或配对关系来精确地推断文件所使用的语言及其相应的编码方式。
Tika的MediaTypeRegistry执行了所有种类的检测机制，并且使得在程序中使用变得可行。
4.3.5其他的机制
一些常见的文件存储架构采用Zip结构（application/zip）、XML（application/xml）或微软特定数据交换标准等基础数据组织形式，并支持超链接及嵌入式文件等特性。即便如此，在宿主系统中识别这些文件的具体类型往往仍具挑战性。为了明确判断其所属的具体文档类型，请先解析容器存储架构。
XMLFORMAT
这一格式中值得特别注意的是XML这一技术体系,它是用来表示不同种类的数据信息的一种通用数据交换方式.它被广泛应用于多种特定类型的文件存储与交换,例如XHTML（application/xhtml+xml）和SVG（image/svg + XML）.具体而言,当需要识别给定XML文档的特定类型时,系统会对该XML文档中的元数据进行解析,随后将其与已知的元数据集合进行比对匹配.
OLEFORMAT
微软OLE格式是一种较为复杂的文档检测规范。从1995年到2003年间发布的微软Office系列软件中，默认情况下支持的版本仍然广泛应用于当前生产环境中。OLE文档格式在全球范围内应用最为广泛。具体而言，通过特定程序解析OLE容器中的目录树信息即可识别文件类型。值得注意的是，在这种文件系统下，默认情况下许多仍在使用的软件程序仍可正常运行，并通过特定程序解析目录树信息来识别文件类型。然而，在这种结构下进行随机访问操作较为复杂，并且由于需要对正在流媒体的文档执行随机存取操作，在Web服务器上实施基于Tika的OLE文档类型检测会面临诸多挑战：Tika采用了相对简便的方法，在这些限制条件下依然能够有效地实现基于Tika的OLE文档类型检测方案
COMBINEDHEURISTICS
在Tika处理新文件格式时（即当tika遇到新的文件格式），这些和其他的定制化检测模块通常会进行延伸以适应这一情况
该机制专注于对不同类型的负载进行检测，并且没有任何一种方法能够保证完全准确。面对这种复杂性, 我们不能放弃吗？实际上, 这种情况并没有想象中那么糟糕, 因为这些先前的方法各自独立地提供了对另一种检测方法结果的有效验证. 然后, 通过整合现有的各种检测手段能够实现几乎所有文档媒体类型的精确估计. 最值得注意的是, Java平台自带的Tika组件已经自动完成了这一功能. 下一节将向大家介绍这个技术是如何实现的.
4.4tika，类型检查者
类似于你在第二章中所了解的情况，在Tika类中存在一个名为detect的方法（））。该方法负责计算并返回指定文件所包含的具体媒体类型信息。而SimpleTypeDetector类则提供了一个具体的实现案例来说明这一过程。
听起来是不是很简单？接下去，请利用类型检测技术你还能实现什么？第一个步骤是将自定义类型的注册转换为一种更灵活的方式，在其中包含了你的程序所需的一些额外信息类别。下面将介绍如何将一个媒体类型的配置文件指定给Tika系统使用。请注意，默认情况下该配置文件的位置设置在"/org/apache/tika/mime/tika-mimetypes.xml"处。
除了将java.io.File实例传递给检测方法detect（）之外，在以上每种情况下（即使用流、URLs或文件名的形式），tika都会尽可能地整合它自身可获取到的文件类型信息以及您提供的相关信息。结果通常是你所预期的结果。
4.5总结
我们围绕文件格式分类及相关的文件类型检测方法展开讨论，并完成了这一部分的内容。我们将通过介绍互联网媒体类型系统以及tika如何利用mime-info数据库中的_MEDIA_TYPE和_MEDIA_TYPE.Registry类来处理媒体类型作为起点。接着探讨检测文件类型的不同层次结构，在此之后最终将回到tika表层的detect()方法。
现在，请您了解不仅限于如何使用Tika来识别文件类型之外的还有一些Tika内部的任务处理机制以及通过自定义的类型信息来增强其功能。这些内容将会在后续章节中详细阐述如何利用这些技术来提取所需的信息。