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:
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).
Änderung der SuiteCRM DB (probiere das am besten erst in einem Test-System, ob es zu Problemen kommt).
Ja, wir haben den Zeichensatz auch auf Feldebene geändert. Hat auch nichts gebracht.
Jetzt versuchen wir herauszubekommen welche Kodierung die Eingangsdaten haben …
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.
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’)
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.