Sie haben eine Datenbank in phpMyAdmin erstellt, WordPress installiert und bemerken eine Woche später verstümmelten Text statt lesbarer Zeichen in Ihren Tabellen. Sie öffnen die Einstellungen und sehen latin1_swedish_ci. Jeder, der mit Laragon unter Windows arbeitet, stößt früher oder später auf diese Überraschung.

Das Problem: Der MySQL-Build, den Laragon standardmäßig installiert, erbt eine veraltete Voreinstellung: latin1 als Zeichensatz und latin1_swedish_ci als Kollation. Für Russisch ist das eine Katastrophe: Kyrillische Zeichen werden als Fragezeichen oder Datenmüll geschrieben, die Zeichenkettensortierung funktioniert nicht und Plugins stürzen mit Fehlern ab.

Nachfolgend beschrieben sind zwei Änderungen in einer Datei, die dieses Problem dauerhaft lösen. Der Vorgang dauert drei Minuten. Funktioniert mit Laragon 6, 5 und selbst mit der alten Version 4.

💡 Kurzüberblick:

• Öffnen Sie my.ini über das Laragon-Menü und fügen Sie zwei Zeilen im Abschnitt [mysqld] hinzu
• Wählen Sie utf8mb4_unicode_ci als optimale Option für WordPress im Jahr 2026 (und wir erklären, warum)
• Speichern Sie die Datei, starten Sie MySQL neu und überprüfen Sie das Ergebnis in phpMyAdmin
• Bonus: So ändern Sie die Kodierung einer bestehenden Datenbank ohne Datenverlust

Warum die Standardkodierung überhaupt wichtig ist

MySQL arbeitet mit einem mehrstufigen Vererbungssystem: Server → Datenbank → Tabelle → Spalte. Wenn auf Serverebene latin1_swedish_ci eingestellt ist, erbt jede neue Datenbank diese Einstellung, sofern bei der Erstellung nichts anderes angegeben wird.

Für WordPress ist das kritisch, denn:

• Der Core, Themes und die meisten Plugins speichern Inhalte in utf8mb4
• Beim automatischen Anlegen einer Datenbank über wp-config.php überschreibt WordPress die Servervoreinstellung NICHT
• Nicht übereinstimmende Kodierungen zwischen Server und Tabellen erzeugen „unklare" Fehler: ??? im Admin-Panel, defekte Zeichen in der JSON-REST-API, Abstürze beim Export

Laut W3Techs-Daten betreibt WordPress 43,5% aller Websites im Internet, und das CMS selbst setzt seit Version 4.2 utf8mb4 für vollständige Emoji-Unterstützung voraus. Laragon ist einer der beliebtesten lokalen Server für Windows, doch sein MySQL-Build wird aus Gründen der Abwärtskompatibilität mit einer konservativen Voreinstellung ausgeliefert. Daher der Konflikt.

Schritt 1: my.ini über das Laragon-Menü öffnen

Der einfachste Weg zur MySQL-Konfigurationsdatei führt über das integrierte Menü von Laragon:

• Klicken Sie mit der rechten Maustaste auf das Laragon-Symbol in der Taskleiste
• Wählen Sie Menü → MySQL → my.ini

Der Editor (oder Ihr Standardeditor) öffnet die vollständige MySQL-Konfiguration. Die Datei ist in Abschnitte in eckigen Klammern unterteilt: [client], [mysqld] und [mysqldump]. Uns interessiert [mysqld] (der Abschnitt mit den Einstellungen des MySQL-Daemons).

Falls das Menü die Datei aus irgendeinem Grund nicht öffnet, finden Sie sie manuell unter: C:\laragon\bin\mysql\<version>\my.ini. Bei Laragon-6-Builds kann der Pfad je nach installierter Version C:\laragon\bin\mysql\mysql-8.0.30-winx64\my.ini lauten.

Schritt 2: Zwei Zeilen im Abschnitt [mysqld] hinzufügen

Scrollen Sie zum Abschnitt [mysqld] und fügen Sie die folgenden zwei Zeilen am Ende ein (vor dem nächsten Abschnitt, falls vorhanden):

1
character_set_server = utf8mb4
2
collation_server = utf8mb4_unicode_ci

Was hier passiert:

• character_set_server = utf8mb4 weist den Server an, standardmäßig die Kodierung UTF-8 Multilingual Version 4 zu verwenden, die ALLE Unicode-Zeichen unterstützt, einschließlich Emoji, Kyrillisch und Hieroglyphen
• collation_server = utf8mb4_unicode_ci legt die Regel für den Zeichenkettenvergleich fest: _unicode_ bedeutet „gemäß Unicode-Standard", _ci bedeutet Vergleich ohne Berücksichtigung von Groß-/Kleinschreibung

