Re^4: Multiple double quotes within csv

I tested this and verified that:
my $csv = Text::CSV_XS->new({allow_loose_escapes => 1,});
parses the OP's example correctly with my code using Text::CSV_XS.

Input Line:
8,""Rat Control" <sip:+15559999999@192.168 .5.233>;tag=gK004bb052",9
Output Line:
8|"Rat Control" <sip:+15559999999@192.168 .5.233>;tag=gK004bb052|9
[download]

Apparently although the OP's CSV line is technically incorrect according to the CSV spec, some smart folks who wrote Text::CSV anticipated this and have an option for it.

Thank you Tux!

As a comment: I always use the pipe, | character when I generate "CSV" files.
Using a different character than "comma" is allowed by the spec. What is shown as the "output" line above, would be my "input" line with no need to use a complex module to parse things (in most, but not all cases). Of course we have to deal with what we get from others.. such is the nature of the beast.

Comment on Re^4: Multiple double quotes within csv Select or Download Code

Replies are listed 'Best First'.
Re^5: Multiple double quotes within csv by mhooper (Novice) on May 13, 2017 at 12:02 UTC
Thank you to all responders. As noted, we have to deal with data we are given. All help is much appreciated and with a couple changes it appears that parsing of all data is successful. Again, thanx.	[reply]
Re^5: Multiple double quotes within csv by Anonymous Monk on May 13, 2017 at 14:22 UTC
Your line 4 from your experiment set however still cannot be parsed, it throws the error `2027 "EIQ - Quoted field not terminated"`.	[reply] [d/l]
Re^6: Multiple double quotes within csv by Marshall (Canon) on May 15, 2017 at 18:05 UTC
Yes. That was an extra test case that I threw in while probing the limits of the parser - what's allowed and not allowed. This case is: instead of quoting the entire field, only part of it is quoted, e.g., a part at the beginning. I have no idea of whether such a construct is technically allowed or not according to the CSV specification. My experiment simply says that this parser doesn't like it. The OP isn't having trouble with this syntax and I haven't investigated further. I have never seen CSV generated like that before. Actually there are a whole bunch of other test cases with weird syntax that I cycled through which I didn't post. When writing test cases, I usually put more cases in than just the "good machine" case because I want to verify the limits. "Bad machine" cases are also of interest if for nothing else than to verify that error handling works and doesn't "blow the whole thing up". For test case 4, I make no claim that it should or should not be parsed according the CSV spec (left for interested readers). All I can say is, "don't do that with this parser".	[reply]