Re^6: Comparison of the parsing features of CSV (and xSV) modules

What about the following:

abcd,"efgh,"ijkl,"mnop",qrst
[download]

Is that malformed or is that meant to be

abcd,"efgh,""ijkl,""mnop",qrst
[download]

The issue is that there are too many edge cases for a general-purpose parser to handle. I'm coming up with a bunch and I'm not even trying hard.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Comment on Re^6: Comparison of the parsing features of CSV (and xSV) modules Select or Download Code

Replies are listed 'Best First'.
Re^7: Comparison of the parsing features of CSV (and xSV) modules by Wally Hartshorn (Hermit) on Jun 16, 2004 at 19:37 UTC
Ah! Now I know what you're asking. Well, my point wasn't that CSV handlers need to be able to handle every possible bit of crud that is thrown at them. I was just saying that it would be useful if they would handle unescaped embedded delimiters -- perhaps not absolutely dirty data, but at least somewhat dusty data. :-) Wally Hartshorn	[reply]
Re^8: Comparison of the parsing features of CSV (and xSV) modules by dragonchild (Archbishop) on Jun 16, 2004 at 19:59 UTC
Heh. Define "dusty". We can tell, but we have to be able to define it to a teddybear in order to have a computer handle it correctly. :-) ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]