OOXML表格单元格类型识别差异：Apache POI与LibreOffice不一致问询

这是个很典型的办公软件OOXML兼容性问题，我来帮你梳理下可能的原因：

1. LibreOffice的单元格类型推断逻辑更侧重样式与实际场景兼容 #

虽然ECMA-376规范明确了未指定t属性的单元格默认类型为n（数字），但LibreOffice在处理Excel生成的文件时，会结合**单元格样式（s属性）**做额外的类型推断。你提到的B2单元格带有s="10"的样式ID，建议你查看文件中xl/styles.xml里对应ID为10的样式定义——如果该样式设置了「文本格式」，LibreOffice会优先应用这个样式的格式类型，直接覆盖ECMA规范的默认值，这就导致单元格被显示为文本类型。

2. 异常Excel文件的隐性元数据遗留问题 #

你提到这是MS Excel生成的异常XLSX文件，这类文件可能存在Excel内部标记与OOXML标准格式不一致的情况。比如Excel可能在生成时，内部标记了该单元格为文本类型，但没有正确写入t属性；而LibreOffice对Excel生成的文件有专门的兼容逻辑，会读取这些隐性的内部标记，而非严格遵循ECMA规范的默认值，这就造成了和Apache POI的差异。

3. 不同软件对规范的容错实现差异 #

Apache POI作为专注于OOXML解析的类库，会严格遵循ECMA-376的规范细节，直接使用t属性的默认值来判定单元格类型。而LibreOffice作为办公软件，需要兼容大量非标准的Excel文件（比如人为修改、异常生成的文件），因此采用了更灵活的容错式解读：当单元格没有t属性时，会结合单元格的值、样式甚至上下文（比如相邻单元格的类型）来推断最符合用户预期的类型，这也是导致差异的核心原因之一。

验证建议 #

• 打开xl/styles.xml文件，查找s="10"对应的样式定义，确认是否包含文本格式的设置；
• 在LibreOffice中选中B2单元格，查看其「单元格格式」设置，确认是否被标记为文本；
• 手动修改sheet1.xml中B2单元格的代码，添加t="n"属性后重新用LibreOffice打开，观察类型是否变为数字。

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