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文件常见开源类库

 

【文章索引】

  1. .NET下读取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中重要的内容解析出来。

View Code
 1 #region 字段
 2 private FileStream m_stream;
 3 private BinaryReader m_reader;
 4 private Int64 m_length;
 5 private DirectoryEntry m_dirRootEntry;
 6 
 7 #region 头部信息
 8 private UInt32 m_sectorSize;//Sector大小
 9 private UInt32 m_miniSectorSize;//Mini-Sector大小
10 private UInt32 m_fatCount;//FAT数量
11 private UInt32 m_dirStartSectorID;//Directory开始的SectorID
12 private UInt32 m_miniFatStartSectorID;//Mini-FAT开始的SectorID
13 private UInt32 m_miniFatCount;//Mini-FAT数量
14 private UInt32 m_difStartSectorID;//DIF开始的SectorID
15 private UInt32 m_difCount;//DIF数量
16 #endregion
17 #endregion
18 
19 #region 读取头部信息
20 private void ReadHeader()
21 {
22     if (this.m_reader == null)
23     {
24         return;
25     }
26 
27     //先判断是否是Office文件格式
28     Byte[] sig = (this.m_length > 512 ? this.m_reader.ReadBytes(8) : null);
29     if (sig == null ||
30         sig[0] != 0xD0 || sig[1] != 0xCF || sig[2] != 0x11 || sig[3] != 0xE0 ||
31         sig[4] != 0xA1 || sig[5] != 0xB1 || sig[6] != 0x1A || sig[7] != 0xE1)
32     {
33         throw new Exception("该文件不是Office文件!");
34     }
35 
36     //读取头部信息
37     this.m_stream.Seek(22, SeekOrigin.Current);
38     this.m_sectorSize = (UInt32)Math.Pow(2, this.m_reader.ReadUInt16());
39     this.m_miniSectorSize = (UInt32)Math.Pow(2, this.m_reader.ReadUInt16());
40 
41     this.m_stream.Seek(10, SeekOrigin.Current);
42     this.m_fatCount = this.m_reader.ReadUInt32();
43     this.m_dirStartSectorID = this.m_reader.ReadUInt32();
44 
45     this.m_stream.Seek(8, SeekOrigin.Current);
46     this.m_miniFatStartSectorID = this.m_reader.ReadUInt32();
47     this.m_miniFatCount = this.m_reader.ReadUInt32();
48     this.m_difStartSectorID = this.m_reader.ReadUInt32();
49     this.m_difCount = this.m_reader.ReadUInt32();
50 }
51 #endregion

说个比较有意思的,.NET中的BinaryReader有很多读取的方法,比如ReadUInt16、ReadInt32之类的,只有ReadUInt16的Summary写着“使用 Little-Endian 编码...”(见下图),其实不仅仅是ReadUInt16,所有ReadIntX、ReadUIntX、ReadSingle、ReadDouble都是使用Little-Endian编码方式从流中读的,大家可以放心使用,而不需要一个字节一个字节的读再反转数组,我在10年的时候就走过弯路。解释在MSDN各个方法中的备注里:http://msdn.microsoft.com/zh-cn/library/vstudio/system.io.binaryreader_methods.aspx

 

【三、我们从Directory开始】

复合文档中其实存放着很多内容,这么多内容需要有个目录,那么Directory就是这个目录。从Header中我们可以读取出Directory开始的SectorID,我们可以Seek到这个位置(0x200 + sectorSize * dirStartSectorID)。Directory中每个DirectoryEntry固定为128字节,其主要结构如下:

  1. 从000H到040H的64字节,是存储DirectoryEntry名称的,并且是以Unicode存储的,即每个字符占2个字节,其实可以看做是UInt16。
  2. 从041H到042H的2字节UInt16,是DirectoryEntry名称的长度(包括最后的“\0”)。
  3. 从042H到042H的1字节Byte,是DirectoryEntry的类型。(主要的有:1为目录,2为节点,5为根节点)
  4. 从044H到047H的4字节UInt32,是该DirectoryEntry左兄弟的EntryID(第一个DirectoryEntry的EntryID为0,下同)。
  5. 从048H到04BH的4字节UInt32,是该DirectoryEntry右兄弟的EntryID。
  6. 从04CH到04FH的4字节UInt32,是该DirectoryEntry一个孩子的EntryID。
  7. 从074H到077H的4字节UInt32,是该DirectoryEntry开始的SectorID。
  8. 从078H到07BH的4字节UInt32,是该DirectoryEntry存储的所有字节长度。

显然,Directory其实是一个树形的结构,我们只要从第一个Entry(Root Entry)开始递归搜索就可以了。

为了方便开发,我们创建一个DirectoryEntry的类

View Code
  1 public enum DirectoryEntryType : byte
  2 {
  3     Invalid = 0,
  4     Storage = 1,
  5     Stream = 2,
  6     LockBytes = 3,
  7     Property = 4,
  8     Root = 5
  9 }
 10 
 11 public class DirectoryEntry
 12 {
 13     #region 字段
 14     private UInt32 m_entryID;
 15     private String m_entryName;
 16     private DirectoryEntryType m_entryType;
 17     private UInt32 m_sectorID;
 18     private UInt32 m_length;
 19 
 20     private DirectoryEntry m_parent;
 21     private List<DirectoryEntry> m_children;
 22     #endregion
 23 
 24     #region 属性
 25     /// <summary>
 26     /// 获取DirectoryEntry的EntryID
 27     /// </summary>
 28     public UInt32 EntryID
 29     {
 30         get { return this.m_entryID; }
 31     }
 32 
 33     /// <summary>
 34     /// 获取DirectoryEntry名称
 35     /// </summary>
 36     public String EntryName
 37     {
 38         get { return this.m_entryName; }
 39     }
 40 
 41     /// <summary>
 42     /// 获取DirectoryEntry类型
 43     /// </summary>
 44     public DirectoryEntryType EntryType
 45     {
 46         get { return this.m_entryType; }
 47     }
 48 
 49     /// <summary>
 50     /// 获取DirectoryEntry的SectorID
 51     /// </summary>
 52     public UInt32 SectorID
 53     {
 54         get { return this.m_sectorID; }
 55     }
 56 
 57     /// <summary>
 58     /// 获取DirectoryEntry的内容大小
 59     /// </summary>
 60     public UInt32 Length
 61     {
 62         get { return this.m_length; }
 63     }
 64 
 65     /// <summary>
 66     /// 获取DirectoryEntry的父节点
 67     /// </summary>
 68     public DirectoryEntry Parent
 69     {
 70         get { return this.m_parent; }
 71     }
 72 
 73     /// <summary>
 74     /// 获取DirectoryEntry的子节点
 75     /// </summary>
 76     public List<DirectoryEntry> Children
 77     {
 78         get { return this.m_children; }
 79     }
 80     #endregion
 81 
 82     #region 构造函数
 83     /// <summary>
 84     /// 初始化新的DirectoryEntry
 85     /// </summary>
 86     /// <param name="parent">父节点</param>
 87     /// <param name="entryID">DirectoryEntryID</param>
 88     /// <param name="entryName">DirectoryEntry名称