BOM及CSV/Excel乱码及从代码上根源解决问题

2023-09-01 03:52| 来源: 网络整理| 查看: 265

背景

在使用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会使用两个或三个字节。

参考

CSV文件打开乱码解决方法-知乎

【本文地址】

公司简介

联系我们