Sie müssen diese Zeilen spezifisch zu [mysqld] hinzufügen, nicht zu [client] oder [mysqldump]. Der falsche Abschnitt ist der häufigste Grund dafür, dass sich „nichts geändert hat".

Der vollständige Abschnitt sollte nach der Bearbeitung in etwa so aussehen:

1
[mysqld]
2
port=3306
3
socket=/tmp/mysql.sock
4
key_buffer_size=256M
5
max_allowed_packet=512M
6
character_set_server = utf8mb4
7
collation_server = utf8mb4_unicode_ci

Schritt 3: Datei speichern und MySQL neu starten

Speichern Sie my.ini (Strg+S) und starten Sie MySQL neu. In Laragon erledigen Sie das über dasselbe Menü:

• Klicken Sie mit der rechten Maustaste auf das Laragon-Symbol in der Taskleiste
• Menü → MySQL → Stop
• Warten Sie 3-5 Sekunden
• Menü → MySQL → Start

Alternativ klicken Sie auf Menü → Neustart, und Laragon beendet und startet alle Dienste auf einmal.

Nach dem Neustart werden neue Datenbanken standardmäßig mit utf8mb4_unicode_ci erstellt. Bestehende Datenbanken werden NICHT automatisch geändert. Lesen Sie den Abschnitt „Häufig gestellte Fragen" weiter unten, um zu erfahren, wie Sie eine bestehende Datenbank konvertieren.

Schritt 4: Ergebnis in phpMyAdmin überprüfen

Öffnen Sie phpMyAdmin über das Laragon-Menü (Menü → MySQL → phpMyAdmin) und erstellen Sie eine Testdatenbank:

• Klicken Sie auf „Datenbank erstellen"
• Geben Sie einen beliebigen Namen ein
• Sehen Sie sich das Dropdown „Kollation" an: Es sollte jetzt standardmäßig utf8mb4_unicode_ci anzeigen

Zeigt das Dropdown weiterhin latin1_swedish_ci an, überprüfen Sie, ob die Zeilen character_set_server und collation_server zum Abschnitt [mysqld] (nicht [client]) hinzugefügt wurden und dass keine überflüssigen Leerzeichen zwischen dem Parameternamen und dem =-Zeichen stehen.

Schnellüberprüfung per SQL-Abfrage (in phpMyAdmin auf der Registerkarte SQL ausführen):

1
SHOW VARIABLES LIKE 'character_set_server';
2
SHOW VARIABLES LIKE 'collation_server';

Beide Variablen sollten utf8mb4 bzw. utf8mb4_unicode_ci zurückgeben.

Welche Kodierung wählen: Vergleich der Optionen

Um die MySQL-Kodierung ranken sich viele Mythen, daher hier eine Aufschlüsselung von drei aktuellen und einer veralteten Option:

Warum wir utf8mb4_unicode_ci für die lokale Entwicklung in Laragon empfehlen:

• Laragon wird mit verschiedenen MySQL-Versionen ausgeliefert (von 5.7 bis 8.0+), und utf8mb4_0900_ai_ci erschien erst in MySQL 8.0 und fehlt in MariaDB, das oft in alternativen Builds enthalten ist
• utf8mb4_unicode_ci funktioniert überall ab MySQL 5.5.3 (2010)
• Der Unterschied in der Sortierqualität zwischen unicode_ci und 0900_ai_ci ist für eine typische WordPress-Site vernachlässigbar
• Shared-Hosting-Angebote nutzen oft MySQL 5.7. Wenn Sie lokal mit 0900_ai_ci entwickeln, diese aber in der Produktion fehlt, erhalten Sie bei der Migration einen Fehler

Wenn Sie sicher wissen, dass Ihr Produktionsserver mit MySQL 8.0+ läuft und Ihr lokales Laragon MySQL 8.0 verwendet, nehmen Sie utf8mb4_0900_ai_ci. Dies ist der moderne, von Oracle empfohlene Standard mit besserer Unterstützung für mehrsprachige Sortierung.

Was ist mit utf8_general_ci? Diese Kollation war vor etwa zehn Jahren relevant, als utf8mb4 noch nicht flächendeckend unterstützt wurde. Heute hat sie zwei fatale Schwächen: Sie kann keine Emoji speichern (WordPress nutzt diese aktiv im Admin-Panel) und sie sortiert erweiterte Zeichen falsch. Es gibt keinen Grund, sie 2026 noch zu verwenden.

