questions about character encoding

[moof1138]

I am running a script on Mac OS X that uses DBI to connect to FrontBase. The DBD:FB module seems to be returning everything in Unicode. Things mostly work except for when I am dealing with diacritics being passed to unicode unaware programs, at which point é is morphed into √©, ä is turned into √§ and so on. I made a sub that did this:

 
sub sanitize  {
    my $string = shift;
    $string =~ s/[àáâãäå]/a/;
    $string =~ s/[ÀÁÂÃÄÅ]/A/;
    $string =~ s/ç/c/i;
    $string =~ s/[èéêë]/e/;
    $string =~ s/[ÈÉÊË]/E/;
    $string =~ s/[ìíîï]/i/;
    $string =~ s/[ÌÍÎÏ]/I/;
    $string =~ s/ñ/n/;
    $string =~ s/Ñ/N/;
    $string =~ s/[òóôõöø]/o/;
    $string =~ s/[ùúûü]/u/;
    $string =~ s/[ÙÚÛÜ]/U/;

    return($string);
}

but it does not work. None of the characters are converted, though if I use the sub on non-unicode text it works fine. I am sure the sub could be simplified, but right now I am just trying to get it to work at all.
I tried 'use UTF-8' thinking it might be needed, but then it gives this error "Malformed UTF-8 character at line xx" for each line of the regex, and again it does work on non-unicode, but does not work on unicode encoded text.

For now I know where the particular pieces of data that are problems are and I just match them with .*, and fix things, but I really want to have a more generic way of fixing this. I didn't see anything in the perlunicode perldoc that seemed to help other than "WARNING: The implementation of Unicode support in Perl is incomplete," which makes me think maybe it either imperfect Unicode support or Mac OS X flakiness, and not just me missing something. But the docs do say

"The existing regular expression compiler does not pro- duce polymorphic opcodes. This means that the deter- mination on whether to match Unicode characters is made when the pattern is compiled, based on whether the pattern contains Unicode characters, and not when the matching happens at run time."

I do not know how to interpret that and I would be very interested to hear what it means in terms of what I am trying to do. Also I wanted to ask the many knowledgeable folks here if anyone knew of a way to strip out diacritics in unicode, strip them in general (since my sub seems like it must be a re-invention but I could not find anything like it) or if perhaps I was missing something somewhere else that was relevant to my problem of flattening out diacritics.

[mirod]

The problem is that when you write $string =~ s/[àáâãäå]/a/; the accented characters are in Mac encoding, not in UTF-8.So they never match in the string.

You should be able to fix this problem using Unicode::Map8 or maybe, I am not (yet!) familiar with it, Encode, which will be part of the core in 5.8.0.

--
The Error Message is GOD - MJD

[moof1138]

Cool, many thanks. Unicode::Map8 looks like it is just what I am looking for to get everything in the same character encoding.

[BorgCopyeditor]

Maybe this will help. Those accented characters you're using are probably iso-8859-1, more or less an extension of ASCII to 8 bits. So, é, for example, is 234. UTF-8 is another encoding altogether that uses multiple bytes to encode character sets from many different writing systems (as you probably know).

Here's where the problem is (and what the error message was telling you). Under UTF-8, 7-bit ASCII characters retain their old mappings. But in order to encode multi-byte characters, UTF-8 uses the high bits. In order to encode a character that is two bytes long, the first byte's high bit is set to one, the second to zero. And so forth for characters that take up more bytes. If you take a string of Latin-A characters (I think they're called), their high bits won't match the carefully thought-out system of UTF-8 encoding, and make a mess of it. The string éêë, for example, has three high bits set to one in a row...

...which is what "malformed UTF-8 character" means.

Update: that should have read "Latin 1," not "Latin A." Also, here's where I learned the little I know about Unicode.

BCE
--Your punctuation skills are insufficient!