Office文件格式奥秘

Office文件的奥秘——.NET平台下不借助Office实现Word、Powerpoint等文件的解析(一)

【题外话】

这是2010年参加比赛时候做的研究，当时为了实现对Word、Excel、PowerPoint文件文字内容的抽取研究了很久，由于Java有POI库，可以轻松的抽取各种Office文档，而.NET 虽然有移植的NPOI，但是只实现了最核心的Excel文件的读写，所以之后查了很多资料才实现了Word和PowerPoint文件文字的抽取。之后忙于各种事情一直没时间整理，后来虽然想写成文章但由于时间太久也记不清很多细节，现在重新查找资料并整理如下，希望对大家有用。

【系列索引】

1.Office文件的奥秘——.NET平台下不借助Office实现Word、Powerpoint等文件的解析

(一)

获取Office二进制文档的DocumentSummaryInformation以及

SummaryInformation

2.Office文件的奥秘——.NET平台下不借助Office实现Word、Powerpoint等文件的解析

(二)

获取Word二进制文档（.doc）的文字内容（包括正文、页眉、页脚、批注等等）

3.Office文件的奥秘——.NET平台下不借助Office实现Word、Powerpoint等文件的解析

(三)

详细介绍Office二进制文档中的存储结构，以及获取PowerPoint二进制文档（.ppt）的文字内容

4.Office文件的奥秘——.NET平台下不借助Office实现Word、Powerpoint等文件的解析

(完)

介绍Office Open XML文档（.docx、.pptx）如何进行解析以及解析Office文件常见开源类库

【文章索引】

下读取Office文件的方式

2.Windows复合二进制文件及其Header

3.我们从Directory开始

4.DocumentSummaryInformation和SummaryInformation

5.相关链接

【一、.NET下读取Office文件的方式】

10年的时候参加比赛要做一个文件检索的系统，要包含Word、PowerPoint等文件格式的全文检索。由于之前用过.NET并且考虑到这些是微软的格式，可能使用.NET读取会更容易些，但没想到.NET这边查到的资料只有Interop的方式读取Office文件。后来接触了Java的POI，发现.NET也有移植的NPOI，但是只移植了核心的Excel读写，并没有

Word、PowerPoint等文件的读写，所以最后没有办法只能硬着头皮自己去做Word和PowerPoint文件的解析。

那么Interop是什么？Interop的全称是“Interoperability”，即微软希望托管的.NET能与非托管的COM进行互相调用的一种方式。通过Interop读写Office即调用安装在计算机上的Office软件来实现Office的读写，其优点显而易见，文件还是由Office生成或读取的，所以与自己打开Office是没有任何区别的；但缺点也非常明显，即运行程序的计算机上必须安装有对应版本的Office软件，同时操作Office文件时实际上是打开了对应的Office组件，所以运行效率低、耗内存大并且还可能产生内存泄露的问题。关于Interop 方式读写Office文件的例子网上有很多，有兴趣的可以自行查阅，这里就不再多讲了。

那么，有没有方式不借助Office软件实现Office文件的读写呢？答案肯定是肯定的，就像Java中的POI及.NET中的NPOI实现的那样，即通过程序自己读写文件来实现Office文件的读写。不过由于Office文件结构非常复杂，这里只提供文件摘要信息和文件文本内容的解析。不过即使如此，对于全文检索什么的还是足够的。

【二、Windows复合二进制文件以及Header】

前几年，微软开放了一些私有格式的规范，使得所有人都可以对其文件进行解析，而不需要支付任何费用，这也使得我们编写解析文件的程序成为可能，相关链接在文章最后可以找到。

对于一个Microsoft Office文件，其实质是一个Windows复合二进制文件（Windows Compound Binary File），文件的头Header是固定的512字节，Header记录文件最重要的参数。Header之后可以分为不同的Sector，Sector的种类有FAT、Mini-FAT（属于Mini-Sector）、Directory、DIF、Stroage等五种。为了方便称呼，我们规定每个Sector 都有一个SectorID，Header后的Sector为第一个Sector，其SectorID为0。

我们先来说Header，一个Header的部分截图及包含的信息如下，比较重要的用粗体表示。

1.Header的前8字节Byte[]，也就是整个文件的前8字节，都是固定的0xD0 0xCF

0x11 0xE0 0xA1 0xB1 0x1A 0xE1，如果不是则说明不是复合文件。

2.从008H到017H的16字节，是Class Id，不过很多文件都置的0。

3.从018H到019H的2字节UInt16，是文件格式的次要版本。

4.从01AH到01BH的2字节UInt16，是文件格式的主要版本。

5.从01CH到01DH的2字节UInt16，是固定为0xFE 0xFF，表示文档使用的是Little

Endian（低位在前，高位在后）。

6.从01EH到01FH的2字节UInt16，是Sector大小的幂，默认为9（0x09 0x00），

即每个Sector为512字节。

7.从020H到021H的2字节UInt16，是Mini-Sector大小的幂，默认为6（0x06

0x00），即每个Mini-Sector为64字节。

8.从022H到023H的2字节UInt16，是预留的，必须置0。

9.从024H到027H的4字节UInt32，是预留的，必须置0。

10.从028H到02BH的4字节UInt32，是预留的，必须置0。

11.从02CH到02FH的4字节UInt32，是FAT的数量。

12.从030H到033H的4字节UInt32，是Directory开始的SectorID。

13.从034H到037H的4字节UInt32，是用于事务的，必须置0。

14.从038H到03BH的4字节UInt32，是最小串（Stream）的最大大小，默认为4096（0x00

0x10 0x00 0x10）。

15.从03CH到03FH的4字节UInt32，是MiniFAT表开始的SectorID。

16.从040H到043H的4字节UInt32，是MiniFAT表的数量。

17.从044H到047H的4字节UInt32，是DIFAT开始的SectorID。

18.从048H到04BH的4字节UInt32，是DIFAT的数量。

19.从04CH到1FFH的436字节UInt32[]，是前109块FAT表的SectorID。

那么我们可以写如下的代码将Header中重要的内容解析出来。

1#region字段

2private FileStream m_stream;

3private BinaryReader m_reader;

4private Int64 m_length;

5private DirectoryEntry m_dirRootEntry;

6

7#region头部信息

8private UInt32 m_sectorSize;//Sector大小

9private UInt32 m_miniSectorSize;//Mini-Sector大小

10private UInt32 m_fatCount;//FAT数量

11private UInt32 m_dirStartSectorID;//Directory开始的SectorID

12private UInt32 m_miniFatStartSectorID;//Mini-FAT开始的SectorID 13private UInt32 m_miniFatCount;//Mini-FAT数量

14private UInt32 m_difStartSectorID;//DIF开始的SectorID

15private UInt32 m_difCount;//DIF数量

16#endregion

17#endregion

18

19#region读取头部信息

20private void ReadHeader()

21{

22if (this.m_reader == null)

23 {