UTF-8编码的文件可以分为without BOM和BOM两种格式。
何谓BOM？ "EF BB BF" 这三个字节就叫BOM，BOM的全称叫做"Byte Order Mark".
在UTF-8文件中常用BOM来表明这个文件是UTF-8文件,
而BOM的本意是在UTF-16中用来表示高低字节序列的。在字节流之前有BOM表示采用低字节序列（低字节在前面），而UTF-8不用考虑字节序列，所以其实有无BOM都可以。UTF-8以字节为编码单元，没有字节序的问题。UTF-16以两个字节为编码单元，在解释一个UTF-16文本前，首先要弄清楚每个编码单元的字节序。例如收到一个“奎”的Unicode编码是594E，“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”，那么这是
“奎”还是“乙”？
如果文件保存时，选择了使用BOM，那么就可能会出现headers already sent的问题。
因为Web服务器软件可能不认识BOM，所以就把BOM的两个特殊字节当做字符发送给浏览器了。
这时再调用session_start()等函数，就会出现headers already sent的问题。
所以解决此问题最根本的方法就是在保存UTF-8编码的文件时，不要使用BOM。
微软的记事本Word等只能正确打开含BOM的UTF8文件，然而UltraEdit却恰恰相反，会把BOM UTF-8文件误认为ascii编码。
UTF-8的BOM是 EFBBBF，因为UE载入UTF-8文件会转成Utf16，上述的EFBBBF 在Utf16中是FFFE（Unicode-LE的BOM），UltraEdit不认识BOM又加多一個BOM，所以有2个FFFE。文件就被它破坏了。
当应用程序的文件使用 UTF8 编码时，在保存文件时，一定要注意 BOM 的问题。那么如何将UTF8 without BOM转换成UTF8呢？
win平台默认的utf8编码的文本性文件带有BOM,java转换流写入的utf8文件不带BOM。所以用java读取手动创建的utf8文件会出现一点乱码(?hello中国,?是bom导致的)