Hallo

Ich habe mich mal wieder mit dem Thema beschäftigt.

Ganz so einfach scheint das nicht zu sein.

Die Tests haben bisher folgendes ergeben:

- Änderung der Spaltenkodierung für die Felder mlf2_entries und mlf2_entries_cache: erfolglos
- Änderung der Tabellenkodierung und -kollation gemäß dieses StackOverflow-Threads (nur auf Tabellen- statt Datenbankebene): erfolglos

Soweit ich mir mittlerweile angelesen habe, muss folgende Kette stehen.

- Kodierung der Datenbank: utf8mb4, Kollation: utf8mb4_unicode_ci
- Kodierung der Tabellen: utf8mb4, Kollation: utf8mb4_unicode_ci
- Kodierung der (gewünschten) Felder: utf8mb4 oder utf8mb4_bin, Kollation: utf8mb4_unicode_ci, utf8mb4_generaql_ci oder utf8mb4_bin (je nach Anwendungsfall)

Hintendran die schon erwähnte Einstellung für die Verbindung selbst.

Wie in dem verlinkten StackOverflow-Thread in mehreren Einlassungen zu lesen ist, muss auch die Datenbankverbindung mit der Kodierung utf8mb4 hergestellt werden.

Wie gesagt.

Wenn die Verbindung mit utf8mb4 erfolgt, aber die Tabellen eventuell nur teilweise in utf8mb4 aber einige "nur" in utf8 vorliegen, könnten Inkompatibilitäten auftreten.

Das wiederum schließen die gelesenen Artikel aus, da ...

Es bleibt daher zusätzlich zu prüfen, ob utf8 für MySQL ein echtes Subset von utf8mb4 ist

... diese Frage eindeutig mit ja beantwortet wird und ...

oder ob alle Tabellen und alle Textfelder umgestellt werden müssen.

... diese Fragestellung mit nein beantwortet werden kann. Es müssen nur die Felder, die UTF8 mit vier Byte speichern sollen, auf diese Kodierung umgerüstet werden.

Dabei sind aber ein paar Dinge zu beachten.

1. Der MySQL-Server

Der MySQL-Server muss mindestens in der Version 5.5.3 laufen. Vorher gab es schlicht kein utf8mb4.

2. Zugriff auf bestimmte Einstellungen

Es ist mehr als fraglich, ob ein Nutzerskript die Kodierung des Servers umstellen darf, wenn der Server nicht unter der Kontrolle des Forenbetreibers steht (Beispiel Shared Hosting). An der Stelle wäre ein Update nur möglich, wenn der Hoster das von sich aus oder auf Nachfrage so einrichtet.

3. unerwartete Einschränkungen

Ein Textfeld mit der Definition varchar(255) kann in einer 1-Byte-Kodierung (wie z.B. ISO-8859-15) 255 Schriftzeichen aufnehmen, verbraucht aber pro mehrbytigem Zeichen die entsprechende Anzahl von Stellen. Das heißt, dass schon jetzt bei Verwendung von außereuropäischen Schriftzeichen, die zwei oder drei Bytes einnehmen, nicht die erwartete volle Länge von 255 Zeichen zur Verfügung steht. Ein Betreff, nur aus Emojis bestehend, könnte bei einer Feldlänge von 255 nur aus maximal 63 Zeichen bestehen (255/4 = 63.75 ≈ 63).

Zudem beträgt die Länge eines Indexes für Tabellen vom Typ InnoDB bis MySQL 5.7 nur 768 Byte. Das entspricht nur der dreifachen Länge von varchar(256) und könnte im Zweifelsfall ein voll ausgenutztes Feld nicht im Index abbilden, wenn der Inhalt nur aus 4-bytigen UTF-8-Zeichen bestünde.

Meine Lektüre:

https://stackoverflow.com/questions/30074492/what-is-the-difference-between-utf8mb4-and-utf8-charsets-in-mysql#30074553
https://www.eversql.com/mysql-utf8-vs-utf8mb4-whats-the-difference-between-utf8-and-utf8mb4/
https://mathiasbynens.be/notes/mysql-utf8mb4
https://dev.mysql.com/doc/refman/5.7/en/charset.html

Tschö, Auge