BOM及CSV/Excel乱码及从代码上根源解决问题
背景
在使用Java代码生成csv文件时，使用Notepad++/Sublime Text之类的文本编辑器打开是没有问题，但可视化效果不好，故而考虑使用Excel打开，可是却出现乱码问题。
注：后来在启动一个应用时，也遇到也个乱码问题，参考IDEA + Tomcat 8.5中文乱码解决过程，是某个HTML文件的编码问题。
BOM，Byte Order Mark，字节顺序标记，一种文件头部协议，存储在文件头部，用于标识文件编码。
BOM，是UTF编码方案里用于标识编码的标准标记，在UTF-16里本来是FF FE，在UTF-8就变成EF BB BF。这个标记是可选的，因为UTF8字节没有顺序，所以它可以被用来检测一个字节流是否是UTF-8编码的。微软做这种检测，但有些软件不做这种检测，而把它当作正常字符处理。
微软在自己的UTF-8格式的文本文件之前加上EF BB BF三个字节, windows上面的notepad等程序就是根据这三个字节来确定一个文本文件是ASCII的还是UTF-8的，这只是微软暗自作的标记，其它平台上并没有对UTF-8文本文件做个这样的标记。
一个UTF-8文件可能有BOM，也可能没有BOM，区分的三种方法：
- 用UltraEdit-32打开文件，切换到十六进制编辑模式，察看文件头部是否有EF BB BF
- 用Dreamweaver打开，察看页面属性，看包括Unicode签名BOM前面是否有个勾
- 用Windows的记事本打开，选择 “另存为”，看文件的默认编码是UTF-8还是ANSI，如果是ANSI则不带BOM。
如果使用UTF-8编码生成CSV文件，会发现CSV文件虽然可以用记事本打开，但是用Excel打开就会出现乱码。
解决
原理：Excel在读取csv时是通过读取文件头上的bom来识别编码的，如果文件头无bom信息，则默认按照unicode编码读取。（bom是微软定义的一种文件头部协定，存储在文件头部，存储内容就是标识文件编码的信息。）而生成csv的平台不一定遵循微软的bom协议，导致如果输出非unicode编码的csv文件（如utf-8），并且没有生成bom信息的话，Excel自动按照unicode编码读取，就会出现乱码问题。
解决：只需将非unicode编码的CSV文件，用文本编辑器（Notepad++）打开并转换为带bom的编码形式（具体编码方式随意），问题解决。
每次都是手动打开CSV文件，修改并转换编码，然后再保存，那不是很傻么？既然CSV文件是程序生成的，那怎么用程序解决这个乱码问题，让生成的CSV文件用Excel打开时不会出现乱码？
Java
BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(Files.newOutputStream(tempFile.toPath(),
StandardOpenOption.APPEND), StandardCharsets.UTF_8));
// fix
bw.write(new String(new byte[]{(byte) 0xEF, (byte) 0xBB, (byte) 0xBF}));
bw.write();
bw.newLine();
bw.flush();
bw.close();
Python
import csv
# utf-8-sig
csv_file = open("writer.csv", "w+", newline = '', encoding = 'utf-8-sig')
writer = csv.writer(csv_file )
writer.writerow(text)
编码
所谓的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会使用两个或三个字节。
