in reply to Re^2: Successful CSV reader?
in thread Successful CSV reader?

There is actually one edge parsing case that Text::xSV handles differently than Text::CSV_XS where I think that Text::xSV's behaviour is more convenient. (There being no spec, it is impossible to say which is right.) In Text::xSV if you have ,, the embedded field is going to be undef, while if you have ,"", the embedded field is an empty string. (This distinction is drawn on writing as well.) Both of those come out as an empty string in Text::CSV_XS.

This behaviour was deliberately chosen to match how Microsoft tools export/import data. Access will turn ,, into a NULL and ,"", into an empty string, and will export them that way as well. Or at least that was how it worked when I last used Access. I don't think that you can draw this distinction in Text::CSV_XS.

Other than that, I believe that the two should have identical capabilities with default settings. But Text::CSV_XS has increased flexibility for changing how it handles parsing (eg changing quote character, delimiter, etc), and Text::xSV has increased flexibility for changing how you can access/manipulate data on the fly (aliases, computed fields).

Replies are listed 'Best First'.
Re^4: Successful CSV reader?
by jZed (Prior) on Apr 27, 2005 at 21:35 UTC
    There is actually one edge parsing case that Text::xSV handles differently than Text::CSV_XS where I think that Text::xSV's behaviour is more convenient.

    Aha, I missed that. and I agree, Text::xSV's is more convenient. I've added that to the chart.