摘要：CSV 看起来是最简单的数据格式，正因如此，微小的不一致——未加引号的文本字段中一个游离的逗号、不匹配的分隔符、隐藏的 BOM——才会导致导入失败或悄悄地使列错位。可搭配 Encoding Converter、Duplicate Finder、Remove Extra Spaces 和 Character Counter 一起使用本指南。
CSV 的真正规则定义在 RFC 4180 中，尽管实际上大多数现实中的 CSV 只是松散地遵循这些规则——这正是大多数导入问题的根源。
CSV 导入究竟在哪里失败
核心问题在于：逗号既是列分隔符，又是一个可以合法出现在文本字段中的字符（一个地址，或者一段产品描述中包含"小号，中号，大号"）。RFC 4180 的解决方案是加引号——包含逗号的字段必须用双引号括起来，字段内字面的双引号则通过重复自身来转义（""）。不遵循这条规则导出 CSV 的软件，会产生这样的文件：一个未加引号的逗号会悄悄地把后面每一列都错位一格。
分隔符并不统一
以逗号分隔是默认假设，但许多实际文件使用的是分号——在那些逗号本身就是数字的小数分隔符的地区尤其常见，这使得把逗号重新用作列分隔符变得含糊不清。在电子表格中打开时显示为单一未拆分列的 CSV，很多时候只是使用了与该工具假设不同的分隔符，并非真的损坏。
编码与不可见的 BOM
UTF-8 字节顺序标记（BOM）——文件最开头三个不可见的字节——是某些工具（尤其是 Excel 导出时）添加的，用来标示编码，但并非所有解析器都会自动去除它。如果保留下来，它可能会不可见地附着在第一列的表头名称上，于是一个查找列名恰好为 name 的操作会失败，因为实际的表头是前面带着一个不可见字符的 name——这是一个确实很难用肉眼发现的问题。
导入前的清理工作流程
- 先以纯文本方式打开原始文件（不要在电子表格中打开，因为它会自动解释并可能隐藏真实结构），以检查真正的分隔符和引号使用方式。
- 如果按列名查找莫名其妙地失败，检查文件开头几个字节是否有 BOM。
- 特别留意本应是单一文本字段中出现的未加引号逗号——这是列错位最常见的原因。
- 检查文件末尾是否有多余的换行符或空行，有些导入工具会将其算作损坏的最后一条记录。
- 如果重复记录会在后续造成问题，在导入前对关键列（如 ID 或电子邮件）运行 Duplicate Finder。
应避免的常见错误
- 假设每个 CSV 都使用逗号——分号分隔的文件很常见，在你尝试用错误的字符拆分之前看起来完全一样。
- 在电子表格应用中编辑 CSV，它会悄悄重新格式化日期、去掉前导零，并可能以与原始文件不匹配的方式重新编码文本。
- 当基于表头的查找无缘无故失败时，没有检查开头是否有 BOM。
- 忽视自由文本字段中未加引号的逗号，直到导入产生明显错位的列。
大多数 CSV 导入失败其实并不真正关乎数据本身——而是关乎解析器的假设（分隔符、编码、引号使用方式）与文件实际内容不匹配。