在UTF-8编码的Web 程序中导出CSV文件乱码问题

在做一个导出CSV文件的功能时发现导出的文件是乱码，上网查了下，发现原来是BOM(Byte Order Mark)的问题

  BOM是UTF编码方案里用于标识编码的标准标记，在UTF-16里是FF FE，UTF-8里是EF BB BF。这个标记是可选的，因为UTF-8没有顺序，所以它可以被用来检测一个字节流是否是UTF-8编码的。微软做这种检测，但有些软件不做这种检测，而 把它当做正常字符处理。

  微软在自己的UTF-8格式的文本文件之前加上了EF BB BF三个字节, windows上面的notepad等程序就是根据这三个字节来确定一个文本文件是ASCII的还是UTF-8的, 然而这个只是微软暗自作的标记, 其它平台上并没有对UTF-8文本文件做个这样的标记，类Unix系统中就没有使用 BOM，因为它会破坏现有的 ASCII 文件的语法约定。

  也就是说一个UTF-8文件可能有BOM，也可能没有BOM，那么怎么区分呢？三种方法。1，用UltraEdit-32打开文件，切换到十六进制编辑模 式，察看文件头部是否有EF BB BF。2，用Dreamweaver打开，察看页面属性，看“包括Unicode签名BOM”前面是否有个勾。3，用Windows的记事本打开，选择 “另存为”，看文件的默认编码是UTF-8还是ANSI，如果是ANSI则不带BOM。

  所谓的unicode保存的文件实际上是utf-16，只不过恰好跟unicode的码相同而已,但在概念上unicode与 utf是两回事，unicode是内存编码表示方案，而utf是如何保存和传输unicode的方案。utf-16还分高位在前 (LE)和高位在后(BE)两种。官方的utf编码还有utf-32，也分LE和BE。非unicode官方的utf编码还有utf-7，主要用于邮件传 输。utf-8的单字节部分是和iso-8859-1兼容的，这主要是为了解决一些旧的系统和库函数不能正确处理utf-16的问题，而且对英语字符来 说，也节省保存的文件空间（以非英语字符浪费空间为代价）。在iso-8859-1的时候，utf8和iso-8859-1都是用一个字节表示的，当表示 其它字符的时候，utf-8会使用两个或三个字节。

  明白了原因之后，我在Struts2的Action里用流生成CSV文件的时候，在一开始就加上这样一句

 

Java代码

1. out = response.getOutputStream();  
2. //加上UTF-8文件的标识字符   
3. out.write(new   byte []{( byte ) 0xEF ,( byte ) 0xBB ,( byte ) 0xBF });  

out = response.getOutputStream();
//加上UTF-8文件的标识字符
out.write(new byte[]{(byte)0xEF,(byte)0xBB,(byte)0xBF});

 

  再用微软的Excel打开，没有乱码了。