Installer nutzt nur MySQL's verkrüppeltes utf8, nicht das vollständige utf8mb4 (z.B. für emojis)

[ddpm@…]

Seit MySQL 5.5 beherrscht MySQL (und MariaDB sowieso) das vollständige UTF-8.

Das nennt sich bei MySQL utf8mb4. utf8 bei MySQL heisst dass es von UTF-8 nur den Teil bis 3Byte-Zeichen unterstützt. z.B. alle Emojis werden abgeschnitten/verhunzt.

Das Elend beginnt in _installer/install_step1.php

Da wird mit "DEFAULT CHARACTER SET utf8" der Default der gesamten aktuellen Datenbank überschrieben, auch wenn vorher vielleicht das üblicherweise korrekte "DEFAULT CHARACTER SET utf8mb4" gesetzt war. Das kann übel sein, wenn auf der gleichen DB noch andere Tabellen/Apps laufen.

Ebenso sollte die collation utf8mb4_general_ci sein anstatt utf8_general_ci.

[Torsten Riemer]

Welchen Mehrwert siehst du da? Chinesische und japanische Zeichen zu speichern oder gar Emojis?
Von "verküppeltem" UTF8 zu sprechen ist schon recht einfach gedacht. Es gab eben noch Zeiten, als UTF8 (UTF8mb3) ausreichte, da es sich nicht um 1853 (bzw. inkl. Varianten 3633) für ein Shopsystem völlig überflüssige Emoji aus Unicode 14.0 kümmern musste.
Soweit ich weiss wird auch mindestens MySQL 5.5.3 bzw. MariaDB 10.x vorausgesetzt.
Basic Multilingual Plane (BMP) deckt alle gebräuchlichen Zeichen (55.632 an der Zahl) ab.

Siehe dazu:

• ​Unicode - Gliederung
• ​Plane (Unicode)

[anonymous]

Für den Fall, dass in der gleichen DB noch andere Tabellen/Apps (z.B. Blog) laufen, die z.B. Emojis nutzen. Im Zeitalter der mobilen Nutzung dürften auch die Bewertungen inzwischen gespickt mit Emojis sein. Bewertungen sind im Shop möglich.

[Torsten Riemer]

Wieso sollte man auf die Idee kommen mehrere CMS in nur eine Datenbank zu packen bei den heutigen günstigen Preisen für Webhosting mit zig enthaltenen Datenbanken?
Die bisherigen Argumente sind für mich nicht überzeugend.

[ddpm@…]

Fehlervermeidung

---

Alle anderen Datenbanken nutzen vollständiges UTF-8. Nur MySQL hat halt diese Extrawurst gefahren. Stell dir eine Warenwirtschaft (z.B. MS SQL oder PostgreSQL) vor, in der Artikel und Hersteller gepflegt werden und nach Abgleich zum Shop sind anstatt der enthaltenen emojis Fragezeichen oder ähnlicher Müll in den Shoptexten, weil Mysql einfach das letzte Byte nicht speichert sondern einfach abhackt und keine Warnung oder Fehlermeldung spuckt.

Einfach mal ein Emoji bei einer Herstellerbeschreibung einfügen und das Ergebnis anschauen.

Das schützt einfach vor nervigen bösen Überraschungen.

Man kann sicher über die Sinnhaftigkeit von emojis diskutieren, sie sind aber nunmal da und weltweit verbreitet und von den großen Playern gepusht worden.

Die emojis sind auf den heutigen Geräten nur einen Fingertipp entfernt und wenn auch Kunden Texte schreiben können (Bewertungen, Kommentar bei Bestellung) sind emojis sicher keine Ausnahme wenn sie auf dem Handy schreiben.

[ddpm@…]

Mit verkrüppelt meine ich, dass ein 4Byte utf-8 Zeichen einfach abgeschnitten wird wenn es in ein MySQL 3Byte utf8-Feld geschrieben wird. Der DB-Eintrag enthält dann quasi Datenmüll.

[ddpm@…]

Dazu gerade passend: ​https://news.ycombinator.com/item?id=29907551

​https://github.com/mysql/mysql-server/commit/43a506c0ced0e6ea101d3ab8b4b423ce3fa327d0

[snocer]

Replying to Tomcraft:

Wieso sollte man auf die Idee kommen mehrere CMS in nur eine Datenbank zu packen bei den heutigen günstigen Preisen für Webhosting mit zig enthaltenen Datenbanken?
Die bisherigen Argumente sind für mich nicht überzeugend.

Dafür kann es mehrere Gründe geben, zum Beispiel auch eine gemeinsame "user_table", Rechteverwaltung etc.

Das machen sogar große WaWi`s und bieten das wahlweise an, neuer Mandant in neue DB oder in vorhandene DB, um zum Beispiel den bereits vorhanden Artikelstamm des Mand1 auch im Mand2 nutzen zu können ohne aufwendigen Im- und Export oder um die Datensätze in allen Mandanten konstant zu halten usw.