CSV乱码 - UTF-8 Unicode (with BOM)

最新推荐文章于 2024-09-20 07:04:51 发布

森伯416

最新推荐文章于 2024-09-20 07:04:51 发布

阅读量5.3k

点赞数 2

分类专栏： Java 文章标签： java unicode utf-8 bom csv乱码

本文链接：https://blog.csdn.net/Dkangel/article/details/119648796

版权

本文介绍了Unicode、BOM和UTF-8编码的概念，并重点讨论了UTF-8 BOM在CSV文件中的作用。当CSV文件缺少BOM标识时，可能导致Excel打开时出现中文乱码。通过Java代码示例，展示了如何生成带有BOM头的CSV文件以避免乱码问题。注意，BOM标识只需在文件头添加一次。

摘要由CSDN通过智能技术生成

Unicode

统一码，也叫万国码、单一码（Unicode）是计算机科学领域里的一项业界标准，包括字符集、编码方案等。Unicode 是为了解决传统的字符编码方案的局限而产生的，它为每种语言中的每个字符设定了统一并且唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。
如果把各种文字编码形容为各地的方言，那么Unicode就是世界各国合作开发的一种语言。
在这种语言环境下，不会再有语言的编码冲突，在同屏下，可以显示任何语言的内容，这就是Unicode的最大好处。就是将世界上所有的文字用2个字节统一进行编码。那样，像这样统一编码，2个字节就已经足够容纳世界上所有的语言的大部分文字了。
Unicode的学名是"Universal Multiple-Octet Coded Character Set"，通用多八位编码字符集，简称为UCS。
现在用的是UCS-2，即2个字节编码，而UCS-4是为了防止将来2个字节不够用才开发的。

BOM

在UCS 编码中有一个叫做 “Zero Width No-Break Space” ，中文译名作“零宽无间断间隔”的字符，它的编码是 FEFF。而 FEFF 在 UCS 中是不存在的字符，所以不应该出现在实际传输中。UCS 规范建议我们在传输字节流前，先传输字符 “Zero Width No-Break Space”。这样如果接收者收到 FEFF，就表明这个字节流是 Big-Endian 的；如果收到FFFE，就表明这个字节流是 Little- Endian 的。因此字符 “Zero Width No-Break Space” （“零宽无间断间隔”）又被称作 BOM。

UTF-8

UTF-8（8位元，Universal Character Set/Unicode Transformation Format）是针对Unicode的一种可变长度字符编码。它可以用来表示Unicode标准中的任何字符，而且其编码中的第一个字节仍与ASCII相容，使得原来处理ASCII字符的软件无须或只进行少部分修改后，便可继续使用。因此，它逐渐成为电子邮件、网页及其他存储或传送文字的应用中，优先采用的编码。

UTF-8 BOM

UTF-8 不需要 BOM 来表明字节顺序，但可以用 BOM 来表明编码方式。字符 “Zero Width No-Break Space” 的 UTF-8 编码是 EF BB BF。所以如果接收者收到以 EF BB BF 开头的字节流，就知道这是 UTF-8编码了。Windows 就是使用 BOM 来标记文本文件的编码方式的。

CSV文件乱码问题

类似WINDOWS自带的记事本等软件，在保存一个以UTF-8编码的文件时，会在文件开始的地方插入UTF-8 BOM头。记事本等编辑器通过它来识别这个文件是否以UTF-8编码(当然即便没有UTF-8 BOM头记事本也能通过其它方式正确识别UTF-8编码)。
如果一个UTF-8编码的字符串的开头处没有BOM头又会发生什么？
举个例子

代码demo

 	/**
     * csv 写入文件头
     *
     * @param pathAndName 文件全路径名
     *                    /Users/yangcheng/Documents/dkangel.csv
     * @throws IOException IO异常，上层捕获处理
     */
    <