如果将 CSV 重新定义为“字符分隔值”,即使用任何单个字符(但通常是任何非字母数字符号)作为分隔符而不仅仅是逗号的数据,那么自动检测文件实际上是 CSV的可靠方法是什么?
本质上,使用这个(重新)定义,CSV = DSV(“分隔符分隔值”),例如,在这篇维基百科文章中讨论过,而“逗号分隔值”格式在RFC 4180中定义。
更具体地说,是否有一种方法可以统计推断数据具有某种“固定”长度,即“可能的 CSV”?仅仅计算分隔符的数量并不总是有效的,因为 CSV 文件的每条记录具有可变数量的字段(即,与 RFC 4180 要求相反的记录,在同一文件中没有相同数量的字段)。
CSV 识别似乎是一个特别具有挑战性的问题,特别是如果检测不能基于文件扩展名(例如,当读取一个无论如何都没有此类信息的流时)。
正确(“完整”)的自动检测需要至少 4 个可靠的决策:
- 检测文件实际上是 CSV
- 检测标题的存在
- 检测实际的分隔符
- 检测特殊字符(例如,引号)
由于其他数据集的相似性(例如,使用逗号的自由文本),完全自动检测似乎没有单一的解决方案,特别是对于可变长度记录、单引号或双引号字段或多行记录等极端情况。
因此,最好的方法似乎是伸缩检测,其中在应用 CSV 检测规则之前检查也可以归类为 CSV 的格式(例如,像 Apache CLF 这样的日志文件格式)。
甚至像 Excel 这样的商业应用程序似乎也依赖文件扩展名 (.csv) 来决定 (1),这显然不是自动检测,尽管如果应用程序被告知数据是 CSV,问题就会大大简化。
以下是一些很好的相关文章,讨论了 (2) 和 (3) 的启发式方法:
(4) 的检测,即引号的类型,可以基于处理文件中的几行并查找相应的值(例如,每行偶数个 ' 或 " 表示单引号或双引号)。这样的处理可以通过初始化现有的 CSV 解析器(例如,OpenCSV)来完成,该解析器将妥善处理 CSV 行分隔(例如,多行事件)。
但是(1),即首先确定数据是 CSV 呢?
数据挖掘可以帮助做出这个决定吗?