in reply to Re (tilly) 1: parsing CSV file with embedded commas (fortunately, fixed-width) - is unpack the solution?
in thread parsing CSV file with embedded commas (fortunately, fixed-width) - is unpack the solution?

Note that Text::xSV can't handle (quite reasonably) the unescaped embedded quote characters inside of quoted fields that amelinda's data appear to have.

        - tye (but my friends call me "Tye")
  • Comment on (tye)Re3: parsing CSV file with embedded commas (fortunately, fixed-width) - is unpack the solution?

Replies are listed 'Best First'.
Re (tilly) 3: parsing CSV file with embedded commas (fortunately, fixed-width) - is unpack the solution?
by tilly (Archbishop) on Nov 01, 2001 at 08:23 UTC
    It could be made to though. That could even be made configurable, though I would prefer it to default to not for the simple reason that I don't like it.

    A bigger problem is that I only consider " a quote character. I will need to check whether ' also qualifies for Microsoft products. If it does I should make it handle that as well. (They never bother writing it, so I didn't either.) If not, then I could make that configurable as well...

      You seem to be assuming that the unescaped quote will never be followed by a comma (or white space and then a comma, or perhaps a newline). Actually, amelinda's use of the word "other" makes me suspect that this assumption is likely true in this particular case. (:

      But I felt it important that readers not get the wrong impression about how well such "not really CSV" data can ever be handled in general. You have to draw the line somewhere. As I said, I find it quite reasonable to draw the line at "your embedded quotes must be escaped". But if you cross that line, there still has to be another line such as "your unescaped embedded quotes must not be followed by...".

      To be honest, I never seriously considered such an option. And then when you mentioned it, the phrase "that way lies madness" (in an appropriately Halloween voice) came to mind. Then I switched to, "well, that would be fairly easy to add." Then I thought about exactly how to do it and recalled how many times I've seen brilliant people that were regex experts get the "match C-style comments" regex wrong and started to have doubts again.

      Perhaps trying something like /'([^']|'(?! *[,\n]))*'/ to match single-quoted fields would work. But I think I'd probably backtrack at this point and say that adding support for that has too high of a risk of introducing bugs. Perhaps making it optional could aleviate that risk when the option isn't selected. Perhaps you have more confidence in your ability to solve that problem correctly than I do in mine. :)

              - tye (but my friends call me "Tye")
        Have Ye No Faith????

        Well, possibly appropriately. :-)

        Anyways the "grab a token" type logic I am using is easy enough to modify to handle all of these options, even as configurable options. Certainly handling this is no harder than figuring out when to read another line from the file.

        The only problem is trying to keep sanity amongst the ever exploding list of file formats which are almost, but not quite, CSV and none of which are quite each other. That interface problem is what gives me doubts. Actually processing them is not a problem.