nicht angemeldet
Ich zeigs Dir mal als Beispiel:
Ich stelle die Spalte(!) auf Latein 1 ein:
mysql> ALTER TABLE __testCHANGEwert wert TEXT CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL;
Query OK, 0 rows affected (0.00 sec)
Records: 0 Duplicates: 0 Warnings: 0
Ich füge Daten ein. Einmal mit Zeichen, die sowohl in UTF-8 als auch Latein 1 darstellbar sind:
mysql> insert into __test (wert) values ('Jörg');
Query OK, 1 row affected, 1 warning (0.01 sec)
Ich füge nochmals Daten ein. Diesmal mit Zeichen, die zwar in UTF-8 aber nicht in Latein 1 darstellbar sind:
mysql> insert into __test (wert) values ('добрый день');
Query OK, 1 row affected, 2 warnings (0.00 sec)
mysql> select * from __test;
+----+-------------+
| id | wert |
+----+-------------+
| 0 | Jörg |
| 0 | ?????? ???? |
+----+-------------+
2 rows in set (0.00 sec)
Die Konsole läuft mit UTF-8.
Das bedeutet für Dich: Geben die Betrachter der Webseite Zeichen ein, welche Latein 1 nicht darstellbar sind, so steht dann "Salat" in der Datenbank.
Ok. Ich ändere zu UTF-8:
mysql> ALTER TABLE __testCHANGEwert wert TEXT CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL;
Query OK, 0 rows affected (0.00 sec)
Records: 0 Duplicates: 0 Warnings: 0
Versuch der Ausgabe:
mysql> select * from __test;
+----+-------------+
| id | wert |
+----+-------------+
| 0 | Jörg |
| 0 | ?????? ???? |
+----+-------------+
2 rows in set (0.00 sec)
Das bedeutet für Dich: Der "Salat" in der Datenbank ist auch nicht zu reparieren, wenn Du nachträglich auf UTF-8 umstellst. Ansonsten macht MySQL das mit den deutschen Umlauten bei der Umstellung alles richtig, sonst gäbe es auch hier "Salat".
Erneutes insert mit denselben Daten, die zwar in UTF-8 aber nicht in Latein 1 darstellbar sind:
mysql> insert into __test (wert) values ('добрый день');
Query OK, 1 row affected, 1 warning (0.01 sec)
Ausgabe:
mysql> select * from __test;
+----+-----------------------+
| id | wert |
+----+-----------------------+
| 0 | Jörg |
| 0 | ?????? ???? |
| 0 | добрый день |
+----+-----------------------+
3 rows in set (0.00 sec)
So geht es also. Was bedeutet das für Dich? Wie jetzt mit den Daten, die zwar in UTF-8 aber nicht in Latein1 darstellbar sind umgegangen wird ist damit von der Anwendung abhängig und zwar davon, wie diese mit MySQL kommuniziert und wie diese diese Daten weiter verarbeiten.
Stellst Du also auf UTF-8 um, dann werden in den anderen Anwendungen wahrscheinlich künftig Fragezeichen oder nichts statt der kyrillischen Zeichen angezeigt.
Stellst Du nicht um passiert das selbe. Du siehst, die Wahl der Kodierung hat eine ziemlich zentrale Bedeutung. Die Entscheidung umzustellen oder nicht und künftige Daten in UTF-8-Kodierung einzutragen oder nicht können wir Dir nicht abnehmen. Es entsteht die Frage, ob es akzeptabel ist, wenn in den älteren Anwendungen für dort unbekannte Zeichen jeweils ein "?" oder nichts ausgegeben wird.
Eines noch.
Bei der Umstellung solltest Du bedenken, dass utf8_general_ci anders sortiert als das Telefonbuch:
Regeln für latin1_german1_ci (Wörterbuchsortierung, DIN 5007-1):
Ä = A
Ö = O
Ü = U
ß = s
Regeln für latin1_german2_ci (Telefonbuchsortierung, DIN 5007-2):
Ä = AE
Ö = OE
Ü = UE
Für die UTF-8-Sortierung wurde bislang nur DIN 5007-1 implementiert. Sie ist Teil von utf8_unicode_ci. Die Sortierung nach DIN 5007-2 kommt wohl frühestens mit MySQL 6.
Auch hier besteht also Klärungsbedarf.
Abschließender Rat:
SOWAS mit so weitreichenden Folgen planen und entscheiden in der Regel studierte Informatiker oder Großkopferte (mit Entscheidungsbefugnis) die sich für gleichwertig halten oder von anderen für dazu fähig gehalten werden. Wieso sollst Du (ich zitiere Dich) daran "herumbasteln"? Da es um eine Übergangslösung geht würde ich - wegen der Seiteneffekte hinsichtlich Dir nicht im Detail bekannter oder gar unbekannter Anwendungen - an der Datenbank nichts ändern bis jemand anders das anders entscheidet. Die Operation am wachen und sich bewegenden Patient fällt damit aus.
Gunnar Bittersmann