Text::xSV was written to address this issue.

1. What modules have you tried?
2. Where's the code that didn't work?

If you show us the code that didn't work, then perhaps we can show you how to fix it. :)

Updated sometime later:
Super Search is your friend. I found How do I parse a CSV that can contain newlines in fields?, Parsing CSV file ?s, and more! Try it some time, you might be surprised what it turns up.

I'm pretty sure that Tie::CSV gets this wrong, unfortunately - I've tried to use it in the past, and never had much success. However, Text::CSV has worked for me with this type of file (well, Text::CSV_XS, which should be the same thing ;)

The basic loop structure that I have is something like:

my $csv = Text::CSV_XS->new({'binary' => 1});
my $current_line;
while (<CVSFILE>) {
    $current_line .= $_;
    next unless ($csv->parse ($current));
    my @row = $csv->fields();
    $current = '';
    # do stuff with the rows...
}
[download]

This seemed to hold up against some really bizarre files (very _very_ big files, for example), so it looks pretty good. Strangely, I think Tie::CSV uses the Text::CSV module to read lines in, but I don't think it gets the loop right (like above). However, this might be my memory playing tricks.

I'm pretty sure that kal is right here, the key feature being the use of the "binary" option. One of the many silly things about CSV_XS is that you *always* want to use the "binary" option (this is reminiscent of FTP in the old days, before they got a clue and made "binary" the default). Pretty much all real text is "binary" from the point of view of CSV_XS (e.g. if you want to use any iso8859 extended characters).

But the last time I looked you definitely wanted to use "CSV_XS", not the older "CSV" module. They're really not the same.

Personally I would not trust that binary setting, it didn't work for me and I got corrupted data when using 8-bit (Japanese SJIS) data. Constrain/pack your data into the ascii range mentioned in one of the CSV module docs or sweat it.