Problem mit Unicode-Emojis (Bugs)

by Taurec, Tuesday, October 09, 2018, 06:00 (230 days ago)
edited by Taurec, Tuesday, October 09, 2018, 06:30

Hallo!

Wie mir von einem Forumsnutzer berichtet wurde, verstümmelt die Forumssoftware Beiträge, wenn darin Unicode-Emojis eingefügt werden.

In der Beitragsvorschau werden die Beiträge komplett und mit Unicode-Smilies angezeigt, nach dem Abschicken ist aber nur der Beitragstext vor den Smileys übertragen worden. Die Smileys selbst und sämtlicher darauf folgender Text gehen hingegen verloren.

Ich habe es eben hier im Sandboxthread versucht (Beitrag wieder gelöscht): derselbe Fehler, so daß ich ausschließen kann, daß es an meiner Installation der Forumssoftware liegt.

Nachdem auch Androidnutzer (zunehemend) die Foren nutzen und auf der dortigen Tastatur eine Smileyfunktion vorhanden ist, die Unicode-Emojis einfügt, sollte der Fehler bei Gelegenheit behoben werden.

Vielleicht ein Problem beim Übertragen exzentrischer Unicodes in die Datenbank? Da das Forum in UTF-8 kodiert ist, liegt wohl kein Problem mit dem grundsätzlichen Anzeigen der Smilies vor. Liegt es vielleicht daran, daß die Datenbank utf8_general_ci nutzt statt utf8_unicode_ci?

Man kann nie ausschließen, daß jemand auf die Idee kommt, Unicode-Emojis zu nutzen statt der forumseigenen Smilies. Womöglich hätte es gar Sinn, letztere komplett zugunsten der Unicode-Emojis abzuschaffen bzw. statt der grafischen ausgewählte Unicode-Smilies im Beitragsformular anzuzeigen, da diese offenbar nun zum Standard gehören. Es wurde hier ja schon in Zusammenhang mit der Responsive-Theme die Einführung von Smilies im SVG-Format diskutiert. Letztlich handelt es sich um nichts anderes.

Gruß
Taurec

Avatar

Problem mit Unicode-Emojis

by Auge ⌂ @, Tuesday, October 09, 2018, 07:47 (230 days ago) @ Taurec

Hallo!

Wie mir von einem Forumsnutzer berichtet wurde, verstümmelt die Forumssoftware Beiträge, wenn darin Unicode-Emojis eingefügt werden.

In der Beitragsvorschau werden die Beiträge komplett und mit Unicode-Smilies angezeigt, nach dem Abschicken ist aber nur der Beitragstext vor den Smileys übertragen worden. Die Smileys selbst und sämtlicher darauf folgender Text gehen hingegen verloren.

Vielleicht ein Problem beim Übertragen exzentrischer Unicodes in die Datenbank? Da das Forum in UTF-8 kodiert ist, liegt wohl kein Problem mit dem grundsätzlichen Anzeigen der Smilies vor. Liegt es vielleicht daran, daß die Datenbank utf8_general_ci nutzt statt utf8_unicode_ci?

Nee, ganz so ist es nicht. Die von dir genannten Angaben betreffen die Sortierung der Inhalte der so ausgezeichneten Spalten. Es geht aber [del]nicht[/del] um die Kodierung bei der Speicherung. Ich vermute, dass hier der Unterschied zwischen der Kodierung in utf8 und utf8mb4 zuschlägt. utf8 speichert, wie ich gerade noch einmal gelesen habe, nur ein-, zwei- und dreibytige Zeichen. Mit utf8mb4 kann man das volle Spektrum bis 4 Byte pro Zeichen ausschöpfen. Die Codepunkte der Smileys sind, soweit ich weiß, im 4-bytigen Bereich angesiedelt.

Ich werde mal probieren, ob es mit der passenden Kodierung funktioniert.

Man kann nie ausschließen, daß jemand auf die Idee kommt, Unicode-Emojis zu nutzen statt der forumseigenen Smilies. Womöglich hätte es gar Sinn, letztere komplett zugunsten der Unicode-Emojis abzuschaffen bzw. statt der grafischen ausgewählte Unicode-Smilies im Beitragsformular anzuzeigen, da diese offenbar nun zum Standard gehören.

