CSV files not strictly following the CSV specification, regarding embedded quotes inside a quoted field are to be doubled, easily trick the import into not distributing following content as the generator intended it to be. Implement some magic to detect and correct at least some of those cases to prevent data loss.
Related:
https://issues.apache.org/ooo/show_bug.cgi?id=78926
and attachments.
Another test case mentioned there, originally from
https://issues.apache.org/ooo/show_bug.cgi?id=80385
with attachments:
,"abc" d "ef",
currently results in
'abc d "ef"'
To not lose data it should result in
'abc" d "ef'
Doing so would also lead to
,"a"b, "a",
resulting in _one_ field
'a"b, "a'
and not two, 'ab' and ' "a"' like it is currently the case. This would then differ from how Excel treats it, but would be more consistent.

I was the author of some of the attachments to OOo bug shown here: https://issues.apache.org/ooo/show_bug.cgi?id=78926
I was able to confirm that the 3 test cases I presented were fixed, but the original bug report included a sample input that I still could not open. I'm not sure if the error message shown below is expected for that input.
Thanks for addressing the cases I found, though!
Confirmed fixed in LibreOffice 3.6.4.2 on Mac OS X:
- att #75189 @ OOo BZ
- att #75191 @ OOo BZ
- att #75192 @ OOo BZ
I still get an error loading the original "input" (att #46282 @ OOo BZ): "The data could not be loaded completely because the maximum number of characters per cell was exceeded".

(In reply to comment #4)
> I still get an error loading the original "input" (att #46282 @ OOo BZ):
> "The data could not be loaded completely because the maximum number of
> characters per cell was exceeded".
I don't get that error, tested in 3.6.4 and 4.0.0.rc2+ and master. All versions load 2371 rows without complaining, which matches the number of lines in the input file.