Empfohlene Datenbank-Kollation und Zeichensatz für mehrsprachige Websites

Was sind Zeichensätze und Kollationen in MySQL?

Wenn WordPress die Inhalte Ihrer Website in der Datenbank speichert (wie Beiträge, Titel, übersetzte Strings usw.), verwendet es einen Zeichensatz zur Darstellung der Zeichen und eine Kollation, um zu definieren, wie diese Zeichen verglichen und sortiert werden.

Zeichensatz (Charset)

Definiert, wie Zeichen in der Datenbank gespeichert werden – im Wesentlichen, welche Bytes für welche Zeichen stehen.

Kollation

Definiert die Regeln für den Vergleich dieser Zeichen (z. B. Groß-/Kleinschreibung, Akzentempfindlichkeit und Sortierreihenfolge).

Warum dies für mehrsprachige Websites wichtig ist

WPML unterstützt mehrsprachige Inhalte, die oft Folgendes umfassen:

• Sonderzeichen (z. B. ñ, é, ö)
• Nicht-lateinische Schriften (z. B. Arabisch, Japanisch, Chinesisch, Hebräisch)
• Emojis und Symbole (🎉, ✔️ usw.)

Viele davon benötigen mehr als 3 Bytes, um korrekt gespeichert zu werden. Wenn Ihre Datenbank eine inkompatible Kollation verwendet, können Zeichen verloren gehen, durch � ersetzt werden oder Datenbankfehler verursachen (z. B. „Incorrect string value“).

Deshalb empfehlen wir dringend, eine Kollation zu verwenden, die 4-Byte-Unicode-Zeichen unterstützt.

Was ist der Standard in MySQL?

MySQL-Version	Standard-Zeichensatz	Standard-Kollation	Unicode-kompatibel
< 5.5	latin1	latin1_swedish_ci	Nein
5.5.x	utf8	utf8_general_ci	Nein
5.7+	utf8mb4	utf8mb4_general_ci / utf8mb4_unicode_ci	Ja
8.0+	utf8mb4	utf8mb4_0900_ai_ci	Ja

WordPress folgt möglicherweise nicht immer dem Standard von MySQL – es kann diesen über die Konfiguration oder Migrationen überschreiben.

Zeichensatz und Kollation für neue Websites festlegen

Um sicherzustellen, dass WordPress neue Tabellen mit dem korrekten Zeichensatz und der korrekten Kollation erstellt, definieren Sie Folgendes in Ihrer wp-config.php:

define( 'DB_CHARSET', 'utf8mb4' ); // If you have utf8 that's fine, WP will automatically map it as utf8mb4
define( 'DB_COLLATE', 'utf8mb4_unicode_ci' );

Dies gilt für Neuinstallationen und neu erstellte Tabellen.

Zeichensatz und Kollation für bestehende Websites und Tabellen überprüfen

Hier erfahren Sie, wie Sie den Zeichensatz und die Kollation auf Ihren bestehenden Websites überprüfen.

Option 1 phpMyAdmin

1. Gehen Sie zur Datenbank Ihrer Website.
2. Überprüfen Sie die Spalte „Kollation“ neben jeder Tabelle.
3. Klicken Sie auf eine Tabelle, um die individuelle Kollation jeder Spalte anzuzeigen.

Option 2 WP-CLI

bash

wp db query "SELECT TABLE_NAME, TABLE_COLLATION FROM information_schema.tables WHERE table_schema = 'your_db_name';"

Sie können auch einzelne Spalten überprüfen:

bash

wp db query "SHOW FULL COLUMNS FROM wp_posts;"

Wenn Sie sehen, dass die Kollation mit utf8mb4_ beginnt, ist sie bereit, alle Arten von Unicode und 4-Byte-Ideogrammen zu unterstützen. Der Zeichensatz ist ebenfalls in Ordnung.

Wenn Sie etwas anderes sehen, zum Beispiel utf8_*, dann müssen Sie es ändern.

Bitte beachten Sie, dass die Kollation je nach Spalte unterschiedlich sein kann.

Zeichensatz und Kollation für bestehende Tabellen und Spalten aktualisieren

Das Aktualisieren der Konstanten DB_CHARSET und DB_COLLATE in Ihrer Datei wp-config.php wirkt sich nur auf neue Tabellen aus. Um Änderungen auf bestehende Tabellen und Spalten anzuwenden, müssen Sie diese manuell per SQL konvertieren.

Wir empfehlen außerdem, die Standard-MySQL-Kollation der Datenbank mit dem folgenden Befehl zu aktualisieren:

ALTER DATABASE your_database_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Beginnen Sie immer mit einem Backup

Bevor Sie Konvertierungsabfragen ausführen:

• Exportieren Sie Ihre Datenbank mit phpMyAdmin oder mysqldump
• Speichern Sie sie sicher für den Fall, dass etwas schiefgeht

Warnung: Kollations-Updates können im Strict-Modus fehlschlagen

Wenn Sie die Kollation einer gesamten Tabelle (oder Datenbank) aktualisieren, erstellt MySQL die Tabellen möglicherweise neu und validiert alle Spaltenstandards erneut – einschließlich nicht zusammenhängender wie DATETIME. Wenn Ihre Datenbank im Strict-SQL-Modus ausgeführt wird (STRICT_TRANS_TABLES, NO_ZERO_DATE), lösen Spalten mit Standardwerten wie „0000-00-00 00:00:00“ Fehler aus, wie zum Beispiel:

