| 導購 | 订阅 | 在线投稿
分享
 
 
 

用Perl來分析並生成中文Excel文件

2008-05-30 23:00:59  編輯來源:互聯網  简体版  手機版  移動版  評論  字體: ||

最近實驗室作爲自學考試的考場,需要在服務器上面爲每個學生創建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。

最近實驗室作爲自學考試的考場,需要在服務器上面爲每個學生創建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。
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
王朝網路微信公眾號
微信掃碼關註本站公眾號 wangchaonetcn
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有