MySQL error 1366 bei Importieren von Emails

Hallo,

wir nutzen Versionen 7.10.7 Sugar Versionen 6.5.25 (Build 344).

Emails von immobilienscout24.de werden nicht importiert. Es gibt den Fehler:
Datenbank Fehler. Bitte sehen Sie sich dazu die Datei suitecrm.log an.

Da steht dann:
MySQL error 1366: Incorrect string value: ‘\xF0\x9F\x91\x8D" …’ for column suitecrm.emails_text.description_html at row 1

Was können wir tun, damit auch die HTML Email von immobilienscout24.de importiert wird?

Ich habe unter Reparatur den Punkt [Schnellreparatur und Neuaufbau] eusgeführt, es hat nichts gebracht.

Hallo Peter,

ich schätze das liegt an der Zeichenkodierung, die in die DB geschrieben werden soll.
Der Sender schickt Zeichen, die in der DB nicht gespeichert werden können.
Da gibt es zwei Lösungsansätze:

  1. Transcodieren der E-Mails (ist recht aufwändig: Ihr nutzt eine Art Middleware die die E-Mails vom Server abholt, transcodiert und dann in die SuiteCRM DB schreibt. Habe ich in einem ähnlichen Projekt gemacht - das kann viel Aufwand darstellen, wenn alles Mögliche abgefangen werden soll).
  2. Änderung der SuiteCRM DB (probiere das am besten erst in einem Test-System, ob es zu Problemen kommt).

Infos zu UTF-8: UTF-8 – Wikipedia
Problem und Lösungsweg für das DB Update: "Incorrect string value" when trying to insert UTF-8 into MySQL via JDBC? - Stack Overflow

Wir haben bereits den Zeichensatz von utf8 nach utf8mb4_general_ci geändert. Hat leider nichts gebracht.
Welchen Zeichensatz sollten wir wählen?

Habe nun in die mysql.cnf Datei das folgende eingefügt, der db server neu gestartet, aber ist immer noch der selbe fehler …

[mysql]
default-character-set=utf8mb4

[mysqld]
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci

Habt ihr auch den Zeichensatz auf Feldebene geändert?

ALTER TABLE `emails_text` CHANGE `description_html` `description_html` LONGTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL;

Die richtige Kodierung hängt allerdings von euren Eingangsdaten ab.
Versuche herauszufinden, wie diese kodiert sind.

Unter Python nutze ich dafür Chardet chardet · PyPI
(funktioniert auch gut für E-Mail Daten/Content)

Online habe ich das noch nicht getestet, aber schau mal ob sowas hilft:
https://www.webatic.com/encoding-explorer

Ja, wir haben den Zeichensatz auch auf Feldebene geändert. Hat auch nichts gebracht.
Jetzt versuchen wir herauszubekommen welche Kodierung die Eingangsdaten haben …

Der Zeichensatz der Email ist utf-8 laut diesem tool hier:

folgendes wurde versucht:

der zeichensatz der tabellenspalte wurde angepasst.
die mysql.conf wurde geändert:
[mysql]
default-character-set=utf8mb4

[mysqld]
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci
init_connect='SET NAMES utf8mb4'

der server wurde neu gestartet.
der zeichensatz der email, die nicht importiert werden kann wurd als utf-8 erkannt.

trotzdem erscheint weiter die Fehlermeldung:

MySQL error 1366: Incorrect string value: ‘\xF0\x9F\x91\x8D" …’ for column suitecrm.emails_text.description_html at row 1

gibt es einen cache? muss der server neu gestartet werden?

Du kannst versuchen den Server neu zu starten (hast du die DB neu gestartet?) aber ich denke nicht, dass das hilft.

Ich würde mich nicht auf die Erkennung verlassen.
Versuche mal den Text manuell nach UTF zu konvertieren mit z. B.: PHP: utf8_encode - Manual
oder online Konvertern.

Du kannst auch einen Texteditor verwenden wie Notepad++ unter Windows etwa.
Die Erkennung von Textkodierungen ist nicht 100% zuverlässig und kann ab und an daneben liegen.

Das aktuelle Problem scheint bei einem Icon aufzutreten (thumbs up sign)

es kann, gerade bei E-Mail Daten, aber ständig wieder vorkommen, auch in anderen Formen.

Hier:

schlägt einer vor, die Spalte in einen blob umzuwandeln.
Könnte funktionieren aber ich würde da eher nach einer Middleware suchen, die Daten vor dem Import validiert und transformiert.

Ich hatte die DB neu gestartet, den apache server auch.
Wenn ich die nicht-importierbare .eml Datei in Notepad++ öffne steht unten rechts UTF-8.
Die Spalte in einen blog umzuwandeln ging nicht, Error #1406 Daten zu lang. Da müsste ich erst Einträge löschen.

Probier mal die eml zu öffnen, speichern und wieder nach IMAP zu importieren.
Es kann sein, dass Notepad++ da eine Konvertierung vornimmt und korrekt speichert. (Evtl. kannst du den Text testweise so in die DB schreiben - dann siehst du besser, wo genau das Problem liegt).

Falls blob zu kurz ist gibt es noch den medium- und longblob Datentyp.

Ich befürchte aber, ohne die Rohdaten stochere ich hier im Dunkeln.
Zeichenkodierung ist ein ganz klassisches Problem bei Datenmigration und oft muss man es ein paar Mal versuchen, bis es klappt.

ich habe die .eml in notepad geöffnet und erneut gespeichert, dann die email weitergeleitet zum crm und wieder versucht zu importieren. gleicher fehler.

ich versuche als nächstes die daten per phpmyadmin in die db zu schreiben.

ich habe hier etwas gefunden:

The client usually sets these values when connecting. The settings in my.ini are merely defaults which apply when the client does not explicitly specify a connection encoding. Since they’re unreliable, every client should specify a connection encoding. Since you’ve got some fancy screenshot there I’ll guess that you’re connecting with some GUI utility which probably explicitly does set some connection encodings.

PHP example of setting a connection charset:
new PDO(‘mysql:host=localhost;charset=utf8mb4’)

Kann man das bei SUITE CRM irgendwo angeben?

die config.php anpassen hat auch nichts gebracht:

Lässt sich der Text über phpMyAdmin o. Ä. in die Tabelle schreiben?

Wenn ich die .eml in Notepad öffne, den Quelltext in phpmyadmin ins feld email_text.description_html einfüge wird er auch in die DB geschrieben.

Was passiert, wenn du den Quelltext im Mail Client direkt kopierst und in die DB einfügst (ohne Umweg über Notepad++)?

dann wird der Quelltext auch in die DB geschrieben.

ich habe gelesen, dass der init_connect='SET NAMES utf8mb4 nicht ausgeführt wird wenn root den mysql server neu startet. also habe ich eine user angelegt und mit diesem den mysql server neu gestartet. leider hat es auch nichts gebracht.

habe das feld description_html in einen mediumblob umgewandelt. jetzt geht der import.

1 Like