2012-06-01 73 views
2

我使用Transfer-Encoding: chunked來編寫HTTP響應。Perl將二進制數據拆分爲塊拆分

的響應被通過以下分裂成碎片:

my $template = "a$buffer_size" x int(length($response)/$buffer_size) . 'a*'; 

foreach my $buffer (unpack $template, $response){ 
    ... 
} 

此工作正常時,內容類型是text/html,但它是腐敗的二進制數據,如application/pdf

可以使用unpack將二進制數據拆分爲相等的長度嗎?

+0

當您說內容類型導致損壞時,您是否確認通過嘗試訪問相同的數據,使用不同的MIME類型發送? – Dancrumb

+0

另外,腐敗的本質是什麼? – Dancrumb

+0

@Dancrumb「腐敗」是該文件被錯誤地標記爲UTF-8而不是ANSI。奇怪的是,如果我用'grep {/ \ S /} split /(.{$ buffer_size})/'來模擬'unpack',一切都很好。而且,如果在命令行完成,'unpack'邏輯就可以(即,不通過mod_perl或ActiveState PerlEx)執行。 – xpsd300

回答

1

仍然不知道爲什麼unpack在這方面失敗,但我偶然發現一個解決方案。

如果我操作與在內存中的文件的響應,unpack正常工作:

my $resp; 
open (my $fh, '>', \$resp); 
my $fh_old = select($fh); 
print $response; 
close $fh; 
select($fh_old); 
$response = $resp; 

任何瞭解爲什麼這個工程?

+1

最後追蹤了問題的根源。 PDF文件是從unicode數據庫中即時創建的。我將寬字符轉換爲'cp1252'以匹配字體對象的'WinAnsiEncoding'。遇到寬字符時,Perl切換到「utf8」模式。這導致'unpack'失敗,因爲它被設置爲以'ascii'模式運行。 – xpsd300

0

這對二進制數據來說工作得很好。問題在別處。 (你是否binmode所有相關的句柄?)