最近實驗室作為自學考試的考場，需要在服務器上面為每個學生創建FTP帳號，我計劃用Perl來實現的批處理創建。考慮到獲取的考場學生名單是存儲在Excel文件里面的，因此還需要讓Perl去分析Excel文件。通過google找到用SPReadsheet::ParseExcel以及Spreadsheet::WriteExcel來讀寫Excel。在www.cpan.org上下載了相應的Module并看了文檔、范例后，終于寫出了一個程序可以讀考場學生名單，并生成密碼清單存到另一個Excel文件中。

這還只是第一步，剛寫出來的程序讀Excel文件中的中文，也無法將中文寫入Excel文件：單元格(Cell) 和工作簿(Worksheet) 中的漢字。

在找相應的幫助，得知可以用Spreadsheet::ParseExcel::FmtUnicode來處理Excel文件中的Unicode字符，其使用方法如下：
use Spreadsheet::ParseExcel::FmtUnicode;
my $oFmtJ = Spreadsheet::ParseExcel::FmtUnicode->new(Unicode_Map => CODE);
my $oBook = Spreadsheet::ParseExcel::Workbook->Parse($ARGV[0], $oFmtJ);

知道了實現的方法，但是這個CODE的值應該為多少還不知道。剛開始我猜測是'GB2312'，可是不知道是哪里其他什么地方錯了導致不成功；后來看到Manual里提到'GB2312-80'，也試了一下，還是不行。最后只好google，發現別人用的是'CP936'，這次就成功了。當成功了以后再把CODE改回'GB2312'居然也可以了。

現在讀Excel文件已經沒有問題了，可是盡管這些中文讀出來了，可是在寫Excel文件的時候并無法寫入中文。

解決方案就只有兩種了：網上搜索答案；看ParseExcel的原文件逆向處理。

首先通過看WriteExcel的Manual得知它是支持寫Unicode字符的，其中就有一個Example說明了通過write_unicode()函數來向單元格寫入日文Unicode字符。可是Example里面提供的日文字符串是通過pack來生成的，本身已經是Unicode格式的了，而我們通常使用的GB2312的字符不屬于Unicode字符串，所以沒法直接寫入。那么如何轉換呢？

通過分析Spreadsheet::ParseExcel.pm和Spreadsheet::ParseExcel::FmtUnicode.pm發現：所有通過ParseExcel從Excel文件中分析出來的字符都是經過函數TextFmt()格式化過的，這個函數的定義在FmtUnicode.pm中。而TextFmt()核心是通過Unicode::Map的from_unicode()函數來將一個unicode字符串轉換為非unicode的字符串，當然在轉換之前還做了一個處理：s/(.)//x00$1/sg。

根據這個思路，就在WriteExcel之前，創建一個Unicode::Map對象，然后調用對象里的to_unicode函數進行字符串格式轉換，最后調用write_unicode函數將中文寫入單元格(Cell) 中。下面給出一個簡單的Example：
use Unicode::Map();
my $Map = new Unicode::Map("GB2312");
$worksheet->write_unicode($iR, 2, $Map->to_unicode("考生姓名"))

