Wenn du UTF-8-Daten hast, dann musst du erst einmal feststellen, in welcher Form du sie enthalten hast. Falls Perl bereits mitbekommen hat, dass es sich um UTF-8 handelt, sind die Daten entsprechend markiert. Ein Aufruf von length("umlaut-a") wuerde dann "1" ergeben, da es sich um ein Zeichen handelt. Hat Perl nicht mitbekommen, dass es sich um UTF-8 handelt, wuerde der Aufruf von length("umlaut-a") "2" ergeben, da ein "ae" in utf-8 mit zwei Bytes kodiert ist.

Eine andere Moeglichkeit herauszufinden, wie Daten intern kodiert sind, ist Devel::Peek::Dump oder Encode::is_utf8.

Alle Perl-Funktionen koennen mit utf-8 perfekt umgehen. Problematisch wird es erst, wenn mit der Aussenwelt kommuniziert wird, also bei I/O oder XS-Modulen. Bei ersterem muss man angeben, wie man die Daten aus/eingegeben haben moechte (siehe binmode oder "use open"), beim zweiteren liegt es am Autor, ob eine explizite UTF-8-Unterstuetzung eingebaut wurde.

Ob es bei DBI oder DBD::mysql UTF-8-Unterstuetzung gibt, weiss ich nicht. Deshalb ist es wahrscheinlich am sichersten, wenn man zusichert, dass immer die Byte- oder Octet-Semantik verwendet wird (also im length-Beispiel oben "2" ausgegeben wird). Das kann man machen, indem man Encode::encode("utf-8", $utf8_string) oder Encode::_utf8_off($utf8_string) verwendet.

Das Problem bei der Datenbank ist, dass zwar exakte Vergleiche weiterhin funktionieren, aber das Sortieren oder Groesser/Kleiner-Vergleichen nicht mehr richtig funktioniert, da Umlaute jetzt falsch sortiert werden. Wenn das ein Problem ist, musst du wahrscheinlich auf mysql 4.1.x umsteigen (ich glaube, diese Version ist noch Beta) und beim Anlegen der Tabelle sowas wie
[sql] CREATE TABLE Table1
(
column1 VARCHAR(5) CHARACTER SET utf8 COLLATE utf8_german
);
[/sql]
verwenden.