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個條目堪稱解題神器。