谁动了我的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!