Ich bin grundsätzlich offen dafür. Wir dürfen dabei aber nicht vergessen, dass es bei bereits laufenden Foren mit sehr hoher Wahrscheinlichkeit GIF- bzw. PNG-Smileys in Beiträgen gibt, man also darüber nachdenken muss, wie man damit umgeht (Mit Übersetzungstabelle in Schriftzeichen verwandeln? Durch SVG-Grafiken ersetzen?) als auch, wie man die Unicode-Smileys anbietet (Desktop: keine Smiley-Tastatur, Mobil: üblicherweise virtuelle Tastatur für Smileys vorhanden).

Es wurde hier ja schon in Zusammenhang mit der Responsive-Theme die Einführung von Smilies im SVG-Format diskutiert. Letztlich handelt es sich um nichts anderes.

Das ist schon etwas anderes. Das eine sind Schriftzeichen, das andere Grafiken. Gemeinsam ist beiden Wegen, dass die Smileys nicht aufpixeln, wenn man die Seite zoomt und das es eine nicht unwesentliche Änderung wäre.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Ergebnisse der ersten Tests

by Auge ⌂ @, Tuesday, October 09, 2018, 09:15 (230 days ago) @ Taurec

Hallo

Ich habe nun die ersten Recherchen und Tests hinter mir. Ganz so einfach scheint das nicht zu sein. Getestet habe ich mit folgender Hard- und Software:

- Samsung Smartphone, Lineage OS 14.1 (entspricht Android 7.1.2)
- virtuelle Tastatur: AnyKeyBoard (die Android-Stock-Tastatur, die von LineageOS benutzt wird, hat tatsächlich kein Smiley-Board)
- Webserver des Forums: Apache, PHP 7.1.22, MySQL 5.7.23

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

Wie in dem verlinkten StackOverflow-Thread in mehreren Einlassungen zu lesen ist, muss auch die Datenbankverbindung mit der Kodierung utf8mb4 hergestellt werden. Das konnte ich auf die Schnelle nicht im Code anpassen, ich habe ja auch noch etwas andere Arbeit auf dem Tisch. Es würde aber vermutlich erhebliche Umbauten an der Struktur der Datenbanktabellen erfordern. 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.

Es bleibt daher zusätzlich zu prüfen, ob utf8 für MySQL ein echtes Subset von utf8mb4 ist oder ob alle Tabellen und alle Textfelder umgestellt werden müssen. Wenn es dazu käme, wäre zu überlegen, ob es nicht günstiger wäre, neue Tabellen anzulegen und hernach mit den Daten aus den alten Tabellen zu füttern anstatt an den bestehenden Tabellen herumzumanipulieren.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Ergebnisse weiterer Recherchen

by Auge ⌂ @, Wednesday, January 30, 2019, 09:49 (117 days ago) @ Auge

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 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

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Tags:
feature request, 2.5

Avatar

Unicode-Emojis, es geht, Beweis mit MLF1 angetreten

by Auge ⌂ @, Saturday, April 27, 2019, 17:49 (30 days ago) @ Taurec

Hallo

Während meiner Tests für eine PHP-7-fähige Version von MLF1 habe ich auch ein paar Installationsversuche durchgeführt. Das förderte folgendes zutage.

- Der MySQL-Server meines Hostingpakets erstellt Text-Spalten (char, varchar, text) als utf8mb4, wenn nichts anderes angegeben wird – und das trifft auf MLF1 zu.
- Auch die Verbindung wird, wenn nichts anderes angegeben wurde – und das trifft auf MLF1 zu –, mit utf8mb4 hergestellt.
- Somit kann ich selbst in MLF 1.7.8 ohne weitere Handstände Emojis in betreff und Postingtext verwenden.

[image]

Das funktioniert nur so einfach, weil der Server von sich aus die passenden Vorgabewerte setzt und verwendet. Auf anderen Servern wird das nicht so einfach funktionieren, zumal MLF 2 ja explizite Angaben zur Kodierung der Spalten macht und auch die Datenbankverbindung mit UTF-8 (maximal 3-Byte-Zeichen) herstellt.

Zumindest ist schon mal sicher, dass die Umstellung der Felder und der Verbindungskodierung die Lösung ist.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

RSS Feed of thread
powered by my little forum