Das Thema sagt alles. Hat da schon wer Erfahrung?

Was auf jeden Fall gehen sollte, ist die Verwendung von Octets statt Characters. Die Encode-Manpage sagt mehr dazu. Neuere MySQL-Versionen koennen wohl auch intern mit utf-8 umgehen, aber ob DBD::mysql das auch unterstuetzt, weiss ich nicht.

Octets heißt doch nur, daß ich Binärdaten speichern würde, oder?

Ich habe gestern mit encode und decode (Encode) probiert und auch
binmode STDOUT, 'encoding(cp850)';
hat erfolgreich funktioniert, wenn ich unter Windows auf die Console schreibe.

Ich habe bei MySQL gelesen, daß das gehen soll, aber wie, das habe ich nicht gefunden.

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.

Danke für die umfangreiche Einführung in UTF-8. Ich werde eine Weile brauchen, um alles auszutesten.

Auf der MySQL-Homepage hatte ich mit den Suchworten qw/CHARACTER SET utf8 COLLATE utf8_german/ keine Ergebnisse.

Konkret geht es mir um die Sprachen ungarisch und dänisch. Dazu habe ich jedoch folgende Links gefunden:
http://www.uni-koeln.de/themen/fremdsprachig/
http://www.uni-koeln.de/themen/fremdsprachig/ungarisch.html
http://www.uni-koeln.de/themen/fremdsprachig/danisch.html\n\n

<!--EDIT|steffenw|1084437141-->

[quote=steffenw,13.May.2004, 10:31]Danke für die umfangreiche Einführung in UTF-8. Ich werde eine Weile brauchen, um alles auszutesten.

Auf der MySQL-Homepage hatte ich mit den Suchworten qw/CHARACTER SET utf8 COLLATE utf8_german/ keine Ergebnisse.

Konkret geht es mir um die Sprachen ungarisch und dänisch. Dazu habe ich jedoch folgende Links gefunden:
http://www.uni-koeln.de/themen/fremdsprachig/
http://www.uni-koeln.de/themen/fremdsprachig/ungarisch.html
http://www.uni-koeln.de/themen/fremdsprachig/danisch.html[/quote]
"utf8_german" ist meine eigene Erfindung, den Rest habe ich aus der MySQL-Info-Datei. Wenn ich es recht uebersehe, kann man MySQL mit eigenen Collating (entsprechend Sprache und Characterset) kompilieren.

Da habe ich doch heute einfach Text mit Umlauten in der MySQL-Datenbank in einem Textfeld gespeichert und später diese zum Browser geschickt. Komische Zeichen, habe dann UTF-8 als Zeichensatz im HTML-Dokument angegeben und siehe da, die Umlaute waren wieder da. Ich habe da wirklich nichts umgewandelt, einfach so.

Wie ich das utf8-Flag setze, weiß ich nun auch:
\n\n

<!--EDIT|steffenw|1084827247-->