通過把Content-Type設置爲application/octet-stream，可以把動態生成的內容當作文件來下載，相信這個大家都會。那麼用Content-Disposition設置下載的文件名，這個也有不少人知道吧。基本上，下載程序都是這麼寫的：
<?php
$filename = "document.txt";
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename=' . $filename);
print "Hello!";
?>
這樣用瀏覽器打開之後，就可以下載document.doc。
但是，如果$filename是UTF-8編碼的，有些瀏覽器就無法正常處理了。比如把上面那個程序稍稍改一下：
<?php
$filename = "中文 文件名.txt";
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename=' . $filename);
print "Hello!";
?>
把程序保存成UTF-8編碼再訪問，IE6下載的文件名就會亂碼。 FF3下下載的文件名就只有“中文”兩個字。Opera 9下一切正常。
輸出的header實際上是這樣子：
Content-Disposition: attachment; filename=中文 文件名.txt
其實按照RFC2231的定義，多語言編碼的Content-Disposition應該這麼定義：
Content-Disposition: attachment; filename*="utf8''%E4%B8%AD%E6%96%87%20%E6%96%87%E4%BB%B6%E5%90%8D.txt"
即：
- filename後面的等號之前要加 *
- filename的值用單引號分成三段，分別是字符集(utf8)、語言(空)和urlencode過的文件名。
- 最好加上雙引號，否則文件名中空格後面的部分在Firefox中顯示不出來
- 注意urlencode的結果與php的urlencode函數結果不太相同，php的urlencode會把空格替換成+，而這裏需要替換成%20
經過試驗，發現幾種主流瀏覽器的支持情況如下：
| IE6 | attachment; filename="<URL編碼之後的UTF-8文件名>" |
| FF3 | attachment; filename="UTF-8文件名" |
| attachment; filename*="utf8''<URL編碼之後的UTF-8文件名>" | |
| O9 | attachment; filename="UTF-8文件名" |
| Safari3(Win) | 貌似不支持？上述方法都不行 |
這樣看來，程序必須得這樣寫才能支持所有主流瀏覽器：
<?php
$ua = $_SERVER["HTTP_USER_AGENT"];
$filename = "中文 文件名.txt";
$encoded_filename = urlencode($filename);
$encoded_filename = str_replace("+", "%20", $encoded_filename);
header('Content-Type: application/octet-stream');
if (preg_match("/MSIE/", $ua)) {
header('Content-Disposition: attachment; filename="' . $encoded_filename . '"');
} else if (preg_match("/Firefox/", $ua)) {
header('Content-Disposition: attachment; filename*="utf8/'/'' . $filename . '"');
} else {
header('Content-Disposition: attachment; filename="' . $filename . '"');
}
print 'ABC';
?>
==============華麗的分割線=============================
在做一個導出CSV文件的功能時發現導出的文件是亂碼，上網查了下，發現原來是BOM(Byte Order Mark)的問題 BOM是UTF編碼方案裏用於標識編碼的標準標記，在UTF-16裏是FF FE，UTF-8裏是EF BB BF。這個標記是可選的，因爲UTF-8沒有順序，所以它可以被用來檢測一個字節流是否是UTF-8編碼的。微軟做這種檢測，但有些軟件不做這種檢測，而把它當做正常字符處理。
微軟在自己的UTF-8格式的文本文件之前加上了EF BB BF三個字節, windows上面的notepad等程序就是根據這三個字節來確定一個文本文件是ASCII的還是UTF-8的, 然而這個只是微軟暗自作的標記, 其它平臺上並沒有對UTF-8文本文件做個這樣的標記，類Unix系統中就沒有使用 BOM，因爲它會破壞現有的 ASCII 文件的語法約定。
也就是說一個UTF-8文件可能有BOM，也可能沒有BOM，那麼怎麼區分呢？三種方法。1，用UltraEdit-32打開文件，切換到十六進制編輯模式，察看文件頭部是否有EF BB BF。2，用Dreamweaver打開，察看頁面屬性，看“包括Unicode簽名BOM”前面是否有個勾。3，用Windows的記事本打開，選擇 “另存爲”，看文件的默認編碼是UTF-8還是ANSI，如果是ANSI則不帶BOM。
所謂的unicode保存的文件實際上是utf-16，只不過恰好跟unicode的碼相同而已,但在概念上unicode與 utf是兩回事，unicode是內存編碼表示方案，而utf是如何保存和傳輸unicode的方案。utf-16還分高位在前 (LE)和高位在後(BE)兩種。官方的utf編碼還有utf-32，也分LE和BE。非unicode官方的utf編碼還有utf-7，主要用於郵件傳輸。utf-8的單字節部分是和iso-8859-1兼容的，這主要是爲了解決一些舊的系統和庫函數不能正確處理utf-16的問題，而且對英語字符來說，也節省保存的文件空間（以非英語字符浪費空間爲代價）。在iso-8859-1的時候，utf8和iso-8859-1都是用一個字節表示的，當表示其它字符的時候，utf-8會使用兩個或三個字節。
明白了原因之後，我在Struts2的Action裏用流生成CSV文件的時候，在一開始就加上這樣一句
<?php
/* 生成文件 */
header ('Content-type: application/CSV');
header ('Expires: 0');
header ('Pragma: no-cache');
header ('Content-Disposition: attachment; filename='.$file_name);
header ('Content-Length: '.$file_size);
echo pack('C', 0xEF);
echo pack('C', 0xBB);
echo pack('C', 0xBF);
echo $data;