2 ms·
I've saved myself a number of headaches by taking the opposite approach and being conservative in what I accept: I ignore the quoting rules. Comma or newline i
by sevensor 9y ago
I've saved myself a number of headaches by taking the opposite approach and being conservative in what I accept: I ignore the quoting rules. Comma or newline in the middle of your field? Malformed. Double-quote by itself in the middle of your field? Fine by me. Most of the weird stuff comes from Excel anyway, and I have a reader for Excel files that tolerates those things just fine. My users are happy with it because I've removed a source of ambiguity for them. My users are also highly technical, so I can get away with this sort of thing.
- burntsushi 9y agoThere's a certain amount of that in my CSV library as well, which is strongly influenced by Python's standard library `csv` behavior. Example: extern crate csv; fn main() { let mut rdr = csv::ReaderBuilder::new() .has_headers(false) .from_reader("abc,foo\"baz,xyz".as_bytes()); println!("{:?}", rdr.records().collect::<Result<Vec<_>, _>>().unwrap()); } Output: [StringRecord(["abc", "foo\"baz", "xyz"])] Python: >>> import csv >>> list(csv.reader(['abc,foo"baz,xyz'])) [['abc', 'foo"baz', 'xyz']] This is what's meant by "prefer a parse over returning an error." I would say that this is the liberal philosophy rather than conservative, though.