Once you have the string in that form, you get rid of the diacritic marks (leaving the letters in place) as follows:

s/\pM+//g;
[download]

Update: I forgot to mention -- even after taking care of the diacritic marks, be aware that you are likely to still have some non-ASCII characters left behind (i.e. things that don't involve an ASCII letter plus a diacritic mark, but are letter or punctuation that fall outside the ASCII range). You might need to tailor some ad-hoc replacements for those if you really need the data to be coherent in an ascii-only environment.

Simply removing mark characters won't always give you ASCII; for example Cyrillic, Greek and CJK won't result in Latin characters. If that's a problem, Text::Unidecode might be an interesting option for you.

use strict;
use warnings;
use utf8;
use charnames ();

#create replace table with charname
my ($str, %table);
$str='Vals På Vinkelgränd';

for (129 .. 255 ){ #iso-8859-1 128 to 255
    my $name=charnames::viacode($_);

    next if (! defined ($name));

    #in case "LATIN CAPITAL LETTER A WITH..." => maybe "A" is replace 
+letter?
    if ( $name =~ m/\w+\s+\w+\s+\w+\s(\w+)\s+/ ){
        $table{chr($_)} = $1;
    }
}

#replace
print "$str\n";
$str =~ s/(.)/exists($table{$1}) ? $table{$1}: $1/eg;
print "$str\n";

__DATA__
this prints 
Vals På Vinkelgränd
Vals PA VinkelgrAnd
[download]

update: I also tried graff's way with Unicode::Normalize. It worked like a charm.

#!/usr/bin/perl -l

use strict;
use warnings;
use utf8;
use Text::Unidecode;

binmode STDOUT, ":encoding(utf8)";
my $guess1 = unidecode("Vals P\403 Vinkelgr\403nd");
my $guess2 = print unidecode($guess1);
[download]

Dropbox most certainly does handle "international characters" in filenames - I've had things there with Russian filenames, for example. Not sure what encoding it was though. This was on OS X, so probably UTF-8.

Your filenames getting garbled is probably because you're expecting different encodings in different places. In my case because I *only* used OS X and iOS, it was the same encoding everywhere.

As for the case-insensitivity - this is probably deliberate so as not to terminally confuse clients using Windows or using case-insensitive versions of HFS+.

An alternative might be to use Punycode. This is an ASCII-compatible encoding for Unicode. It essentially strips out non-ASCII characters, and adds a bunch of base64-like crud to the end of the string.

perl -Mutf8::all -MEncode -MEncode::Punycode -E'say encode(Punycode =>
+ "It cost me €200!")'
[download]

It's not as pretty as the technique you suggest, but has the advantage of being completely reversible. (i.e. you can decode it and back the original string.)

Punycode happens to be the encoding used to store non-ASCII names in the DNS, and so it is best known for just encoding domain names. However it can in fact be applied to arbitrary Unicode strings.

Believe it or not ... this approach works:

use utf8;
$string =~ tr/åä/aa/s;
[download]

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Thanks everyone for all the great replies! Sorry for the long delay in responding; got a fresh newborn over here. :-)

I tried most of the methods suggested; graff's idea of using Unicode::Normalize and a s///g works well, but I eventually went with moritz's Text::Unidecode for simplicity: it does exactly what I want in one step. ++ to both you guys!

@DrHyde: You may very well be right about the encoding issues. I do have to transfer (occasionally) between Linux and Windows machines (although less and less Windows these days), so perhaps that was the source of the problem. I just decided it was easier to strip the accented characters for the filenames.

@jeffa: Sure, I knew I could use tr, but I was looking for something that wouldn't require me to anticipate every international character I might run across. So far, Text::Unidecode is working great for me.