Video: So ändern Sie die MySQL-Datenbankkodierung über phpMyAdmin

Textanleitungen sind gut, aber manchmal ist es einfacher, es einmal zu sehen. Dieses 4-minütige Video zeigt den vollständigen Prozess der Kodierungsänderung einer bestehenden Datenbank über die phpMyAdmin-Oberfläche, von der Tabellenauswahl bis zur abschließenden Überprüfung:

⁉️🤔 Häufig gestellte Fragen

Ich habe bereits eine Datenbank mit latin1_swedish_ci. Wie ändere ich deren Kodierung?

Der sicherste Weg führt über phpMyAdmin. Wählen Sie links die Datenbank aus, gehen Sie zur Registerkarte „Operationen", wählen Sie im Block „Kollation" utf8mb4_unicode_ci und klicken Sie auf „OK". phpMyAdmin generiert ALTER-Abfragen für jede Tabelle. Erstellen Sie vor diesem Vorgang unbedingt ein Backup: Registerkarte „Exportieren" → SQL-Format → „OK".

Ich habe my.ini geändert, MySQL neu gestartet, aber phpMyAdmin zeigt immer noch latin1_swedish_ci. Was ist falsch?

Die drei häufigsten Ursachen: (1) Die Zeilen wurden zu [client] anstatt zu [mysqld] hinzugefügt. Prüfen Sie, unter welchem Abschnitt in eckigen Klammern sie stehen. (2) MySQL wurde nicht neu gestartet. Öffnen Sie den Windows-Task-Manager und stellen Sie sicher, dass der Prozess mysqld.exe verschwunden und wieder erschienen ist. (3) Es gibt mehrere [mysqld]-Abschnitte in my.ini. Das passiert manchmal nach mehreren Laragon-Updates. Behalten Sie nur einen.

Was ist besser für WordPress: utf8mb4_unicode_ci oder utf8mb4_general_ci?

Für WordPress ist der Unterschied minimal. utf8mb4_unicode_ci sortiert mehrsprachige Inhalte genauer (z. B. deutsches „ß" = „ss"), während utf8mb4_general_ci bei großen Datenmengen etwas schneller ist, der Unterschied liegt jedoch im Millisekundenbereich. Wählen Sie unicode_ci und machen Sie sich keine weiteren Gedanken.

Kann ich die Kodierung einfach in wp-config.php angeben?

define('DB_CHARSET', 'utf8mb4') und define('DB_COLLATE', 'utf8mb4_unicode_ci') in wp-config.php betreffen NUR die Tabellen, die WordPress selbst bei der Installation erstellt. Die Servervoreinstellung bleibt unverändert, und jede manuell über phpMyAdmin erstellte Datenbank erhält latin1_swedish_ci. Deshalb ist die Bearbeitung von my.ini weiterhin notwendig.

Nach der Kodierungsänderung wurden einige Texte auf der Site zu Fragezeichen. Ist das umkehrbar?

Ja, aber Sie müssen vorsichtig vorgehen. Fragezeichen erscheinen, wenn Daten in latin1 geschrieben, aber als utf8 gelesen werden. Die Lösung: Exportieren Sie die Datenbank mit dem Flag --default-character-set=latin1 und importieren Sie sie dann mit --default-character-set=utf8mb4. Der genaue Befehl hängt von Ihrer MySQL-Version ab, konsultieren Sie daher die offizielle Dokumentation.

Zusammenfassung: Was Sie jetzt in my.ini einfügen sollten

Wenn Sie Laragon für die lokale WordPress-Entwicklung nutzen, lösen die folgenden zwei Zeilen das Kodierungsproblem ein für alle Mal:

1
character_set_server = utf8mb4
2
collation_server = utf8mb4_unicode_ci

Diese Option funktioniert mit jeder MySQL-Version von 5.5 bis 8.4 und mit allen aktuellen MariaDB-Builds. Sie speichert Kyrillisch und Emoji korrekt und verursacht keine Überraschungen bei der Migration der Datenbank von lokal zu Produktion, unabhängig davon, welches Hosting auf Ihrem Produktionsserver läuft.

Haben Sie Fragen zu einer bestimmten Laragon-Version oder einer nicht standardmäßigen Konfiguration? Sehen Sie sich den Thread im Laragon-Forum an, in dem Entwickler Nuancen der Kodierungskonfiguration diskutieren, einschließlich Docker-Builds und benutzerdefinierter Ports. Und wenn dieser Artikel Ihnen einen Abend erspart hat, teilen Sie ihn mit Kollegen, die ebenfalls mit latin1_swedish_ci kämpfen.