导出csv文件中文乱码问题

本文探讨了不同系统间文件编码的问题,特别是中文字符在不同操作系统间的显示差异及乱码产生的原因。文章还介绍了如何正确地进行编码转换,以确保文件在各种环境下都能正常解读。

编码相关基础:

参考http://blog.youkuaiyun.com/youyue/article/details/4580402

http://blog.163.com/asd_wll/blog/static/21031040201361043947625/

首先获取的中文字符是从内存数据库获取的,是一直存储在内存中的,所以是unicode编码,然后输出到csv文件时,默认是采用系统的编码格式进行写文件。那么在某个linux系统就是UTF_8,在windows就是GBK。生成的文件是什么编码格式的,那么在系统中打开时,就需要选择相应的解码格式来打开文件。

注意:在ORACLE数据库的话,他是有编码格式的。所以读取时,要确保是数据库设定的编码格式。

 

当在linux中生成的csv文件是UTF_8编码的,拿到windows系统用excel打开时,由于excel默认采用操作系统的编码即GBK进行解码,所以导致解码错误,出现乱码且错行。

但用文本编辑器如UE打开就没有问题,因为它可以自适应根据文件的编码格式进行解码打开文件。

如果需要用excel打开的话,可以用文本编辑器打开然后另存为选择操作系统可以识别的编码,那么再用excel打开的话就没问题。

 

像平时有的文件,强制用UE打开的时候,也会出现一堆二进制,那也是解码格式和文件的编码格式不一致导致的,这种情况由于文件实际是正确的,因此选择正确的解码方式进行解码打开文件就可以了。


编码基础

不管是中文字符还是英文字符等所有字符,在java的内存中都是以unicode编码比如UTF-8存储的。

 

读写文件也不一定非得用什么编码写。只要写和读采用相同的编码就不会出错。

 

比如某个文件(含中文)是UTF-8编码格式,那么在java文件编写读入该文件的时候,就得用OutputStreamWriter(UTF-8)进行解码,这样在编译java文件时读入的数据才会是正确的。

Java文件编写完成后就要进行编译,在java文件中数据读取都会存储到对象中,即存储在内存中,而内存中都是unicode编码的,所以从文件读取时采用正确的编码格式解码,那么读取的文件信息就是正确的。存储到内存中时,java虚拟机会自动将其转换为unicode编码格式的信息,那么信息也是正确的。

 

要注意的是编写java文件时,java文件也是有编码格式的(即每个文件都是有编码格式的)。比如UTF-8。那么编译时,若是命令行采用javac进行编译,若未指定编码类型,那么就会采用操作系统默认的编码类型来编码,比如在中文windows系统中,默认是GBK,此时编译的话就会出现乱码,即编译生成的class文件就乱码了,那么后续就无法恢复了,除非是再重新编译。所以一定要注意编译时的类型,这也是为什么在windows系统编写的文件,拿到linux系统中编译会出现问题的原因,windows写的文件一般是GBK的,而linux编码一般是UTF-8或UTF-16的,所以在linux编译的话就会出错。

当然,在输出的时候可以指定编码格式,比如new OutputStreamWriter(os,“GBK”);

那么写出的文件就是GBK格式的,在windows系统查看就会没问题。但是在linux系统中查看可能就会有问题,比如linux有个第三方软件默认编码是系统编码即UTF-8,那么用来解析GBK的就会出错。

但是在IDE环境中,比如eclipse和IDEA,它可以为每个java文件设置字符编码类型,而内置的编译器就会根据此设置来编译java文件。

 

保证java文件编译生成的class文件没有问题后,那么后续输出出现乱码的话,就可以进行相应解决了。

### 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]. --- ### 总结 以上四种策略各有优劣之处,可根据实际情况灵活选用其中一种或多种组合起来应对复杂的业务挑战。无论是前端展示层面还是后台持久化环节都需要给予足够的重视程度才能真正意义上杜绝此类现象再次发生。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值