#1067 - Invalid default value.

Was ist der Strict-Modus?

Der Strict-Modus steuert, wie MySQL ungültige oder fehlende Werte behandelt, wenn Daten in die Datenbank eingefügt oder aktualisiert werden. Ein Wert kann aus mehreren Gründen ungültig sein. Zum Beispiel könnte er den falschen Datentyp für die Spalte haben oder außerhalb des zulässigen Bereichs liegen.

Informationen zu den verschiedenen Arten der Datenvalidierung für den Strict-Modus finden Sie in der MySQL-Dokumentation.

Wie sich der Strict-Modus auf eine WordPress-Website-Datenbank auswirkt

Standardmäßig verwendet WordPress „0000-00-00 00:00:00“ als Standard für einige datetime-Spalten, was vom Strict-Modus NO_ZERO_DATE nicht akzeptiert wird.

Beachten Sie, dass diese Standardwerte bei der ursprünglichen Tabellenerstellung (z. B. während der WordPress-Einrichtung) zulässig waren, aber bei ALTER-Operationen in Strict-Umgebungen fehlschlagen.

So überprüfen Sie, ob der Strict-Modus aktiviert ist

Führen Sie den folgenden Befehl aus:

SELECT @@SESSION.sql_mode, @@GLOBAL.sql_mode;

Suchen Sie nach:

• STRICT_TRANS_TABLES
• STRICT_ALL_TABLES
• NO_ZERO_DATE

Wenn Sie einen davon finden, ist der Strict-Modus aktiviert.

Um Fehler bei der Aktualisierung von Zeichensatz und Kollation zu vermeiden, müssen Sie nur den Strict-Modus NO_ZERO_DATE deaktivieren.

So gehen Sie sicher vor

Führen Sie einen der folgenden Schritte aus, um sicher vorzugehen:

1. Vermeiden Sie es, Spalten und Tabellen zu ändern, es sei denn, die Kollation muss tatsächlich geändert werden.

2. Deaktivieren Sie den Strict-Modus vorübergehend nur für die Sitzung, während Sie Konvertierungsabfragen ausführen. Dies können Sie mit dem folgenden Befehl tun:

SET SESSION sql_mode = REPLACE(@@sql_mode, 'NO_ZERO_DATE', '');

Hinweis: Es gibt zukünftige Pläne für MySQL, die Strict-Modi zusammenzuführen.

Im Falle anderer, für Ihre Daten spezifischer Probleme möchten Sie möglicherweise jeden Strict-Modus mit dem folgenden Befehl deaktivieren:

SET SESSION sql_mode = '';

Abfragen zum Konvertieren von Daten

Die gesamte Datenbank konvertieren

Das Folgende generiert eine ALTER TABLE-Abfrage für jede Tabelle in Ihrer Datenbank:

SELECT CONCAT(
  'ALTER TABLE `', TABLE_NAME, '` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;'
) AS query
  FROM INFORMATION_SCHEMA.TABLES
  WHERE TABLE_SCHEMA = 'your_database_name';

Führen Sie die resultierenden Abfragen in phpMyAdmin aus oder kopieren Sie sie in die MySQL CLI / WP-CLI.

Dies stellt sicher, dass alle Tabellen in Ihrer Datenbank den neuen Zeichensatz und die neue Kollation übernehmen.

Eine bestimmte Tabelle konvertieren Optional/Zusätzlich

ALTER TABLE wp_posts 
  CONVERT TO CHARACTER SET utf8mb4 
  COLLATE utf8mb4_unicode_ci;

Dies aktualisiert alle Textspalten in der Tabelle wp_posts, sodass sie utf8mb4 und die angegebene Kollation verwenden.

---

Eine bestimmte Spalte konvertieren Optional/Zusätzlich

ALTER TABLE wp_posts 
  CHANGE post_title post_title TEXT 
  CHARACTER SET utf8mb4 
  COLLATE utf8mb4_unicode_ci;

Häufige Fehler beim Konvertieren

Hier sind zwei häufige Fehler, auf die Sie beim Konvertieren von Tabellen und Spalten stoßen könnten.

Nicht übereinstimmender Zeichensatz und Kollation

-- INVALID: utf8 collation with utf8mb4 charset
ALTER TABLE wp_posts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8_general_ci;
-- Error: COLLATION 'utf8_general_ci' is not valid for CHARACTER SET 'utf8mb4'

Lösung:

• Verwenden Sie eine passende Kollation: utf8mb4_*

---

Limit für Indexschlüssellänge

ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes

In einigen Konfigurationen, insbesondere bei MySQL-Versionen unter 5.7, kann die maximale Indexschlüssellänge überschritten werden, wenn ein weiteres Byte pro Zeichen hinzugefügt wird.

Lösung:

• Kürzen Sie indiziertes VARCHAR(255) bei Bedarf auf VARCHAR(191)
• Oder führen Sie ein Upgrade auf MySQL ab 5.7 durch und stellen Sie sicher, dass innodb_large_prefix aktiviert ist