Filesystems in general don't know about encoding.

Unixish filesystems (and the APIs) usually expose the filename as a binary blob, which matches well with using UTF-8 encoded filenames.

Windows filesystems (and the APIs) usually expose the filename as Wide Characters, so if you get the filename as UTF-8, you need to translate it to Wide Characters and you also need to use the Wide APIs (CreateFileW etc) to access such files.

As a workaround to these issues, I am a fan of Text::Unidecode (and Text::CleanFragment) to downcase characters to ASCII.

Personally, I try to avoid non-ASCII characters in the functional parts of programs and instead use the named entities:

my $PathCorpusDB2 = "\N{LOWER CASE LATIN LETTER U WITH DIAERESIS}/data
+baseTest2.db";
[download]

This still won't solve your problem with Umlauts in the charset though. I think that using CreateFileW() with UTF-8 encoded filenames should work, but I don't know how to tell SQLite that.

I'm not convinced that the non-ascii character in your code is actually utf-8 (at least not as represented here on this site). Replacing this with its named character (slightly different from Corion's example) I get this test script which passes fine on Linux (having first run mkdir a ü of course). YMMV with other OSes.

#!/usr/bin/perl 
use utf8;
use strict;
use warnings;
use DBI;
use Test::More;

my @dbs = ('a/databaseTest1.db',
    "\N{LATIN SMALL LETTER U WITH DIAERESIS}/databaseTest2.db");
plan tests => 7 * @dbs;

for my $db (@dbs) { dbt ($db) }

exit;

sub dbt {
    my $dbname = shift;
    my $dbh = DBI->connect("dbi:SQLite:$dbname", "", "", { RaiseError 
+=> 1, AutoCommit => 1, PrintError => 1 });
    ok ($dbh, "Creating database $dbname");
    ok ($dbh->do( "CREATE TABLE data ( ID INTEGER PRIMARY KEY, text, f
+ilename)" ), "Created table data");
    ok ($dbh->disconnect, "Disconnected from $dbname");
    ok (-e $dbname, "Database file exists");

    $dbh = DBI->connect("dbi:SQLite:$dbname", "", "", { RaiseError => 
+1, AutoCommit => 1, PrintError => 1 });
    ok ($dbh, "Reconnected to database $dbname");
    my $AllDbText_ref = $dbh->selectall_arrayref("SELECT filename FROM
+ data");
    ok (defined $AllDbText_ref, "Results set obtained from $dbname");
    ok ($dbh->disconnect, "Disconnected from $dbname");
}
[download]

You'll see that I've moved the operations into a subroutine to show that there aren't any differences (and to shorten it). Here's the output:

$ perl sqlt.pl 
1..14
ok 1 - Creating database a/databaseTest1.db
ok 2 - Created table data
ok 3 - Disconnected from a/databaseTest1.db
ok 4 - Database file exists
ok 5 - Reconnected to database a/databaseTest1.db
ok 6 - Results set obtained from a/databaseTest1.db
ok 7 - Disconnected from a/databaseTest1.db
ok 8 - Creating database ü/databaseTest2.db
ok 9 - Created table data
ok 10 - Disconnected from ü/databaseTest2.db
ok 11 - Database file exists
ok 12 - Reconnected to database ü/databaseTest2.db
ok 13 - Results set obtained from ü/databaseTest2.db
ok 14 - Disconnected from ü/databaseTest2.db

HTH, Hippo

\test>perl test-unicode-sqlite.pl
1..14
ok 1 - Creating database a/databaseTest1.db
ok 2 - Created table data
ok 3 - Disconnected from a/databaseTest1.db
ok 4 - Database file exists
ok 5 - Reconnected to database a/databaseTest1.db
ok 6 - Results set obtained from a/databaseTest1.db
ok 7 - Disconnected from a/databaseTest1.db
ok 8 - Creating database ⁿ/databaseTest2.db
ok 9 - Created table data
ok 10 - Disconnected from ⁿ/databaseTest2.db
not ok 11 - Database file exists
#   Failed test 'Database file exists'
#   at test-unicode-sqlite.pl line 22.
ok 12 - Reconnected to database ⁿ/databaseTest2.db
ok 13 - Results set obtained from ⁿ/databaseTest2.db
ok 14 - Disconnected from ⁿ/databaseTest2.db
# Looks like you failed 1 test of 14.

test>dir  ü
 Volume in drive C is Win10
 Volume Serial Number is D27E-5B7F

 Directory of ...test\ü

11/08/2017  09:36 AM    <DIR>          .
11/08/2017  09:36 AM    <DIR>          ..
11/08/2017  09:36 AM             2,048 databaseTest2.db
               1 File(s)          2,048 bytes
               2 Dir(s)  813,772,779,520 bytes free
[download]

I'm not sure if you're trying to work with Windows and/or a non-Windows OS. You mention Windows in your first sentence, but your code appears to be more for Linux (based on the first line and the file paths used). The comments below would only apply to Windows.

I'm probably not going to be able to explain this fully and might not use the correct terminology. In Windows, there's an attempt to maintain backwards compatibility. As a result, the default filesystem API has some limits (such as no Unicode support and a max path length of about 260 characters). Most programs (including file explorer and the command prompt) use this API. And this is also the API used by most Perl modules.

There is a second filesystem API available that will allow for Unicode characters and a significantly larger max path length. The one Perl module that I've had success in dealing with longer path names is Win32::LongPath and it does support Unicode characters in paths.

I don't have experience using the DBI module, so I took a quick look to see if it will take a file handle instead a file path. Unless I missed it, I don't think that it does. I would suggest trying to take a look at the shortpathL function from the Win32::LongPath module. This function will attempt to return the "short path" (which I'm assuming is the path in DOS 8.3 format). You might have better luck using the "short path" of the file that has Unicode characters in its path.

See also discussion in Accent file names issue and Perl on Windows: file names with accented characters, UTF-8 and -e (link to the latter is thanks to jahero in Re: Accent file names issue as part of the second thread).