bluescreen's suggestion is a good one if your CSV is otherwise uncomplicated - i.e. no quoted fields.

But for complicated CSV, you really do want to use something like Text::CSV. It is a shame that, even setting Text::CSV's eol option, it can't handle this situation.

Best solution would probably be to pre-process each line, replacing the bare "\n" with another character, parse it with Text::CSV, and then replace it back again. Something like:

use Data::Dumper;
use IO::Scalar;
use Text::CSV;

my $data = "Alice,123\r\n"
    .    "Bob\nSmith,456\r\n";
my $io = IO::Scalar->new(\$data);

$/ = "\r\n";
my $CSV = Text::CSV->new({
    eol      => $/,
    sep_char => q{,},
    binary   => 1,
    });

while (defined(my $line = <$io>))
{
    $line =~ s/\n(.)/\xFF$1/g;
    $CSV->parse($line);
    my @row = map { s/\xFF/\n/g; $_ } $CSV->fields;
    print Dumper(\@row);
}
[download]

You have to change the record separator to "\r\n"

use strict;
use warnings;
use 5.010;

my $text = "field\n1,field2,field3\r\nfield4,field\n5,field6\n\r\n";
open my $fh, '<', \$text;
local $/ = "\r\n";

while (<$fh>) {
    chomp;
    my ( $col1, $col2, $col3 ) = split ',';
    say "|$col1 $col2 $col3|";
}
[download]

Of course when you print it you'll see the new lines, if you don't want that either you can replace them.

Not that I am aware off. You're trapped.

If you know in advance how many fields each line should have, you could create your own parser based on this example.

DBD::CSV has always worked best for me with CSVs and lets me suck it all into an HoH, but not sure it would work with a file like the one you're describing, albeit what you're describing doesn't sound like a CSV in the conventional sense...

This is one of those problems I wish I had an easy answer for as well. I've run into it a number of times while doing data imports for one of my clients.