單元格中的中文可以正常顯示了，可是在寫工作簿名稱的時候這個方法就不那么管用了，像$worksheet = $workbook->add_worksheet($Map->to_unicode($name)這樣進行的話，就會產生工作簿名稱非法的錯誤而退出。同樣的方法在set_header()是也不管用，盡管不會出錯可是顯示的卻是亂碼。在處理單元格的時候有分unicode的方法和非unicode的方法，為什么add_worksheet的時候沒有呢？莫非要自己去寫個函數或者加個參數來擴展？

單元格中的中文可以正常顯示了，可是在寫工作簿名稱的時候這個方法就不那么管用了，像$worksheet = $workbook->add_worksheet($Map->to_unicode($name)這樣進行的話，就會產生工作簿名稱非法的錯誤而退出。同樣的方法在set_header()是也不管用，盡管不會出錯可是顯示的卻是亂碼。在處理單元格的時候有分unicode的方法和非unicode的方法，為什么add_worksheet的時候沒有呢？莫非要自己去寫個函數或者加個參數來擴展？

再次進入源代碼Spreadsheet::WriteExcel::Workbook.pm，發現原來add_worksheet()函數還可以傳遞一個$encoding的參數的，可是這個參數僅用于判斷輸入的unicode字符是否符合長度要求，編碼轉換哪里去了？如果說要自己去補齊的話該加什么代碼呢？比較Spreadsheet::WriteExcel::Worksheet.pm中的write()（實際上最后調用的是write_string）和write_unicode()發現，后者比前者多了相應的這么一段代碼>（說相應是由于一些變量名的差異，將此代碼直接添加到前者是不能工作的）：

# Check for a valid 2-byte char string.
croak "Uneven number of bytes in Unicode string" if $num_bytes % 2;

# Change from UTF16 big-endian to little endian
$str = pack "v*", unpack "n*", $str

那么也就是說將這段代碼加入到add_worksheet()適當的位置就可以嘍？答案是令人沮喪的。為了查找原因再次回到Spreadsheet::ParseExcel.pm，從調入Excel文件分析Excel文件開始，看看工作簿名稱是如何得到的。

分析代碼發現，TextFmt()處理工作簿名稱時是這樣的：$sWsName = $oBook->{FmtClass}->TextFmt($sWsName, 'ucs2')。TextFmt()函數還有一部分是針對Excel文件個別類型的字符串（如header，footer，工作簿名稱等）不做上面提到的處理（s/(.)//x00$1/sg）。可是這個不是關鍵問題，不能解釋為什么直接裝換為unicode的字符不能寫入。

進一步分析發現，相對于單元格的字符其他的特殊的字符再進行TextFmt()格式化之前都有進行類似_SwapForUnicode(/$sWsName)的調用，也就是說還有特殊處理：

sub _SwapForUnicode(/$)
{
my($sObj) = @_;
#for(my $i = 0; $i for(my $i = 0; $i<(int (length($$sObj) / 2) * 2); $i+=2) {
my $sIt = substr($$sObj, $i, 1)
substr($$sObj, $i, 1) = substr($$sObj, $i+1, 1);
substr($$sObj, $i+1, 1) = $sIt
}
}

根據以上所有的分析，最后得出了一個解決方案：

my $sWsName = $Map->to_unicode($sWsName);
&SwapForUnicode(/$name);
my $worksheet = $workbook->add_worksheet($name, 1);

再經歷兩天的失敗了以后，成功意外的降臨了，上面的代碼是可行的。第一行，將非Unicode的字符轉換為Unicode的；第二行，變更其存儲格式使之符合Excel文件的要求；第三行，通過帶參數$encoding的調用，執行了相當于write_unicode()中寫入unicode字符的代碼（事實上這部分代碼所說的自行添加的部分，NOTE:修改了Module的源文件）：$name = pack "v*", unpack "n*", $name;

最后是與標題無關的總結。

Spreadsheet這兩個模塊處理Excel的能力太過獨立，二者很難結合的很好。兩個模塊要么只能讀，要么只能寫，必須要一個中間的數據存儲。

雖然說ParseExcel使用WriteExcel模塊寫了一個SaveParser，可本質上還是通過用SaveAS方法來新建了一個Excel對象并把數據復制過去，并沒有真正意義上的“Save”。

而且SaveParser還有一個嚴重的問題：它內部同時使用了ParseExcel和WriteExcel的Workbook對象，可是卻無法將二者統一起來：兩個對象執行同一功能的函數名不同，如AddFormat()和add_format()，讓人很難確定什么時候改用什么；甚至很多功能函數沒有繼承下來，如keep_leading_zeros()，這給我寫“000946”帶來了很大的麻煩。

希望以后能夠出一個Module將這二者很好的結合起來新Module。