喔天啊我終於解開這個謎了，真令人感動... 由於缺乏對其他 HTTP header 的瞭解和在網路上放音樂的經驗，著實吃了點苦頭 =.=
簡言之: 不要用 Content-Disposition: attachment 的方法送檔案，然後也順便送出 Content-Length 就行了。
代碼:
$file=fopen("after_17.mp3","r");
header("Content-Type: audio/mpeg");
header("Content-Length: ".filesize("after_17.mp3"));
while(!feof($file)){echo fread($file,50000);}fclose($file);
----
以下是「遊記」，由於自以為蠻有趣就寫一下，沒興趣的看剛剛那段瞭解作法就好了..
----
由於我記得以前曾以送出「Content-Disposition: attachment; filename=something.pdf」的方式製作「下載 PDF 檔」的連結（使用者按下此連結後不會在瀏覽視窗中開啟 Acrobat Reader），或許問題就在那裡？所以做了這個測試。
1. 直接從位址列輸入網址，測試瀏覽器怎麼處理。
* Firefox: 以 plugin 開啟
* IE: 以 plugin 開啟
2. 撰寫與提問中相似的 PHP 程式碼，測試瀏覽器怎麼處理。
* Firefox: 下載檔案
* IE: 下載檔案
3. 以 LiveHTTPHeader 查閱直接輸入檔名與間接透過 PHP 接收檔案的差異。以下以加號代表「間接方式有」但「直接方式沒有」的項目，減號代表「直接方式有」但「間接方式沒有」的項目。
- Etag: "1c9d-285000-ca78dee4"
- Accept-Ranges: bytes
- Content-Length: 2641920
+ X-Powered-By: PHP/4.3.3
+ content-disposition: attachment; filename=after_17.mp3
+ Transfer-Encoding: chunked
經此研究獲得的結論如下：
* 不管是哪種方式，以輸入網址方法操作的話兩種瀏覽器處理方式都一樣。
* 兩種方式的 HTTP header 有不少差異
獲得假設：
* 可能是瀏覽器把接收到的檔案轉交給 plugin 的方式不同？
* 如果想辦法把兩種 header 都做到一樣，或許就可以了？
第一個假設如果成立的話，我們是鐵定無能為力的 XD
為了測試第二個假設，決定不用 attachment 作法傳檔案，直接把傳出去的東西當成音樂檔（ㄟ... 這樣講有點奇怪，反正就是不把他當成「網頁的 attachment」XD )。
哇，可以播了耶！不過沒送 Content-Length 會中斷，所以補上就 ok 了...
----
都說了我只是自以為有趣...
登入
註冊
問答集
搜尋
