k3n_dvemoji für TYPO3: Emoji-Support & UTF-8mb4-Migration

Emojis als Fragezeichen sind kein Darstellungsproblem, sondern ein Datenbank-Konfigurationsfehler

Wenn in einem TYPO3-Backend ein Redakteur ein Emoji eingibt und im Frontend stattdessen ein Fragezeichen oder ein leeres Kästchen erscheint, liegt das Problem nicht im Browser und nicht in TYPO3. Es liegt in der MySQL- oder MariaDB-Datenbank, die mit dem Zeichensatz utf8 statt utf8mb4 konfiguriert ist. Der Unterschied: utf8 speichert maximal 3 Bytes pro Zeichen, Emojis brauchen 4 Bytes. k3n_dvemoji ist eine TYPO3-Extension, die dieses Problem adressiert, indem sie die Datenbank-Konfiguration um UTF-8mb4-Support erweitert. Seit TYPO3 v10 ist der Core allerdings selbst auf utf8mb4 vorbereitet, sodass die Extension nur noch bei älteren oder falsch konfigurierten Installationen nötig ist.

Für TYPO3-Administratoren und Agenturen, die ältere Installationen betreuen, ist k3n_dvemoji ein Diagnosewerkzeug und ein Fix zugleich. Die Extension identifiziert Tabellen mit falschem Zeichensatz und konvertiert sie, was manuell ein fehleranfälliger Prozess ist.

Typische Einsatzszenarien betreffen ältere Installationen, Migrationen und internationale Inhalte

Das häufigste Szenario ist eine TYPO3-v8- oder v9-Installation, die seit Jahren läuft und deren Datenbank noch auf utf8 (nicht utf8mb4) konfiguriert ist. Schätzungsweise 30% aller TYPO3-Installationen, die vor 2018 eingerichtet wurden, haben dieses Problem, weil die Installationsroutine damals utf8 als Standard setzte. Solange Redakteure nur lateinische Zeichen verwenden, fällt das nicht auf. Sobald ein Social-Media-Post mit Emoji auf der Website eingebettet wird oder ein Redakteur ein Emoji in eine Überschrift setzt, bricht die Darstellung. k3n_dvemoji konvertiert die betroffenen Tabellen und Spalten auf utf8mb4.

Zweites Szenario: Datenbank-Migrationen zwischen Servern. Beim Umzug einer TYPO3-Datenbank von einem alten Server auf einen neuen kann der Zeichensatz durch einen fehlerhaften mysqldump-Befehl verloren gehen. Ein Dump mit —default-character-set=utf8 statt utf8mb4 schneidet alle 4-Byte-Zeichen ab. k3n_dvemoji hilft bei der nachträglichen Reparatur.

Drittes Szenario: Internationale Websites mit asiatischen Sprachen. Chinesische, japanische und koreanische Schriftzeichen benötigen teilweise 4 Bytes. Ohne utf8mb4 werden einzelne Zeichen verstümmelt dargestellt, was bei CJK-Content-Seiten zu unlesbarem Text führt. Auch mathematische Symbole, Musiknoten und diverse Sonderzeichen aus dem Unicode-Bereich oberhalb von U+FFFF sind betroffen, was für Hochschul-Websites und wissenschaftliche Portale relevant ist.

Technische Architektur analysiert und konvertiert Datenbank-Tabellen auf Spaltenebene

k3n_dvemoji arbeitet auf zwei Ebenen: Analyse und Konvertierung. Im Analyse-Modus scannt die Extension alle TYPO3-Tabellen und prüft den Zeichensatz jeder Spalte. Das Ergebnis ist ein Report, der zeigt, welche Tabellen und Spalten noch auf utf8 (3 Byte) statt utf8mb4 (4 Byte) stehen. Ein typisches TYPO3-System hat 100 bis 300 Tabellen, von denen oft 20 bis 50 einen falschen Zeichensatz aufweisen.

Im Konvertierungs-Modus generiert die Extension ALTER TABLE Statements für jede betroffene Spalte und führt sie aus. Das klingt trivial, hat aber Fallstricke: Indizes auf varchar-Spalten mit utf8mb4 können die maximale Index-Länge von MySQL überschreiten (767 Bytes bei InnoDB mit antique format). Die Extension prüft diese Limits und passt die Index-Definitionen an.

Zusätzlich muss die TYPO3-Konfiguration in LocalConfiguration.php den Zeichensatz utf8mb4 deklarieren: ['DB']['Connections']['Default']['charset'] = 'utf8mb4' und ['DB']['Connections']['Default']['tableoptions']['collate'] = 'utf8mb4_unicode_ci'. Ohne diese Konfiguration nutzt TYPO3 weiterhin utf8 für neue Tabellen.

Häufige Probleme sind Index-Längenbeschränkungen, Backup-Fehler und inkonsistente Spalten

Problem eins: MySQL-Index-Längenbeschränkung. Bei InnoDB mit dem alten Compact-Format (Standard bis MySQL 5.6) ist die maximale Index-Länge 767 Bytes. Ein varchar(255) mit utf8mb4 braucht 1.020 Bytes Index-Platz. Die Konvertierung scheitert mit “Specified key was too long”. Die Lösung: ROW_FORMAT auf DYNAMIC umstellen (Standard ab MySQL 5.7) oder die varchar-Länge in den betroffenen Spalten reduzieren.

Problem zwei: Backup vor der Konvertierung. Ein ALTER TABLE auf grossen Tabellen (100.000+ Zeilen) sperrt die Tabelle und kann bei Produktionsdatenbanken zu Ausfällen führen. Die Lösung: Konvertierung ausserhalb der Geschäftszeiten durchführen und vorher ein vollständiges Backup erstellen. Bei grossen Tabellen empfiehlt sich pt-online-schema-change von Percona für eine lockfreie Konvertierung.

Problem drei: Inkonsistente Spalten nach teilweiser Konvertierung. Wenn nur Teile der Datenbank konvertiert wurden, können JOINs zwischen utf8- und utf8mb4-Spalten zu Performance-Problemen führen, weil MySQL eine implizite Zeichensatz-Konvertierung durchführt. Gosign prüft nach jeder Konvertierung alle Tabellen auf Konsistenz.

Ab TYPO3 v10 ist die Extension überflüssig, wenn die Datenbank korrekt konfiguriert ist

TYPO3 v10 und alle folgenden Versionen erwarten utf8mb4 als Standard-Zeichensatz. Bei einer Neuinstallation mit v10 oder höher wird die Datenbank automatisch korrekt konfiguriert, und k3n_dvemoji ist nicht nötig. Die Extension bleibt relevant für Installationen, die von v7, v8 oder v9 auf v12 oder v13 migriert werden und deren Datenbank noch nie konvertiert wurde. Gosign löst das im Rahmen jeder TYPO3-Migration automatisch mit: KI-gestützter Datenbank-Scan, vollständige Konvertierung und Konsistenz-Check als Teil des Standard-Upgrade-Prozesses. Der Scan analysiert alle Tabellen und Spalten in unter 5 Minuten, generiert die nötigen ALTER TABLE Statements und führt sie in einer Transaktion aus, sodass bei einem Fehler der vorherige Zustand wiederhergestellt werden kann. Das Ergebnis ist eine Datenbank, die utf8mb4 durchgängig unterstützt, ohne dass eine Extension im Betrieb nötig ist.