在 clojure.data.csv/read-csv 中支持更多格式不正确的文件

Question

想象我们有一个以下的 CSV 文件

A,B,C
this is,"a badly" quoted, file

当我尝试用 clojure.data.csv/read-csv 解析这个文件时，我得到以下异常

{:type java.lang.Exception
 :message "CSV error (unexpected character:  )"
 :at [clojure.data.csv$read_quoted_cell invokeStatic "csv.clj" 37]}

这个文件显然格式不正确，但我已经在现实生活中见过这样的文件，所以如果 read-csv 能够像这样处理引用部分之后的额外内容将是非常好的。

["this is" "a badly quoted" " file"]    

---

这个建议的潜在问题

如果引用内有分隔符，这将变得难以解释。例如：

this is,"a, badly" quoted, file

可能被解析为

["this is" "a, badly quoted " " file"]

或

["this is" "\"a" " badly\" quoted " " file"]

虽然第二种解释对我来说似乎不太可能，但我不确定在这种情况下“最佳努力”的解析策略是什么。

Answer 1

我们不计划支持格式较差的 CSV 数据。支持格式良好的 CSV 数据就足够困难了。可能还有其他（Java）库可以处理或清理像这样的数据，但这超出了 data.csv 的范围。

Comments

值得一提的是：我在处理一个来自供应商Web应用的CSV文件时遇到了这个问题。起初，我对此有些沮丧，因为Clojure不能消费CSV，而Excel和Python似乎可以很好地处理它。但后来我发现，这些更宽容的消费器似乎省略了第一个未转义的引号。这可能会给我带来后续的问题。所以，及早发现问题可能从长远来看能节省我的时间。我已将关于破损CSV问题的报告反馈给了Web应用的供应商。唯一我认为Clojure可能有所不同的事情是，它应该提供更多关于在哪里检测到破损模式的信息。抱歉，也许我在阅读堆栈跟踪时错过了这一点。

---

我打算为至少报告错误发生的位置这一请求+1。查看Reader、FilterReader和PushbackReader的Java API层次结构，我看到这不是一项容易的任务。尽管如此，这应该属于data.csv的职责范围内 - 告诉读者破损发生在哪里 - 至少文件名、行号和列。意外字符在哪里？

这将大大节省我寻找一个工具来告诉我这些信息的时间，在那个时刻我发现错误是在一个引用字符串中的未转义引号，然后我不得不找到另一个工具来修复它。这个问题在我现在工作中遇到的数据集中非常普遍，它应该被认定为data.csv应该刮除或至少诊断的事情。

---

我已经记录了https://clojure.atlassian.net/browse/DCSV-22来跟踪这个问题

Answer 2

您可以通过指定不同的：引号字符来解析字段从未被引号的文件。然后，实际的引号标记就成为CSV读取时从字段中收集的字符串的一部分。我认为这种技术在制表符分隔的文件中比逗号分隔的文件中使用更频繁。一些生产奇特逗号分隔文件的制作者可以生成制表符分隔的文件，从形式上看，同样很奇特，但幸运的是没有包含实际制表符的原始值，因此它们在下游的各种处理中都表现得更好。