As others have pointed out, fiddling with the UTF-8 flag is a really bad idea.

However, you might have encountered problems in your code later because of a known gotcha between Perl and file systems. The hardware of your file system doesn't know about encodings, it only knows bytes. So someone has to encode non-ASCII-characters in file names, and here's a place where Perl itself trips over the UTF-8 flag.

In short: When you have a path name with the UTF-8-flag on, then Perl will silently encode the path name as UTF-8 before passing it to the file system (or, more precise, to the C library). This is particularly nasty for characters which can be expressed in Perl's default 1-Byte encoding, like e.g. "ä". Depending on the history of an "ä" in Perl code, it is stored either as one byte, with the UTF-8 flag off, or as two bytes, with the UTF-8 flag on. So from two characters which compare "equal" to Perl, Perl creates two different path names.

For substr and other Perl functions it is really, really best to leave the UTF-8 flag alone. The flag is "internal", which means its value is not documented nor guaranteed not to change with Perl versions.

For the details, let's start with a demo program:

use strict;
use warnings;
use File::Temp qw/tempdir/;
use Test::More tests => 14;
use Encode qw/decode/;

my $ae   = "\N{LATIN SMALL LETTER A WITH DIAERESIS}";

is (length $ae, 1,
    "The a with diaeresis is one character to Perl,");
ok (utf8::is_utf8($ae),
    "  ...and Perl knows it to be UTF-8 (UTF-8 flag on),");

my $ae2 = $ae;
ok(utf8::downgrade($ae2),
   "  ...and it can be downgraded");
ok(! utf8::is_utf8($ae2),
   "  ...so that is no longer stored as UTF-8 (UTF-8 flag off).");
is ($ae,$ae2,"UTF-8 encoded and downgraded versions are equal.");

note ("Now we are creating file(s), using the character as a filename.
+");
my $tempdir = tempdir( CLEANUP => 1 )
    or BAIL_OUT "No tempdir, demo terminated.";

for my $file ($ae,$ae2) {
    ok (open (my $out,'>',"$tempdir/$file"),
        "Opening two files with the same (?) name.")
        or BAIL_OUT "No file written, demo terminated.";
    close $out;
}

note ("Now reading the contents of the directory...");
opendir (my $dh,$tempdir);
my @files = sort { length $a <=> length $b }
            grep { /^[^.]/ } # exclude . and ..
            readdir $dh;

is (scalar @files, 2, "We apparently have created TWO files.");
is (length $files[0],1,"The first filename is one byte long,");
is (length $files[1],2,"The second filename is TWO bytes long.");

ok(! utf8::is_utf8($files[0]),
   "The first filename is stored as bytes (UTF-8 flag off).");
ok(! utf8::is_utf8($files[1]),
   "The second filename is ALSO stored as bytes (UTF-8 flag off).");

is ($files[0],$ae,"The first filename is what we provided.");
is (decode('UTF-8',$files[1],Encode::FB_CROAK),$ae,
    "The second filename needs to be decoded to match what we provided
+.");
note("There is silent encoding of path names, but no silent decoding!"
+);
[download]

Stuff like this makes me think at least twice whether I really need non-ASCII characters in a path name. It gets even messier if you have files which have been created under some old OS versions before UTF-8 was a quasi-standard.