升级tika-app至1.28.2及以上版本生成无效.xlsx文件求助

可能的原因 #

• Apache POI版本迭代引发的文件结构/签名变化：Tika 1.28.2版本升级了依赖的Apache POI库，新版本POI生成XLSX文件时，可能调整了特定偏移位置的签名字节、压缩包内部元数据（如文件权限、路径格式），或者省略了部分默认XML属性（如collapsed="false"）。被测系统的校验逻辑比Excel更严苛，依赖旧版POI生成的固定格式，因此判定新版本文件无效。
• Tika对Excel序列化逻辑的修改：1.28.2版本的Tika调整了Excel文件写入流程，导致生成的XLSX压缩包存在隐性结构问题——比如解压后重新压缩失败，说明压缩包内可能存在不可读文件、缺失必要隐藏元数据，或压缩算法参数不符合被测系统预期。
• 被测系统校验规则的隐性依赖：系统可能硬编码了XLSX文件特定位置的签名值，或要求必须包含某些默认属性（如显式的collapsed="false"），新版本生成的文件不满足这些未公开的校验规则。

下一步排查方向 #

1. 对比文件签名与内部结构
   • 用十六进制编辑器查看两个版本生成文件在0x000001E4位置的字节内容，明确差异；同时对比压缩包内的文件列表、权限设置，检查1.28.3版本是否存在不可读文件或异常路径。
2. 验证缺失属性的影响
   • 手动给1.28.3版本生成的sheet2.xml和sheet3.xml添加collapsed="false"属性，重新打包成XLSX后测试是否能通过被测系统校验，确认是否是该属性缺失导致的问题。
3. 绕过Tika直接使用POI测试
   • 修改Groovy代码，直接用Apache POI的API读取模板并填充数据，跳过Tika封装层。如果生成的文件能通过校验，说明问题出在Tika对POI的封装逻辑上。
4. 排查POI变更日志
   • 查阅Tika 1.28.2升级的POI版本对应的变更记录，重点关注XLSX文件写入、签名生成、XML序列化相关的修改，定位可能导致文件结构变化的具体改动。
5. 分析被测系统的校验规则
   • 若有系统文档，查看其对XLSX文件的校验标准；若无，可将Excel“修复”后的文件与1.28.3生成的文件对比，找出修复过程中Excel调整的内容（如补充的元数据、修正的压缩结构），反向推导系统的校验点。

内容的提问来源于stack exchange，提问作者SuedeCA