utf-8文件加BOMl与不加BOM的影响？有没研究过的？

Question

我遇到一个关于BOM的问题：
1、用Windows下的记事本保存PHP代码，其中的PHP代码有header函数，也就是标头的函数，用UTF-8编码保存，会产生Cannot header By什么的错误。研究发现Windows下记事本程序保存含有发送HTTP标头的语句会产生缓存的错误，是因为Windows记事本保存UTF-8默认是有BOM的。2、用Dreamweaver（可以选择是否保存BOM）、EditPlus是没有这种错误。

Answer 1

utf-8本来就不应该加bom，除了让编辑器知道它是个utf-8之外什么用处都没有。实际上编辑器完全有能力在不太多的几个编码格式之间根据特征来判断一个文件是什么编码，就算不能自动识别，编辑器也应该有设置编码的地方。所以我觉得BOM对于utf-8来说是多余的东西。utf-16才需要加bom。因为它是按unicode顺序编码，在BMP范围内是二字节，需要识别是大或小字节序。实际上，我觉得utf-8引入大小字节序的概念太愚蠢了，不知道那些标准委员会是怎么想的。大小字节序存在的意义，在于cpu的处理方式。如果cpu是大字节序处理，那么对于小字节序，就必须做一层转换，这带来了效率上的下降。但是在实际应用里，谁会去关心大小字节序？文本编码引起字节序的概念，只能说那些制定标准的人太死板了。对于utf-16，我认为只要全世界都遵循一种字节序方式，那就没什么必要用BOM来标注了。话说回来，PHP是不支持utf-16编码的文件的。因为例如$这个符号，在utf-8里也是两个字节，PHP解码器无法解析的。不知道PHP6内部处理引入unicode 的概念之后，对这个是否会有支持。编码问题是一个说起来简单，但是实际上很繁琐的东西。很多程序，都有分层编码的概念。像MySQL，就分为client->connection->storage和storage->connection->result这些概念。storage又分为system,database,table,column。我有时候在想，有必要搞这么复杂嘛，TNND。像MySQL，谁用利用它这些特性阿？除非允许两个client在不同的编码环境下运作，否则它把client编码分离出来根本没有什么必要。大多数情况下，直接binary in/binary out就好了。

Answer 2

主要是php程序内部API在处理2位字符串的时候经常会出现错误。
其他得到不常见。开发主要用Eclipse，几乎都没考虑过BOM问题，UTF-8转换问题碰到的并不多。

Answer 3

更正一下一句话：“因为例如$这个符号，在utf-8里也是两个字节”应该为“因为例如$这个符号，在utf-16里也是两个字节”另外补充一下，我说的PHP不支持utf-16文件，是指php不能解析编码为utf-16的php脚本文件，而不是说PHP脚本无法处理utf-16的串。

Answer 4

一直用editplus开发，快
现在发现对utf-8支持不好，PHPCB用不上，无法格式化代码，老出乱码
看来还是zend IDE比较正规

Answer 5

另外，editplus有添加和删BOM的功能，但不知影响和效果，它自身也不能查看BOM
utf-8文件上传服务器后
还有就是没有BOM，在FXP中打开远程utf-8编辑是乱码,必须本地改后，上传才可没有BOM时，如果没有指定meta charset，乱码，如果指定或header搞得我头大

Answer 6

会的吗？？？有BOM时，PHP的文件不能有header的，否则会有1楼讲的错误，开启output缓冲除外（要在php.ini开启才有效）。

Answer 7

是header强制一下字符集编码，没有BOM,有时要强制指定

Answer 8

lz不要在BOM上钻牛角尖。
大多出程序中处理UTF-8文本信息，并不会去看BOM，保存的时候也不会特意加BOM，重视BOM处理的只有文本编辑器。如果你写的程序出现乱码，可以从以下两点思考：
1.判断，上传/下载数据，以什么样的编码被保存，以正确解析；
2.注意HTTP吞吐数据过程中，头信息的编码；
建议，PHP工程开发使用IDE。

Answer 9

