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的进步~

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

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

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

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

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

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

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

 

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

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