CSV 文件的字符编码与 Locale 设置指南

CSV 文件在跨系统读写时常常出现乱码、数字解析错误、日期格式错乱等问题。本文详细解释为什么需要关注 Character（字符编码）和 Locale（区域设置），分析不同系统的默认编码差异，以及数字、日期格式在不同 Locale 下的解析规则，帮助读者在导出、导入和程序处理 CSV 时做出正确的选择。

为什么要关注字符编码？

CSV 不保存编码信息

CSV 文件里只有字节，不会记录自己用的是 UTF-8、GBK 还是 Shift-JIS。打开程序必须"猜"，猜错了就会乱码。

不同系统的默认编码不同

典型问题

• UTF-8 文件用 Excel 直接打开 → 中文变乱码
• GBK 文件用程序按 UTF-8 读取 → 报错或乱码

最佳实践

• 优先使用 UTF-8（带 BOM），兼容性最好
• 数据含多语言时，必须用 UTF-8

为什么要关注 Locale？

Locale 决定数字、日期、货币的解释方式，CSV 同样不会自动说明。

数字格式差异

示例：

3,14

• 美式：3
• 德式：3.14

同一个 CSV，不同 Locale 会被解析成完全不同的数值。

日期格式差异

示例：

01/02/2024

• 美国：2024 年 1 月 2 日
• 欧洲：2024 年 2 月 1 日

日期直接错乱，分析结果完全错误。

排序与大小写规则

Locale 还影响：

• 字符串排序规则
• 大小写转换
• 货币符号识别

为什么 CSV 特别容易出问题？

因为 CSV：

• 没有表结构
• 没有数据类型
• 没有编码声明
• 没有区域声明

一切依赖打开方的解读规则。

相比之下：

• Excel（.xlsx）：自带编码、格式、类型
• JSON / XML：可明确声明编码
• 数据库：强类型约束

实际工作中的正确做法

导出 CSV 时

• 明确指定：UTF-8
• 明确分隔符（, / ;，因 Locale 而异）
• 统一日期格式：YYYY-MM-DD

导入 CSV 时

• 手动指定编码
• 手动指定 Locale / 区域
• 校验数字、日期是否正确解析

程序处理时

读取：指定 encoding + locale
存储：转成标准格式（ISO 日期、标准小数）

总结

字符编码决定你能不能"看见正确的文字"，Locale 决定你能不能"算对数字和日期"。在处理 CSV 文件时，明确指定这两项参数是避免数据错误的关键。