Andere Nachrichten mit einem Nicht-UTF-8-Zeichensatz, z. B. iso-8859-1, werden korrekt importiert.
Bevor ich versuche, die Ursache des Problems zu finden, indem ich den Quellcode untersuche, beginnend mit script/import_scripts/mbox/support/indexer.rb, hat jemand eine Idee? Könnte es ein Umgebungsproblem sein und nicht im Code vorhanden? Tritt dies auch auf, wenn ein Benutzer im Mailinglisten-Modus eine Antwort mit dieser Kodierung sendet?
Ich habe einen kurzen Test durchgeführt, und Email::Receiver scheint einwandfrei zu funktionieren. Es wandelt die Eingabe in UTF-8 um. Ich kann mir keinen Grund vorstellen, warum die Kodierung danach falsch sein sollte.
[1] pry(main)> raw_email = File.read("/tmp/windows.txt");
[2] pry(main)> receiver = Email::Receiver.new(raw_email, convert_plaintext: true, skip_trimming: false);
[3] pry(main)> body = receiver.select_body;
[4] pry(main)> receiver.mail.charset
=> "windows-1252"
[5] pry(main)> body.first.encoding
=> #<Encoding:UTF-8>
[6] pry(main)> puts body.first;
cette réflexion me fait penser : y\-a\-il une obligation/raison \(en dehors du coup de maintenannce\) à avoir un même outil pour les 2 fonctionnalités \(interactions vs galerie\) ?
Danke für den schnellen Test: Ich wüsste selbst nicht, wie ich das machen soll Könnte es sein, dass im Import-Container etwas fehlt? Ich würde sehr gerne nachvollziehen, was du gemacht hast, und von dort aus weiterforschen. Falls ich nichts finde, werde ich Anweisungen bereitstellen, um das Problem mit dem mbox-Importverfahren zu reproduzieren, wobei der Posteingang nur diese eine E-Mail enthält.
Ich erhalte die gleichen Ergebnisse wie du, also liegt das Problem nicht dort. Ich führe einen Import nur mit dieser E-Mail und einer neuen Kategorie durch, um zu überprüfen, ob dies keine Nebenwirkung ist.
Oder der Unterschied liegt darin, wie die Nachricht aus der mbox-Datei extrahiert wird: Hier weicht der Codepfad ab. Das oben gezeigte raw_email = File.read("/tmp/windows.mbox") unterscheidet sich vom Aufteilen der Datei mit regulären Ausdrücken, und vielleicht liegt hier der Fehler.
Und tatsächlich erzeugt das Hinzufügen von File.open('/tmp/message.txt', 'w') { |file| file.write(receiver.raw_email) } nach dieser Zeile die folgende Datei, die sich von der Originaldatei unterscheidet.\n\nmessage.txt (3,7 KB)\n\nBeim Ausführen in der Rails-Konsole ist receiver.raw_email ebenfalls von der Originaldatei verschieden: Sie ist korrekt als UTF-8 kodiert.\n\nHaben Sie eine Idee, wo diese falsche Änderung stattfindet?
Es kann sein, dass Sie nach dem Lesen der Datei einen Aufruf von .force_encoding hinzufügen müssen, um Ruby mitzuteilen, welche Kodierung die E-Mail-Datei hat.
Entschuldigung, falls das eine Anfängerfrage ist, aber ich bin mit der Codebasis nicht vertraut Hast du einen Vorschlag, wo eine solche Änderung sinnvoll wäre?
Nachdem wir eingegrenzt haben, wo die unerwünschte Transformation stattfindet, scheint es hier zu sein:
line.scrub ist dafür verantwortlich, den Inhalt in etwas zu verwandeln, das sich vom Original unterscheidet. Wenn dies entfernt wird, schlägt der reguläre Ausdruck mit folgendem Fehler fehl:
...
1: from /var/www/discourse/script/import_scripts/mbox/support/indexer.rb:174:in `block in each_mail'
/var/www/discourse/script/import_scripts/mbox/support/indexer.rb:174:in `=~': invalid byte sequence in UTF-8 (ArgumentError)
Denn es ist nicht UTF-8, tatsächlich
Haben Sie eine Idee, wie dies gelöst werden sollte? Vielleicht ein erster Durchgang nur durch die E-Mail-Header, um nach dem Zeichensatz zu suchen? Hier scheint ein -und--Problem vorzuliegen.
-und-
-Problem vorzuliegen.