Alfresco community 4.0 无法识别 DITA 文件 mimetype

Question

所以我安装了 Community 4.0.a 并使用 mimetype-map.xml 扩展了 mimetype 列表，就像我之前在 3.4 中所做的那样

<alfresco-config area="mimetype-map">
<config evaluator="string-compare" condition="Mimetype Map">
    <mimetypes>
<mimetype mimetype="application/dita+xml" text="true" display="DITA">
        <extension default="true" display="DITA Topic">dita</extension>
        <extension default="true" display="DITA Map">ditamap</extension>
        <extension default="true" display="DITA Conditional Processing Profile">ditaval</extension>
      </mimetype>

等等……

但每次我导入 DITA 文件时，它要么被识别为 XML 文件，要么被识别为 PLAIN TEXT。我已经深入研究了它，看起来这是因为 Apache TIKA 分析了文件的开头以检查它的 mimetype。

如何使用我的自定义 mimetype-map 来快捷方式 TIKA（从代码中可以看出 TIKA 是首先触发的，如果它发现了一些东西，那么游戏就结束了）？

我是否必须编写自己的解析器来扩展 TIKA？

Answer 1

4.0 中的 Mimetype 匹配逻辑略有变化，现在可以检测内容，而不仅仅是文件名。作为其中的一部分，如果 Tika 非常确定文件是什么，那么这将是首选。

在大多数情况下，这意味着对于常见但名称不正确的文件，Tika 可以帮助纠正错误。对于非标准文件，Tika 将拒绝提供强烈建议，并且将像以前一样使用基于 Alfresco 名称的匹配。 （如果 Tika 和 Alfresco 对 mimetype 的规范形式存在差异，则首选 Alfresco 版本）

在少数情况下，文件类型实际上是通用类型的特化，而 Tika 知道父类型但不知道具体的类型。在这种情况下，Tika 强烈建议使用父类型，我们无法意识到添加到 Alfresco 的新类型是基于此的。 （Tika 有一个 mimetypes 层次结构，而 Alfresco 只有一个平面列表）。对于这些少数情况，Tika 也需要指导。

通常的修复方法是报告 Tika 错误，并在上游添加文件类型。 （对于非常自定义的类型，您还需要添加一个 Tika custom-mimetypes.xml，它定义了层次结构 + glob。）

在这个 DITA 案例中，我打开了TIKA-784 并添加了一个临时修复。这也有now gone into Alfresco。