itextsharp-5.2.1-修正无法签名大文件问题

PDF文件格式几乎是所有开发平台或者业务系统都热爱的一种文档格式。

目前有很多优秀的开源PDF组件和类库。主要平时是使用.NET和Java开发，所以比较偏好使用iText，当然，它本身就很强大。iTextSharp是一个用来生成PDF文档的C#组件，相当于Java版的iText。iTextSharp可以运行在Windows操作系统中，由C#语言开发，授权协议是AGPL。其官方网站为 http://itextpdf.com/

关于iText（iTextSharp）的使用，有机会再跟大家一起分享一下。这里主要记述一次修复iTextSharp-5.2.1版本的一个小bug。

一件很小的事情

事情很简单，在一次政府项目中有需要对PDF格式的附件进行操作。由于有着iText的使用经验，自然首选了iTextSharp作为文件读写操作的中间件。正如众多故事的开始，系统一直正常运行着，一切都很正常。直到有一天，客户反应他们的附件无法正常操作，团队的成员先是简单测试后，没发现问题；但是，就是客户发来的附件确实无法正常操作。经过排查，排除了客户文件加密或者版式等问题，只有一点：附件相对通常用户的附件大了不少！将近百兆。好吧，开发人员反馈回来，估计是iTextSharp本身的bug问题吧o(︶︿︶)o

首先想到的就是，是不是内存溢出了？（为什么这是第一反应）没办法，只有开扒源码了，还好，它是开源的，我们可以尝试去修改源码。OMG~万能的source code，绝对是所有开发人员的最终挚爱。

从官网下载源码之后，用VS2010打开项目工程itextsharp，

很快，定位到如下路径（~\itextsharp-dll\itextsharp-src-core-5.2.1\iTextSharp\text\pdf\ByteBuffer.cs）

仔细查看后，发现确实有个很明显的失误，果断加入如下代码：

        /**
         * Appends a string representation of a <CODE>long</CODE> according
         * to the Pdf conventions.
         * @param i the <CODE>long</CODE> to be appended
         * @return a reference to this <CODE>ByteBuffer</CODE> object
         */
        public ByteBuffer Append(long i)
        {
            return Append((double)i);
        }

兴奋的重新编译，生成，替换引用，一气呵成！　　然后几经测试，终于成功了。

也许在各位看来这是一个如此简单的问题，能叫修复吗？能算有成就感吗？确实，这段代码不足为奇，甚至简单到不能再简单。然而，它确实起效了！解决问题了。限于篇幅，在此就不再深究，也不反复推敲，有兴趣的可以去刨源码，或者另作讨论。

那么问题来了，这般博尔特式的百米冲刺，快刀斩乱麻，甚至“不讲道理”，下面的就是题外话了。

那你想说什么呢？

那么我到底想说什么呢？总的来说，由这件事想到了几点，权且作为一次007mm的进步~

权且抛砖引玉了，只言片语：

1、关于开发：每个开发人员的时间都是及其宝贵的，我们要做的是在有效的时间内创造有效的价值；但是我们是否应该在开发是更专注一些，能够考虑到的方面更全面一些，一个如此成熟优秀的开源软件，同样也存在着如此微小的错误。我们更因共同勉之励之。

以前听说微软的开发小组将错误分成以下4个等级。一级严重：错误导致软件崩溃。二级严重：错误导致一个特性不能运行并且没有替代方案。三级严重：错误导致一个特性不能运行但有替代方案。四级严重：错误是表面化的或是微小的。或许在快速迭代开发或者是软件开发初期是一个有效的记录分析手段，利于重点着手处理；但到软件发布时，错误不应该有等级之分。也就是说，所有的错误都是严重的，应该引起足够的重视不存在微不足道的小错误。只有这样才能不断的减少犯错。

2、关于测试：本人从不善于测试，只是单纯认为：测试的重点在于功能，而决定性在于边界。主要包括数据结构的边界、状态变换的限制及功能的界限。

3、关于问题解决：一直以来围绕着如何解决问题都有着不休的争论，首先声名：笔者绝对不是在这里和稀泥，张家李家还有隔壁老王家确实一个个的都是各有各理。本人一直追求所谓的实效主义，实用、有效是是手段，解决问题是目标。

记得有位牛人也是伟人——弗拉基米尔·伊里奇·乌里扬诺夫（好像也叫 列宁 o(∩_∩)o ）说过：目的决定手段。在能够简单解决问题时，把BUG修复一定是开发人员的默认首选项。至于问题探索和总结，那是之后的事情了（请原谅我的囫囵吞枣、不求甚解babala功利主义）。但作为共识的程序员，我们的优质特点就是精益求精，之后个人升级进阶的事情自然就是顺理成章。

如果园友有好的建议和想法，欢迎留下您的足迹讨论。

最后推荐一本大家应该都看过、甚至都推荐过的美国著名数学家和数学教育家G▪波利亚所写的名著《怎样解题》。
How to Solve It : A New Aspect of Mathematical Method, George Polya

全书的精华是【怎样解题表】，图表中的四大步骤：“理解问题”、“拟定计划”、“实现计划”和“回顾反思”绝对是精华中的极致精品；后面附带作者总结的的探索小词典更是诸多有效的实用的技能手段，总计67个条目堪称解题神器。