Dienstag, 4. Mai 2021
Fehlende utf8mb4-Emojis nach Hosting-Migration
Am 29.04.2021 migrierte Hosttech mein Hostingpaket auf eine neue Serverumgebung.
Dieser Beitrag dient dazu, das Problem der fehlenden utf8mb4-Emojis darzustellen, welche vor der Migration alle sichtbar waren, nach der Migration aber zu 99% nur noch als "?" angezeigt werden.
Hier 10 utf8mb4-Emojis hintereinander: ??????????.
Nach der Migration geschrieben und soweit korrekt dargestellt. So sieht dieser Abschnitt in der Datenbank aus:
<p>Hier 10 utf8mb4-Emojis hintereinander: ??????????</p>
Im Vergleich dazu dieser Beitrag vom 08.01.2020. Nach dem Wort "Zauberhand" wird ein einziges utf8mb4-Emoji dargestellt. Alle anderen fehlen, respektive werden auch im Frontend nur noch als "?" dargestellt. Die anderen sichtbaren Emojis sind Serendipity-interne und haben nichts mit utf8mb4 zu tun (siehe z.B. :bow). So sieht der entsprechende Abschnitt in der Datenbank aus:
<p>? <strong>und wie durch Zauberhand! </strong>✨ <strong>Schon implementiert!</strong> ? ? ? Vielen Dank! :bow:</p>
Bei der nächsten Support-Anfrage werde ich diesen Beitrag verlinken. Vielleicht hilft es ja... ?
Dieser Link ist nicht aktiv. Er enthält eine kopierbare Trackback-URI, um manuell ein Ping- und Trackback zu diesem Eintrag für ältere Blogsysteme zu generieren; zB (immer noch valide) über das zur Verfügung gestellte Eintragsfeld des serendipity_event_trackback Plugins. Serendipity und andere Blogsysteme erkennen die Trackback-URL heutzutage aber automatisch anhand der Artikel-URL. Die Trackback-URI für ihren Link des Sender-Eintrages lautet daher wie folgt: »https://www.blog.dokumenzi.ch/2659-Fehlende-utf8mb4-Emojis-nach-Hosting-Migration.html«
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Ian Styx am :
Nur zur Klarstellung:
Die jetzt fehlenden bzw durch ? platzierten Emojis beziehen ihre Daten aus dem stark erweiterten Unicode Raum.
Das Sternenglitzer ✨ aber und zb auch das irische Kleeblatt ☘ befnden sich schon im einfach erweiterten Unicode Raum. An diese Räume wird noch heute fortwährend angedockt, deswegen auch gibt es so viele unterschiedliche Unicode Implementierungen. Die ;-( Ersetzungen sind keine Emojis im eigentlichen Sinne, sondern Emoticons, bestimmte Zeichenfolgen aus ASCII-Zeichen, die mit kleinen vorgefertigte Bildchen durch eine runtime regex ersetzt werden.
Meine Verständnis dieser (unvollständigen) Migration war eben, dass der Datenbank Dump zur Migration durch deinen Hoster keinen vollständigen Unicode Satz benutzt hat. Wenn die alte Datenbank auf dem alten Server nicht mehr original vorliegt ist da wohl auch nichts mehr zu machen und all unsere schönen Mimiken sind perdu!
Beat Post author am :
Dann stellt sich mir die Frage, was ich denn nun lieber will:
Falls ein 29.04.-Backup vorliegt, dass dieser eingespielt wird und wir dadurch alles verlieren, was wir hier danach geschrieben haben (2 Artikel und 36 Kommentare)
oder so lassen und daraus lernen, dass bei einer angekündigten Servermigration von meiner Seite aus ein DB-Backup gemacht werden muss, den ich gegebenenfalls nach der Migration selbst wieder einspielen kann.
Ian Styx am :
Beides! Lernen und vervollständigen. Denn das neue seit ein paar Tagen ließe sich durch ein schnelles Backup sicherlich retten und aufgepropft zurückspielen,
Das sollte es auch gar nicht sein, denn ein Backup wäre ja auch schon irgendwie gezogen, mit der Unsicherheit das der ganze Salat sich wiederholt. Es müsste sozusagen deine alte DB auf dem alten Server sein. damit man von dort mit dem richtigen Tool (*) eine korrekten Dump erstellen kann.
(*) PhpMyAdmin kann das, siehe beispielhaft
Das mit dem "notwendigen" Backup ist ein Erfahrungswert, der wohl jetzt erst beginnt vemehrt Daten zu liefern. Schaffen es Hoster darauf professionell Rücksicht zu nehmen ohne das man es ihnen extra sagen muss. Wir wissen ja zB auch nicht ob es tatsächlich ein Dump war. Vielleicht spielen da Dateisysteme und Ähnliches auch noch eine Rolle, bzw irgendwelche Zwischenablagen, angemessene Dateiformate, Editoren, etc..
Ian Styx am :
Nanu ????