导出CSV文件中的乱码

CSV文件乱码问题及解决方案
当使用Excel打开UTF-8编码的CSV文件时,内容可能会显示为乱码,因为Excel默认以ANSI格式打开。规避方法是通过Excel的文本导入向导选择UTF-8编码。但真正的解决方案是在导出CSV时加入BOM(字节顺序标记),以标识文件的UTF-8编码。


问题概述

如今的AUT导出csv文件的功能已经相当的常见,而打开文件后内容显示为乱码的现象也着实屡见不鲜,即便编码时候特意指定了码表为UTF-8,如下所示。

public void exportCSV(){
	OutputStreamWriter fwriter = new OutputStreamWriter(
		new FileOutputStream(new File("csv/export.csv")), "UTF-8");  
	  	  
	ICsvBeanWriter writer = new CsvBeanWriter(fwriter, 
		CsvPreference.EXCEL_PREFERENCE);  
…
}

既然指定了码表,为何用 Excel 打开 UTF-8 编码的 CSV 文件后,内容依然会是乱码呢?究其原因,竟是Excel本身默认会以 ANSI 格式打开,不做编码识别。

规避手段

对于这种情况,我们可以采用最简洁的规避手段。

1.    打开 Excel

2.    选中DATA -> From Text

3.    选择UTF-8编码的CSV文件,出现文本导入向导Import

4.    选择Delimited -> Next

5.    勾选Comma,去掉Tab -> Next

6.    最后点击确定完成

说它最简介,是因为不需要dev改动任何一处代码,即可达到目的。然而这终究只能称之为一个workaround,而非solution

解决方案

为了彻底解决该问题,我们需要引入一个叫做BOM的东西,关于其定义,wiki如是说——

字节顺序标记(英语:byte-order mark,BOM)是位于码点U+FEFF的统一码字符的名称。当以UTF-16或UTF-32来将UCS/统一码字符所组成的字符串编码时,这个字符被用来标示其字节序。它常被用来当做标示文件是以UTF-8、UTF-16或UTF-32编码的记号。

 

修改代码,在导出CSV文件时,引入includeBOM,再次查验CSV文件内容,这下大家应该可以彻底跟乱码说bye bye了吧!

// Include the byte order mark (BOM) for UTF-8 encoding.
private function includeBOM(value:String):ByteArray {
	var byteArray:ByteArray = new ByteArray();
	byteArray.writeByte(0xEF);
	byteArray.writeByte(0xBB);
	byteArray.writeByte(0xBF);
	byteArray.writeUTFBytes(value);
	return byteArray;
}
### MySQL 数据库导出 CSV 文件时中文乱码解决方案 当从 MySQL 数据库导出 CSV 文件并遇到中文乱码问题时,通常是由字符编码不匹配引起的。以下是几种有效的解决方法: #### 方法一:调整导出命令中的字符集 通过 `SELECT ... INTO OUTFILE` 命令导出数据到 CSV 文件时,可以指定字符集为 GBK 或 UTF-8 来避免乱码问题。如果目标文件将在 Excel 中打开,则建议设置为 GBK 编码。 ```sql SELECT * INTO OUTFILE '/path/to/file.csv' CHARACTER SET gbk FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM your_table; ``` 这种方法直接在 SQL 查询中指定了字符集为 GBK[^1],从而解决了因默认 UTF-8 和 Excel 默认使用的 GBK 不一致而导致的乱码问题。 --- #### 方法二:通过 Excel 手动加载 CSV 并选择正确编码 另一种常见的方式是在导出过程中保持原始 UTF-8 编码不变,在后续处理阶段由用户手动配置正确的编码支持。具体操作如下: 1. 使用标准工具或脚本完成 CSV导出; 2. 新建一个空白 Excel 工作簿; 3. 转至 **数据 -> 获取外部数据 -> 导入文本/CSV 文件**; 4. 在导入向导的第一步中,将文件原编码选为 **65001 (UTF-8)**[^2]; 此法无需修改服务器端任何参数即可实现兼容性较高的显示效果。 --- #### 方法三:借助中间媒介转换编码形式 对于某些特殊场景下无法更改源程序或者数据库连接属性的情况,可考虑采用间接手段来规避潜在冲突风险——即将初始结果存储成纯文本格式(.txt),再利用 Microsoft Office 提供的功能读取该文档的同时允许自定义解析选项(如设定输入流所遵循的具体字节序列规则)。例如: 1. 将查询所得记录写入本地磁盘上的临时 .TXT 文档; ```sql SELECT * FROM user WHERE ... INTO DUMPFILE '/tmp/user_data.txt'; ``` 2. 启动 MS Excel 应用软件,并选取上述生成的目标位置下的 TXT 实体作为待分析素材对象; 3. 遵循提示逐步填写必要字段直至最终确认完毕为止(期间记得勾选对应的语言环境标签页内的“Unicode”单选项卡)[^3]. 如此这般既保留了原有逻辑架构又兼顾到了实际应用需求之间的平衡关系. --- #### 方法四:LOAD DATA INFILE 语句修正 如果是重新载回含有汉字成分的数据项回到 Mysql 表格内部的话, 则需要特别留意 insert 操作前后的 session 变量状态值是否统一指向 utf8mb4 。即执行下面两行预置指令后再继续常规流程 : ```sql SET NAMES 'utf8mb4'; SET CHARACTER_SET_CLIENT='utf8mb4'; SET CHARACTER_SET_RESULTS='utf8mb4'; SET COLLATION_CONNECTION='utf8mb4_general_ci'; LOAD DATA LOCAL INFILE '/test.csv' INTO TABLE table_name CHARACTER SET utf8mb4 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\r\n' IGNORE 1 LINES ; ``` 这里强调的是全程维持一致性的重要性 , 即使面对不同平台间交互也应如此对待 [^4]. --- ### 总结 以上四种策略各有优劣之处,可根据实际情况灵活选用其中一种或多种组合起来应对复杂的业务挑战。无论是前端展示层面还是后台持久化环节都需要给予足够的重视程度才能真正意义上杜绝此类现象再次发生。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值