谁动了我的Infopath附件？－Infopath上传文件产生“文件损坏”

  最近接到了一个需求，需要将保存在Infopath表单中的数据提取出来。可是这么做出现了一个问题，就是经过IP上传的文件，似乎都被IP的附件控件增加了一些数据，这会导致一种颇为致命的错误，这么来做会破坏原文件的二进制布局。如果容错性不好的程序，会直接报错。比如我把word文件提出来序列化到硬盘上打开，2003会直接提示错误，2007倒是在提示错误以后，可以自动修复。不过我们不需要这种功能。
 Here we go!
 首先应该找出，调皮的Infopath到底将哪些数据藏在了文件的什么地方。动手写了一个程序，将未处理过的文件和被处理过的文件逐字节匹配，遇到不匹配的数据以后会尝试查找匹配的数据。

            FileStream fs1 = new FileStream(@"c:\source", FileMode.Open);
            FileStream fs2 = new FileStream(@"c:\dest", FileMode.Open);
            BinaryReader brSrc = new BinaryReader(fs1);
            BinaryReader brDst = new BinaryReader(fs2);
            byte[] src=brSrc.ReadBytes(int.Parse(brSrc.BaseStream.Length.ToString()));
            byte[] dst = brDst.ReadBytes(int.Parse(brDst.BaseStream.Length.ToString()));
            int destPtr = 0;
            for (int srcPtr = 0; srcPtr < src.Length; srcPtr++, destPtr++)
            {

                if (dst[destPtr] != src[srcPtr])
                {
                    Console.WriteLine(string.Format("目标文件的第{0}位置出现与源文件{1}不匹配的情况，不匹配的字符{2}",srcPtr,destPtr,dst[destPtr]));
                    
                    for (; destPtr < dst.Length; destPtr++)
                    {
                        if (dst[destPtr] == src[srcPtr])
                        {
                            Console.WriteLine(String.Format("在第{0}个位置上，找到对应byte", destPtr)); Console.Read();
                            break;
                        }
                    }
                }
                else
                    Console.WriteLine("source的第{0}位与dest的第{1}位匹配",srcPtr,destPtr);                
            }
            Console.Read();

经过测试发现，新的文件比老文件增大了58个字节，看来我的猜测是对的，Infopath的确在文件中动了手脚!
再看一下结果：


还好，数据只被增加到了Infopath文件的头部。剩下的就是要分析头的格式，因为一般头都是可变长度的，所以分析格式可以动态的取出实际的infopath文件。

取出这58个字节，经过Unicode解码，发现了我上传文件的文件名。联想到infopath的xml文件中，并没有存有文件名的节点，但是仍然可以在infopath中将数据显示出来的情况，问题就很好解释了。

参考Infopath的官方博客的文章，http://blogs.msdn.com/infopath/archive/2004/03/18/92221.aspx
发现了这么一段话：

·         BYTE[4]: Signature (based on the signature for PNG): 

(decimal)                       199       73         70         65
(hexadecimal)                C7        49         46         41 
(ASCII C notation)          \307      I           F          A  


The first byte is chosen as a non-ASCII value to reduce the probability that a text file may be misrecognized as a file attachment.  The rest identifies the file as an InfoPath File Attachment.  


·         DWORD: Size of the header 

·         DWORD: IP Version 

·         DWORD: dwReserved 

·         DWORD: File size 

·         DWORD: Size of file name buffer 

·         File name buffer: variable size 

注意到这个头文件的格式分为六个部分，除了BYTE[4]中的四个字节，其余五部分都是DWORD类型。注意，DWORD是双字，一字是两个字节，也就是说一个DWORD的大小是4个字节。问题到这里就很清楚了，前4*(4+1)个字节是固定不变的，其中，在第20到24字节保存的正是文件名的大小。



OK，现在我们要做的就是找出动态的文件头，并把他们从我们的文件中剔除出去！文件的偏移量应该是 24+文件名长度。

            int namebufferlen = dst[20] * 2;
            byte[] namebuf=new byte[namebufferlen];
            int headLength = 24 + namebufferlen;
            string name = Encoding.Unicode.GetString(dst, 0, headLength);
            byte[] realContent = new byte[dst.Length - headLength];

realContent就是我们实际的文件的内容！

Enjoy Infopath!