date.csv:"ID" "NAME" "EMAIL"
"1" "小明" "xm@"
"2" "小东" "xd@"
"3" "小少" "shaozi@"
读取这个csv文件
$handle=fopen('date.csv','r');
while($data=fgetcsv($handle,10000,"/t"))
{
echo "$data[0]"."$data[1]"."$data[2]";
}
?>
读取后在页面上显示时,成了这样:"ID" NAME EMAIL
1 小明 xm@
2 小东 xd@
3 小少 shaozi@
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字节,大功告成。
最后说一下,这是个大问题,所有要自己写插件的,编辑别人的插件自己用的,需要修改模版的(这条估计每个人都需要吧),最好了解一下上面的知识,免得出现问题时不知所措。
如果觉得《csv乱码 ftp_php读取csv文件后 uft8 bom导致在页面上显示出现问题的解决方法》对你有帮助,请点赞、收藏,并留下你的观点哦!