date.csv:
"ID" "NAME" "EMAIL"
"1" "小明" "xm@163.com"
"2" "小東" "xd@sina.com"
"3" "小少" "shaozi@hotmai.com"

讀取這個csv文件
復制代碼 代碼如下:
<?php
$handle=fopen('date.csv','r');
while($data=fgetcsv($handle,10000,"/t"))  
{  
  echo "$data[0]"."$data[1]"."$data[2]";  
}
?>

讀取后在頁面上顯示時，成了這樣：
"ID" NAME EMAIL
 1 小明 xm@163.com
 2 小東 xd@sina.com
 3 小少 shaozi@hotmai.com
fgetcsv函數的字段環繞符默認是雙引號,
為什么我讀取出來時，其它字段都好好的，可是ID還有雙引號包著？

上網查了下，原來是utf8編碼的bom在php下無法識別.
下面是查來的資料：
Unicode規范中有一個BOM的概念。BOM――Byte Order Mark，就是字節序標記。在
這里
找到一段關于BOM的說明：
在UCS 編碼中有一個叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的編碼是FEFF。而FFFE在UCS中是不存在的字符，所以不應該出現在實際傳輸中。UCS規范建議我們在傳輸字節流前，先傳輸字符"ZERO WIDTH NO-BREAK SPACE"。這樣如果接收者收到FEFF，就表明這個字節流是Big-Endian的；如果收到FFFE，就表明這個字節流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被稱作BOM。

UTF-8不需要BOM來表明字節順序，但可以用BOM來表明編碼方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8編碼是EF BB BF。所以如果接收者收到以EF BB BF開頭的字節流，就知道這是UTF-8編碼了。
Windows就是使用BOM來標記文本文件的編碼方式的。

另外unicode網站的
FAQ-BOM
詳細介紹了BOM。官方的自然權威，不過是英文的，看起來比較費勁。
UTF-8編碼的文件中，BOM占三個字節。如果用記事本把一個文本文件另存為UTF-8編碼方式的話，用UE打開這個文件，切換到十六進制編輯狀態就可以看到開頭的FFFE了。這是個標識UTF-8編碼文件的好辦法，軟件通過BOM來識別這個文件是否是UTF-8編碼，很多軟件還要求讀入的文件必須帶BOM。可是，還是有很多軟件不能識別BOM。我在研究Firefox的時候就知道，在Firefox早期的版本里，擴展是不能有BOM的，不過Firefox 1.5以后的版本已經開始支持BOM了。現在又發現，php也不支持BOM。

php在設計時就沒有考慮BOM的問題，也就是說他不會忽略UTF-8編碼的文件開頭BOM的那三個字符。由于必須在轉換->UTF-8轉ASCII，或者在另存為里選擇ASCII編碼。如果是DOS格式的行尾符，可以用記事本打開，點另存為，選ASCII編碼。如果包含中文字符的話，可以用UE的另存為功能，選擇“UTF-8 無 BOM”即可。請參考下面的圖片：


根據Bo-Blog的wiki的說明：Editplus需要先另存為gb，再另存為UTF-8。不過這樣做要小心，所有GBK編碼中不包含的字符就會都丟了。如果有一些非中文的字符在文件里的話還是不要用這種辦法了。(從這一個小方面來看，UE――UltraEdite-32確實比Editplus好很多，Editplus太輕量級了)

另外我發現了一個辦法，就是利用Wordpress提供的文件編輯器。這個辦法不受限制，不需要去下載專門的編輯器，畢竟大家都在用Wordpress嘛。先在ftp里把要編輯的文件的寫入權限打開，然后進入Wordpress后臺->管理->文件編輯器，輸入要編輯文件的路徑，點編輯文件。在顯示出來的編輯界面中，你是看不到開頭的那三個字符的，不過沒關系，把光標定位在整個文件的第一個字符前，按一下Backspace鍵。OK了，點更新文件吧，在ftp里刷新一下，可以看到文件小了3字節，大功告成。

最后說一下，這是個大問題，所有要自己寫插件的，編輯別人的插件自己用的，需要修改模版的(這條估計每個人都需要吧)，最好了解一下上面的知識，免得出現問題時不知所措。

php技術：php讀取csv文件后,uft8 bom導致在頁面上顯示出現問題的解決方法，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。