这个问题测测再看了
大家都用什么编辑器了，我用的最多的就是代码格式化和预览调式
但editplus 的utf-8的代码格式化不行，不知PHPCB.exe一调用就出现乱码，gb下正常
zend IDE很好，支持自动格式化，但预览慢，不内置FF

Answer 10

一般用ultraEdit和Zend或者记事本,呵呵,没有遇到你这种情况.

Answer 11

VIM在Linux好像不需要下载的，安装的时候选择它就可以了。

Answer 12

Unicode标准并不推荐在utf8中使用BOM， 所以不能怪标准委员会的。。：）

Answer 13

做过一段时间的转码器
如果utf8不加BOM的话，
编辑器无法100%准确测出文件使用的编码
特别是在中文环境中
这情况真的很无奈而PHP中utf8加 BOM会出现问题
主要是因为PHP编译器不支持

Answer 14

当有bom的文件include另一个有bom的文件就会出现两个bom~~某个地方看到的~~~反正没bom就对了~~

Answer 15

把工程拉到netbeans里面吧~~省事~~~

Answer 16

EditPlus 总是 移除 BOM

Answer 17

我发现EditPlus是可以自动识别编码的，但vim在win下就不行
还发现，如果没有BOM，也没有Meta或header charset浏览器可能会不知道是什么编码

Answer 18

vim可以识别编码的，win/mac/linux都可以，只要设置正确。我以前写的一篇关于vim编码的文章：vim的编码详解和中文环境设置vim可以格式化代码，最基本的格式化你可以打开一个乱了的文件按“100==”试试。vim的可扩展性很强，可以通过插件来实现很多原来没有的功能，而插件在vim.org可以下载到很多，自己写也不难。所以vim没有做不到，只有想不到。虽然vim要经过比较多的配置和学习才能很完美地作为编程工具，但是对于打算写一辈子程序的我来说，这点配置和学习成本值得。

Answer 19

我试过了，VIM,在没有BOM的情况下，不会自动识别
格式化的我再试我原来用Ediplus，也是配置了用户插件，支持代码分析，美化，但转utf-8后发现PHPCB.exe美化不工作

Answer 20

Ediplus我最喜欢的是他的预览功能，太快了，CTRL+B,而且内置js错误控制台
对于偶这样echo调试的，很方便

Answer 21

不要加BOM，不好，session时容易出错

Answer 22

utf8编码最好不要加bom，当然有ob系列函数可以解决含有BOM的utf8编码文档。
说到文件编码难免要讨论一下编辑器。在下认为任何编辑器只要用着顺手就行，不存在什么王道不王道的。
editplus不是，EmEditor不是，vim不是，bluefish不是，eclipse也不是。当然也可以都是王道。
PHP的编辑器，在下用得比较习惯的有eclipse pdt 和 自己整合的Editplus4PHP 。基本上坚持在eclipse pdt下编写，毕竟这个是通用而且强大的IDE。

Answer 23

可以的，你把你的.vimrc或者_vimrc贴出来我看看。

Answer 24

你用过vim吗？或者你用过emacs吗？我没过vim之前，也觉得编辑器都差不多，因为他们的操作方式没什么区别。用了vim，你就知道什么叫做程序员的编辑器了。当然，各有所爱，我只是在推荐我所喜欢的vim而已。

Answer 25

被包含的php文件不要转，直接ansi

Answer 26

至目录前为止，我还没有发现关于这方面的错误，好象有没有BOM都可包含，utf-8也是这样

Answer 27

我遇到一个问题，将一个系统从中文转为日文的时候，有些页面会出现显示不正常，页面整个贴着左边，有些字体还会变大，有人跟我说是BOM的问题，可是看了我的文件，并没有BOM。我用的编码是UTF-8。大家认为会是什么导致的这个问题呢。

Answer 28

第一种情况：
你转的不完整，彻底，html中只要有一下标签不对，就没有形，看你转后的文件输出的源文件中是否有非法字符这说明转码不完全正确第二种情况：
 css也要转，不过这种情况问题可能性少
参考我写的：
 http://www.zzxj.net/blog/fxs_2008/archive/2009/02/12/19.html

Answer 29

最怕那些在不该出现中文的地方调试时搞出中文来，结果转成了utf-8结果情况就发生了