CSV转Excel再转回来，怎样不弄坏数据

分隔符问题在打开文件之前就开始了

Excel按照操作系统区域设置里配置的列表分隔符，决定怎样把CSV拆成列，而不是去看文件本身。在设成欧洲区域的电脑上，这个分隔符默认是分号，于是一份普通的逗号分隔导出文件，会全部挤在一列里，没有拆开。在按美国区域设置的电脑上，分号分隔的文件会遇到相反的情况。这两种结果都不代表文件坏了，只说明Excel是按照与文件写法毫无关系的设置猜的。像CSV转Excel这样的转换器，会用几种候选分隔符解析文件，检查哪一种在抽样的各行里得到一致的字段数，从而完全绕开这个猜测，既不依赖文件扩展名，也不依赖系统设置。

前导零和长数字是悄无声息的受害者

CSV转Excel时，最具破坏性的事情是太急于把文本变成数字。写成00123的产品代码，只要电子表格认为它看起来像数字，就会立刻变成数字123，而那个前导零事后无法恢复，就这样没了。较长的标识符出问题的方式不同。十六位的银行卡号或条形码号码会在没有任何提示的情况下丢掉最后几位，因为电子表格的标准数字最多只能保存大约十五位有效数字，超出就会四舍五入。这两种值都应该保留为文本，而不是转换；目标是程序而不是Excel时，规则也一样：CSV转JSON会把它们保留为字符串。真正的数字，比如数量、价格和合计，仍然应该正常转换，这样才能求和、计算。

非英文数据往往坏在编码上

从老旧的财务系统或数据库导出的文件，很多时候根本不是UTF-8。西里尔文字用的Windows-1251和西欧带重音字符用的Windows-1252是常见的情况，按错误的编码打开，就会出现熟悉的满屏乱码。先检查有没有字节顺序标记，再严格按UTF-8校验，失败时根据高位字节的分布回退，用这种方式检测真实编码，就能自动发现这个问题。谁都不用在一堆编码选项里猜。

字节顺序标记本身也会悄悄造成损坏

UTF-8字节顺序标记（BOM）是文件最开头三个看不见的字节，告诉Excel后面的文字是Unicode。目标是Excel时，这很有用。一旦文件的去向不是Excel，它就成了问题。不会去掉这几个字节的命令行工具或老旧的数据处理流程，会把它们粘在第一个表头单元格的第一个字符上，于是本该叫“id”的列，和任何按这个确切名字查找它的地方都对不上。BOM该保留还是去掉，完全取决于下一个读取文件的是什么，而不是一个通用的默认值。

反方向转换也有自己要做的决定

用Excel转CSV把电子表格转回CSV时，会遇到正向转换从来不会碰到的问题。含公式的单元格有两个值：公式文本本身，以及它上次计算出的数字，而CSV一次只能带一个。导出计算结果，是大多数系统导入时期望的；导出公式文本，则是人工审阅者想看的。日期同样需要明确处理。按一种固定、选定的格式写出日期，而不是相信电子表格碰巧显示的样子，就能避免同一个文件因为格式化时用的电脑区域设置不同，而显示出不同样子的日期。

常见错误，以及防止每种错误的设置

把小数分隔符留在点号上。来自把一点五写成1,50的国家的分号分隔导出文件，需要在CSV转Excel里把“小数分隔符”设为“逗号”；否则每个价格都会留作字符串，无法求和。把标识符交给自动类型识别。它能保护前导零和超过十五位的数字，但没有前导零的订单号或邮政编码仍然会变成数字；如果没有哪一列需要计算，把“单元格类型”设为“全部作为文本”，每个值都会和原来写的一模一样。把几百万行的导出文件塞进一个工作簿。XLSX最多1,048,576行，所以更长的CSV会被拒绝，并给出CSV拆分的链接，而不是一声不吭地截断。

转回CSV时，把Excel转CSV里的三个默认设置和下一个读取文件的程序对照一下。“输出编码”默认是带BOM的UTF-8，这是Excel需要的形式；脚本或数据库加载工具通常要不带BOM的普通UTF-8。“日期格式”默认是ISO 8601，所以2026年3月14日在每台电脑上都写成2026-03-14，可选的还有14.03.2026、03/14/2026和Excel序列号。“换行符”默认是Windows用的CRLF，Unix工具可选LF。第四个设置很容易漏掉：默认只导出第一个工作表，所以有第二个标签的工作簿需要选“所有工作表”，结果是一个ZIP压缩包，每个工作表一个CSV。